LINUX.ORG.RU
Форум — Development  

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

 , , ,


0

4

Поскольку единственное что есть плохого в rust это синтаксис, то давайте подумаем над rust, у которого будет такая же операционная семантика, но синтаксис будет на s-expressions.

Как вам идея?

★★★★★

 ← 1 2 →

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

Bad_ptr ★★★★★
() 
(fn greet String (name &str)
    (format! "Hello, {}!" name))

(fn main ()
    (let* ((name "World")
           (greeting String (greet name)))
      (println! "{}" greeting)))
theNamelessOne ★★★★★
()
Последнее исправление: theNamelessOne (всего исправлений: 1)

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

mix_mix ★★★★★
()

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

Kuzy ★★★
()

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

vertexua ★★★★★
()

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

anonymous
()

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

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

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

Kuzy ★★★
()

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

Aswed ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от DarkEld3r

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(define #:forall (R T1 T2) (compose_map [f : (T1 (T2 . -> . R) . -> . R] [l : (Listof (Pairof T1 (T2 . -> . R)))])
   ...)
monk ★★★★★
()
Ответ на: комментарий от monk

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

Kuzy ★★★
()
Последнее исправление: Kuzy (всего исправлений: 2)
Ответ на: комментарий от Kuzy

Ну, если (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, то читается не хуже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

monk ★★★★★
()

Жирновато.

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

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

anonymous
()

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

ozkriff ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 →
Development