LINUX.ORG.RU

Почему скобки удобны

 , ,


0

2

Пишу вот я код на F# и приходится мне помнить порядок вычисления, когда он не важен мне совершенно, поэтому беру я и указываю явно, чтобы другие не утруждались, кто код мой будет потом читать, смотрю, а получается как на лиспе. Вот пример, когда скобки удобнее, помнить надо меньше.

        (stage1 
            @ (free |> List.map (fun l -> l, [l]))) //причинное место
        |> List.groupBy 
            (fun (mline1, lines1) (mline2, lines2) ->
                Math.Abs(mline1.x-mline2.x) < 0.1 
                && Math.Abs(mline1.y-mline2.y) < 0.1)
       (List.groupBy 
	(lambda (mline1 lines1 mline2 lines2)
	  (and (< (Math.Abs (- mline1.x mline2.x) 0.1))
	       (< (Math.Abs (- mline1.y mline2.y) 0.1))))
	(@ stage1 
	   (List.map (lambda (l) (list l (list l))) 
		     free)))))

Ответ на: комментарий от qnikst

Если устранение скобок поставить самоцелью, то в таком случае f2 a `f1` f3 b :)

motto ()

2 замечания отвлечённо от приведённого ТС примера

1) вообще-то скобки вредят пониманию любого кода, потому как указывают на «иной приоритет» операций.

2) подсветка синтаксиса кода в LOR просто ужасна. Я за то чтобы её отключить - пусть останется просто <pre> monospace на чуть другом фоне, чем то что есть.

MKuznetsov ★★★★★ ()
Ответ на: комментарий от motto

Я же говорю хороших :), подозреваю что ещё можно через functor /cofunctor для функции.

qnikst ★★★★★ ()
Ответ на: комментарий от deterok

Наверное, это потому, что в языках с ~ одинаковой выразительностью типовой код будет иметь примерно одинаковое количество блоков/подпрограмм/выражений, которые надо как-то обозначать и отделять друг от друга. И здесь кроме скобок и индентов ничего не придумали.

Virtuos86 ★★★★★ ()
Ответ на: комментарий от qnikst

Ты пытаешься доказать, что оба куска кода дают одинаковый результат. Никто и не спорит. Но одинаковый результат != «код делает одно и то же». Семантика у кода разная. Точно так же, например, разные вещи 1+1 и 2.

anonymous ()
Ответ на: комментарий от anonymous

Я показал (хотя строго не доказал для случая _|_), что денотационная семантика у данных функций одинакова; более того в большинстве случаев компилятор выдаст один и тот же код уже на уровне core (при включенных оптимизациях), несмотря на то, что ($) должен выдавать лишний thunk/или функцию, а (.) создавать функцию являющуюся композицией функций аргументов. Про какую семантику говоришь ты?

При этом я не спорю, что репрезентационно данные функции несут разную нагрузку.

P.S. я вообще не понимаю спор начался с того, что на ($), (.) ругаются, я говорю, что нет данные функции, как впрочем и указанные тут flip активно используюся в проектах не являющихся факториалом. Естественно это не значит, что все надо броситься переписывать в point-free или наоборот point-full.

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

Я показал (хотя строго не доказал для случая _|_), что денотационная семантика у данных функций одинакова

Если денотационная семантика каких-то ф-й совпадает - это совсем не значит, что эти ф-и делают одно и то же (то есть, что у них совпадает семантика).

Про какую семантику говоришь ты?

Про семантику языка. . - принимает две ф-и и возвращает третью, в то время как $ - просто аппликация. По-этому f $ g $ x никак не будет то же самое, что и (f . g) $ x - в первом случае нету никакой ф-и f . g.

У алгоритмов, решающих одну и ту же задачу, но с разной сложностью тоже денотационная семантика совпадает, но эти алгоритмы, совершенно определенно, делают совершенно разные вещи.

P.S. я вообще не понимаю спор начался с того, что на ($), (.) ругаются, я говорю, что нет данные функции, как впрочем и указанные тут flip активно используются в проектах не являющихся факториалом.

Не используются.

anonymous ()
Ответ на: комментарий от pseudo-cat

там я буду вынужден писать последовательно вложенную программу, потому как чтобы применить ф-цию к A, A должна быть вычислена ранее и лежать на стеке

В рамках классического изкоробочного механизма — да. Но Форт — метаязык, ленивые вычисления на котором пишутся в пару-тройку десятков строк, после чего становятся частью проблемно ориентированного языка.

Но, вообще, в постановке вопроса этот критерий не звучал :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от pseudo-cat

-ция copy принимает 2 аргумента, или 2 аргумента и 1 из них опциональный

Если два аргумента, то следующие два 'слова' будут аргументами copy, опциональные аргументы есть, это как этот /all в реплейс, то есть 'имя' функции содержит инфу о том сколько аргументов надо этому конкретному вызову.

loz ★★★★★ ()
Ответ на: комментарий от pseudo-cat

в лиспе нужны особо обученные привычки чтобы читать текст вида (- 2 4)

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

да, но это легко читается когда вырабатывается одна основная привычка - смотря на код, видеть везде - (function args). То же самое что и с $ в Хаскеле, |> в F#, function(args) в Java... В случае твоего примера, такого навыка не достаточно, надо смотреть сколько аргументов принимает ф-ция.

pseudo-cat ★★★ ()
Ответ на: комментарий от pseudo-cat

многие говорят что у лиспа читаемость на нуле, я считаю это делом привычки и опыта.

loz ★★★★★ ()
Ответ на: комментарий от loz

полностью согласен. Но, как и во многих ЯП, если писать много кода в одном блоке, то читаемость не очень, т.к. ф-ция и аргументы «отдаляются» друг от друга. Так же с уровнем вложенности. Надо грамотно разбивать, не зря об этом пишут почти во всех книжках по программированию как таковом.

pseudo-cat ★★★ ()

да неудобны они

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.