Сергей Суровцев ©   (10.02.17 11:27) [73]


> В общем и целом да, до какого-то момента и вообще не отличаются.
>  Но дальше "дьявол в деталях".


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

>Игорь Шевченко ©   (10.02.17 13:51) [80]
>ты не генерацией кода занимаешься, а выполнением операций языка.

Вот именно. "Занимаешься", "ты", пошагово, построчно, сам, лично, ручками. По каждой операции. И вопросы хранения, доступа, обработки переменных, массивов, совместимости типов, вызова функций, проверка параметров, анализ и сообщения об ошибках и т.д. это только твое личное дело. И все это хозяйство не в виде скомпилированного кода, а в виде исходного. И надо чтобы по времени все это обрабатывалось приемлемо шустро. Тут и возникают вопросы оптимальной реализации.

> И все это хозяйство не в виде скомпилированного кода, а
> в виде исходного.


Все это хозяйство в виде синтаксического дерева.


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


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

Открой для себя Yacc.

>Юрий Зотов ©   (10.02.17 10:10) [66]
>Я тоже не встречал.

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

> Сергей Суровцев ©   (10.02.17 13:30) [79]
> >aka ©   (10.02.17 13:10) [77]Дело не в минусах. А в операциях.
>  --х судя по Сишному синтаксису интерпретатора тоже предполагается.
>  Как и ++х. Дело в том, чтобы не разрешать 2 и более подряд
> унарных операций. Кому сильно надо, есть скобки.

В Си++ знаки идущие рядом преобразуются в теги ещё на стадии препроцессинга.
-----ap преобразуется в набор тегов '--' '--' '-' 'ap'
А вот дальше грамматический анализ проверяет унарность операций. И в данном примере унарный минус тут только один. Но даже если каким-то чудом или за счёт использования пробела их было два. То компилятор бы начал ругаться.

По поводу запретить две и более унарных знака поддерживаю. Хотя насколько знаю в Си это сделано из-за указателей (унарный оператор '*').
'**' - это отдельный оператор.

> aka ©   (09.02.17 23:31) [57]
>
> Ну так даже проще в реализации. Но это с родни бессмысленности
> лишних символов, сюда же можно отнести пустые выражение
> (когда можем наставить сколь угодно ;;;;;;;). А зачем?

С одной стороны да. Но с другой никогда не знаешь каким боком тебе такие упрощения вылезут.

Например, в Делфи в отличие от С не обязательно писать скобки при вызове функций. В C надо писать
;, а в Делфи хватит и просто
. В большинстве случаев. Но в редких случаях в делфи эти скобки писать обязательно. И это вот неединообразие ведет к неочевидным на первый взгляд багам.

Синтаксис должен быть простым, предсказуемым и единообразным. Действие операторов не должно зависеть от контекста.

>Игорь Шевченко ©   (10.02.17 14:34) [82]
>Часть этих проблем решается на уровне анализа, часть на уровне исполняющей среды.

Игорь, прости, какой "исполняющей среды"?

> Сергей Суровцев ©   (10.02.17 14:18) [81]


> Тут и возникают вопросы оптимальной реализации.

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


> И вопросы хранения, доступа, обработки переменных,

Это решается семантическим деревом.


> совместимости типов

Решается на этапе преобразование в триграммы вернее в IR (внутренее представление).  


>  проверка параметров

Статическая типизация?

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

> Это решается семантическим деревом.

Когда строишь это дерево дублирующие данные заменяешь на ссылки.
Обращение по ссылкам уже оптимально O(1). Поэтому при исполнение всё будет быстро.

У тебя есть синтаксическое дерево с тегами к примеру 'MyVar'. Ты не знаешь к кой переменной они относятся так как у разных переменных может быть одно имя.
Надо обойти дерево и заменить теги ссылками на объявления переменных. Которое храниться в этом же дереве.

Запретив вложенные функции такой поиск объявлений сводиться к просмотру 4-х списков. Поиск в которых можно свести к O(1) при желании (Хэш таблицы).
А если не заморачиваться, то обход дерева с возвратом. Возврат нужен для поиска первого объявления так как бывают перекрывающиеся имена.  
Так как я не запрещал вложенные пришлось много кода править. Но не так много как кодогенирация.

Сергей Суровцев ©   (10.02.17 15:12) [86]


> Игорь, прости, какой "исполняющей среды"?


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

> [76] Сергей Суровцев ©   (10.02.17 12:31)
> Если заранее известно что "не надо так делать", значит не
> надо давать возможности "так делать".

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

> [81] Сергей Суровцев ©   (10.02.17 14:18)
> И все это хозяйство не в виде скомпилированного кода, а
> в виде исходного.

Вообще-то "скомпилированного" в дерево.

> [83] Сергей Суровцев ©   (10.02.17 14:39)
> >Юрий Зотов ©   (10.02.17 10:10) [66]
> >Я тоже не встречал.
>
> Вот это и странно. Большинство современных и популярных
> языков либо интерпретаторы, либо изначально были таковыми.

Я где-то видел интерпретатор Си. Не у того ли автора, что ИШ привёл?

> [84] Pavia ©   (10.02.17 14:42)
> В Си++ знаки идущие рядом преобразуются в теги ещё на стадии
> препроцессинга.
> -----ap преобразуется в набор тегов '--' '--' '-' 'ap'

Круто.

> [84] Pavia ©   (10.02.17 14:42)
> в Си это сделано из-за указателей

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

>Игорь Шевченко ©   (10.02.17 15:49) [89]
>Обычно выход интерпретатора - это набор инструкций для некоторой виртуальной исполняющей среды, которую тем или иным образом эмулируют на конкретном процессоре

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

> [84] Pavia ©   (10.02.17 14:42)
> '**' - это отдельный оператор.

Нет - это две операции.

> [95] Сергей Суровцев ©   (10.02.17 16:21)
> В середине либо построчная обработка

Язык Fort в этом смысле всех уел - и построчная и компиляция.:)

Сергей Суровцев ©   (10.02.17 16:21) [95]

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

> [96] Inovet ©   (10.02.17 16:33)
> > [84] Pavia ©   (10.02.17 14:42)
> > '**' - это отдельный оператор.
>
> Нет - это две операции.

А в Фотртане, да.