Re[24]: преимущества erlang-а?
От: EXO Россия http://www.az.inural.ru
Дата: 02.02.06 05:16
Оценка: +1
Здравствуйте, VladD2, Вы писали:
VD>Простая арифметика. 4 < 20. Ускорившись в 4 раза, я замедлюсь в 20. В тоге я все равно относительно замедлюсь.

Вот здесь похоже и есть точка непонимания.
У меня например, эта разница около 40%
Все остальные элементы спора — уже следствия.
Re[21]: преимущества erlang-а?
От: raskin Россия  
Дата: 02.02.06 05:42
Оценка:
VladD2 wrote:
> Здравствуйте, raskin, Вы писали:
>
> R>Гм, для того чтобы вызвать функцию 5 раз — причём параметры 5 вызова
> R>зависят от результата 4-го, я же не уверен в результате тестирования,
>
> Не понял, причем тут это? Нужно вызвать 5 раз — вызови пять раз.
Это пять запусков программы — я ещё не решил какие параметры.
>
> R>ещё надо выбирать при создании тип: консольное, вписывать write/print в
> R>зависимости от языка, и подключать модуль — который в некомпилируемом
> R>состоянии, так как интерфейс написан, а имплементация — нет.
>
> Это вопросы выбора языка. К вопросу интерпретации vs. компиляции
> отношения не имеющие. Нет проблем использовать компилируемую версию того
> же Питона из под VS 2005. Лично я предпочту Шарп, но это дело вкуса.
В программе на LISP просто пять вызовов функции не будут выводить
результат каждого без display, а вот в интерпретаторе будут.
>
> R>Или — alt-tab и вставить из буфера пару страниц кода (функция же требует
> R>предыдущую, согласен). Зависит от привычек, что лучше.
>
> А в клипборде то откуда возьмется? Вот пока будешь долбить без
> плноценного комплита и т.п. и офигешь.

Я рассматриваю ситуацию, когда от модуля есть куски, и я хочу прямо
сейчас их оттестировать. И они в файле лежат, причём редактирую я не в
MIT-Scheme Editor (например, потому что пишу не на MIT Scheme). А
комплит много где есть. Только в Nemerlish он такой странный (я пытался
убедить его напечатать за меня System.Console.WriteLine . Он победил).
Даже в ViM без настроек уже можно делать комплит по встречающимся словам
(нет ничего тупее), но в предположении написания и тестирования кода
мелкими кусочками комплит нужен не столько как подсказка, сколько как
сокращение набора.
Posted via RSDN NNTP Server 2.0
Re[17]: преимущества erlang-а?
От: EXO Россия http://www.az.inural.ru
Дата: 02.02.06 05:48
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Видимо птому, что они пишут на С++. А горбатого только могила...

Да нет, сейчас на C#.

VD>Мне кажется ты путашь причино-следственную связь. Это не Ява раскрутилась птому, что МС помогал. А МС начал помогать так как увидил, что Ява начала раскручиваться. А раскрутилась она так как перспективна


Я хорошо помню, какое сопротивление яве было в сообществе. И как тогда старались рекламисты микрософт.

VD>Если ты помнишь, то Яву талкали как средство создания аплетов, то есть как замену скриптам.


Очень недолго. Потом IBM громко закричал о северных задачах, а MS поддержал.

VD>Хм. Парсер есть у самого Нэмерла. Да и зачем "в кмплектациия"? В чем проблема скачать zip? Парсеры есть отдельные. От клонов yacc-а (Jey), до CocoR и ANTLD.


Кстати, посмотрел ANTLD. И обнаружил, что "знакомые все лица".
От своего предка — PCCTS он ушел не слишком далеко (а с последним я года полтора возился и глюки его знаю).
Так вот — наиболее критичный глюк основного алгоритма не исправлен.
Там токенайзер начинал вести себя странно, если требовалась глубина анализа больше 2.
То есть корректно компилировались только простые и очень однозначные грамматики.

VD>А каково Эрлэнгу и его ранайму?


Нормально.
Вот у меня сейчас на разработческой тачке для отладки запущен сервер + мнезия (с базой около полугига) + вебсервер.
Суммарно в памяти занимают 30 мег. При этом кеши мнезии не урезаны. Можно уплющить мег до 12, проиграв по быстродействию где-то в четверо. Если учесть, что на микрописишках базы обычно только "аварийного хранения" (дня на 4 — если в праздники оборвется связь с центральным сервером). То вполне можно жить.

VD>И что мешает развернуть тот же моно?


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


VD>Да и для бесплатной версии самое оно. Если у кого-то большие объемы, то ему и полноценный сервер купить не грех.


Вопрос в самих этих объемах.
В Штатах — да, граница где "лицензия sql уже не тяготит" проходит где-то в районе 4 гиг. В России денег у предприятий поменьше будет (некоторые сектора типа нефте-газа я не считаю). И граница эта колеблется примерно в районе 10-15 гиг.
Re[24]: преимущества erlang-а?
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 02.02.06 05:49
Оценка: 1 (1) +1 -1
VladD2,

VD>Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.


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

CAR и CDR — исторически сформировавшиеся и давно устоявшиеся названия. Если глянуть в историю, то всё становится достаточно логично:

The names have their origin in the first implementation of Lisp on an IBM 704 computer, and retain their primacy for purely nostalgic reasons. But on the 704, an atom was represented by a single 36-bit machine word containing a so-called address part and a decrement part. Each of these parts had a length of 15 bits. The address part was used to point to the head of a list and the decrement part was used to address its tail. The functions used to extract either part of a machine word were called car (Contents of Address of Register) and cdr (Contents of Decrement of Register).

http://en.wikipedia.org/wiki/Cadr

Кроме того ещё полезно прошвырнуться по листингам нетривиальных примеров Лисп программ и посмотреть, насколько часто там используются непосредственные манипуляции списками (то есть применение CAR/CDR) и насколько часто используются операции более высокого уровня.

structure-search-example.lisp, 4.5Kb — ни одного вхождения car/cdr
word-ladders.lisp, 4.5Kb — ни одного вхождения
backprop.lisp, 15Kb — ни одного вхождения
deftable.lisp, 12.5Kb — car=1, cdr=3
Gates.lisp, 6Kb — ни одного вхождения
blocks.lisp, 6.2Kb — ни одного вхождения
Simple-Metering.lisp, 21Kb — car=1, cdr=1
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[18]: преимущества erlang-а?
От: EXO Россия http://www.az.inural.ru
Дата: 02.02.06 05:55
Оценка:
Здравствуйте, EXO, Вы писали:
VD>>И что мешает развернуть тот же моно?
EXO>То, что оно пока не продукт промышленного качества.
EXO>Но пока рано.

Кстати, в дальнейшем я бы уж смотрел скорее сингулярити, чем моно.
Но тоже рано.
Re[19]: преимущества erlang-а?
От: raskin Россия  
Дата: 02.02.06 06:02
Оценка:
VladD2 wrote:
> Здравствуйте, raskin, Вы писали:
>
> R>Замечу, речь о Linux. Когда увидел, что Mono — родная для nemerle среда
> R>- скачал, скомпилировал.
>
> Боюсь, что Линукс интересен не многим. Тут же речь не о частном случае,
> а в общем, как я понимаю?
Я спрашивал, стоит ли мне на это смотреть (=> ставить).
>
> R>Ну, всё равно writeln набирать. Это — лишнее.
>
> Хм. Мы еще о необходимости интерпретаторов или уже о синтаксисе
> конретного языка?
А в каком языке при вычислении числа и его выкидывании оно выведется на
экран. Ладно, нужен не writeln, а echo, printf, whatsoever.
>
> R>Для меня посчитать чуть-чуть — не всегда про числа.
>
> Посчитать лучше на калькуляторе. А как считать не про числа, я и
> представить то боюсь.
На калькуляторе простейший конечный автомат обычно не пишется.
Рекурренты требуют искусства и не всегда поддаются описанию. И т.д.
>
> R>Гм, на КПК иногда хочется написать что-то, когда ноутбук далеко (дома),
> R>а розеток в десяти метрах не было никогда
>
> На КПК проблематично именно писать. Если ты пишешь одиним пальцем, то
> может тебе и пофигу. А я без клавы писать очень не люблю. Ноут и то
> неудобство вызвает. Я знаете ли привых к "натуральным" клавам.
Мне не по фигу (пишу и правда где-то пятью пальцами), но это лучше, чем
не мочь сделать очевидное действие.
>
> R>На КПК ещё и компилировать — слишком, будет тормозить сильнее
> R>интерпретатора.
>
> Современный КПК это обычно не ниже 200 мегагерц. Я копилровал С++- и
> Дельфи-проекты еще на 90-ом Пне. Так что...
Ну, даже 500. На 486-66МГц я тоже программировал. Впрочем, КПК — это
RISC, но всё равно получается больше, да. Однако на маленьком экране
тормозить буду ещё и я при компиляции (я так и не научился эффективно
переключать окна). Плюс к тому — в простых случаях интерпретатор даёт
ответ почти мгновенно. Компилятор ещё надо выбрать, чтобы линковка не
занимала по секунде, а есть ещё и просто затраты на управление им.
А Схема уже есть.
PS. Не буду я ставить Nemerlish на КПК. Секунда-другая на 2+2 — это
много. Хотя через полминуты после появления приглашения тормозить перестаёт.
>
> R>Мне просто ни одну ещё поставить без глюков не довелось.
>
> И МС-ную?
Вроде да. Глюкодром. КПК — VGA-шный. Перерисовка консоли не всегда
затрагивает левый край.
>
> R>Я никого не хочу расстраивать, но эта опечатка — точка с запятой,
> R>испортившая if. Не помню, был ли это Си или Си++. Даже посмотрев в
> R>отладчике, как if игнорируется, я не понял, что происходит. Почему этот
> R>код был легален??
>
> Ты про такой случай:
>
> class Program
> {
> static void Main()
> {
> bool OK = true;
>
> if (OK)
> ;
> }
> }
>
>
> Компилятор C# про это дело тебе сразу же заметит:
>
> Program.cs(8,4): warning CS0642: Possible mistaken empty statement
>
Наконец-то это стало warning. Мучительно не пойму, почему это исходно (в
Си) не error — если это нужное поведение, то всё равно можно писать if(){} .

> R>А про хлам.. Си-шарп даст генерировать generic-ами что угодно? Тогда его

> R>тоже надо докручивать — так же, как Паскаль. Немерле посмотрю.
>
> Дженерики == обобщенное программирование. К метапрограммированию, в
> отличии от шаблонов С++ они оношения не имеют.
Ну, можно сказать, что язык без метапрограммирования вообще сам по себе
не живёт. Его надо докручивать. Паскаль я уже докрутил. Что есть — ООП
исходно + метапрограммирование. + замена Make, так как появились новые
типы зависимостей.
>
> R>Паскаль читаем. Схема требует привычки для чтения, Си* тоже.
>
> С читаем не хуже Паскаля, если конечно в коде не используется
> выкрутасов. Даже мне синтаксис паскаля нравится намного меньше. В
> Обероне он намного продуманнее.
Дело вкуса. Мне Паскаль читать приятнее (равно как и Shell-скрипты), а
ALL-CAPS куски кода на Обероне, приводившиеся в Философии, когда я её
ещё читал, нервировали.


Что-то как-то я совсем написал не в тему исходной ветки.
Posted via RSDN NNTP Server 2.0
Re[23]: преимущества erlang-а?
От: the_void Швейцария  
Дата: 02.02.06 08:10
Оценка: 1 (1) +2 :)
Здравствуйте, VladD2, Вы писали:

VD>О том что ОКамл охринительный язык я понял когда пытаясь в нем разобраться не задал типы параметров и сделал какую-то ошибку. — моп твою ять — идумал я! — а вель еще говорят, что сообщения об ошибках в С++ запутаны!


Очень интересно, какую ошибку надо сделать, чтобы так подумать
Как правило, все сообщения об ошибках типизации в OCaml сводятся к
This expression has type ... but is here used with type ...
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[26]: преимущества erlang-а?
От: Programmierer AG  
Дата: 02.02.06 08:45
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Битвы, во первых, нет. "Титаны" прекрасно друг друга понимают, и спорить не собираются.

Ну это я так, для красного словца, и дабы подчеркнуть уважение, т.е. ключевое слово — титаны, а не битва .

G>Что же касается мета-макро-прочего — здесь у Немерле немного другой подход. По моим ощущениям, Camlp4 мощнее и гибче

Я, повторюсь, Немерле не видел. Просто мне различие уровня, на котором можно метапрограммировать в Немерле и в Camlp4, показалось существенным. Например, было бы неплохо, если бы в потоках не надо было отличать выражения-потоки и выражения-элементы синтаксически:
[<'elem1;stream1;'elem2;stream2>]

Это можно сделать только при наличии информации о типах. В данном случае это мелочь, но могут быть случаи, когда это окажется серьезным препятствием.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[23]: преимущества erlang-а?
От: Programmierer AG  
Дата: 02.02.06 09:18
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>О том что ОКамл охринительный язык я понял когда пытаясь в нем разобраться не задал типы параметров и сделал какую-то ошибку. — моп твою ять — идумал я! — а вель еще говорят, что сообщения об ошибках в С++ запутаны!


Да вы шо?
Сделаем откровенную глупость:
#include <map>

using namespace std;

int main() {
    std::map<int, int> m;

    m.insert( std::make_pair(&m, &m) );
    return 0;
}

Получим:
g++ qqq.cpp
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_pair.h: In constructor `std::pair<_T1, _T2>::pair(const
 std::pair<_U1, _U2>&) [with _U1 = std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >*,
 _U2 = std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >*, _T1 = const int, _T2 = int]':
qqq.cpp:8:   instantiated from here
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_pair.h:90: error: invalid conversion from `std::map<int, int,
 std::less<int>, std::allocator<std::pair<const int, int> > >* const' to `int'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_pair.h:90: error: invalid conversion from `std::map<int, int,
 std::less<int>, std::allocator<std::pair<const int, int> > >* const' to `int'

При этом любой плюс-плюсник, который не первый день с СТЛ, сразу найдет ошибку, т.к. знает, что из этого читать не надо.
В последней Visual Studio с этим значительно лучше, т.к. очень много усилий было затрачено на улучшение читабельности диагностики. Но вопрос принципиальный: в C++ шаблоны инстанцируются типами, типы могут рекурсивно вкладываться друг в друга, поэтому там запросто можно получить километровое имя типа (проблема то не в самом сообщении об ошибке, а в именах типов). В ML такое невозможно. Нужно только научиться читать типы функций и понимать, что такое currying.
Ну а в клинических случаях добавляешь аннотацию типа вручную, тогда скорее ткнут носом в проблемное место.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[24]: преимущества erlang-а?
От: gandalfgrey  
Дата: 02.02.06 09:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А ты думал я этот язык как идеал читабельности привел? Я просто показываю тебе, что минимализм синтаксиса не дает простоты. Это ошибочная предпосылка.

Язык должен быть легкочитаем, это понятно

VD>Простота это очень сложное комплексное понятие.

Это верно ! Но есть простые приближения к этой сложности

VD>Статистики нет. Но приблизительно могу сравнить. Работающую версию редактора кода с подсветкой синтаксиса я создал за месяц ненапряжного труда. В разы более ириметивную версию на С++ я создавал пол года. Конечно я стал более опытным, но и сейчас бы у меня ушло на это бы месяца 4 не менее. Правда и объем исходников существнно меньше получился. Но все же положительная динамика в скорости аписания есть.

Дык, я говорю не о скорости написания КОНЕЧНОГО ПРОДУКТА, а о скорости писания кода ! Вот в этом примере с редактором — ежели обьем кода на каждом языке разделить на время написания редактора на этом языке, не ролучатся ли близкие значения ?

VD>Но я то говорю о людях! У разных людей разная производительность. Иначе пофигу было бы кому писать романы, а кому шайбу гонять.

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

VD>Оно огромно! Моя производительность снижается на порядок если я пишу в нотпэде.

VD>Я готов отказаться от более продвинутого языка если есть менее продвинутый, но с отличной поддежкой среды. Ведь среда может компенсировать многие проблемы и дать огромный выирыш.
Это весьма редкий случай, как мне кажется. Обычно люди не придают заметного значения наличию или отсутствию среды. Разве что для ваяния ГУЯ

VD>Простая арифметика. 4 < 20. Ускорившись в 4 раза, я замедлюсь в 20. В тоге я все равно относительно замедлюсь. В бизнесе это называется упущенной выгодой. Ее може быть не заметно, но она есть.

А почему 20 ? Половина рабочего времени — это рабочий день / 2. То-есть будет общее ускорение в 4 / 2 раза.

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

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

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


VD>Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.

Ну, Лисп это еще не все языки
any(Pred, [H|T]) ->
    case Pred(H) of
        true  ->  true;
        false ->  any(Pred, T)
    end;
any(Pred, []) ->
    false.

Несколько более читаемо, правда ?

VD>Я придерживаюсь гипотизы, что для человека нет разницы между одно- двух-буквенными конструкциями и словами. Человек читает их какбудто распознает образы. Значимы обычно первая и последняя буква (поэтому в Лиспе так тяжело отличать CAR, CONS, CDR и т.п.).

Это близко к истине, на мой взгляд.
Re[27]: преимущества erlang-а?
От: Gaperton http://gaperton.livejournal.com
Дата: 02.02.06 09:35
Оценка: -1
Здравствуйте, Programmierer AG, Вы писали:

G>>Что же касается мета-макро-прочего — здесь у Немерле немного другой подход. По моим ощущениям, Camlp4 мощнее и гибче

PA>Я, повторюсь, Немерле не видел. Просто мне различие уровня, на котором можно метапрограммировать в Немерле и в Camlp4, показалось существенным. Например, было бы неплохо, если бы в потоках не надо было отличать выражения-потоки и выражения-элементы синтаксически:
PA>
PA>[<'elem1;stream1;'elem2;stream2>]
PA>

PA>Это можно сделать только при наличии информации о типах. В данном случае это мелочь, но могут быть случаи, когда это окажется серьезным препятствием.

С другой стороны — есть прямой контроль над грамматикой. Что круто, на самом деле. Например, я могу расширить синтаксис арифметики на любом уровне, если захочу. Синтаксис определения класса. И т.д. Любую мелочь — и всегда укажу точно, чего именно касается изменение. При большом желании — можно вмешаться и в семантический анализ, где доступна информация о типах, но это уже не так просто, и вроде как к camlp4 не относится. Сам понимаешь, чтобы была информация о типах, ее надо сначала вывести. Далее — расширения можно смешивать в произвольных сочетаниях, например — в одной программе можно использовать несколько конфликтующих друг с другом расширений языка (в разных модулях).

Короче, они разные. В nemerle более гражданский, прикладной подход, а в OCaml — более системный
Автор: Gaperton
Дата: 01.02.06
, штоли.
Re[24]: преимущества erlang-а?
От: little_alex  
Дата: 02.02.06 09:41
Оценка: 5 (1) +2
Системы основанные на макросах (или чем-то подобным : макросы lisp и C ,C++ templates ,latex) обладают обшим недостатков — в некоторых случаях сообщения об ошибках очень невразумительные.
Re[25]: преимущества erlang-а?
От: Quintanar Россия  
Дата: 02.02.06 10:10
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Q>>Берешь и вызываешь. Макросы ничем в этом смысле от функций не отличаются.

Q>>Лисп — это же не компилятор, а среда. Если в ней известны определенные функции на момент вызова макроса, то их можно вызвать.

VD>Это будет код макроса. А речь о внешних модулях. Хотя это конечно скорее разговор о поддежке компонентного подхода.


Не могу понять все равно о чем речь. Лисп компилирует иначе, чем С++ и прочие. Он просто загружает определения функций одно за другим в свою среду, поэтому в макросах ты можешь использовать абсолютно, что угодно, главное, чтобы это было загружено раньше.
Re[21]: преимущества erlang-а?
От: CrazyPit  
Дата: 02.02.06 13:32
Оценка:
Здравствуйте, Vermicious Knid, Вы писали:

VK> Т.е. при наличие совместимой версии компилятора "макросы" можно распространять без исходного текста.


В CL — аналогично.
Re[22]: преимущества erlang-а?
От: CrazyPit  
Дата: 02.02.06 13:35
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Vermicious Knid, Вы писали:


VD>...


VD>Во-во. И я о том же. Вот и не ясно, почему Лиспы и Эрланги тут пиарятся как будто за них приплачивают. А о столь неординарной вещи практически тишина.


Да немерле тоже очень хороший язык, просто пока менее применяемый — поэтому так. Только у него есть один большой недостаток и одновременно большое достоинство — он под .NET.
Re[19]: преимущества erlang-а?
От: CrazyPit  
Дата: 02.02.06 13:47
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>Хм. Может все же прще глянуть на то о чем речь идет? В студии почти как ты говоришь и сделано. Есть специальное окно "Immediate". Вводишь в него строку, жмешь Ввод и получашь результат. Консоль чистой воды.


Да типа этого.

VD> Только переключаться никуда не надо. Окно можно закрепить где удобно.

:)




VD>Есть все же некоторая разница между Лиспом и языками с синтаксисом. К тому же попробуй "так" отлаживать нечто требовательное к производительности. При отладке дотнетного прилоежения замедление получается раза в 2-6 по сравненю с релизом без отладчика. А вот интерпретация да еще и интерактивная — это от 10 и выше. Не все так можно отлаживать.


Нет. В лиспе это вполне может быть компиляция, а интерпретация (В SBCL — так всегда, а в CMUCL — опционально). Лисповый процесс загружен в память и функции по мере написания копилируються и помещаються в памать процесса без перезапуска. Т.е. я могу написать функцию нажать Crtl-c Ctrl-c. И в окне комадной стркоки тут же провести пару тестов с этой функцией (и она уже будет откомпилена). Вообще у этого всего есть названи — инкриментальная компиляция.

Пример:
http://img506.imageshack.us/img506/6694/lastss2mk.png
Re[21]: преимущества erlang-а?
От: CrazyPit  
Дата: 02.02.06 13:59
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Больше потому что уровень интеграции другой. В Лиспе макросы — это препроцессор. А в Нэмерле — это плагины к компилятору.


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


Если имеете ввиду лисп. То макрос тоже может использовать любой бибилотечный код, и вообще всё что угодно.
Вполне можно написать макрос который в момент компиляции обращаеться к астрологическому интернет ресурсу. И генерирует различный код взависимсости от фазы луны и положения марса относительно солнца:)
Re[23]: преимущества erlang-а?
От: CrazyPit  
Дата: 02.02.06 14:22
Оценка: 8 (2)
Здравствуйте, VladD2, Вы писали:

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


R>>Ну внешний код, как мне казалось, и для Лиспа не вопрос.


VD>Покажи, плиз, как на Лиспе вызвать внешний код из макроса?


(defparameter *a-site* "astrology.org")

(defmacro defun-moon (name args  &body body)
  (let ((moon-phase (astrology:get-moon-phase *a-site*)))
    (case moon-phase
      (:full `(defun ,name ,args ....
           ))
      ....
      ....
      (:none `(progn
           (setf *dark* t)
           (print "moon defun does not work in new moon"))))))

(defun-moon blah (x y)
  .....)


Более релаьный прмер. Теоритически можно делать вообще так:

(def-ruby-func "
def x(a,b)
  c = 10 + a
  b * c
end
")


которая во время компиляции, используя вненший транслятор, преобразуеться в:
(defun x (a b)
  (let (c (+ 10 a))
        (* b c)))
Re[24]: преимущества erlang-а?
От: CrazyPit  
Дата: 02.02.06 14:28
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.


Есть синонимы first & rest. А Car cdr удобно, т.к. есть функции типа caddr аналогичные (car (cdr (cdr ...)).
Re[18]: преимущества erlang-а?
От: Arioch  
Дата: 02.02.06 17:12
Оценка:
On Thu, 02 Feb 2006 08:48:29 +0300, EXO <41956@users.rsdn.ru> wrote:

> VD>И что мешает развернуть тот же моно?

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

dotGNU бегает на разном железе, зато он еще менее промышленный, чем Mono

Его, собственно и создавали ,как во-первых быстрый легко потртируемый
интерпретатор, а уже потом JIT :D

> граница эта колеблется примерно в районе 10-15 гиг.


Вы же говорили про сотни гигов ?
на 10/15 вроде бегают бесплатные Firebird, Postgress, etc


--
Отправлено M2, революционной почтовой программой Opera:
http://www.opera.com/mail/
Posted via RSDN NNTP Server 2.0
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.