Ограничения синтаксиса, это когда ты не пишешь нормальный код, даже если можешь, потому что ппц синтаксис говно

Изоморфно оно изоморфно, но я то не транслятор, а глупая бионейронка

так несколько раз упоминал выше - напиши свой транслятор в свой синтаксис. 21 век на дворе

Я напишу, почему-то сложно заставить его остальным поддерживать и подсвечивать, читать и отлаживать. А ещё требуют какие-то денотационные и трансляционные семантики на бумаге описать. Фу

вы так говорите, как будто не подозреваете, что можно тот же хаскель изоморфно отобразить на лисп-синтаксис ) демонстрируете вышеупомянутый блаб-парадокс в чистом виде

Можно, только нужно будет ввести ключевые слова, например \x -> x надо будет представить как (lam (x) (x)) и вот если это в итоге для макросов тупо представить как дерево data AST = Lam | V String | Node [AST] Node [Lam, V “x”, V “x”] то тогда для того, чтобы понять, что первый “x” это binding occurrence, а второй на него ссылается, то нужно будет инспектить ключевое слово в начале

А в нормальном синтаксическом дереве это было бы data Expr = Lam Pat Expr | …

И с таким деревом лисповые скобки это просто просранная нотация

Так в чем там ее смысл тогда?

Я напишу, почему-то сложно заставить его остальным поддерживать и подсвечивать, читать и отлаживать. А ещё требуют какие-то денотационные и трансляционные семантики на бумаге описать. Фу

а зачем остальных заставлять? ты свою цветовую схему в редакторе тоже всех заставляешь использовать?

А Elm позволяет легко и по быстрому вкатиться. А потом пациенту может захотеться функциональщины посерьёзней.

кстати хороший пойнт. т.к. те, кому не захочется, всё равно не целевая аудитория онтопика.

Уродский синтаксис - очень субъективная вещь. Для многих программистов синтаксис хаскеля как раз будет весьма уродским.

я хорошо помню время, когда синтаксис хаскеля казался мне уродским

Так он и есть уродский, о чем речь-то?

Столько фич в ASCII впихать — никто нормально не сделает.

a + b = … это мы оператор объявили a ! b = … а это на самом деле “a" функция, а "b" это строгий аргумент, т.е. a (!b) = …

Если BangPatterns включить.

При том, что ! это все-таки оператор. Но вот его определить можно только как (!) a b = ...

Или выключив BangPatterns в модуле определения.

Столько фич в ASCII впихать — никто нормально не сделает.

На APL пишешь?

Agda

это все только для разработчика парсера тяжело, а человек-то нормально читает уродство в хаскеле это (из ходового) 1) ду-нотация 2) семейства

Человек напишет a + b = … a ! b = ...

Только первое сработает, а второе нет.

Это не инженерная проблема, а проблема спецификации.

Если б еще сделать это whitespace sensitive, то можно было бы жить, типа bang pattern должен вполтную прилегать, иначе это оператор.

Ага, все языки плохие, один хаскель хороший в белом пальто стоит красивый.

close enough

close enough

хаскель то тоже плохой

почему-то искатели токсичности считают, что хаскелисты считают всех кроме себя дурками

проблема реальная, но не особо важная, ну сколько люди оператор ! объявляют? c теми же отрицательными литералами проблема куда хуже

но "кроме себя" это ж лишнее

но, конечно, надо было с самого начала делать чтоб банги писались без пробела с паттерном

хаскель то тоже плохой

это уровень плохости, недостижимый мейнстримом

Ну если кто-то пропозал сделает такой, то можно и реализовать.

Думаю, даже не слишком трудно.

такой пропозал не пройдет

Для type applications же сделали whitespace-sensitive.

Тут чем-то отличается?

Просто не детектить ! как bang, если после него пробел

да, но банги-то 20 лет уже есть

да, но банги-то 20 лет уже есть

а as-patterns с зачатия языка

@iodamagistr будет жить. Поприветствуем!

Но не постеснялись и сломали их в пользу type applications

а as-patterns с зачатия языка

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

Можно и новое ввести, -XStickyBangPatterns

А потом сделать восьмилетний deprecation schedule для старых

Как с * сделали

Это еще может и пройдет, но тут уже главный минус что расширение состоит примерно из ничего

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

@strikepark будет жить. Поприветствуем!

Это еще может и пройдет, но тут уже главный минус что расширение состоит примерно из ничего

Оно состоит из исправления синтаксиса

Какие-нибудь -XNumericUnderscores ничем не лучше.

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

Через восемь лет жить уже не планируешь?

Оно состоит из исправления синтаксиса

ну вот посмотрите как докопались до минимального пропозала "лейблы с большой буквы", там в обсуждении уже думают что бы еще добавть, а то маловато что-то

надо делать такие вещи частью OverqualifiedConstraints патчей

Короче, кто б запропоузил, я может и заимплеменчу.

Sticky bang patterns

Через восемь лет жить уже не планируешь?

кем видите себя через 8 лет? трупом/инвалидом/бомжом

трупом-хаскелистом инвалидом-хаскелистом бомжом-хаскелистом

я тоже не надеюсь, что за восемь лет что-то толковое новое сделают Ж(((

Можно и новое ввести, -XStickyBangPatterns

Я бы ещё @ в тайпаппликейшнах приклеил

Ты про то, что можно писать f @ ty?

@true_grue будет жить. Поприветствуем!

TypeApplication сделали наоборот “отклеенным”, то есть это перед ним должен быть пробел, иначе получится as-pattern

Я бы ещё @ в тайпаппликейшнах приклеил

уже (но наоборот)

a@b - at pattern

as-pattern предполагает имя

А тут f @ x выглядит, как оператор

a@[foo] ?

или скобку, (x)@b тоже как as-pattern распарсится

это что?

a@[foo] ?

паттерн

Я за f @T, вощм

И за обязательные пробелы вокруг операторов

сам я обычно за закорючку, а не за ключевое слово, но вот тут не уверен, что @ лучше as

Вот пойди да напиши пропозал, если ты так видишь.

Это к Aleksey (astynax) про обязательные пробелы вокруг операторов

сам я обычно за закорючку, а не за ключевое слово, но вот тут не уверен, что @ лучше as

((x:_) as all)?

кто бы написал пропозал idiom brackets

Иди напиши, я сделаю. Синтаксис (| f a b |), отберем у поганых стрелок

((x:_) as all)?

да, но можно и наоборот (это мне всегда в такой конструкции нравилось, что с обеих сторон именовать паттерн можно)

Кажется, что возможны разночтения...

Но сходу не придумаю

Оставьте мне as неключевым словом, я пишу f (a:as) (b:bs) = ...

as был бы полущ, чем слишком "плотный" @

Ты решил разуплотнить синтаксис

(tree as (Tree @ _ @ Int _ (l as (0:_)) _)) vs tree@(Tree @ _ @ Int _ l@(0:_) _) :)

надо реанимировать идею haskell 2

Зачем?

(tree as (Tree @ _ @ Int _ (l as (0:_)) _)) vs tree@(Tree @ _ @ Int _ l@(0:_) _) :)

Оба варианта трешёвые какие-то...

Ты решил разуплотнить синтаксис

Да, больше пробелов!

Зачем?

1) много обсуждений синтаксиса без особой заботы об обратной совместимости 2) успех сам себя не избежит

Да, больше пробелов!

Надо сделать как в Nim, где precedence количеством пробелов определяется?

Нет. Нужно чтобы пробелы были, но кол-во пробелов не было значимо

> много обсуждений синтаксиса без особой заботы об обратной совместимости Если дело только в синтаксисе, то можно просто сделать расширение -XHaskell2 и другим парсером проходиться