s-exp синтаксис для rust

Не нужно!

Единственная вещь, у которой синтаксис может быть хуже, чем s-exp — Perl. Так что нет, спасибо.

а чё тут думать? Идея неплоха.
Макры там есть, интересно можно ли такое замутить на растовских макрах.

почему не Mexp?

Уж лучше ML тогда, благо сам язык к этому предрасполагает. А вообще вангую в скором времени появится и закрепится аналог CoffeeScript для раста.

Какие профиты? Оно же не будет гомоиконным.

Нет.

Лисп не для такого делался и не такую философию распространяет. Потому будет как велосипед с колесом на замке

s-exp с типами? Отвратительно.

А какая семантика макросов в rust? Если как в syntax-rules (то есть, в общем, нет доступа к окружению) то несложно сделать на той же ракетке простенький транслятор s-exp rust -> rust и при этом будет возможность писать для него макросы на ракетке

Чо, malbolge не видел?

Да, был уже такой лисп, BitC назывался. Не взлетел.

Я, когда смотрел пример с let x = if(cond){1}else{2};, вот тоже подумал, что в лиспе это намного аккуратнее выглядит. Хотя в целом толку от этого никакого не будет.

Я так понял, что выполнять произвольный код в макрах не выйдет. Вообщем, это мало чем отличается от сишного define-а.

тогда может хоть так выйдет http://doc.rust-lang.org/guide-plugin.html

Да, был уже такой лисп, BitC назывался.

Не было :)

А чем, собственно, его синтаксис хуже чем S-expr? Только если макросы сложней писать, но не более. Мне сложно представить синтаксис более неприятный глазу чем S-expr и его бесконечные скобки. Я сам очень хорошо отношусь к лиспу, но синтаксис его считаю очень тяжелым.

Звучит заманчиво. Как rust устаканится, заценю - ownership взлетел/нет. Если взлетел - добавлю в свою уютнуюненужную схемку. А статическая типизация в лифпеге и иммутабильность по умолчанию мне и так очень нравятся.

Он однородный. в расте куча всяких операторов :~^&@;

Если производительность не очень важна, то лучше писать на Racket с нормальными макросами и сборщиком мусора.

Если производительность важна, то С/С++ быстрее (http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=... а для него уже есть L++

Ну, это уже кому что нравится. Лично меня невозможность разобраться в скобках без подсветки редактора раздражает больше чем такие символы. Тут уж что больше нравится разработчикам, то и правда.

Если производительность не очень важна, то лучше писать на Racket с нормальными макросами и сборщиком мусора.

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

Если производительность важна, то С/С++ быстрее

А не рановато сравнивать? Тем более, что в бенчмарках сравнивается ГЦЦ, который и так быстрее цланга.

Лично меня невозможность разобраться в скобках без подсветки редактора

В лиспах такой проблемы как раз не возникает. А вот в языках с сиподобным синтаксисом - часто.

Ну, возможно, только я так плохо пишу на лиспе. Тем не менее, у меня такой проблемы в ml-подобных или c-подобных не возникает.

Тем не менее, у меня такой проблемы в ml-подобных или c-подобных не возникает.

То есть ты с лёгкостью читаешь конструкции вида

list<R> (*compose_map)(R (*f)(T1 x, R (*f)(T2 y)), list<pair<T1,R (*)(T2 x)> > l) {
   ...
}

?

А если хочется статической типизации?

Typed Racket — любые возможные типы и статические проверки.

Да и мне кажется, что растовских макросов для многого и так хватит. Уж получше сишных дефайнов.

Это да. Но есть ещё ATS. С зависимыми типами, паттерн-матчингом, производительностью Си и макросами на уровне раста. Но не взлетел. :-(

А не рановато сравнивать?

Может и рановато. Но на данный момент другого раста нет.

Typed Racket — любые возможные типы и статические проверки.

И отставание от обычного racket (по фичам) в комплекте.

Это да. Но есть ещё ATS. С зависимыми типами, паттерн-матчингом, производительностью Си и макросами на уровне раста. Но не взлетел. :-(

Интересно, почитаю на досуге. Кстати, на первый взгляд, выглядит как-то страшно. Лисп/ракет и раст такого впечатления не вызывали.

А так паттерн матчинг и производительность у раста тоже есть. Ну и с выделением/освобождением памяти там как-то мутно.

Но на данный момент другого раста нет.

На данный момент, (для «промышленного применения») никакого нет. Ну и про ГЦЦ/цланг ты проигнорировал.

Кстати, на первый взгляд, выглядит как-то страшно.

Хаскелл тоже страшно выглядит. Математики так думают.

Чтоб не очень страшно, начинай с http://www.cs.bu.edu/~hwxi/ATS/#simple_ats_programs

Тогда остальное хоть как-то читается :-)

Ну и про ГЦЦ/цланг ты проигнорировал

В смысле, rust всегда будет тормозней, чем gcc? Или будем как автор picolisp'а сравнивать с самыми тормозными из активно использующихся реализаций?

И отставание от обычного racket (по фичам) в комплекте

Например? Что в Racket 6.1 нельзя сделать в Typed Racket?

Теперь напиши это на s-выражениях. Желательно точно так же - в одну строчку.

Хаскелл тоже страшно выглядит.

Как сказать. Если в дебри не лезть, то всё нормально. А по мере изучения и остальное не так страшно казаться будет. А тут в стартовых примерах какой-то ужас. Хотя, конечно, это всё субъективно. Но показалось, что разного «визуального мусора» много.

В смысле, rust всегда будет тормозней, чем gcc?

Почему всегда? LLVM активно развивается - может и догонят. А как раст устаканится, то возможно, и со стороны языка за оптимизации возьмутся.

Что в Racket 6.1 нельзя сделать в Typed Racket?

Вложенные модули? Когда в последний раз смотрел, то for: не поддерживал #:break. Это только то, на что я наткнулся особо не углубляясь.

Желательно точно так же - в одну строчку.

(define #:forall (R T1 T2) (compose_map [f : (T1 (T2 . -> . R) . -> . R] [l : (Listof (Pairof T1 (T2 . -> . R)))])
   ...)

Ну, если (2 + 2 * 2) - тоже конструкция из языка на s-выражениях ((2+ 2 * 2) тоже можнозделать), то ладно, хотя я не понимаю, зачем использовать такие костыли для расширения парсера.

Ну, если (2 + 2 * 2) - тоже конструкция из языка на s-выражениях

Тебе конструкция (T2 . -> . R) не понравилась? Ну если без неё, то то же самое будет даже короче:

(define #:forall (R T1 T2) (compose_map [f : (-> T1 (-> T2 R) R] [l : (Listof (Pairof T1 (-> T2 R)))])
   ...)

Разве что чуть менее наглядно для того, кто не знает синтаксис. Если знать, что (-> arg1 arg2 ... result) описывает функцию с параметрами arg1, arg2, ... и результатом result, то читается не хуже.

И в любом случае "(Listof (Pairof T1 (-> T2 R)))" гораздо легче читается, чем эквивалентное «list<pair<T1,R (*)(T2 x)> > l».

Последнее вообще глазами разбирается как «что-то > l». Но пробел обязателен, иначе C++ не поймёт.

Еще :. И, возможно [ ... ].

(define #:forall (R T1 T2) (compose_map [: f (-> T1 (-> T2 R) R] [: l (Listof (Pairof T1 (-> T2 R)))])

Вообще, тут скорее проблема угребищного синтаксиса указателей на функции в Си.

Для нормально сравнения можно использовать Haskell и Liskell. Субъективно, первый читается много лучше.

Сравнение уровня a<b, c<d, e>, g<e, s> > с (a b (c d e) (g e s))

А не надо такие конструкции писать. Подобное и в s-expr будет убого выглядеть.

Еще :. И, возможно [ ... ]

А это уже стандартный синтаксис Typed Racket. параметры функции описываются как [имя : тип].

тут скорее проблема угребищного синтаксиса указателей на функции в Си

Так это был ответ на «Тем не менее, у меня такой проблемы в ml-подобных или c-подобных не возникает». Я и привёл яркий пример из С-подобных.

Для нормально сравнения можно использовать Haskell и Liskell.

Нельзя. Liskell — калька с Haskell. Соответственно функции написаны так, чтобы их было удобно использовать в синтаксисе Haskell. Поэтому же не получил распространения ни один вариант портирования C++ STL на Common Lisp.

Можно сравнивать Typed Racket с Haskell на аналогичных задачах. Но тут уже чистый субъективизм.

-> T2 R

R (*)(T2 x)

Сорта, извините.

Тема о синтаксисе rust-а. Сравнение rust-а с rust-ом на s-выражениях, близко к сравнению Haskell с Liskell.

Сравнение rust-а с rust-ом на s-выражениях, близко к сравнению Haskell с Liskell

ОК. Согласен.

Как рабочую версию рассматриваю только аналог L++. В смысле генерацию кода на Rust из Racket с макросами на Racket.

Оставлять полностью семантику Rust, но на скобочках — будет изврат.

Жирновато.

А зачем в одну строчку, если можно разбить на несколько и сделать код понятнее? То, что лиспо-синтаксис позволяет разбивать все по строкам - это как раз одно из важных преимуществ. То, что ты предлагаешь - это примерно как писать на ФП и не пользоваться лямбдами.

Ну, убогость синтаксиса ржавчины - очень спорно. Не идеал точно, но получше очень многих языков и меня вполне устраивает. Если серьезно, то слабо себе представляю, как это дело можно адекватно перенести на s-выражения, особенно &'lifetime mut. Но интересно было бы взглянуть, если кто-то такого монстра сделает когда-нибудь.

Нет, не спорно. Еще страшнее, чем цпп