- innuendo
- Постоялец
TarasB
> Я сваливаю из этой темы, потому с такими, как ты, разговаривать вообще западло.
западло наезжать на других :)
0iStalker
switch(op) { case 1: std::cout<<"+"; break; case 2: std::cout<<"-"; break; case 3: std::cout<<"*"; break; case 4: std::cout<<"/"; break; }
Это говнокод. Лучше так:
char operations[]={'+', '-', '*', '/'}; std::cout << operations[op-1];
Соглашусь с innuendo. Lisp, если уметь им пользоваться, может быть весьма не плох в этой области.
Естественная "польская нотация" на уровне языка для обработки выражений; данные как код; макросы, затачивающие язык под разбор языков; и может быть для некоторых разрабатываемых языков динамическая типизация - могут сыграть свою положительную роль.
Интерпретатор Lisp На Lisp, может есть и меньше:
http://lisp.ru/forums.php?m=posts&p=545#545
evalquote[fn;x] = apply[fn;x;NIL]
where
apply[fn;x;a] =
[atom[fn] -> [eq[fn;CAR] -> caar[x];
eq[fn;CDR] -> cdar[x];
eq[fn;CONS] -> cons[car[x];cadr[x]];
eq[fn;ATOM] -> atom[car[x]];
eq[fn;EQ] -> eq[car[x];cadr[x]];
T -> apply[eval[fn;a];x;a]];
eq[car[fn];LAMBDA] -> eval[caddr[fn];parlis[cadr[fn];x;a]];
eq[car[fn];LABEL] -> apply[caddr[fn];x;cons[cons[cadr[fn];
caddr[fn]];a]]]
eval[e;a] = [atom[e] -> cdr[assoc[e;a]];
atom[car[e]] ->
[eq[car[e],QUOTE] -> cadr[e];
eq[car[e];COND] -> evcon[cdr[e];a];
T -> apply[car[e];evlis[cdr[e];a];a]];
T -> apply[car[e];evlis[cdr[e];a];a]]
evcon[c;a] = [eval[caar[c];a] -> eval[cadar[c];a];
T -> evcon[cdr[c];a]]
evlis[m;a] = [null[m] -> NIL;
T -> cons[eval[car[m];a];evlis[cdr[m];a]]]laMer007
Ну раз ты согласен с ним то расскажи за счет чего лисп может быть лучше немерла.
chucheloid
> Ну раз ты согласен с ним то расскажи за счет чего лисп может быть лучше немерла.
2-3 пункта, которых нет в Nemerle, я уже перечислил в своём посте. Ими как раз Lisp будет лучше Nemerle. Но вот вопрос, может по каким то пунктам Lisp Nemerl'у тоже проиграет.
Ну вот "язык" с моим уровнем пока легче будет на Nemerle написать. Те же макросы в Nemerle есть. И даже есть готовые парсеры на макросах (даже в стандартной библиотеке) Nemerle.
chucheloid
> Ну раз ты согласен с ним то расскажи за счет чего лисп может быть лучше
> немерла.
ну раз ты не согласен - то докажи обратное :)
0iStalker
> основная работа
> распарсить исходный код
> и составить дерево разбора
> Потом, используя это дерево, - применив к нему, при
> обходе узлов, 100500 проверок (определены ли используемые переменные/функции,
> совпадают ли типы присваиваемых значений - типам переменных, попадают ли
> числовые данные в свои диапазоны, итд, итп - можно собственно сгенерировать
> нужный нам код (либо бинарный, либо исходный другого языка). То же самое
> дерево разбора используется для подсветки синтаксиса в IDE,... только тут ещё
> нужна продвинутая система восстановления после ошибок.
я вот давно задумываюсь, что представление исходного кода в виде просто последовательности букв - плохая идея.
почему? да потому что нужно потом делать кучу проверок (валидации кода): является ли эта куча букв и цифр программой? синтаксически верной программой? логически-непротиворечивой программой?
например нашли несоответствие - теперь нужно создавать целую классификацию ошибок и сообщать о найденных ошибках программисту.
а учитывая, что стадий несколько, то и классификаций ошибок тоже несколько, и нужно тащить информацию о месте (файле, номерах строки и символа) через лексер-парсер-оптимизатор AST.
моя точка зрения в том, что лучшая защита от ошибок - исключение причин их появления, а не борьба с уже существующими.
т.е. не давать вводить невалидный код различными способами, от визардов, сниппетов и шаблонов кода, автокомплита до построения самого языка таким образом, чтобы максимально уменьшать неоднозначности и рутинную набивку кода.
laMer007
>2-3 пункта, которых нет в Nemerle, я уже перечислил в своём посте.
То, что ты перечислил, к делу не относится. Либо немерле умеет не хуже.
А динамическая типизация это зло. Всегда.
ffinder
>я вот давно задумываюсь, что представление исходного кода в виде просто последовательности букв - плохая идея.
Все попытки уйти от текста провалились с треском.
ffinder
>оно называется interoperability с сишным и плюсовым кодом, потому что куча нужных библиотек написана на С/С++.
>и тут появляется две возможности:
>1. писать под всё врапперы. упаришся писать на самом деле. библиотек много, а рук всего две.
>2. делать утилиту для автоматического импорта, чтобы умела парсить сишные хэдеры (макросы это одна беда, а вот плюсовые шаблоны это уже не шутка).
Есть более простой способ: пишешь парсер упрощенного Си/C++ и копируешь туда все определения из *.h с минимумом изменений.
Далее есть два варианта: либо после парсинга создавать автоматом функции-переходники, либо создавать машинный код этих функций уже во время исполнения.
chucheloid
> > -3 пункта, которых нет в Nemerle, я уже перечислил в своём посте.
> То, что ты перечислил, к делу не относится. Либо немерле умеет не хуже.
лишь потешить бы себя, что немерли крут ?
> А динамическая типизация это зло. Всегда.
с вами не согласны афторы динамиков :)
Например, есть твоя функция, объявленная на твоем языке, но реализованная на Си:
function MyFunction (MyInt a, MyString b);
Создаем такой код переходника:
MyFunction:
push [a]
call MyIntToInt
push eax
push [ b ]
call MyStringToPChar
push eax
call MyFunction_C ; вызываем int MyFunction_C (int, char*)
add esp, 8
Для такой функции достаточно всего несколько машинных инструкций, а работает быстро.
innuendo
> с вами не согласны афторы динамиков :)
Может потому, что вывод типов только счас получил достаточное освещение и распространение?
Grey304
> > с вами не согласны афторы динамиков :)
> Может потому, что вывод типов только счас получил достаточное освещение и
> распространение?
а 20-30 лет назад никто и не знал про это ?
Grey304
Для того чтобы сделать вывод типов нужно очень много знать. А если мы говорим про вывод типов в языке, где есть перегрузка функций и неявное приведение типов то это рокет-сайнс шо писец.
Для того чтобы написать интерпретатор динамически типизированного языка достаточно базовых навыков программирования.
chucheloid
> Все попытки уйти от текста провалились с треском.
только на моей памяти успешных было две:
Spectrum Basic (c) 1982 Sinclair Research Limited - токены вводились нажатием одной клавиши, синтаксический и лексический анализ проводились при нажатии клавиши Enter, подсвечивая места ошибок, и не давая продолжать ввод программы в случае их обнаружения
QBasic (c) Microsoft Corporation - при вводе строки она сразу же парсится и форматируется.
так что не надо про треск, ок?
Тема в архиве.