>> Ну а Си++ просто слишком сложен, чтобы его еще расширять > Он и так расширяемый.

очень смелое утверждение :)

>Чем это отличается от хеш-таблицы?

Возможностью переопределения в потомках.

function title() { return "Объект ".parent::title(); }

У меня такая фигня постоянно используется. Объекты в разных системах очень разнообразные, а вот доступ к элементам - всюду унифицированный.

>Генерировать классы, кстати, в Java можно

Но не средствами самой Java :) В смысле - языка. А то и на Бейсике можно машинный код генерировать :)

> Там, где полиморфизм в стиле Java/.NET, ничего хорошего из вывода типов не получится.

Scala, D - вроде всё нормально.

>> В Питоне не хватает pattern matching и статической типизации.

> Он тогда OCaml-ом станет.

Мне симпатичен Ocaml :) Но если будет хоть одно из двух, уже прекрасно.>

>> В Си - исключений, параметризуемых типов и опять pattern matching.

> PM поверх чего? Tagged unions в язык вводить на низком уровне, что ли?

Ага. И поверх параметризуемых типов :) Ну то есть мне хочется упрощенный Cyclon.

>> Ну а Си++ просто слишком сложен, чтобы его еще расширять

> Он и так расширяемый.

Некоторыми вещами его не расширишь. Тем же PM, или выводом типов, да и новые синтаксические конструкции, вводимые a-la Boost, вызывают у меня страх :D

> Там, где полиморфизм в стиле Java/.NET, ничего хорошего из вывода типов не получится.

Этого не понял.

auto v = new MyClass();

auto m = new Map<String, float>();

уже короче и понятнее.

Re^4: Расширяемые ЯП

>>Ну что-то типа <elem1 elem2 elem3>. Вроде как {...}, но с подстановкой, но в то же время не "...". Ну или уж сразу скобки по-лисповски :)

> можно предложить TIP на укороченную запись, вроде $ для подстановки. а для начала можно такой синтаксис сделать самостоятельно. кстати, что в jabber'е не отвечаешь?

Может ты не мне пишешь? `whoami`@jabber.ru

> это будет совсем другой язык. ну подумай, когда должна выполнятся статическая проверка типов при наличии eval и возможности подмешивания произвольного кода?

Понимаю.

> Возможностью переопределения в потомках.

> function title() { return "Объект ".parent::title(); }

> У меня такая фигня постоянно используется. Объекты в разных системах очень разнообразные, а вот доступ к элементам - всюду унифицированный.

Получается, у parent-а title() генерируется автоматически в рантайме, а у потомка она статически описывается и делается предположение, что у parent-а она есть. Не представляю такого в статически типизируемом языке, честно говоря.

> Но не средствами самой Java :) В смысле - языка. А то и на Бейсике можно машинный код генерировать :)

Джава в этом смысле лучше тем, что у неё байткод стандартизован и можно использовать готовые библиотеки без боязни, что оно где то не будет работать. Да и вообще можно сгенерировать код на java, в память его скомпилировать и тут же загрузить. Я не пробовал, но вроде все возможности есть.

Re^4: Расширяемые ЯП

> ИМХО, вполне логично и компактно :) Разве что для list@ можно алиас l@ ввести.

Тебе логично, а я мозг сломал, пытаясь вникнуть :)

> Хорошо живёт, лучше чем под родным .NET.

Есть ли ide с поддержкой сего или вообще какие-нибудь инструменты, кроме компилятора и vm?

> Это на Форте. Прямых аналогов в других языках не знаю. В общем, это генерация генерирующих определений :)

defmacro в Лиспе делает это и много чего ещё.

>Получается, у parent-а title() генерируется автоматически в рантайме, а у потомка она статически описывается и делается предположение, что у parent-а она есть. Не представляю такого в статически типизируемом языке, честно говоря.

Не совсем так. У базового объекта title обрабатывается геттером __get. Т.е. если не находится метод title() у родителя, то вызывается __get("title", ...), который уже и прочитает соответствующее поле класса.

У статического языка может быть то же самое. Геттеры там никто не отменял. Вон, Boo в качестве примера можно привести :) Статическая типизация, но геттеры/сеттеры и расширяемость.

>Джава в этом смысле лучше тем, что у неё байткод стандартизован и можно использовать готовые библиотеки без боязни, что оно где то не будет работать.

Да. Но это уже тема другого разговора :)

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

JBForth2 так и будет делать. Там все классы будут нативные для Java.

>Я не пробовал, но вроде все возможности есть.

В рамках именно языка Java - нет. Т.е. загрузка-то, конечно, класслоадеры - это конёк Java, а вот генерация их - фиг. Системный вызов javac из SDK - это уже, опять же, другая история, к _языку_ отношения не имеет :) Тогда, опять же, можно сказать, что Бейсик может Хаскелл-программы исполнять ;) (развивать эту аналогию не нужно, она гипертрофированная)

> Scala, D - вроде всё нормально.

Это не вывод типов ещё. Такого, как в Haskell, в языках с полиморфизмом быть не может.

> реквестирую учебник Форта :)

http://akps.ssau.ru/forth/

В первую очередь порекомендовал бы Баранова и Ноздрунова - шикарная книга.

Есть мода для Emacs, что гораздо лучше любой IDE.

>Тебе логично, а я мозг сломал, пытаясь вникнуть :)

Просто нужно помнить, что в Форте всё выполняется слово за словом и что у xxx@ слов традиционная стековая нотация ( object index -- value ) :) Т.е. кладём на стек объект, в нём адрес/позицию, после выполнения - значение, хранящееся в этой позиции.

Дело привычки.

Доступ к элементам массивов в том же Хаскелле не менее зубодробителен :)

>Такого, как в Haskell,

А в чём там серебряная пуля?

>в языках с полиморфизмом быть не может.

Ты на 100% уверен? :)

> auto v = new MyClass();

Это не вывод типов. Тип то явно задан - MyClass.

А вот если, например: function test(arg1) { var x = arg1.Run(); return x.Run(); }

и при этом классов, у которых есть метод Run, наберётся с пару десятков - то никакого вывода типов тут не будет.

> А в чём там серебряная пуля?

Там вывод типов. Полноценный. Другие варианты - это не вывод типов.

> Ты на 100% уверен? :)

Да. Я смеху ради делал вывод типов для .NET. После получаса работы на простейших выражениях алгоритм выдавал наиболее общий тип функции на двести строк текста. Кому такое надо?

Слишком много общих имет у методов разных классов, при этом имена не принадлежат одному общему интерфейсу. Внутри одного класса может быть множество методов с одинаковым именем и арностью, но с разными типами аргументов, и на каждый такой метод сложность вывода типов (и сложность результата) растет экспоненциально.

> : autoinc "CREATE 0 , DOES> ...;" EVALUATE ;

Ой мама моя ! Хтож так робыть ?

: xxx CREATE ... DOES> CREATE ... ;

> Есть мода для Emacs, что гораздо лучше любой IDE.

Я так и думал... Ничего кроме как подсвечивать код и запускать компилятор эта мода конечно же не умеет?

>> auto v = new MyClass();

> Это не вывод типов. Тип то явно задан - MyClass.

Задан тип выражения в правой части. Тип левой выводится.

> при этом классов, у которых есть метод Run, наберётся с пару десятков - то никакого вывода типов тут не будет.

То есть полного отказа от объявлений типов не получится? Ну и пусть. Я могу обойтись и без академической чистоты Хаскеля.

>Ой мама моя ! Хтож так робыть ?

Ну вот, я же говорю - закопайте меня :) И DOER не нужен...

>http://akps.ssau.ru/forth/

благодарю

>Доступ к элементам массивов в том же Хаскелле не менее зубодробителен :)

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

> Тебе логично, а я мозг сломал, пытаясь вникнуть :)

Постфиксная AKA "польская" запись. Если про это вспомнить, то читается на ура.

> Задан тип выражения в правой части. Тип левой выводится.

Ха ха. Тогда и тип str в выражении String str = "..." выводится.

Это не вывод типов! Это банальный type propagation, который существуюет в любом типизированном языке в той или иной форме.

> То есть полного отказа от объявлений типов не получится?

Не получится. Не получится вообще вывода типов, никакого.

> Я могу обойтись и без академической чистоты Хаскеля.

Это не "академическая чистота", а удобство использования. Или вывож типов есть, и код немногословный получается, или его нет, и абсолютно все типы надо задавать явно. Конечно, можно и нужно избавляться от дублирования информации о типах, как в дебильной Жабке, но вот исключить её вообще в таких языках просто невозможно. Убил бы того, кто придумал полиморфизм!

> Я так и думал...

Это - то, чем пользуются сами разработчики. Чего тебе ещё надо?

> Ничего кроме как подсвечивать код и запускать компилятор эта мода конечно же не умеет?

Там есть REPL, а это как раз и есть самое главное, что нужно от любой среды разработки.

> Там есть REPL, а это как раз и есть самое главное, что нужно от любой среды разработки.

ППКС.

>> Задан тип выражения в правой части. Тип левой выводится.

> Ха ха. Тогда и тип str в выражении String str = "..." выводится.

А зачем его тогда пишут? :)

> Это не вывод типов! Это банальный type propagation

ОК, значит, я хочу type propagation.

> Или вывож типов есть, и код немногословный получается, или его нет, и абсолютно все типы надо задавать явно.

...или есть type propagation и не все типы нужно задавать явно :) Меня устроит компромисс.

> Убил бы того, кто придумал полиморфизм!

А typeclasses в Хаскеле? А Ocaml?

>> В Java не хватает развитой рефлексии >Ой. А можно развить мысль?

Определение класса - first-class object? А замыкания? И т.п. :)

>[c]
>printf("%s", "Hello, world");
>[end-c]
>." And Forth again"

Как на Форте реализовать синтаксис Си, если в нем пробелы — разделители?
«." And Forth again"», здесь после первой кавычки пробел убрать нельзя, не так ли?
Объясните в двух словах, как это ограничение обходится?

google:carbonado ?

> Там есть REPL

Что-то в имаксе я не обнаружил repl nemerle... (естественно nemerle установил :))

> Определение класса - first-class object?
Для большинства использований - да? Объекты класса java.lang.Class...

> А замыкания?
При чем тут рефлексия?

> А зачем его тогда пишут? :)

Так он и выводится, из узла <String> в узел <str>. Ничуть не проще и не сложнее, чем протянуть тип из правой части в левую, ровно тот же механизм.

> ОК, значит, я хочу type propagation.

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

> ...или есть type propagation и не все типы нужно задавать явно :) Меня устроит компромисс.

Да нет же, ВСЕ кроме очевидных константных надо задавать явно, когда нет возможности вычислить типы из-за сложности полиморфизма.

> А typeclasses в Хаскеле? А Ocaml?

Это другой полиморфизм.

Если бы, например, все методы с одинаковыми именами обязательно были бы реализациями одного интерфейса - то не было бы и проблем.

>Как на Форте реализовать синтаксис Си, если в нем пробелы — разделители?

Просто по [c] включится альтернативный парсер входного потока.

>здесь после первой кавычки пробел убрать нельзя, не так ли?

В классическом Форте - нет. Там «."» - самостоятельное слово. И должно от последующей строки отделяться пробелом. Сам пробел (и только один), естественно, печататься не будет :)

Но никто не запрещает вводить классические строки и печатать их обычно:

"Hello, world" .

>Объясните в двух словах, как это ограничение обходится?

Если же речь именно об альтернативных языках, то, повторюсь, тут подменяется целиком транслятор. Т.е., понятно, что Си на Форте - это не Форт-Си, а чистый Си, написанный на Форте. Просто может транслировать входной поток Форта и может включаться/выключаться.

> > А замыкания? > При чем тут рефлексия?

При том, что в языке с хорошей рефлексией разобрать по частям и собрать заново можно всё. Common Lisp, к слову, полностью такое не умеет (макросы и замыкания не первоклассные).

> в языке с хорошей рефлексией
Видимо, для Вас "язык с хорошей рефлексией" предполагает работу с классами в рантайме. В жабке этого нет. Поэтому я сказал - для жабской модели ее рефлексия делает все необходимое. Возражения будут по поводу этой формулировки?

> Как на Форте реализовать синтаксис Си, если в нем пробелы — разделители? «." And Forth again"», здесь после первой кавычки пробел убрать нельзя, не так ли? Объясните в двух словах, как это ограничение обходится?

http://www.forth.ru/

Например, как в http://www.forth.ru/gp/gp-forth.exe (http://www.forth.ru/sources.html)

Смотри описание компилятора "Псевдо-Паскаля" PAS.COM, PAS.DOC и PAS.FRT (7z из p7zip-full нормально распаковывает gp-forth.exe)

Ах да, поправка про дженерики. Там как-то мутно с рефлексией, вроде как. Но я не смотрел, руки не доходили.

>Просто по [c] включится альтернативный парсер входного потока.

Как в Common Lisp'е, в Форте поведение reader'а можно перепрограммировать?

> Как на Форте реализовать синтаксис Си, если в нем пробелы — разделители?

bl word - здесь будет разделителем пробел

C" " word - здесь двойная кавычка

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

>Как в Common Lisp'е, в Форте поведение reader'а можно перепрограммировать?

Парсер входного потока там (в классическом Форте) чудовищно примитивен. Поэтому и обычно не перепрограммируется, если что, а пишется свой. Столь же примитивный, но с иным функционалом :)

...

В JBForth, правда, парсер не «чистый», на Java написан. Всё же, нынешний вариант уступает чистой оптимизированной Java на пару порядков, ибо не генерит нативный JVM-байткод код.

А со строками в Форте работать удобно?
Насколько я понимаю, их в стеке хранить нельзя.
Значит, они выделяются в куче, потом освобождаются...
И все это вручную: ведь сборщика мусора там нет, верно?
Как-то читал статью Мура, в ней он строки откровенно не жаловал.

> А со строками в Си работать удобно? Насколько я понимаю, их в стеке хранить нельзя. Значит, они выделяются в куче, потом освобождаются... И все это вручную: ведь сборщика мусора там нет, верно? Как-то читал статью {Кернигана&Ритчи}, в ней они строки откровенно не жаловали.

fixed

И они тоже?

> А со строками в Форте работать удобно? Насколько я понимаю, их в стеке хранить нельзя. Значит, они выделяются в куче, потом освобождаются... И все это вручную: ведь сборщика мусора там нет, верно?

Строки по умолчанию лежат в словаре (т.е. статичны), если хочется - выделяй в хипе, я, например, прикручивал к своему Форту Boehm GC.

А как с их объединением, выделением подстрок и т. п.?

>А со строками в Форте работать удобно?

В классическом - относительно. Типичная Форт-строка - это два параметра в стеке, адрес и длина. Соответственно, работа идёт операторами для работы с двойными словами. Обычно проблем не составляет, но учитывать надо больше тонкостей.

>Насколько я понимаю, их в стеке хранить нельзя.

Указатели на них в стеке хранятся. Сами строки - в любой памяти. Выделяемой из хипа, буферах, кодофайле...

Ну а в JBForth строка - это обычный java.lang.String. В смысле - указатель на него в стеке.

Вот контактенировать строки в Форте не так удобно. Их контактенация в постфиксной записи смотрится не так привычно и удобно, как в случае арифметики + отсутствие в Форте полиморфизма требует отдельного оператора для сложения строк вместо привычного «+» (и «.» занята словом печати значения ;) )

>А как с [...] выделением подстрок и т. п.?

Это, как раз, ничего сложного, обычные слова. Как напишешь, так и будет. MID/SUBSTR/TRIM/etc... В стандарте не оговариваются, но синтаксис их для всех языков схожий.

...

Кстати, помню, как делал лет 15 назад динамические строки даже термина такого не зная, как «сборка мусора» :) Помогало то, что в Форте ничто никуда не пропадает. Удаление любого параметра - явное. Сбросить параметр со стека - drop. Соответственно, объектный drop делает delete для объекта перед его освобождением :)

А вот в JBForth уже ничего специально не освобождаю. Этим уже GC JVM заботится.

>ЗЫ Про расширение на лету спорить не буду - его нет, хотя не ощущал реальной нехватки.

Есть работы на тему "обновление Java приложения на лету", вроде

http://www.springerlink.com/content/032t5n0j3227334w/
http://www2.computer.org/portal/web/csdl/doi/10.1109/QSIC.2006.30
http://portal.acm.org/citation.cfm?id=1248820.1248860
http://portal.acm.org/citation.cfm?id=879757&dl=GUIDE&coll=GUIDE&...
http://portal.acm.org/citation.cfm?id=1172983&dl=GUIDE&coll=GUIDE&...
http://64.233.179.104/scholar?hl=en&lr=&q=cache:na_ZpQqEKaYJ:www.cs.umd.edu/Honors/reports/MarthagmHonorsProject.pdf+related:77O4OSDUJ2EJ:...