Как грамотно написать интерпретатор?

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

Как грамотно написать интерпретатор?

Александр Попов, вообще советую почитать
https://tc39.github.io/ecma262
dmitrysoshnikov.com/ecmascript/es5-chapter-3-1-lex...

Как грамотно написать интерпретатор?

Александр Попов,

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

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

Как грамотно написать интерпретатор?

То есть я к тому что для работы с замыканиями как мне кажется тебе в любом случае придётся в самом объекте скоупа хранить ссылку на родительский скоуп.
Я делал это так: при создании функции в объекте функции сохраняется ссылка на скоуп в котором функция была создана (closure), потом при вызове функции есть хешмап со значениями переданными в качестве аргументов (argsdict) и также при вызове передаётся собственно скоуп в котором функция вызывается (scope). Соответственно при попытке получить переменную из тела функции порядок был таким: argsdict -> closure -> scope. Это правда не совсем оптимально, потому что фактически у closure и scope часть "предков" - общие, и по ним алгоритм проходился дважды. О том как не проходить по ним дважды тоже надо будет подумать тебе, ну в принципе ничего сложного по идее.

Как грамотно написать интерпретатор?

Вообще я не очень понимаю твою идею со скоупами. Типа во время вызова функции на стек кладётся новый хешмап, а после возвращения значения убирается со стека? А как же замыкания? Или-таки я неправильно понял твою идею?

Как грамотно написать интерпретатор?

Ещё кстати надо как-то обрабатывать исключения. Я бы сделал так что все выражения возвращают не JsValue а какой-нибудь JsResult - аналог Result в Rust или Either в Haskell. Если вкратце, то у JsResult при таком подходе должно быть два наследника - JsOk, хранящий значение (JsValue) и JsError, хранящий ошибку и всякую дополнительную информацию.

Как грамотно написать интерпретатор?

Александр Попов,
1. Ну тут просто смысл в том что в рантайме обрабатывать попытку "вызова" значений, которые вызывать нельзя, все равно надо, а через оверрайдинг, как мне кажется, это делать удобнее всего.
2. Так нет, если функция пишет переменную без var, переменная не пишется сразу в родительский скоуп. Интерпретатор прыгает по родительским скоупам пока не найдёт где-то объявленную переменную с таким именем, и только если он так по цепочке скоупов дойдёт до глобального и нигде не найдёт такую переменную, то создаст новую в глобальном. Ну и да, ссылку на root scope не проблема хранить и при моём подходе.

Java или C++ в качестве первого языка. Что выбрать?

Rust классный, но начинать всё же я считаю стоит с чего-то более популярного и с автоматической сборкой мусора. С той же Java, например.

Как сделать документацию к коду?

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

Как сделать документацию к коду?

Alex Wells, я вот типа ни разу не защитник JS, но ругать JS и приводить в пример PHP - такое.

Как сделать документацию к коду?

Alex Wells, очень странное заявление, особенно учитывая что речь идёт о документации, а это к конкретному языку программирования прямого отношения не имеет. На JS точно также можно писать (по крайней мере, относительно) самодокументируемый код, писать JSDoc-комментарии и генерировать документацию из них, писать юнит-тесты.

Как корректно получить вчерашнюю дату в Python?

вчера было 31 ноября 2017 года
не благодари

В каких случаях использовать ООП?

Модератор, но если человек думает что если вместо простой функции сделать статический метод класса, то это ООП - тогда он точно не знает что такое ООП.

В каких случаях использовать ООП?

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

В каких случаях использовать ООП?

vasIvas, лол, это Вы с ООП вообще не знакомы, раз у Вас наличие изменяемых переменных означает ООП.

В каких случаях использовать ООП?

vasIvas, я же написал про State, Reader, Writer. Так и хранится.

В каких случаях использовать ООП?

vasIvas, я Вам уже ответил на этот вопрос, читайте внимательнее.

В каких случаях использовать ООП?

vasIvas, собственно для работы с неким состоянием (контекстом) в чисто функциональных языках и используют монады State, Reader, Writer. Состояние там на самом деле, конечно, неизменяемое, но работа с ними похожа на работу с изменяемым состоянием.

В каких случаях использовать ООП?

vasIvas, поясню на примере. Зачастую к важным подходам ООП относят позднее связывание (и, соответственно, dependency injection). В Java/C#/... это реализовано в виде всяких IoC-контейнеров. В Haskell/Idris/... - в виде монады Reader. Вот это пример того как одна и та же концепция ООП может быть реализована как в императивном стиле, так и в функциональном.

В каких случаях использовать ООП?

vasIvas, Вы вообще видели функциональный код? Как вы его без if представляете? Откуда эта мысль взялась вообще я не понимаю. В чисто функциональном Haskell есть if. Другой вопрос, что там if - выражение, возвращающее результат. И это удобно, это и в императивных языках сейчас встречается, вроде Rust или Kotlin.

Я не разглядываю в ООП признаки ФП, я говорю что ООП не зависит от того как логика реализована на низком уровне.

Если Вы пишите код с var, let то это уже ооп

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