Комментарии 35
Почему СОМОбъект, а не КОМОбъект?:) И первые три буквы русские или латинские?
Латинские. Это стандартное название конструктора COM, взятое из 1С. Хотя, конечно «КОМ» можно было перевести, как Компонентная Объектная Модель.
НЛО прилетело и опубликовало эту надпись здесь
Старый добрый Not Invented Here!
Для поиграться — прекрасно, а для отдать в продакшен (другу попользоваться) — зло.
Это же сразу потерять всю базу знаний и сообщество пользователей известных языков и открыть разум для дефектов языка и багов транслятора и среды исполнения.
Те же области видимости — это тихий ужас, который авторы каждого языка били-били-недобили (что лисп, что питон, что яваскрипт — всюду реализации с приколами).
Для поиграться — прекрасно, а для отдать в продакшен (другу попользоваться) — зло.
Это же сразу потерять всю базу знаний и сообщество пользователей известных языков и открыть разум для дефектов языка и багов транслятора и среды исполнения.
Те же области видимости — это тихий ужас, который авторы каждого языка били-били-недобили (что лисп, что питон, что яваскрипт — всюду реализации с приколами).
Старый добрый Not Invented Here!
Ну разумеется, это он. Я вроде бы написал, что изначальный интерес — исследовательский. Просто мне делать что-то интереснее, когда цель звучит конкретно и имеет прикладной смысл. Я ни разу не претендую на завоевание какой-то ниши среди языков. А инженер, с которого это началось уже освоил VBScript.
Старый добрый Not Invented Here!
— You are saying it like it is something wrong!
— You are saying it like it is something wrong!
Те же области видимости — это тихий ужас, который авторы каждого языка били-били-недобили (что лисп, что питон, что яваскрипт — всюду реализации с приколами).Раскройте, пожалуйста, мысль.
lambdas = [lambda a: a + i for i in xrange(5)]
[l(1) for l in lambdas]
# [5, 5, 5, 5, 5]
Ну замыкания, что тут такого.
Тут можно поспорить, областью видимости переменной из list comprehensions должная быть одна итерация цикла или весь цикл. Но в данном случае в питоне всё ещё веселее. Областью видимости такой переменной будет та, где был расположен цикл:
Как в старом добром Паскале — если случайно во внутреннем цикле используешь ту же переменную — что во внешнем, то сразу наступишь на грабли.
>>> lambdas = [lambda a: a + i for i in xrange(5)]
>>> [l(1) for l in lambdas]
[5, 5, 5, 5, 5]
>>> a
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
>>> i
4
>>> l
<function <lambda> at 0x02402D30>
>>>
Как в старом добром Паскале — если случайно во внутреннем цикле используешь ту же переменную — что во внешнем, то сразу наступишь на грабли.
Обходить конкретно эти грабли принято с помощью функции высшего порядка, введя таким образом промежуточный scope:
Мне больше нравится как в C++ оно работает. Хочешь — захватываешь по значению, тогда всё работает предсказуемо. Хочешь — по ссылке, но тогда имей в виду что её время жизни не продлевается. Хочешь — сделай shared_ptr и захватывай его по значению.
В Java чтобы люди не путались запретили не final переменные захватывать.
А в Python как-то ни рыба ни мясо. Захват по read-only reference-counted ссылке (причём ссылка второго порядка: она ссылается на переменную, а не на сам объект: если извне в переменную записать ссылку на новый объект — в замыкании оно тоже поменяется).
>>> lambdas = [(lambda i: lambda a: a + i)(i) for i in xrange(5)]
>>> [l(1) for l in lambdas]
[1, 2, 3, 4, 5]
Мне больше нравится как в C++ оно работает. Хочешь — захватываешь по значению, тогда всё работает предсказуемо. Хочешь — по ссылке, но тогда имей в виду что её время жизни не продлевается. Хочешь — сделай shared_ptr и захватывай его по значению.
В Java чтобы люди не путались запретили не final переменные захватывать.
А в Python как-то ни рыба ни мясо. Захват по read-only reference-counted ссылке (причём ссылка второго порядка: она ссылается на переменную, а не на сам объект: если извне в переменную записать ссылку на новый объект — в замыкании оно тоже поменяется).
В Java чтобы люди не путались запретили не final переменные захватывать.Всегда, когда можно, делаю переменную
final, предпочитаю объявить две финальный переменных, чем одну изменяемую. При этом при декомпиляции такого кода слова final не вижу. Вот интересно, финальность переменных поддерживается на уровне JVM или только на уровне синтаксиса компилятора?Всегда, когда можно, делаю переменную final, предпочитаю объявить две финальный переменных, чем одну изменяемую.
Я тоже так делаю, бро.
При этом при декомпиляции такого кода слова final не вижу. Вот интересно, финальность переменных поддерживается на уровне JVM или только на уровне синтаксиса компилятора?
Думаю только на уровне синтаксиса. Это ведь просто синтаксический сахар для человека, какой был бы бенефит от него в JVM? Та же история с generics в Java, после компиляции происхолит type-erasure и один и тот же код работает для всех инстансов дженерика. В отличие от C++ где каждое инстанциирование шаблона порождает независимую копию кода. Поэтому кстати в Java нельзя в шаблоне написать new T(), или T::foo().
Ну, проще всего предложить самостоятельно изучить, — как ищутся переменные в упомянутых языках.
Причём лисп надо рассматривать в трёх эпохах — до Common Lisp, Common Lisp и Scheme.
До кучи, можно ещё поиск имён в C++ вспомнить…
Это долгая и печальная история хождения по граблям, начиная с момента изобретения лиспа в 1958 году.
Если, например, все имена хранить в глобальном контексте, то мы не можем позволить себе рекурсию.
Если полностью изолировать глобальный контекст и контекст функции, т.е. в функции искать переменные только локально, — создаём кучу неудобств.
Если разрешаем видеть глобальные переменные из функции, то
— приходится изобретать способы различения — где имя глобальное, а где локальное (по-яваскриптовски, var локальное, иначе глобальное; или по-питоньи, global глобальное, есть присваивание — локальное, иначе хитровывернутый поиск)
— приходится изобретать правила для вложенных функций, вложенных блоков, замыканий, циклов и т.д.
Не, для примитивного скриптового языка можно договориться, что всегда есть ровно два контекста: глобальный и самый локальный.
Вложенных функций нет.
Любую переменную обязательно надо анонсировать, а не так, как в бейсике: сделал присваивание — значит, мысленно сделал dim.
О, кстати, до кучи. Переменные окружения в cmd и bash.
Если я в бат-файле написал SET some_new_var=value, и потом этот бат-файл вызвал из другого бат-файла, — это some_new_var окажется ему доступно? Т.е. можно ли так делать возврат значений из подпрограмм?
Оказывается, иногда можно, а иногда нельзя, смотря, как вызывать. Есть способы изоляции вложенных процессов друг от друга.
Причём лисп надо рассматривать в трёх эпохах — до Common Lisp, Common Lisp и Scheme.
До кучи, можно ещё поиск имён в C++ вспомнить…
Это долгая и печальная история хождения по граблям, начиная с момента изобретения лиспа в 1958 году.
Если, например, все имена хранить в глобальном контексте, то мы не можем позволить себе рекурсию.
Если полностью изолировать глобальный контекст и контекст функции, т.е. в функции искать переменные только локально, — создаём кучу неудобств.
Если разрешаем видеть глобальные переменные из функции, то
— приходится изобретать способы различения — где имя глобальное, а где локальное (по-яваскриптовски, var локальное, иначе глобальное; или по-питоньи, global глобальное, есть присваивание — локальное, иначе хитровывернутый поиск)
— приходится изобретать правила для вложенных функций, вложенных блоков, замыканий, циклов и т.д.
Не, для примитивного скриптового языка можно договориться, что всегда есть ровно два контекста: глобальный и самый локальный.
Вложенных функций нет.
Любую переменную обязательно надо анонсировать, а не так, как в бейсике: сделал присваивание — значит, мысленно сделал dim.
О, кстати, до кучи. Переменные окружения в cmd и bash.
Если я в бат-файле написал SET some_new_var=value, и потом этот бат-файл вызвал из другого бат-файла, — это some_new_var окажется ему доступно? Т.е. можно ли так делать возврат значений из подпрограмм?
Оказывается, иногда можно, а иногда нельзя, смотря, как вызывать. Есть способы изоляции вложенных процессов друг от друга.
«Новый COMОбъект» — у меня слезы умиления :)
P.S. В комментариях к статье про 1С обязательно должно быть сообщение «Как можно писать операторы на русском языке?» :)
====
Давным давно я тоже так думал. Но на практике (года три писал параллельно на «нормальных» языках и на 1С) переключаться между например похапе и 1С намного проще чем скажем между пхп и питоном. Меня реально бесили только сложности со знаками препинания и спецсимволами которые в русскоязычной раскладке не там, или вообще отсутствуют. Ну и отсутствие наследования сильно мешает конечно… А вот в нормальной среде реально сложно когда задача не требует сложных решений, а требует множество предметно-ориентированных понятий которые существуют на русском языке, и приходится постоянно ИСКУССТВЕННО переводить только для кода. Ну и красивого GUI-построителя конечно часто нехватает, но это уже про IDE.
По поводу проекта — спасибо за материал. Всё коротко и по сути. Давно об этом задумывался (признаться для такой же цели — сделать русскоязычный скриптовый язык для СЭД), да забросил эту затеи по той же причине что и основная критика — язык без экосистемы это зло. Разве что сделать совсем уж кальку с какого-то пхп, и «компилировать» не в байткод а в пхп.
====
Давным давно я тоже так думал. Но на практике (года три писал параллельно на «нормальных» языках и на 1С) переключаться между например похапе и 1С намного проще чем скажем между пхп и питоном. Меня реально бесили только сложности со знаками препинания и спецсимволами которые в русскоязычной раскладке не там, или вообще отсутствуют. Ну и отсутствие наследования сильно мешает конечно… А вот в нормальной среде реально сложно когда задача не требует сложных решений, а требует множество предметно-ориентированных понятий которые существуют на русском языке, и приходится постоянно ИСКУССТВЕННО переводить только для кода. Ну и красивого GUI-построителя конечно часто нехватает, но это уже про IDE.
По поводу проекта — спасибо за материал. Всё коротко и по сути. Давно об этом задумывался (признаться для такой же цели — сделать русскоязычный скриптовый язык для СЭД), да забросил эту затеи по той же причине что и основная критика — язык без экосистемы это зло. Разве что сделать совсем уж кальку с какого-то пхп, и «компилировать» не в байткод а в пхп.
Лексический анализатор (парсер)
что-то здесь не так
>>Существуют следующие базовые типы значений:
Объект — не базовый тип значения
Забыли про NULL.
Объект — не базовый тип значения
Забыли про NULL.
>>обращение к массивам — в квадратных скобках.
Не только к массивам, а к любым коллекциям.
>>Каждый оператор завершается точкой с запятой
Не завершается, а разделяется. Операторы разделяются символом «Точка с запятой».
Не только к массивам, а к любым коллекциям.
>>Каждый оператор завершается точкой с запятой
Не завершается, а разделяется. Операторы разделяются символом «Точка с запятой».
1. Null это специальный литерал для представления NULL-ов, получаемых из базы данных. Здесь никаких баз данных нет, Null не нужен.
2.
Не цепляйтесь к мелочам. Подраздел, который вы цитируете называется «краткое описание». На пару абзацев. Полагаю, там есть чего покритиковать поважнее.
2.
Не только к массивам, а к любым коллекциям.
Не завершается, а разделяется. Операторы разделяются символом «Точка с запятой»
Не цепляйтесь к мелочам. Подраздел, который вы цитируете называется «краткое описание». На пару абзацев. Полагаю, там есть чего покритиковать поважнее.
Есть еще аналогичные изыскания на эту тему, не знаю, автор видел или нет, называется: GPL-2C.
Краткое описание
Включает интерпретатор объектноориентированного языка, напоминающего по синтаксису язык 1с, визуальную среду разработки (конфигуратор) и исполнения (2с: Предприятие).
Прямые драйверы к базам данных MySQL и SQLite, возможность подключения к другим базам через ODBC.
Встроенный набор визуальных объектов. Возможность расширения библиотеки объектов и системных функций с помощью плагинов на C++ либо на встроенном интерпретируемом языке.
Открытый исходный код.
Прямые драйверы к базам данных MySQL и SQLite, возможность подключения к другим базам через ODBC.
Встроенный набор визуальных объектов. Возможность расширения библиотеки объектов и системных функций с помощью плагинов на C++ либо на встроенном интерпретируемом языке.
Открытый исходный код.
Эх, ностальгия. Когда-то то же решал подобную задачу, но вместо классической стековой машины использовал извращение со стеком процедур, как самостоятельных исполняемых единиц с передачей параметров по ссылкам. Никогда не забуду чувство удовольствия, когда прикрутил свое недоразумение к MOGRE ради проверки потенциальной жизнеспособности. До сих пор удалить исходники рука не поднимается, хотя на код без слез смотреть не могу.
Спасибо за статью.
Мне тоже интересна эта тема.
Скажите а типы лексем, расстановку приоритетов операторов и пр. вы сами делали или что-то взято из литературы?
Можете посоветовать дополнительную литературу по данной теме?
Мне тоже интересна эта тема.
Скажите а типы лексем, расстановку приоритетов операторов и пр. вы сами делали или что-то взято из литературы?
Можете посоветовать дополнительную литературу по данной теме?
Уже давно не первый год, как разработана мною система контроля отчетности. Хранилище отчетов в SQL BLOB-ах в нативном виде (файлы).
И встроенный обработчик (прекомпилятор + интерпретатор) собственного скрипт языка.
Вначале он был построен на латинице стандартно (Init, Open, BeginLoop, Offset), а не так давно,
по разным соображениям, переведен на патриотичную Кириллицу :) Теперь операторы, наверное как у 1С,
хотя я с ней не общался, просто слышал. Теперь у меня скрипты состоят из Отчет, Открыть, Смещение, Сброс, Цикл, Возврат…
В языке куча практических возможностей — открытие из хранилища любого количества необходимых для кросс-проверки отчетов, обращение к ним через координатную функцию (парсинг на-лету), циклы, справочники коллекций для подстановки, арифметические и логические функции, подробное протоколирование действий.
Сразу сделал подсистему разграничения прав доступа и подробного аудита.
В итоге получилась работоспособная система выявления потенциальных ошибок в отчетах внутри и между формами, о которых человек, проверяющий вручную мог бы только догадываться, или запросто пропустить.
С одной стороны интересно и приятно быть создателем собственного языка программирования, не используя абсолютно ничего готового, стороннего — парсеров или библиотек. С другой — получилась система не для развлечения, а для конкретных реальных и каждодневных задач. Причем, периодическое вылавливание ошибок в отчетности и предотвращает неприятности до их появления, и дает знать о эффективности механизма. Как-то так… Я когда начал статью читать — прям как про себя прочел. Правда не совсем уловил практического применения.
И встроенный обработчик (прекомпилятор + интерпретатор) собственного скрипт языка.
Вначале он был построен на латинице стандартно (Init, Open, BeginLoop, Offset), а не так давно,
по разным соображениям, переведен на патриотичную Кириллицу :) Теперь операторы, наверное как у 1С,
хотя я с ней не общался, просто слышал. Теперь у меня скрипты состоят из Отчет, Открыть, Смещение, Сброс, Цикл, Возврат…
В языке куча практических возможностей — открытие из хранилища любого количества необходимых для кросс-проверки отчетов, обращение к ним через координатную функцию (парсинг на-лету), циклы, справочники коллекций для подстановки, арифметические и логические функции, подробное протоколирование действий.
Сразу сделал подсистему разграничения прав доступа и подробного аудита.
В итоге получилась работоспособная система выявления потенциальных ошибок в отчетах внутри и между формами, о которых человек, проверяющий вручную мог бы только догадываться, или запросто пропустить.
С одной стороны интересно и приятно быть создателем собственного языка программирования, не используя абсолютно ничего готового, стороннего — парсеров или библиотек. С другой — получилась система не для развлечения, а для конкретных реальных и каждодневных задач. Причем, периодическое вылавливание ошибок в отчетности и предотвращает неприятности до их появления, и дает знать о эффективности механизма. Как-то так… Я когда начал статью читать — прям как про себя прочел. Правда не совсем уловил практического применения.
Большое спасибо, как раз искал подобное
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем интерпретатор скрипта и стековую машину