Синтаксический и лексический анализ.

bc

Во всех мануалах yacc/bison/etc в качестве примера реализуется калькулятор.

Пользовал muParser. Он, правда, для С++. В mathgl есть ещё нечто подобное.

Есть обёртка под C, и лицензия MIT.

Если выражение не будет преобразовываться, то всунуть его в виде текста в С-шный код и собрать gcc в виде отдельного модуля.

Если выражение будет преобразовываться - преобразовать его какой нить CAS, выгрузить результат в C-шный код и собрать gcc в виде отдельного модуля.

Или Вы хотите сказать, что выражение задается в формате не похожем ни на какой ЯП? А привести его к формату похожему на ЯП не проще будет?

В обычном формате будет - «1+2*a+sqrt(b)».
Собирание в виде отдельного модуля имхо слишком затратно.
muParser кажется реалистичней.

antlr - на жабе, но зато грамматику можно просто нарисовать и получить парсер

Я знаю про Книгу Дракона

Если нужно просто пособие по генерации AST, то в http://pragprog.com/book/tpdsl/language-implementation-patterns есть нужный материал. Там изложение на основе ANTLR и Java, но вполне доступно. Всю книгу читать не обязательно.

А если нужен просто калькулятор, то самый лучший пример калькулятора, который я видел - у Страуструпа. Recursive descent, без всяких внешних утилит. В ранних редакциях калькулятор был почти на Си :)

кстати, muParser жив ещё?

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

Понятия не имею. Использовал год назад, всё работало.

Тогда начни с примера Страуструпа. Если тебе всё-таки не нужно внуртрннее представление - это то, что доктор прописал. Если нужно - думаю, генерацию польского кода туда добавить нетрудно.

1. Парсишь на лексемы (это у нас число, это сложение)
2. Конвертишь в RPN
3. Реализуешь простенькую стековую машину
Можно уложиться в пару десятков строк.

Можно уложиться в пару десятков строк.

O_o

O_o

http://www.math.bas.bg/bantchev/place/rpn/rpn.c.html
Ну и парсер столько же примерно будет. Ну хотя да, побольше, чем пару десятков. А вообще (аналог сишного кода по ссылке):

calc :: String -> [Float]
calc = foldl f [] . words
  where 
    f (x:y:zs) "+" = (y + x):zs
    f (x:y:zs) "-" = (y - x):zs
    f (x:y:zs) "*" = (y * x):zs
    f (x:y:zs) "/" = (y / x):zs
    f xs y         = read y : xs

http://www.math.bas.bg/bantchev/place/rpn/rpn.c.html

Это RPN-калькулятор, _преобразования_ в RPN там нет.

_преобразования_ в RPN там нет

Ну так я написал, что парсер столько же примерно будет.

1. Парсишь на лексемы (это у нас число, это сложение)
2. Конвертишь в RPN
3. Реализуешь простенькую стековую машину
Можно уложиться в пару десятков строк.

Ну так я написал, что парсер столько же примерно будет.

Не вижу про «не считая парсера».

Не вижу про «не считая парсера».

1 и 2 пункты очень мило объединяются при реализации однопроходного алгоритма.
http://ru.wikipedia.org/wiki/Обратная_польская_запись#Преобразование_из_инфик...

1 и 2 пункты очень мило объединяются при реализации однопроходного алгоритма.

И? В 20 строк не уложишься ни при каком раскладе.

Собирание в виде отдельного модуля имхо слишком затратно.

А что потом планируется с ним делать?

Данное выражение довольно часто меняется, в этом дело.

насколько часто? запуск копийлера это доли секунды.

Не настолько часто значит. Пользователи вводят выражения, они вычисляются. Всё время генерировать новый модуль и подгружать его. А если не будет компилятора на рабочей машине?

Лорчую.

Ну другой, самый дешевый (по трудозатратам) путь, это взять ЯП где есть eval;-)

Есть на Делфи

времени нет пока

Так на свет появляется говно.

Вон из профессии.

Анонимус, ты лично выкопал руду, из которой смастерил свой компьютер и лично написал ОС, из-под которой написал это очень полезное сообщение? Я всё таки homo sapiens, а не человек повторяющий.

А в MathGL все таки проще

mglExpr f(«1+2*sqrt(x)»); printf(«result is %g\n», f.Eval(10));

Можно и переменные 'a'...'z' использовать. См. http://mathgl.sourceforge.net/doc_en/doc_en_70.html#Evaluate-expression

В Squeeze mathgl требует 7 пакетов, muParser - 2.

Не надо книг дракона и прочей давно устаревшей дребедени. PEG на Си пишется за пять минут. А в твоем случае и вообще тупейший рекурсивный LL(n) сойдет.

Программист, не умеющий писать парсеры и простые компиляторы - это вообще не программист, а отстой, так что ссылаться на «нет времени» просто гнило. На все задачи готовых решений не напасешься, а эта задача - одна из наиболее часто встречающихся, и умение это - одно из самых мощных (позволяет писать DSL, а это многократно повышает производительность труда).

Ты и арифметику в школе не учил под тем же предлогом, лошара?

В Squeeze mathgl требует 7 пакетов, muParser - 2.

Это вопросы к маинтайнеру. Собрать можно вообще без внешних зависимостей.

imtw не было проблем с muParserDLL.h, или ты не использовал её?

Использовал пару раз в лабах. Проблем не заметил.

Косяк с #include <muParserDLL.h> в нескольких файлах. Странно.

Плюсую. Нафига тебе готовое решение задачи, если парсер по методу рекурсивного спуска пишется на раз-два, руками? Да ещё и обратная польская нотация элементарно генерируется?

Учебные примеры лучше всего делать своими руками, так чётче в голове отложится. Конечно, потом можно и «готовое решение» присобачить — и сравнить ощущения. Например, взять bison/ANTLR/PEG в качестве «готовой» библиотеки, разобрать типичный элементарный пример — калькулятор на этих примерах, почувствовать разницу.

Но только потом.

Иначе ты ничему не научишься.

В качестве простого LALR-парсера, можно взять например, GOLD parser. Там из коробки много языков и примеров ( например ). ЕМНИП, и калькулятор есть.

Заодно, если повторить пример раза 4: «ручной» RDP парсер, PEG, LALR (gold/yacc/bison) , LL(k) парсер (ANTLR), GLR(bison,...) лучше поймёшь разницу.

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

А если нужен просто калькулятор, то самый лучший пример калькулятора, который я видел - у Страуструпа.

ещё Креншоу в «Давайте напишем компилятор» пишет компилятор какого-то паскаля на RDP парсере, написанном вручную

Хотя это довольно устаревшая книжка.