Здравствуйте, z00n, Вы писали:


Z>А в чем принципиальная разница?

Ты разбираешь список я дерево.
Тебе тут конкретно помог сахар,(кстати у тебя ошибка внешние скобки тоже значущие)
без него (например на чистом лиспе) пришлось бы разбор разбивать.

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

Tst {
    ((e.1) e.2 (e.3) e.4 (e.5)) = 1;
    e.9 = 0;
};

которому будет удовлетворять любое выражение типа:
((<выражение>)<может быть куча символов> (<выражение>) <может быть куча символов> (<выражение>))

CE>>Да меня в общем то тоже удивило и огорчило, что автор языка несколько отстал развития

MC>До кучи даже анпакинг туплов выкинули (pep-3113 без слез читать невозможно)

Да. Ну. Нафиг

Блин. Почитать, что ли PEP 3113... Потому что полезная фича была...

FR>>Угу согласен.
FR>>Но вообще под питон есть очень интересная штучка http://www.fiber-space.de/EasyExtend/doc/EE.html
FR>>В общем вводит в питон макросы типа немерловских, при желании можно наваять почти любой нужный
FR>>язычок.

dmz>Так оно и для других языков есть такое; впрочем для erlang — не знаю, есть или нет.

Для эрланга есть типа parse_transform

http://hyperstruct.net/2007/6/26/literal-xml-in-erlang-with-parse-transform-2
http://www.trapexit.org/forum/viewtopic.php?t=6385&amp;sid=7400902cee48db0074bf2650d50c362c

но используют его мало и неохотно (видимо, сложно)

Здравствуйте, Mamut, Вы писали:

M>Для эрланга есть типа parse_transform

M>http://hyperstruct.net/2007/6/26/literal-xml-in-erlang-with-parse-transform-2
M>http://www.trapexit.org/forum/viewtopic.php?t=6385&amp;sid=7400902cee48db0074bf2650d50c362c

M>но используют его мало и неохотно (видимо, сложно)

Ну и вроде как не очень рекомендуется (кто-то в мейллисте такое говорил из гуру)

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, z00n, Вы писали:

Z>>

Z>> fun foo
Z>>   | (a :: "+" :: b :: []) :: "*" :: (c :: "+" :: d :: []) :: [] -> 1
Z>>   | x -> 0
Z>> end
Z>> print$ foo([ [1,"+",2],"*",[3,"+",4] ]) ---> 1
Z>> print$ foo([1,"+",2])                   ---> 0
Z>>

FR>Ты разбираешь список я дерево.
Я тоже дерево

FR>Тебе тут конкретно помог сахар,(кстати у тебя ошибка внешние скобки тоже значущие)
FR>без него (например на чистом лиспе) пришлось бы разбор разбивать.
Разбивать- не разбивать — это не принципиально, особенно в лиспе, поскольку всегда можно подкрутить компилятор макросами. Я видел паттерн-матчер для Scheme, который был бы даже круче: он позволял помечать переменные особым образом, в результате чего их рекурсивно гоняли через функцию до победного конца (там это называлось катаморфизм — наверное так оно и есть ). Скобки я вроде не забыл — выделил болдом.

FR>Ну и так как дерево в общем случае нельзя заменить списком рано или поздно ты не сможешь
FR>повторить, например:

FR>

FR>Tst {
FR>    ((e.1) e.2 (e.3) e.4 (e.5)) = 1;
FR>    e.9 = 0;
FR>};
FR>

FR>которому будет удовлетворять любое выражение типа:
FR>((<выражение>)<может быть куча символов> (<выражение>) <может быть куча символов> (<выражение>))

Согласен. Предлагаю обобщить:
Списки: (<выражение>)<может быть куча чего-то>
Refal: (<выражение>)<может быть куча чего-то>(<выражение>)
Я собственно это и сказал 3 поста назад

И, добавлю — не совсем правильно говорить, что в Рефале нет списков — там есть их надмножество.
В луа, же никакой "функциональной" сруктуры данных нет, а то что можно сделать из того, что под рукой намного хуже списков в хорошей имплементации Схемы.

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Mamut, Вы писали:

M>>Для эрланга есть типа parse_transform

M>>http://hyperstruct.net/2007/6/26/literal-xml-in-erlang-with-parse-transform-2
M>>http://www.trapexit.org/forum/viewtopic.php?t=6385&amp;sid=7400902cee48db0074bf2650d50c362c

M>>но используют его мало и неохотно (видимо, сложно)

К>Ну и вроде как не очень рекомендуется (кто-то в мейллисте такое говорил из гуру)

Ну, это напрямую в докуметации написано: http://www.erlang.org/doc/man/erl_id_trans.html

Parse transformations are used if a programmer wants to use Erlang syntax, but with different semantics. The original Erlang code is then transformed into other Erlang code.

Note
Programmers are strongly advised not to engage in parse transformations and no support is offered for problems encountered.

Кстати, есть еще parse tools: http://www.erlang.org/doc/apps/parsetools/index.html Они, в теории, могут позволить написать парсер любого языка, грамматику которого можно записать в BNF

Здравствуйте, Mamut, Вы писали:

M>Кстати, есть еще parse tools: http://www.erlang.org/doc/apps/parsetools/index.html Они, в теории, могут позволить написать парсер любого языка, грамматику которого можно записать в BNF

Будущее за системами типа OMETA или XOC
OMeta: an Object-Oriented Language for Pattern Matching
Xoc, an Extension-Oriented Compiler

Здравствуйте, z00n, Вы писали:

Z>Здравствуйте, Mamut, Вы писали:

M>>Кстати, есть еще parse tools: http://www.erlang.org/doc/apps/parsetools/index.html Они, в теории, могут позволить написать парсер любого языка, грамматику которого можно записать в BNF

Z>Будущее за системами типа OMETA или XOC
Z>OMeta: an Object-Oriented Language for Pattern Matching
Z>Xoc, an Extension-Oriented Compiler

Очередной пророк?
Скажи мне лучше, каким образом оно к Эрлангу относится?
Тем более ещё объектно-ориентированное к "традиционному" функциональному языку?

Здравствуйте, Курилка, Вы писали:

К>Скажи мне лучше, каким образом оно к Эрлангу относится?
К>Тем более ещё объектно-ориентированное к "традиционному" функциональному языку?

OMETA можно реализовать на любом нормальном языке, сейчас она есть на Smalltalk, JavaScript, Scheme. Насчет Эрланга тоже были планы:

FROM: http://vpri.org/pipermail/ometa/2008-June/000010.html
> Finally, if I wanted to target a different VM, such as the Erlang VM,
>> would it make sense to use the Cola version of OMeta to compile to Erlang
>> bytecode, or would you recommend I reimplement OMeta in Erlang for that?

XOC тоже хорош, только они зачем-то взяли GLR парсер вместо PEG.

Здравствуйте, z00n, Вы писали:

FR>>Ты разбираешь список я дерево.
Z>Я тоже дерево

Угу распечатаную картинку дерева

FR>>Тебе тут конкретно помог сахар,(кстати у тебя ошибка внешние скобки тоже значущие)
FR>>без него (например на чистом лиспе) пришлось бы разбор разбивать.
Z>Разбивать- не разбивать — это не принципиально, особенно в лиспе, поскольку всегда можно подкрутить компилятор макросами. Я видел паттерн-матчер для Scheme, который был бы даже круче: он позволял помечать переменные особым образом, в результате чего их рекурсивно гоняли через функцию до победного конца (там это называлось катаморфизм — наверное так оно и есть ). Скобки я вроде не забыл — выделил болдом.

В общем-то может и непринципиально, то что получается в рефале естественно в языках со списками можно делать только с помощью сахара.


FR>>которому будет удовлетворять любое выражение типа:
FR>>((<выражение>)<может быть куча символов> (<выражение>) <может быть куча символов> (<выражение>))

Z>Согласен. Предлагаю обобщить:
Z>Списки: (<выражение>)<может быть куча чего-то>
Z>Refal: (<выражение>)<может быть куча чего-то>(<выражение>)
Z>Я собственно это и сказал 3 поста назад

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

Z>И, добавлю — не совсем правильно говорить, что в Рефале нет списков — там есть их надмножество.

Угу.

Z>В луа, же никакой "функциональной" сруктуры данных нет, а то что можно сделать из того, что под рукой намного хуже списков в хорошей имплементации Схемы.

Как в луа я уже не помню

Здравствуйте, Курилка, Вы писали:

К>Очередной пророк?
К>Скажи мне лучше, каким образом оно к Эрлангу относится?
К>Тем более ещё объектно-ориентированное к "традиционному" функциональному языку?

Так тема вообще-то про питон и к нему должно нармально пришится.

Здравствуйте, Critical Error, Вы писали:

CE>Как мрачно! Вот отказываться от питона не есть гуд решение. Все же ничего лучше и удобнее не найдете (после питона любой язык покажется унылым и неудобным). Поступайте как все умные питонисты — пишите критичные по производительности куски приложений на С, благо C-API у питона отменное, да еще и CPP-API имеется, ну где вы еще такое найдете?

Ну, это конечно банальность, но по обоим выделенным параметрам Руби вполне конкурентоспособен /Что не отменяет наличия у Руби других проблем/

Здравствуйте, Гест, Вы писали:

Г>Ну, это конечно банальность, но по обоим выделенным параметрам Руби вполне конкурентоспособен /Что не отменяет наличия у Руби других проблем/

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

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Гест, Вы писали:

Г>>Ну, это конечно банальность, но по обоим выделенным параметрам Руби вполне конкурентоспособен /Что не отменяет наличия у Руби других проблем/

FR>Угу только почему-то руби в отличии от питона на десктопах и как язык расширения приложений не прижился.

Ну, во-первых "не то чтобы совсем не попал". В смысле не то, чтобы вообще не прижился (сходу могу вспомнить SketchUp, где он таки язык расширений). Во-вторых, процесс продолжает идти — одна из громко развивающихся библиотек в руби-сообществе — библиотека Shoes для кросс-платформенного десктопного GUI. Еще есть, к примеру, такая милая и довольно популярная штучка как WaTiR — скриптование тестирования веб-сайтов через браузер.

Ну и наконец, я вообще не совсем понимаю, какое этот аргумент имеет отношение к делу

Здравствуйте, Гест, Вы писали:

FR>>Угу только почему-то руби в отличии от питона на десктопах и как язык расширения приложений не прижился.

Г>Ну, во-первых "не то чтобы совсем не попал". В смысле не то, чтобы вообще не прижился (сходу могу вспомнить SketchUp, где он таки язык расширений). Во-вторых, процесс продолжает идти — одна из громко развивающихся библиотек в руби-сообществе — библиотека Shoes для кросс-платформенного десктопного GUI. Еще есть, к примеру, такая милая и довольно популярная штучка как WaTiR — скриптование тестирования веб-сайтов через браузер.

Ну так это и есть не прижился, в сравнении с питоном или луа

Г>Ну и наконец, я вообще не совсем понимаю, какое этот аргумент имеет отношение к делу

Очень даже по делу, тут вроде еще не было флемов питон vs руби

Г>Ну, это конечно банальность, но по обоим выделенным параметрам Руби вполне конкурентоспособен /Что не отменяет наличия у Руби других проблем/

Для руби кто нибудь делает LLVM бекенд?