Зачем нужны динамические языки?

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

Мне кажется (как минимум в императивном языке) реализация конструкции for else из питона будет более читабельна в виде макроса.

>> новую синтаксическую конструкцию (for else из Python'а, например)?

> Нет. Но это в в любом не-ленивом языке нельзя сделать, будь он даже функциональный.

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

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

В формулировке "если пользовтель ограничивает себя работой в этом подмножестве" меня это устроит (чужие либы тоже либо должны быть отмечены pure, либо должны считаться грязными)

> Вопрос: а надо ли тогда всё остальное вообще?

Надо. Доказывать я это здесь не буду.

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

> Надо. Доказывать я это здесь не буду.

Это, как раз, самое интересное.

> Либо нам надо забить на интересные вещи из функциональных языков и делать другие интересные вещи, из, например, императивных языков - тогда, опять-таки, непонятно, зачем был этот pure.

Можно в одних местах делать одно, а в других -- другое.

>>> новую синтаксическую конструкцию (for else из Python'а, например)?

>> Нет. Но это в в любом не-ленивом языке нельзя сделать, будь он даже функциональный.

> В Лиспе можно (и это, фактически, основная фишка Лиспа).

Макросом? Тогда в любом языке можно.

> В Форте можно

Форта не знаю, так что ХЗ.

> Смолтоке, как я понимаю, можно.

Кодовым блоком? Ну дак это специальная ленивая конструкция.

> Можно в одних местах делать одно, а в других -- другое.

И мы, фактически, получаем два очень слабо связанных языка. Не проще сразу взять два языка вместо одного?

>> новую синтаксическую конструкцию (for else из Python'а, например)?

> Нет. Но это в в любом не-ленивом языке нельзя сделать, будь он даже функциональный.

Если у тебя есть замыкания, это спокойно делается. (кстати, надо будет попробовать это на с++0х с препроцессором, но полноценно, конечно, не получится из-за слабой системы типов)

> И мы, фактически, получаем два очень слабо связанных языка. Не проще сразу взять два языка вместо одного?

И тут мы приходим к тому, о чем я -надцать раз говорил. Атрибут pure можно в некоторых случаях ОПРАВДАНО выставить, даже если компилятор не согласен.

насчет DDC -- обязательно гляну его систему типов (вообще, как я и писал уже, хаскель нужен в основном чтобы изучать)

> Макросом? Тогда в любом языке можно.

Не в каждом языке есть собственная макросистема, да ещё достаточно богатая. Да, конечно, можно использовать что-то вроде m4... но тогда нам будет ОЧЕНЬ трудно добиться того, чтобы эта конструкция вела себя именно как конструкция языка.

> Кодовым блоком? Ну дак это специальная ленивая конструкция.

Фишка в том, что через кодовые блоки там сделан практически весь синтаксис.

Впрочем, соглашусь, Смолток несколько не в кассу.

> насчет DDC -- обязательно гляну его систему типов

http://haskell.org/haskellwiki/DDC - если ты ещё не нашёл.

> Нет. Но это в в любом не-ленивом языке нельзя сделать, будь он даже функциональный.

Я так понимаю ленивый язык -- это язык с ленивым вычислением аргументов.

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

> Нет. Но это в в любом не-ленивом языке нельзя сделать, будь он даже функциональный.

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

>> Макросом? Тогда в любом языке можно.

> Не в каждом языке есть собственная макросистема, да ещё достаточно богатая.

Это философский вопрос - считать ли макросистему частью языка. Мое мнение - не считать.

Правильное расширение достигается с помощью чисто языковых средств, как в твоем примере с Бейсиком-в-Хаскеле (насколько я понял, там преропроцессор не использовался).

>Ну тогда остается только тема с тем примером, который на хаскеле не дали

если у меня счас не сгорит железо - пример сделаю. ну во всяком случае постараюсь :)

>А почему именно такой (странный, ИМХО) список требований?

навскидку то, что я использую в Haskell и не могу (очевидным образом) сделать в C++

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

А если есть ленивые вычисления, то не надо делать замыкания из блоков.

>> Нет. Но это в в любом не-ленивом языке нельзя сделать, будь он даже функциональный.

>Вообще (это не столько даже тебя касается) видно, как люди совершенно неправильно строят граф зависимостей фич языка

В чем неправильность построенного мной графа (и как он выглядит %))?

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

я уже несколько усомнился в своей однозначной позиции :) но без доказательства всё равно обсуждать не могу, бессмысленно это

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

как по мне, так семантическое. синтаксис-то тут при чём?

>изначальный язык был изначально чем-то типа "чисто имеративного лиспа"

Tcl? :)

>если бы оператор . в с++ имел бы еще и другую синтаксическую версию a.b <===> subfield(a,b) то проблем бы у буста с ним не было

если бы его по-прежнему нельзя было перегружать - были бы

>> можно на D в локальную переменную сохранить функцию, созданную на лету как композицию двух-трёх других функций? let f = a . b . c in ...?

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

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

> Это философский вопрос - считать ли макросистему частью языка. Мое мнение - не считать.

Зависит, естественно, от макросистемы. В Лиспе она интегрирована с основным языком, в C - нет, в C++ - нечто промежуточное (я имею в виду, естественно, не #define-ы).

> Правильное расширение достигается с помощью чисто языковых средств

В том-то и дело, что в Лиспе и в Форте макросистема - чисто языковое средство.

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

Ы?

Или ты хочешь сказать "как и замыканий"?

> А если есть ленивые вычисления, то не надо делать замыкания из блоков.

При условии, что у тебя еще есть дополнительно 2. eval 3. AST, а ведь их может и не быть.

> Или ты хочешь сказать "как и замыканий"?

В с++0х уже есть.

>> А если есть ленивые вычисления, то не надо делать замыкания из блоков.

> При условии, что у тебя еще есть дополнительно 2. eval

Я не знаток Хаскеля, но не припомню там eval. Впрочем, можно считать, что он там условно есть.

> 3. AST, а ведь их может и не быть.

Это не нужно.

SELFIX:

При условии, что у тебя еще есть дополнительно AST, а ведь его может и не быть.

Мне кажется, что лучше без него...

> В с++0х уже есть.

А. Я уж испугался было.

Вообще я чуствую тормозить начал.

И потом мне кажется, что где-то может быть разница между ленивым вычислением AST и замыканиями, причем существенная.

> А если есть ленивые вычисления, то не надо делать замыкания из блоков.

Ладно, еще возражения:

* ленивые вычисления вообще нам не нужны, нам нужны только ленивые вычисления аргументов-в-виде-блоков-кода

* в случае for( ; ; ) тебе придется перевычислять блоки кода, я не уверен, что это входит в понятие "ленивый язык"

кстати, как там в D? оно перевычисляется? я не помню

> навскидку то, что я использую в Haskell и не могу (очевидным образом) сделать в C++

Я догадывался, и потому просил тебя выдвинуть собственное видение, а не из википедии.

Хорошо бы выкатил более полный список.

>Хорошо бы выкатил более полный список.

в смысле - того, чего мне не хватает в C++? или чего, какой список? я несколько потерял нить беседы :(

> А если есть ленивые вычисления, то не надо делать замыкания из блоков.

f(lazy int i);

f(lazy void x); // забавно но по смыслу возражений нет

f(lazy int i) throw;

В последнем случае, если окажется, что i может вызвать исключение, компилятор ругнется. По-моему f( int i() ) throw; выглядит гораздо прямее.

Хотя я еще сомневаюсь...

> в смысле - того, чего мне не хватает в C++? или чего, какой список? я несколько потерял нить беседы

И то, и другое, и можно без хлеба (С) Винни-пух

1. Неприятные места плюсов

2. Те хорошие фишки, которые ты считаешь "функциональными" (на проверку они могут оказаться не такими, но не беспокойся об этом).

в смысле, могут оказаться не чисто функциональными

>f(lazy void x);

а когда force произошёл - оно какого типа стало?

вообще это больше на futures похоже - из C++0x. да и для D реализация была, находил как-то

>в смысле, могут оказаться не чисто функциональными

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

> было бы ещё совсем здорово, если бы в тред вернулись лисперы, и дали бы ещё макр на подумать и о них тоже...

Лисперы в столь поздний час или спят или зохавывают мир, им не до тебя :)

>Лисперы в столь поздний час или спят

спят? а что, лисперам так же как и людям необходим сон? я думал они давно этот досадный момент уже соптимизировали, поручив спать макре... :)

>им не до тебя

увы. но я ещё надеюсь

> а когда force произошёл - оно какого типа стало?

void конечно! (ради побочного эффекта юзается)

> вообще это больше на futures похоже - из C++0x.

нет, тут ничего в отдельной нитке не запускается

> да и для D реализация была, находил как-то

в Д можно так писать, только не знаю насчет void и перевычисляются ли они -- надо разобраться

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

Лисперы давно в нирване, с тобой на лоре как раз общается написанная ими сонливая макра.

>> было бы ещё совсем здорово, если бы в тред вернулись лисперы, и дали бы ещё макр на подумать и о них тоже...

> Лисперы в столь поздний час или спят или зохавывают мир, им не до тебя :)

Они интересные вещи говорят, но в практическую ценность чего-то из лиспа я не верю (разве что дебаг). Qi я конечно изучу, но по-моему это больше отмазка, чем реально юзаемая лисперами вещь.

>void конечно! (ради побочного эффекта юзается)

стоп. побочный эффект чего? вычисления x?

>Они интересные вещи говорят, но в практическую ценность чего-то из лиспа я не верю

практическую ценность CL (да и Scheme, в общем-то) я наблюдаю регулярно, во вполне себе продакшен-коде. практического использования Qi не видел ни разу - ни лисперами, ни функциональщиками

>Лисперы давно в нирване, с тобой на лоре как раз общается написанная ими сонливая макра.

я подозревал!

Кстати, gaa, ключевые аргументы нужны, но нихрена не понятно, как взаимодействовать с функциями, расчитанными на позиционные аргументы. И еще надо как-то вводить название ключевых параметров в сигнатуру функции. Я это как-то еще не додумал.

> стоп. побочный эффект чего? вычисления x?

ну конечно. а что?

>> Лисперы давно в нирване, с тобой на лоре как раз общается написанная ими сонливая макра.

> я подозревал!

http://www.linux.org.ru/jump-message.jsp?msgid=3594542&cid=3599744 %)

> И то, поскольку полноценный type inference для полного Питона довольно сложен (и никем не реализован), как бэ намекает, что type inference уменьшит его выразительность.

Есть и другие варианты. Обычно type inference делается под какой-то явный критерий (ну типа минимальный достаточный для ... тип), а тут может такого критерия вообще нет. Или не получилось... так или иначе (ЕМНИП вообще может даже критерий быть, но не вычислимый... если я не брежу)

>ну конечно. а что?

то есть на самом деле это процедура. со связанными аргументами. у нас тут call by name или мемоизация? сколько раз побочные эффекты получить можно?