LINUX.ORG.RU

Формальное описание синтаксиса Tcl

 


2

3

Пишу парсер этого языка. Если с базовыми вещами всё просто, то дальше начинаются некоторые непонятки. Например, комментарий начинается с # и заканчивается концом строки, но внутри switch-выражения подобная конструкция считается значением. Есть ли список таких «особенностей» на одной странице?

P.S. Вообще я был бы счастлив увидеть EBNF или любую другую формальную нотацию, но, насколько я понял после пары дней гугления, такой вещи в случае с Tcl просто не существует.

★★★★★

Последнее исправление: hateyoufeel (всего исправлений: 1)

был бы счастлив увидеть EBNF или любую другую формальную нотацию

её нет по определению

Например, комментарий начинается с # и заканчивается концом строки

комментарии начинаются с # стоящим первым в выражении :-) то есть первым или на строке или после ;

выражение proc # { args } { ... } вполне себе допустимое

а вообще см. http://wiki.tcl.tk/10259?redir=36586

MKuznetsov ★★★★★
()

Пишу парсер этого языка

в самом tcl (в С API) см. Tcl_Parse (если есть желание можешь даже сломать голову в исходниках) - процедура которая разбирает tcl на токены. Проще зацепить сам tcl для таких нужд

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

её нет по определению

Да, это я знаю.

комментарии начинаются с # стоящим первым в выражении :-) то есть первым или на строке или после ;

Я правильно понимаю, что switch - это специальная конструкция внутри языка, и её нельзя парсить как другие команды - command arg1 arg2 ... argN ?

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от MKuznetsov

в самом tcl (в С API) см. Tcl_Parse (если есть желание можешь даже сломать голову в исходниках) - процедура которая разбирает tcl на токены. Проще зацепить сам tcl для таких нужд

Я уже читал код. Я хочу написать небольшое подмножество языка для расширения функционала своих приблуд. Сначала хотел использовать hiccup (https://code.google.com/p/hiccup/), но он сейчас в нерабочем состоянии - даже парсер не работает, а от вида исходников у меня волосы на заднице зашевелились. И плюс LGPL тоже не добавляет привлекательности, т.к. планируется использование в проприетарном софте, и наши юристы это не одобрят.

Да, язык реализации - Haskell.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Я правильно понимаю, что switch - это специальная конструкция

неправильно..

с точки зрения языка switch ровно такая-же процедура как и все остальные.

MKuznetsov ★★★★★
()
Ответ на: комментарий от hateyoufeel

для расширения функционала своих приблуд

каким функционалом вы хотите расширить свои приблуды ? и что за приблуды..может подскажу чего

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

каким функционалом вы хотите расширить свои приблуды ? и что за приблуды..может подскажу чего

Пока что основная идея: дать возможность админам писать скрипты для обработки различных событий в серверном софте. То есть, при наступлении события вызывается процедура на скриптовом языке (tcl) в соответствующими параметрами. Что там будет, уже не моя забота.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

дать возможность админам писать скрипты для обработки различных событий в серверном софте. То есть, при наступлении события вызывается процедура на скриптовом языке (tcl) в соответствующими параметрами

а зачем при этом парсер на haskell`е ?

MKuznetsov ★★★★★
()
Ответ на: комментарий от anonymous

может лучше использовать Lua

Почему? Я его рассматривал как вариант, но tcl мне больше понравился ввиду своей простоты.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от MKuznetsov

а зачем при этом парсер на haskell`е ?

Парсер - потому что это полезная практика. Накидать биндинги на FFI я всегда успею. На Haskell'е - потому что софт, к которому я это хочу в первую очередь прикрутить, написан на нём.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

дурное это дело парсеры писать если ты не собираешься и сам движок на tcl писать, имхо самое просто это пользоваться токенизацией/парсингом самого языка. Мы так делали с R, соотв. в хацкеле можно писать

[r| какое-то-выражение-из-р(коллбек_в_хацкельный_код_hs, хацкельное_значение_hs, значение-из-r |]

причем никакой сериализации как к quasi-quote-r или прочих подобых либах, единственное, что хацкельные значения сразу в формат воспринимаемый R конвертятся с минимальным копированием.

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от qnikst

имхо самое просто это пользоваться токенизацией/парсингом самого языка. Мы так делали с R, соотв. в хацкеле можно писать

Если я правильно тебя понял, это не пойдёт, к сожалению. Я хочу возможность подгружать код на Tcl без перезапуска процесса и уж тем более без перекомпиляции.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Парсер - потому что это полезная практика

разве что ради этого :-)

- программа состоит из выражений разделённых \n или ;
- выражение может начинаться с коментария # который игнорируется
- выражение состоит из слов разделённых пробелами
- первое слово выражения - имя команды, остальные слова - аргументы
- произвольный текст заключённый в парные {} должен рассматривваться парсером как единое слово и не разбирается
- текст заключенный в парные [] должен рассматриваться как единое слово и может быть разобран как выражение
ну еще про «строки» и всякие \n

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

Спасибо, я что-то подобное и искал (без воды в смысле).

P.S. Вообще, невозможность ставить комментарий внутри выражения - немного странное решение.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

не понял в чем проблема.. и не понял зачем парсер.

Я вижу ровно одну причину почему ты можешь хотеть парсер - подставлять в tcl-ный код колбеки в хацкель или какие-то внутренние значения. Да и для этого без полноценного парсера можно обойтись.

Никаких причин почему нужно перекомпилировать код нет.

qnikst ★★★★★
()
Ответ на: комментарий от hateyoufeel

а вообще давай рассказывай полностью задачу :)

qnikst ★★★★★
()
Ответ на: комментарий от hateyoufeel

> что-то подобное и искал

man Tcl

?

anonymous
()
Ответ на: комментарий от hateyoufeel

Да, язык реализации - Haskell.

самая идиотская затея, которую я видел когда-либо. Писать мощный язык на слабом языке — это сущий ад. Проще на асме написать. У Вас тут все такие м-м-м... странные? Как закончишь, выложи сюда кусок кода, хочется посмотреть а этот мазохизм, поржать. На хаскеле даже сам хаскель написать без костылей невозможно, лол.

anonymous
()

синтаксис очень простой

файл = строка*

строка = «[^\n]*» | {.*} | \a\w+

за точность не отвечаю, но суть такова

MyTrooName ★★★★★
()
Ответ на: комментарий от hateyoufeel

невозможность ставить комментарий внутри выражения - немного странное решение

учитывая что у выражений нет «нутри», да и выражениями мы их называем скорее по привычке, когда они просто идущие одна-за-другой команды - это нормальное решение.

Зато наверное заметил (раз смотрел как Tcl_Parse устроен) незаюзанную ещё мега-фичу - комментарии лексически являются частью выражений.

MKuznetsov ★★★★★
()

https://github.com/msteveb/jimtcl

- Jim is simple, 14k lines of core code. If you want to adapt it you can hack
the source code to meet the needs of your application. It makes you
able to have scripting for default, and avoid external dependences.

Having scripting support *inside*, and in a way that a given version
of your program always gets shipped a given version of Jim, you can
write part of your application in Jim itself. Like it happens for
Emacs/Elisp, or Gimp/Scheme, both this applications have the interpreter
inside.

да и лицензия вроде достаточно свободная чтобы встраивать

avsej
()
Ответ на: комментарий от MKuznetsov

учитывая что у выражений нет «нутри», да и выражениями мы их называем скорее по привычке, когда они просто идущие одна-за-другой команды - это нормальное решение.

Понятно, просто в других скриптовых языках комментарием считаются символы от # до конца строки в независимости от остального кода (хотя есть исключение - Perl). Впрочем, в случае с Tcl это должно наоборот упростить парсер.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от nagibator

Луа — это что-то типа псевдокода, который будет понятен почти всем.

Как человек, уже много лет пользующийся Ion3, позволю себе не согласиться.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от nagibator

Я думаю, что Tcl проще парсить ввиду меньшего количества сущностей в базовом языке. Это как лисп, только скобочки немного другие.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от nagibator

Тогда у меня вопрос: что приоритетнее удобство пользователей (будущих) или написание парсера? ;-)

Простота кода реализации приоритетнее. Что-то сложное через это запускать - плохая идея в любом случае, лучше тогда через system() вызвать стороннюю программу.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Ага, тогда вопрос снимается. Мне в началае подумалось, что там будут тысячи строк пользовательского кода.

nagibator
()
Ответ на: комментарий от hateyoufeel

Я думаю, что Tcl проще парсить

вы настолько всех заинтриговали, что аудитория прямо-таки жаждет услышать «зачем парсить Tcl» (ну или что там вы в итоге выберете)

покачто я понял, что ТС`у просто интересно написать парсер, но должно-же существовать практическое применение

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

ТС`у просто интересно написать парсер

Да.

должно-же существовать практическое применение

Я уже выше об этом писал :)

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от MKuznetsov

я тоже так понял, и вроде практическое применение с парсером не особо связано..

qnikst ★★★★★
()
Ответ на: комментарий от hateyoufeel

А почему бы не использовать lua/python/js? Существуют готовые библиотеки для для парсеров этих языков. Просто подключаешь их, задаешь окружение и вуаля. Если же не терпится самому писать парсер, то я бы посоветовал взять лисп. По уровню читабельности для человека тисиэль и лисп почти равны, а парсер для лиспа написать много проще.

Aswed ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.