Хороший стиль кодирования на Haskell блока управления if / else?
final Map<String,String> params = new HashMap<String,String>();
params.put("email", customer.getEmail());
params.put("password", customer.getPassword());
String url = Constants.BASE_URL+"login";
doWebRequestPost(url, params);
public void doWebRequestPost(String url, final Map<String,String> json){
getmDialogListener().showDialog();
StringRequest post = new StringRequest(Request.Method.POST, url, new Response.Listener<String>() {
@Override
public void onResponse(String response) {
try {
getmDialogListener().dismissDialog();
response....
} catch (Exception e) {
e.printStackTrace();
}
}
}, new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {
Log.d(App.TAG,error.toString());
getmDialogListener().dismissDialog();
}
}){
@Override
protected Map<String, String> getParams() throws AuthFailureError {
Map<String,String> map = json;
return map;
}
};
App.getInstance().getRequestQueue().add(post);
}
8 ответов
Стиль Хаскелла функциональный, а не обязательный! Вместо того, чтобы "делать то, что нужно", подумайте об объединении функций и описании того, что ваша программа будет делать, а не как.
В игре ваша программа запрашивает у пользователя догадку. Правильное предположение - победитель. В противном случае пользователь повторяет попытку. Игра продолжается до тех пор, пока пользователь не угадает правильно, поэтому мы пишем, что:
main = untilM (isCorrect 42) (read `liftM` getLine)
Используется комбинатор, который многократно запускает действие (getLine тянет строку ввода и read преобразует эту строку в целое число в данном случае) и проверяет ее результат:
untilM :: Monad m => (a -> m Bool) -> m a -> m ()
untilM p a = do
x <- a
done <- p x
if done
then return ()
else untilM p a
Предикат (частично примененный в main) сверяет догадку с правильным значением и отвечает соответственно:
isCorrect :: Int -> Int -> IO Bool
isCorrect num guess =
case compare num guess of
EQ -> putStrLn "You Win!" >> return True
LT -> putStrLn "Too high!" >> return False
GT -> putStrLn "Too low!" >> return False
Действие, которое будет выполняться до тех пор, пока игрок не угадает правильно, равно
read `liftM` getLine
Почему бы не сделать его простым и просто не составить две функции?
*Main> :type read . getLine
<interactive>:1:7:
Couldn't match expected type `a -> String'
against inferred type `IO String'
In the second argument of `(.)', namely `getLine'
In the expression: read . getLine
Типом getLine является IO String, но read хочет чистую String.
Функция liftM из Control.Monad берет чистую функцию и "поднимает" ее в monad. Тип выражения многое говорит нам о том, что оно делает:
*Main> :type read `liftM` getLine read `liftM` getLine :: (Read a) => IO a
Это действие ввода/вывода, которое при запуске возвращает нам значение, преобразованное с помощью read, в нашем случае Int. Вспомните, что readLine - это действие ввода/вывода, которое дает значения String, поэтому вы можете подумать, что liftM позволяет нам применить read "внутри" IO monad.
Sample game:
1 Too low! 100 Too high! 42 You Win!
Можно использовать "случай" - конструкция:
doGuessing num = do
putStrLn "Enter your guess:"
guess <- getLine
case (read guess) of
g | g < num -> do
putStrLn "Too low!"
doGuessing num
g | g > num -> do
putStrLn "Too high!"
doGuessing num
otherwise -> do
putStrLn "You Win!"
-
1Если камера калибруется, я думаю, получая фактическое расстояние, должно быть возможным, не только относительное расстояние. – Hannes Ovrén 26 January 2010 в 09:22
Незначительное улучшение оператора выбора mattiast (я отредактировал бы, но я испытываю недостаток в карме) должно использовать сравнить функцию, которая возвращает одно из трех значений, LT, GT или EQ:
doGuessing num = do
putStrLn "Enter your guess:"
guess <- getLine
case (read guess) `compare` num of
LT -> do putStrLn "Too low!"
doGuessing num
GT -> do putStrLn "Too high!"
doGuessing num
EQ -> putStrLn "You Win!"
мне действительно нравятся эти вопросы о Haskell, и я поощрил бы других отправлять больше. Часто Вы чувствуете, что существует , заставил быть лучшим способом выразить то, что Вы думаете, но Haskell является первоначально столь внешним, что ничто не придет на ум.
вопрос о Премии для Haskell journyman: каков тип doGuessing?
-
1Я предполагаю you' ре прямо об этом являющийся возможным в принципе, но you' ре также прямо об объеме. Откровенно говоря, даже пространственный параллакс doesn' t звучат как все это легкое осуществить на практике. Pontiac6000fan' s предложение об использовании датчика расстояния (сверхзвуковой или радар или безотносительно) начинает звучать хорошим мне. I' ll идут, бросают их upvote. – Steven Sudit 25 January 2010 в 21:26
Можно также использовать явную группировку с фигурными скобками. Посмотрите раздел расположения http://www.haskell.org/tutorial/patterns.html
, я не рекомендовал бы это все же. Я никогда не видел, что любой использует явную группировку, кроме того, в нескольких особых случаях. Я обычно смотрю Стандартный код Вводной части для примеров стиля.
-
1Если Сцена не compleely однородный (думайте, управляя в абсолютно белой арктической среде), тогда возможно получить adisplacement карту каждого пикселя и оттуда получить расстояние. – Hannes Ovrén 26 January 2010 в 09:21
Я использую стиль кодирования как Ваш пример из Викиучебника. Несомненно, это не следует инструкциям C, но Haskell не C, и это довольно читаемо, особенно как только Вы привыкаете к нему. Это также сделано по образцу стиля алгоритмов, используемых во многих учебниках, как Cormen.
-
1На самом деле, на уровне реализации, ссылки обычно указатели на память, содержащую объект. ОДНАКО нет никакого способа, которым обычная программа Java может " посмотрите позади curtain" и используйте ссылки в качестве подобных C указателей. – Stephen C 13 April 2010 в 12:23
Обратите внимание, что то, что необходимо сделать отступ 'тогда' и 'еще' в, 'действительно' блокируется, считается ошибкой многими. Это будет, вероятно, зафиксировано в Haskell' (главный Haskell), следующая версия спецификации Haskell.
-
1Вы правы. но можно всегда использовать его для указания на что-то на самом механизме, который является известным расстоянием далеко; таким образом, у Вас есть масштабный коэффициент! – Egon 29 January 2010 в 02:07
Путь Haskell интерпретирует , если ... Тогда ... else в DO Блок очень придерживается всего синтаксиса Haskell.
Но многие люди предпочитают немного другой синтаксис, позволяющий затем и иначе , чтобы появиться на одном уровне вдавливания, что и соответствующее , если . Следовательно, GHC поставляется с выдвижением языкового отказа под названием doadifthenelse , что позволяет этот синтаксис.
Расширение doadiftenelse продление входит в часть ядра основного языка в последнем пересмотре спецификации Haskell, Haskell 2010 .
Похоже, вам нужно использовать локальное уведомление:
и
— 121---1937840-Вы увидите множество различных стилей отступов для Haskell. Большинство из них очень сложно поддерживать без редактора, настроенного на создание отступов в любом стиле.
Стиль, который вы показываете, намного проще и менее требователен к редактору, и я думаю, вам следует его придерживаться. Единственное несоответствие, которое я вижу, заключается в том, что вы помещаете первую команду do в отдельную строку, а остальные команды размещаете после then/else.
Прислушайтесь к другому совету о том, как думать о коде на Haskell, но придерживайтесь своего стиля отступов.