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

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

По-моему, это язык делается таким, чтобы с ним справлялся type inference. Python таким не сделали.

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

Как там в Д, я не помню.

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

Если используется редко --- оставить как есть, если часто --- написать Ъ-обёртку (что-то сиплюсплюсом запахло, откройте форточку :) ).

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

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

class CoolFun {
public:
CoolFun();
~CoolFun();

void setDir (const string &);
void setMailBox (const string &);

list<Messages> operator ();
};

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

Кстати, помня твоё желание видеть гибкия язык с простым вызовом функций из внешних библиотек: http://wiki.tcl.tk/1197

> По-моему, это язык делается таким, чтобы с ним справлялся type inference. Python таким не сделали.

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

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

>Как там в Д, я не помню.

если много раз, то надо ещё как-то контролировать идемпотентность сайд-эффектов :) в Slice (IDL для ZeroC ICE), помнится, для этого отдельный квалификатор ввели

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

> Для динамических языков сигнатура вроде бы ни к чему, а для сиплюсплюса как-то так:

Ну во-первых для плюсов (как всегда, гы-гы-гы) есть костыль, который дает именованные параметры, например messages(dir="asdf",mailbox="input"), а я веду речь (как говорил ден73) о языке мечты, где все правильно сделано.

> Ну во-первых для плюсов (как всегда, гы-гы-гы) есть костыль, который дает именованные параметры, например messages(dir="asdf",mailbox="input"), а я веду речь (как говорил ден73) о языке мечты, где все правильно сделано.

Значит да, они должны быть частью сигнатуры.

точнее даже можно так:

int dir=1; int messages=2;

vector<string> m = ns::messages(dir="asdf",mailbox="input");

> Значит да, они должны быть частью сигнатуры.

Что я и писал несколько постов назад.

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

Придумай мне хоть какой-нибудь макрос в Хаскелле (ты же его честь отстаиваешь в этом бреду на последних страницах?), который бы имел синтаксис основного языка и полноценно (с рекурсивными экспандами, сессно) выполнялся бы ещё в компайл-тайме. Очевидно, что все варианты препроцессоров и темплейтов на макросы не тянут.

Например, в CL макрос loop или iter (уже не CL, к сожалению) в компайл-тайме макроэкспандом разворачивается в код, который выполняет только то, что этим макросом описано, т.е. натурально генерирует исходный код для компилятора.

Я, кстати, видел плюсатый код знакомого маньяка, который в компайл-тайме считал простенькое мат.выражение. Но являло это собой полное говнище в исходниках, компилировалось только одним компилятором с определённым патчсетом и жрало памяти просто неимоверно. И всё равно это даже отдалённо не макросы :)

Я не про то, что так можно сделать.
Тем более что нельзя, в хаскеле нет unwind-protect.
Я про то, что напишите на своем m4 простенький 'шаблонный' макрос, который раскрывался бы в открытие файла, закрытие его в конце области видимости, и хендлинг исключений во время.

> Придумай мне хоть какой-нибудь макрос в Хаскелле , который бы имел синтаксис основного языка и полноценно (с рекурсивными экспандами, сессно) выполнялся бы ещё в компайл-тайме. Очевидно, что все варианты препроцессоров и темплейтов на макросы не тянут.

К слову, а что это в лиспе за разброд и шатание с макросами? Почему они не являются типичной процедурой основного языка? А то получается неравномерность как у плюсов с их темплейтами.

Что ты имеешь в виду под разбродом и шатанием?

> Что ты имеешь в виду под разбродом и шатанием?

То, что макра!=функция. Я ведь не ошибся и это на самом деле так?

Фактически, макрос - это функция. Она выполняется в компайл-тайм и оперирует исходным текстом.

> Фактически, макрос - это функция. Она выполняется в компайл-тайм и оперирует исходным текстом.

Ну вот, собственно, это мне и кажется "шатанием". Как-то неоднородно.
Получается две возможности решения одного и того же (через макры и функции), что может привести к неудобствам при попытке два этих метода смешать. Да и с кодом макры в райтайме не поработаешь.

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

Не понимаю, про что ты?

> Да и с кодом макры в райтайме не поработаешь.

Почему это?

(eval '(defmacro entity (x) `,x)) или (eval (read-from-string "(defmacro entity (x) `,x)"))

(macroexpand (entity 1))

=> 1, NIL

Всё то же самое.

>Придумай мне хоть какой-нибудь макрос в Хаскелле (ты же его честь 
отстаиваешь в этом бреду на последних страницах?), который бы имел 
синтаксис основного языка и полноценно (с рекурсивными экспандами, 
сессно) выполнялся бы ещё в компайл-тайме. Очевидно, что все варианты 
препроцессоров и темплейтов на макросы не тянут. 

cnst 0 str = lift str
cnst n str = do e <- cnst (n-1) str
                [| \_ -> $e |]

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

>Я, кстати, видел плюсатый код знакомого маньяка, который в 
компайл-тайме считал простенькое мат.выражение. Но являло это собой 
полное говнище в исходниках, компилировалось только одним компилятором 
с определённым патчсетом и жрало памяти просто неимоверно. И всё равно 
это даже отдалённо не макросы :)

это всё чудесно, и я тоже такое писал. вот только в Haskell оно
попроще получается. эдак на порядок

cnst 0 str = [| str |]
cnst n str = [| \_ -> $(cnst (n-1) str) |]

упрощённый вариант того же шаблона

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

Что-то типа.

>Тем более что нельзя, в хаскеле нет unwind-protect

почитал про unwind-protect, не понял что же он такого делает, чего не делает тот же bracket

>Я про то, что напишите на своем m4 простенький 'шаблонный' макрос, который раскрывался бы в открытие файла, закрытие его в конце области видимости, и хендлинг исключений во время.

а я про то, что до сих пор все примеры макр CL выполняют работу костылей - всё то же самое можно сделать и без их использования (или с использованием шаблонов). я никоим образом не пытаюсь наехать на CL и лисперов, я просто хочу понять - что можно сделать на CL и чего я при всём желании не смогу сделать на Haskell/TH. желательно чтобы это что-то имело практическую пользу, а не было бы подпоркой макросистемы CL (вроде проблемы захвата имён)

Ты отрицаешь макросы, как идею метапрограммирования, или сравниваешь их с темплейтами в хаскелле?

Судя по прочитанному по диагонали про th, этого вполне достаточно для нормального meta. Отличия от лисповских макросов не искал, кроме того, что лисповым макросам ~40 лет, и всё, кто хотел, могли скопировать и улучшить эту идею.

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

>Ты отрицаешь макросы, как идею метапрограммирования, или сравниваешь их с темплейтами в хаскелле?

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

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

у меня Tcl одним из основных используемых языков. необходимость в динамике я понимаю хорошо

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

где можно посмотреть на хотя бы сотню программистов на Haskell? :) кроме как на c.l.haskell или #haskell at FreeNode. как-то моды не заметно

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

С помощью макросов (если ещё точнее, то eval-when) можно выполнять код на различных стадиях. Сколько десятков лет существует template haskell? ;) Возможно, люди по привычке продолжают так говорить. 40 лет, всё-таки...

> необходимость в динамике я понимаю хорошо

Объясни. Я вот в ней принципиальной необходимости не вижу совсем. Практическую - да, но не принципиальную.

Вот, кстати, ещё вопрос... При всей своей правильности, как языка, почему у Хаскелля не самый лучший компилятор? Он ведь статически типизированный, без сайдэффектов, какой простор для оптимизаций. Где-то на просторах ЖЖ видел дизассемблированный дамп, ну откровенно слабые места видно на глаз.

>Объясни. Я вот в ней принципиальной необходимости не вижу совсем. Практическую - да, но не принципиальную.

представь себе Linux без Bash. с компилируемым языком комманд. до сих пор не видишь необходимости?

Принципиально вычислительная техника не нужна, но практически это удобно =)

>> Объясни. Я вот в ней принципиальной необходимости не вижу совсем. Практическую - да, но не принципиальную.

> представь себе Linux без Bash

А без аналогий? Представить - как нефиг делать. Это, правда, будет уже не Линукс.

> с компилируемым языком комманд.

Ты не это хотел сказать, правда? А то ipython - вполне компилируемый язык команд.

>Вот, кстати, ещё вопрос... При всей своей правильности, как языка, почему у Хаскелля не самый лучший компилятор? Он ведь статически типизированный, без сайдэффектов, какой простор для оптимизаций. Где-то на просторах ЖЖ видел дизассемблированный дамп, ну откровенно слабые места видно на глаз.

про GHC мне говорить сложно :) он слишком большой, чтобы я мог нормально его комментировать. но качество генерируемого кода - да, качество там такое себе. мне рассказывали про by design проблемы его оптимизатора, но подробностей не помню

очень интересная разработка JHC. если проект не умрёт и его таки отладят, у него шансов на промышленное применение будет куда больше:

http://repetae.net/computer/jhc/

> Принципиально вычислительная техника не нужна, но практически это удобно =)

Блин, да вы поэты оба двое. Так и сыплете метафорами O_o

Т.е., на данный момент, Хаскелль - это такая же маргинальщина для мейнстрима, как и CL? С неясным будущим, при том...

> Блин, да вы поэты оба двое. Так и сыплете метафорами O_o

А что ты хочешь в ответ про *принципиальность* услышать? :)

> что ты хочешь в ответ про *принципиальность* услышать? :)

Если бы я знал, что именно хочу услышать, то я бы знал, зачем необходима динамика.

Use-case, который невозможно сделать на статике, меня бы устроил (только не надо про определение классов в рантайме - это элементарно делается, если компилятор доступен в виде библиотеки).

> Use-case, который невозможно сделать на статике

Твой пример с "элементарностью" в виде доступности компилятора на библиотечном уровне уже говорит, что проще это сделать на языке, у которого eval/compile встроенные. Дело не в принципильной невозможности, а в кол-ве энтропии, которое на решение проблемы потратится.

> пример с "элементарностью" в виде доступности компилятора на библиотечном уровне уже говорит, что проще это сделать на языке, у которого eval/compile встроенные.

Не совсем так. Практика говорит, что eval проще реализовать в динамическом языке, но не более. Я лично не вижу, почему eval невозможен в статическом языке. У Ocaml есть toplevel, у haskell - GHCi.

> Не совсем так. Практика говорит, что eval проще реализовать в динамическом языке, но не более. Я лично не вижу, почему eval невозможен в статическом языке. У Ocaml есть toplevel, у haskell - GHCi.

Речь идёт про энтропию.

> http://repetae.net/computer/jhc/

Produces 100% portable ISO C. Закопайте.

>> http://repetae.net/computer/jhc/

> Produces 100% portable ISO C. Закопайте.

Си++ начал с этого и зохавал весь мир. Хотя да, Хаскел лучше бы закопать^Wоставить академикам.

>Produces 100% portable ISO C. Закопайте.

это ещё почему?

>Си++ начал с этого и зохавал весь мир

C++ и 100% portable - это оксюморон

>> Си++ начал с этого и зохавал весь мир

> C++ и 100% portable - это оксюморон

Не более, чем 100% portable Haskell.

Непонятно, правда, причем тут Си++ - речь шла о сгенерированном Си-коде.

>Хаскелль - это такая же маргинальщина

У них в "целях" записано, избегать популярности любой ценой.

>Непонятно, правда, причем тут Си++ - речь шла о сгенерированном Си-коде

я о том же. про C++ ты речь завёл, не я. в генерации C ничего плохого я не вижу, даже наоборот

> про C++ ты речь завёл, не я

Ну если ты не видишь аналогии между Cfront и JHC, тогда ой.

> в генерации C ничего плохого я не вижу, даже наоборот

Я и не говорил, что это плохо (хотя это не очень хорошо, наверное :D).

>> Ну вот, собственно, это мне и кажется "шатанием". Как-то неоднородно. Получается две возможности решения одного и того же (через макры и функции), что может привести к неудобствам при попытке два этих метода смешать.
> Не понимаю, про что ты?

Макры из функций вызывать вроде можно. А функции из макр? Если нет, то постоянно придётся помнить, что какой-то кусок кода может быть использован в макрах и писать его на макрах.

>> Да и с кодом макры в райтайме не поработаешь.
> Почему это?

То, что ты привёл --- не работа с кодом, а вызов кода на исполнение. Вот в Tcl есть [info body], которая для любой функции вернёт её тело как текст, т.е. исходный код именно в том виде, как я его написал.

>Ну если ты не видишь аналогии между Cfront и JHC, тогда ой

уже вижу :) но CFront нынче где?

>Я и не говорил, что это плохо

это говорил не ты. но тем не менее

>Вот в Tcl есть...

в Tcl есть всё :) кстати, никто ещё не додумался реализовать CL (или хотя бы CLOS) на Tcl? было бы забавно

> Макры из функций вызывать вроде можно. А функции из макр?

Конечно.