Ada_Ru форум

Обсуждение языка Ада

Базовая документация на Аду

Оставить новое сообщение

Сообщения

teplouhov
Базовая документация на Аду
2005-08-16 06:46:28

Hello.

 

А где-нить есть четкое описание синтаксиса вроде этого

 

http://opensource.ethz.ch/emacs/vhdl93_syntax.html

(это кстати язык описания схем - все-же он на Аду больше

похож и похоже из нее и сделан :) )

 

Так-же бы не плохо найти или сделать что-то вроде

краткого справочника по синтаксису чтоли - что-то среднее

между примерами и формальным описанием, можно в основном

не очевидные формы (чем будет короче, тем лучше :) )...

Ну например только общие скелеты и фичи:

[declare ...] begin [name;] ... [exception ...] end [name];

и тд

Лишней воды не надо - можно только ссылки на подробную доку.

 

 

rationale что-то нашел только в инете - в стандартной поставке

его нет чтоли? Причем поисковики почему-то ищут только по его

оглавлению кроме самого текста, так что в инете найти

что-то не получается - пришлось сливать весь и индексировать

локальным поисковиком(чтобы слить пришлось еще и в настройках

качалки покапаться :) )...

Живет тут

http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-contents.html

 

Quality and Style тоже в стандартную поставку gnat не входит?

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Hello teplouhov,

 

Tuesday, August 16, 2005, 9:46:28 AM, you wrote:

 

Hello.

 

А где-нить есть четкое описание синтаксиса вроде этого

 

http://opensource.ethz.ch/emacs/vhdl93_syntax.html

(это кстати язык описания схем - все-же он на Аду больше

похож и похоже из нее и сделан :) )

 

Так-же бы не плохо найти или сделать что-то вроде

краткого справочника по синтаксису чтоли - что-то среднее

между примерами и формальным описанием, можно в основном

не очевидные формы (чем будет короче, тем лучше :) )...

Ну например только общие скелеты и фичи:

[declare ...] begin [name;] ... [exception ...] end [name];

и тд

Лишней воды не надо - можно только ссылки на подробную доку.

Ссылки похерены. Лови доку :)

 

 

rationale что-то нашел только в инете - в стандартной поставке

его нет чтоли? Причем поисковики почему-то ищут только по его

оглавлению кроме самого текста, так что в инете найти

что-то не получается - пришлось сливать весь и индексировать

локальным поисковиком(чтобы слить пришлось еще и в настройках

качалки покапаться :) )...

Живет тут

http://www.adahome.com/LRM/95/Rationale/rat95html/rat95-contents.html

 

Quality and Style тоже в стандартную поставку gnat не входит?

 

Vladimir

 

 

 

--

Best regards,

Vladyslav

teplouhov@... wrote:

 

Hello.

 

А где-нить есть четкое описание синтаксиса вроде этого

 

http://opensource.ethz.ch/emacs/vhdl93_syntax.html

(это кстати язык описания схем - все-же он на Аду больше

похож и похоже из нее и сделан :) )

 

А чем плохо описание синтаксиса в стандарте? В той версии, что

входит в поставку GNAT'a (и Annex P, и рассредоточенное по тексту),

и гиперссылки работают.

 

 

Так-же бы не плохо найти или сделать что-то вроде

краткого справочника по синтаксису чтоли - что-то среднее

между примерами и формальным описанием, можно в основном

не очевидные формы (чем будет короче, тем лучше :) )...

Ну например только общие скелеты и фичи:

[declare ...] begin [name;] ... [exception ...] end [name];

и тд

Лишней воды не надо - можно только ссылки на подробную доку.

 

А зачем? Реально оно надо на очень короткий момент в процессе

освоения языка. Поскольку синтаксис интуитивно понятный, а

диагностика компилятора вполне разумна, скоро все само на место

в голове встает.

 

rationale что-то нашел только в инете - в стандартной поставке

его нет чтоли?

Нет. Это ведь не стандарт.

 

Quality and Style тоже в стандартную поставку gnat не входит?

 

Нет по той же причине.

On Tue, Aug 16, 2005 at 12:46:28PM +0600, teplouhov@... wrote:

[declare ...] begin [name;] ... [exception ...] end [name];

и тд

Лишней воды не надо - можно только ссылки на подробную доку.

 

Кажется, то что тебе нужно называется Quick Reference Cards

Их полно в инете. Например

http://www.digilife.be/quickreferences/quickrefs.htm

 

 

--

Maxim Reznik

On Tue, 16 Aug 2005 11:10:37 +0400, Sergey I. Rybin <rybin@...> wrote:

 

teplouhov@... wrote:

А где-нить есть четкое описание синтаксиса вроде этого

 

http://opensource.ethz.ch/emacs/vhdl93_syntax.html

(это кстати язык описания схем - все-же он на Аду больше

похож и похоже из нее и сделан :) )

 

А чем плохо описание синтаксиса в стандарте? В той версии, что

входит в поставку GNAT'a (и Annex P, и рассредоточенное по тексту),

и гиперссылки работают.

 

наверное, только отсутствием прямых ссылок на нее ;)

 

Хотя надо сказать что и по ссылке пришлось искать минут 5 ;)

(ну это мне, сколько будет искать новый чел не понятно)

 

Ну и еще - БНФ это все-же не совсем синтаксис, точнее в форме

более интересной для компилятора компиляторов, чем доступной

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

полезно(например, а что там вообще можно писать в этом

месте и какого типа).

 

 

В общем я смотрю в разных местах дока вся или почти вся

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

 

 

 

 

Так-же бы не плохо найти или сделать что-то вроде

краткого справочника по синтаксису чтоли - что-то среднее

между примерами и формальным описанием, можно в основном

не очевидные формы (чем будет короче, тем лучше :) )...

Ну например только общие скелеты и фичи:

[declare ...] begin [name;] ... [exception ...] end [name];

и тд

Лишней воды не надо - можно только ссылки на подробную доку.

 

А зачем? Реально оно надо на очень короткий момент в процессе

 

Гы. Точно! Вы прям как мысли читаете :))

 

Вот этой "мелочи" чуть-чуть и не хватает...

 

Да и не всегда на короткий - например в файл где записаны

разные мудренные формы асма я до сих пор иногда подглядываю :)

(правда там синтаксис и идеология гораздо кривее будет :) )

 

освоения языка. Поскольку синтаксис интуитивно понятный, а

диагностика компилятора вполне разумна, скоро все само на место

в голове встает.

 

rationale что-то нашел только в инете - в стандартной поставке

его нет чтоли?

 

Нет. Это ведь не стандарт.

 

Доки на GNUсные программы тоже не стандарт, а есть...

 

 

Quality and Style тоже в стандартную поставку gnat не входит?

 

Нет по той же причине.

 

Вот что. Я думаю надо дополнить списками(ну комплект + списки url

на случай если не где скопировать всю коллекцию и придется тянуть

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

комплекта, которого впринципе вполне достаточно чтобы полностью

разобраться и начать писать. Думаю понятно, что объём (как по

траффику, так и по числу сущностей :) ) такого комплекта должен

быть минимизирован, но он должен включать все что надо...

 

Кстати всякие интегрированные редакторы думаю выкинуть за рамки

этого комплекта как и большинство библиотек, но оставить в нем

описания их и ссылки где искать.

 

В общем надо бы что-то такое сделать, потому что то что есть

на сайте может быть интересно только после этого, но никак ни до :)

А то там можно заблудиться :))) Да и вообще с большинством

спецушных вещей лучше работать только когда они понадобятся,

и то через поисковик, а вот базовый комплект всегда должен

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

не только когда что-то будет надо :) В общем идея примерно такая.

 

Vladimir

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Tue, 16 Aug 2005 21:39:45 +0300, Maxim Reznik <yeo@...> wrote:

 

On Tue, Aug 16, 2005 at 12:46:28PM +0600, teplouhov@... wrote:

[declare ...] begin [name;] ... [exception ...] end [name];

и тд

Лишней воды не надо - можно только ссылки на подробную доку.

 

Кажется, то что тебе нужно называется Quick Reference Cards

 

угу, возможно. По крайней мере это лучше чем ничего :)

(насколько я понял это что-то вроде краткого справочника)

 

Только почему-то везде что-то вроде БНФ форм - это хорошо

для компилятора компиляторов, но не очень похоже на синтаксис

программы.

Что-то мне так кажется что "скобочная" запись применяется

не заслуженно мало. По крайней мере по ней сразу хорошо

видно внешний вид, и что должно быть обязательно или нет.

(кстати, как она правильно называется?

Ну шаблоны типа [x] - 0 или 1 раз, {x} - любое число раз и тп))

 

Думаю что краткий справочник по синтаксису лучше в такой

форме, ну а дальше уже ссылки на более полное описание

если не понятно, может даже эти БНФ или просто доку или книгу.

 

Vladimir

PS Кстати надо подумать, может и что-то вроде yacc можно

для скобочных форм сделать - тогда описывать любой спецязык

будет вообще легко...

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

hi,

 

teplouhov@... wrote:

 

PS Кстати надо подумать, может и что-то вроде yacc можно

для скобочных форм сделать - тогда описывать любой спецязык

будет вообще легко...

А почти все уже сделано :-)

На выбор:

1) AYACC и AFLEX

2) OpenToken

3) COCO/R

И даже документация для этого хозяйства на русском имеется

(в разделе документации www.ada-ru.org)

 

 

Alex

Приветствую.

Кто хочет понять, как правильно проектируются объектно-ориентированнные системы, предлагаю заглянуть во в эту книжку:

http://anatolix.naumen.ru/files/books/design_patterns_rus.zip

(5.6МБ)

И ещё ссылка:

http://anatolix.naumen.ru/files/books/interface.zip

(900КБ)

Hello iZEN,

 

Thursday, August 18, 2005, 1:38:40 PM, you wrote:

 

Приветствую.

Кто хочет понять, как правильно проектируются объектно-ориентированнные системы, предлагаю заглянуть во в эту книжку:

http://anatolix.naumen.ru/files/books/design_patterns_rus.zip

(5.6МБ)

И ещё ссылка:

http://anatolix.naumen.ru/files/books/interface.zip

(900КБ)

 

А книги по Swing GUI которую ты читаешь, в интернете нету? :)

Уж больно толстая, что б покупать. Хотя, если доберусь до магАзина, может быть и куплю (усе времени нету :(

 

 

--

Best regards,

Vladyslav

 

 

Vladyslav Kozlovskyy пишет:

 

Hello iZEN,

 

Thursday, August 18, 2005, 1:38:40 PM, you wrote:

 

Приветствую.

Кто хочет понять, как правильно проектируются объектно-ориентированнные

системы, предлагаю заглянуть во в эту книжку:

http://anatolix.naumen.ru/files/books/design_patterns_rus.zip

(5.6МБ)

И ещё ссылка:

http://anatolix.naumen.ru/files/books/interface.zip

(900КБ)

 

А книги по Swing GUI которую ты читаешь, в интернете нету? :)

Уж больно толстая, что б покупать. Хотя, если доберусь до магАзина,

может быть и куплю (усе времени нету :(

 

Есть подобная книжка в электронном виде, но на английском:

ftp://195.161.102.62/pub/books/swing/Java%20Swing%20(Manning).pdf.bz2

(5891 KB)

Рекомендую.

В том же каталоге есть ещё. ;-)

On Thu, 18 Aug 2005 11:09:52 +0300, Oleksandr Havva <alex@...> wrote:

teplouhov@... wrote:

 

PS Кстати надо подумать, может и что-то вроде yacc можно

для скобочных форм сделать - тогда описывать любой спецязык

будет вообще легко...

 

 

А почти все уже сделано :-)

На выбор:

1) AYACC и AFLEX

 

Дак это обычные lex и yacc - они нынче много где есть...

 

Новых скобок в шаблонах что-то я не заметил(в lex они

всегда были, но это немного другое).

 

 

Кстати, тут прикольная штука попалась на

http://www.adaic.com/standards/ada95.html

 

- описание синтаксиса самой Ады на yacc - менее 20K всего!

 

 

Впечатляет ;) Но более понятным и удобным чем примеры

я бы его не назвал(всмысле как справочник по синтаксису,

но для написания какого-то парсера самое оно, так что

впринципе любой ада-подобный язык из него можно быстро

сделать - был бы смысл :) )...

 

 

 

2) OpenToken

 

этот мне более понятным чем даже yacc не показался...

 

3) COCO/R

 

этого под рукой что-то нет, не скажу(хотя может

поисковик до него еще не дошел - каким-то каталогом

с тышами файлов давиться бедный ;))) )

 

И даже документация для этого хозяйства на русском имеется

(в разделе документации www.ada-ru.org)

 

 

 

Вот что, раз уж дошло до обсуждения спецязыков(в тч

и применительно к GUI), то предлагаю начать это на примере

самого yacc... (Есть мысли? ;) )

 

В общем читаемость у него никакая - без доки мало что

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

(для тех кто не в курсе - у него 3 секции явно никак

не описываемые, разделенные символом "%%" - в общем

все в Ц-ном стиле :) )

 

Теперь давайте подумаем как бы его можно было улучшить...

В большинстве языков уже давно перед каждой секцией

пишется явно ключевое слово - ну вроде там procedure,

begin, var, type, const и тп и тд. Если синтаксис изменить

на явное написание названия секции, то читаемость

и понятность должна сильно улучшиться, IMHO. (ну и плюс

ко всему появляется возможность их писать в любом порядке,

в нескольких частях и тд и тп)

Причем что интересно, даже не зная описания уже

можно будет по исходнику понять что к чему, тоесть

с читаемостью будет намного лучше... (применительно

к GUI - учить еще одну песочницу очень бы не хотелось,

тоесть язык если и делать то желательно как надстройку

над чем-то в более стандартном виде - вызове процедур

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

с чем-то уже готовым на этом языке проблем нет - даже

понятней должно быть, ну а писать если не много чтобы

можно было в рамках стандартного языка если нет

времени/желания разбираться со спецязыком)

 

Теперь насчет формы шаблона синтаксиса. Все-же БНФ

формы удобней описывают семантику, чем синтаксис, IMHO.

Было бы удобней если вид формы описания синтаксиса

был бы сильно похож непосредственно на вид разбираемой

ей входной синт. конструкции... Ну например так

 

["declare" X]

"begin" [T ";"]

Y

["exception" Z]

"end" [T] ";"

 

Такая форма более удобна и понятна, IMHO.

(а теперь сравните с тем-же grammar9x.y из стандарта :) )

А уже потом где-нить описывать что такое X, Y, Z, T

чтобы не портило вид и не мешалось...

 

Ну примерно идея думаю понятна :)

Как это применить к GUI - точно х/з, например как

конвертор данных из текста в какой-то формат файла

или записей(тут есть сразу возможность заполнять

поля записи напрямую на языке программы либо воспользоваться

конвертором если это более удобно)... Насчет каких-то

более сложных конструкций надо хорошо подумать - если

выгода значительная, то сделать, если не очень то

лучше не надо ;) (Всяких песочниц и так хватает...)

 

В общем тут надо наверно посмотреть что чаще

всего хочется на практике и как это было бы более

удобно и коротко описывать...

 

 

Да, еще одна идейка :) Тут глядя на многие оконные

поделки просто удивляешься как можно было такой

неудобный изврат придумать и тем более считать

что это чем-то удобнее командной строки (или даже

ваще не знаю с чем сравнить - разве что набором маш

кода руками :) )...

Тоесть идейка такая - посмотреть нельзя ли подобные

извраты сразу отсеч(ну, намекнуть - типа если

очень хочется то можно, но писать раз в 20

придется больше, что может несколько отобьет

желание извращаться :) ) на уровне языка,

тоесть сделать так чтобы более правильное

построение интерфейса писалось на нем проще...

 

 

Vladimir

PS Еще кажется подобные языки для описания

протоколов были...

PPS Вот над чем стоит подумать - это расширение

для дист. управления в реальном времени - все

остальное уже будет так, частный случай :)

PPPS Где бы наверно программный(языковой) подход

и блоки с exception были удобны - это для контроля

канала связи и пользователя - например, автоматически

переходить в автоматический режим управления при

потере связи и тп... (кстати и дополнительные фичи

и датчики были бы не лишние - для мыши может

и не актуально, а для пульта ДУ было бы полезно

контролировать и присутствие юзера - типа отпустил

руку, и он сам перешел в авт. режим управления и тп)

Причем похоже что описывать реакцию на exception

по синтаксису было бы полезно не как обычно опционально

и после, а обязательно и до :) (а то весело же

будет выглядеть runtime error, например, на UAV

пульте после перехода в ручной режим управления :) )

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Sat, Aug 20, 2005 at 01:32:01PM +0600, teplouhov@... wrote:

На выбор:

1) AYACC и AFLEX

 

Дак это обычные lex и yacc - они нынче много где есть...

 

Так это-то и хорошо!

Новых скобок в шаблонах что-то я не заметил(в lex они

всегда были, но это немного другое).

 

Более распространенное название "новых скобочек" - EBNF,

Extended BNF (расширеная форма Бекуса-Наура).

 

 

Кстати, тут прикольная штука попалась на

http://www.adaic.com/standards/ada95.html

 

- описание синтаксиса самой Ады на yacc - менее 20K всего!

 

 

Впечатляет ;) Но более понятным и удобным чем примеры

я бы его не назвал(всмысле как справочник по синтаксису,

но для написания какого-то парсера самое оно, так что

впринципе любой ада-подобный язык из него можно быстро

сделать - был бы смысл :) )...

 

Ой ли? IMHO отношение трудоемкости задачь 1) построить

BNF из синтаксиса ARM и 2) построить механизм разрешения

Overload Resolution правил языка Ада это примерно

одна неделя и один год работы. К тому же взяв "чужой"

синтаксис в формате yacc ты потом убьешь неделю

пытаясь разобраться как они там исхитрились спрятать

от yacc неоднозначности языка, типа общей формы записи

вызова функции, преобразования типа, взятия элемента

массива и т.д.

 

3) COCO/R

 

этого под рукой что-то нет, не скажу(хотя может

поисковик до него еще не дошел - каким-то каталогом

с тышами файлов давиться бедный ;))) )

Все на www.ada-ru.org

http://www.ada-ru.org/src_acr.html

 

Вот что, раз уж дошло до обсуждения спецязыков(в тч

и применительно к GUI), то предлагаю начать это на примере

самого yacc... (Есть мысли? ;) )

 

В общем читаемость у него никакая - без доки мало что

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

Прелесть yacc в его "каноничности". Освоив его в одной системе

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

То что он не понимает EBNF - просто дело привычки, по

мощьности обе формы одинаковые.

 

Теперь давайте подумаем как бы его можно было улучшить...

Если тебя yacc не устраивает, не стоит его менять, лучше

поискать подходящую утилиту. Тот же COCO/R умеет многое

из того, что ты описал.

 

 

Тоесть идейка такая - посмотреть нельзя ли подобные

извраты сразу отсеч(ну, намекнуть - типа если

Поонятие "изврат" весьма субьективное, описать

формально правила его искоринения - неблагодарная

затея.

 

--

Maxim Reznik

On Sat, 20 Aug 2005 17:54:55 +0300, Maxim Reznik <yeo@...> wrote:

On Sat, Aug 20, 2005 at 01:32:01PM +0600, teplouhov@... wrote:

...

- описание синтаксиса самой Ады на yacc - менее 20K всего!

 

 

Впечатляет ;) Но более понятным и удобным чем примеры

я бы его не назвал(всмысле как справочник по синтаксису,

но для написания какого-то парсера самое оно, так что

впринципе любой ада-подобный язык из него можно быстро

сделать - был бы смысл :) )...

 

Ой ли? IMHO отношение трудоемкости задачь 1) построить

BNF из синтаксиса ARM и 2) построить механизм разрешения

Overload Resolution правил языка Ада это примерно

одна неделя и один год работы. К тому же взяв "чужой"

синтаксис в формате yacc ты потом убьешь неделю

 

не путать использование чего-то готового, и написание

своего с нуля с использованием готовых кусков.

В одном случае надо разобраться как оно там было

сделано, и своих мыслей может и не быть, а в другом

все же свои мысли есть :) Тоесть все просто - писать

это все с нуля можно, но это точно потом уйдет не одна

неделя на доводку и проверку совместимости, поиск доки и тп,

а тут все уже готовое. Если что-то не понятно,

значит оно и не нужно и можно смело удалить и тд :)

 

пытаясь разобраться как они там исхитрились спрятать

от yacc неоднозначности языка, типа общей формы записи

вызова функции, преобразования типа, взятия элемента

массива и т.д.

 

боюсь что никак, если для этого нужна уже семантическая

информация, но это не важно - можно просто обойти и не

использовать, никто не собирается полностью реализовать

стандарт Ады - достаточно того чтобы по синтаксису

они были боле-мене похожи для облегчения изучения и работы...

(а местами пожалуй стоит и наоборот сделать явно не так,

если семантика отличается - чтобы не было путанницы)

 

 

В общем если какой-то спецязык действительно нужен,

то его слепить вполне реально и если делать с умом

то это и не так долго.

 

Теперь главный вопрос - а нужен ли он вообще...

 

 

 

> 3) COCO/R

 

этого под рукой что-то нет, не скажу(хотя может

поисковик до него еще не дошел - каким-то каталогом

с тышами файлов давиться бедный ;))) )

Все на www.ada-ru.org

http://www.ada-ru.org/src_acr.html

 

во, еще одна песочница для описаний синтаксиса...

Ух и развелось же их :) В общем на чем написать

спецязык похоже будет дольше выбирать чем писать :)))

 

(а насчет неоднозначности что-то тут с ходу такая

мысля появилась - подкрутить лексический анализатор - сделать

его так, чтобы он по одному ключевому слову выдавал

разные коды лексем в зависимости от таблиц компилятора - и нет

проблем с неоднозначностью, далее систаксическая часть

уже получает разные коды в зависимости от варианта...

Кстати это один из побочных эффектов песочниц - с одной

стороны они чего-то ускоряют, а с другой и ограничивают

возможности что приходиться извращаться чтобы это как-то

обойти, причем приходиться еще и разбираться и учитывать

их особенности кишков...)

 

 

Вот что, раз уж дошло до обсуждения спецязыков(в тч

и применительно к GUI), то предлагаю начать это на примере

самого yacc... (Есть мысли? ;) )

 

В общем читаемость у него никакая - без доки мало что

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

Прелесть yacc в его "каноничности". Освоив его в одной системе

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

 

ну это конечно - я с этой горбухой еще на электронике-85 разбирался ;)

 

То что он не понимает EBNF - просто дело привычки, по

мощьности обе формы одинаковые.

 

 

да не, похоже что расширенная форма более сложная и может

быть реализована как еще один уровень поверх этого!

Тоесть впринципе можно слепить еще один препроцессор

сверху(за разом кстати туда и интерфейсы можно прикрутить,

всмысле разделить описание и реализацию), который уже

будет выдавать код yacc примерно как обычный компилятор

выдает машкод из текста на Ц :)_

 

С другой стороны, я уже намекал что скорость во многих

случаях пофиг, и не исключено что можно тут реализовать

тупую рекурсивную обработку прямо по тексту шаблонов

синтаксиса - тогда и скобки, и сам yacc и еще много

чего можно попробовать реализовать напрямую и более

гибко(не разбираться к кишками yacc/lex в тех случаях

когда надо извратиться и что-то обойти)...

 

 

Теперь давайте подумаем как бы его можно было улучшить...

Если тебя yacc не устраивает, не стоит его менять, лучше

поискать подходящую утилиту. Тот же COCO/R умеет многое

из того, что ты описал.

 

 

кстати если разобраться то он просто табличный - отсюда и все.

Причем рекурсия менее эффективна по скорости, да и вообще

очень часто что после оптимизации ее вообще не остается,

тоесть как бы более теоретический и универсальный вариант,

но и менее эффективный в реализации...

Кстати, возможно что тут стоит вспомнить о чем-то вроде

лиспа или пролога - там подобные рекурсивные фичи реализуются

как родные... (как вариант - рекурсивная программа на Аде,

если фичи лиспа вроде (eval) не нужны)

 

 

Тоесть идейка такая - посмотреть нельзя ли подобные

извраты сразу отсеч(ну, намекнуть - типа если

Поонятие "изврат" весьма субьективное, описать

формально правила его искоринения - неблагодарная

затея.

 

как сказать...

 

Кстати определенные шаблоны накладывает любой язык.

Даже чистый машкод! Тоесть уже в коде процессора

уже заложен(ы) какой-то один или несколько предпочтительных

вариантов, и если делать по-другому, то будет больше работы

только... (язык так-же позволяет обойти какие-то ограничения

и взять на себя "сложности", тоесть генерить всю связку

при компиляции)

 

Я это к чему - для оценки плюсов и минусов появления

какого-то над/супер/пупер :) языка... (или, если посмотреть

с другой стороны - то увы, часто это получается просто

ограниченная песочница, на изучение которой еще надо и потратить

время)

 

В общем при прочих равных(допустим что реализация на спецязыке

даже не дает никакого выигрыша по скорости и пускай даже

синтаксис языка позволяет 1:1 передать эту программу компилятору

без обработки) давайте оценим все плюсы и минусы.

Минусы думаю понятны - лишний довесок, ограничения и тд и тп,

но тут есть одна идейка и о полезности...

В общем идея такая - этот самый шаблон, ограничения которые

накладывает язык иногда могут быть и полезны - например,

возможностью смены шаблона.

Тоесть для примеру допустим что синтаксис 1:1 Ада,

но если писать по-быстрому(ну всмысле что нет времени

на расписывание всех обработчиков исключений и тд и тп,

да и даже если и есть время, то любой код это место

где могут быть ошибки или прятаться скрытые глюки), то Ада

обычно установит обработчики исключений на runtime error

и аварийное завершение программы. Причем не писать обработчик

она вполне позволяет - установит по умолчанию на этот

стандартный и тп. Но такая реакция часто не годиться

для управляющих систем - например, если процесс уже запущен

(допустим в реактор уже загружено несколько тонн какой-то

химической дряни или самолет уже взлетел, то управление

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

или перехода его на какую-то безопасную стадию), то просто

так прерывать программу уже нельзя, ни смотря ни на какие

ошибки...

В общем песочница может впринципе или сама по умолчанию

в подобных случаях устанавливать более подходящий обработчик

по умолчанию(например, переход в автоматический режим

управления при потери связи или поломке пульта и тп), либо

требовать его явного и обязательного описания(что кстати

само собой получается при заполнении какой-то структуры

данных, где явное описание всех полей обязательно).

 

Еще одна полезная вещь - какие-то сложности можно будет

таки скрыть. Тоесть, мне бы например хотелось контроль

связи и тп ввести прямо на этом уровне библиотеки чтобы

не думать и не было повода про это забыть :) Но, с другой

стороны, и просто существующие библиотеки уже настолько

сложны, что разбираться с ними не очень-то хочется,

а добавление всяких подобных фич еще больше увеличит

количество всяких разных параметров,

хитрых настроек и тд и тп...

В общем подобная песочница могла бы взять на себя

скрещивание обоих вариантов - чтобы и просто было пользоваться,

но на выходе использовались все те-же серьезные библиотеки

где есть поддержка всех функций(иначе я смотрю это все

рано или поздно приводит к появлению всяких "альтернативных"

вариантов вроде упрощенных библиотек где этого просто

вообще нет внутри как класса, виндов вместо системы и тд и тп.

Думаю понятно какие задачи чаще встречаются на практике

чаще всего и почему всякое дерьмо более распостранено,

не смотря на то что давно уже есть более серьезные системы).

Тоесть грубо говоря так - если нужен простой интерфейс,

то всякие лишнии параметры можно даже вообще скрыть,

заполнив их автоматически, но если включен режим генерации

кода для более серьезных применений, то та-же посочница

может уже начать требовать их обязательного явного описания

и тд и тп...

 

Кто еще что может сказать в защиту насекомых? :)

 

Vladimir

PS Ну это я так, для примеру - я пока еще не считаю что

язык вообще нужен, а тем более что он должен быть похож на Аду :)

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Кто еще что может сказать в защиту насекомых? :)

 

Я - так скорее в нападение...

 

Я дико извиняюсь, но всерьез этим заниматься можно лишь тогда,

когда ну ОЧЕНЬ делать нечего...

On Mon, 22 Aug 2005 22:42:37 +0400, Sergey I. Rybin <rybin@...> wrote:

 

Кто еще что может сказать в защиту насекомых? :)

 

Я - так скорее в нападение...

 

это хорошо :)

Прежде чем что-то делать, надо исключить все аргументы

чтобы этого не делать :)

 

 

Я дико извиняюсь, но всерьез этим заниматься можно лишь тогда,

когда ну ОЧЕНЬ делать нечего...

 

 

можно и не заниматься, но тогда боюсь что придется использование GUI

вообще запретить во многих местах :( Те кривые реализации что сейчас

есть просто вообще никуда не годяться...

 

Недавно заметил кстати что и изображение иногда таки портиться

в некоторых программах :/ Ладно там глюки допустим на винды можно

списать, но изображение в других окнах-то зачем портить?..

Фиг бы с ним с изображением, но где гарантия что эти глюкавые либы

не попортят память более серьезных процессов...

Вы все еще хотите использовать готовые либы? :}

Некая надстройка над этими глюкавыми либами была бы полезна -

(ну и работа GUI через сеть тоже - на худой конец можно весь этот

GUI хлам просто запускать на другой машине - пускай там глючит :) )

можно постепенно переписывать или менять библиотеки и тд и тп,

не переделывая все наработки... (делать два варианта - для себя

некрасивый и глюкавый на продажу тоже бы не хотелось - так

и времени не останется, а продажи всякого дерьма по шароваре и тп

я рассматриваю как мелкий временный колым, не смотря на то

что денег от этого на порядки больше :( )

Так что некий смысл этим позаниматься таки есть...

Ну а времени на реализацию надо не так уж и много, тем более

если использовать готовые генераторы вроде yacc и тп. Больше

всего времени уйдет на изучение готовых библиотек и тп(и чтобы

подумать как же правильно всем этим пользоваться :) ), но этим-то

придется заниматься все равно хоть так хоть так, так что затраты

на подобный проект в общем-то не большие.

 

Vladimir

PS А какая замечательная директива pragma Ada83 - чик,

и не надо идиотам читать проповеди по поводу правильного

использования ООП по назначению... :}

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

teplouhov@... wrote:

On Mon, 22 Aug 2005 22:42:37 +0400, Sergey I. Rybin <rybin@...> wrote:

 

 

Кто еще что может сказать в защиту насекомых? :)

 

Я - так скорее в нападение...

 

 

это хорошо :)

Прежде чем что-то делать, надо исключить все аргументы

чтобы этого не делать :)

 

 

Я дико извиняюсь, но всерьез этим заниматься можно лишь тогда,

когда ну ОЧЕНЬ делать нечего...

 

 

 

можно и не заниматься, но тогда боюсь что придется использование GUI

вообще запретить во многих местах :( Те кривые реализации что сейчас

есть просто вообще никуда не годяться...

 

Тут - одно из двух: или я выпал из контекста данной дискуссии, или

дискуссия зажила своей непредсказуемой жизнью.

 

Я что-то не могу понять связи между GUI и представлением Адского синтаксиса...

On Tue, 23 Aug 2005 14:10:45 +0400, Sergey I. Rybin <rybin@...> wrote:

teplouhov@... wrote:

On Mon, 22 Aug 2005 22:42:37 +0400, Sergey I. Rybin <rybin@...>

wrote:

...

Я дико извиняюсь, но всерьез этим заниматься можно лишь тогда,

когда ну ОЧЕНЬ делать нечего...

 

 

 

можно и не заниматься, но тогда боюсь что придется использование GUI

вообще запретить во многих местах :( Те кривые реализации что сейчас

есть просто вообще никуда не годяться...

 

Тут - одно из двух: или я выпал из контекста данной дискуссии, или

дискуссия зажила своей непредсказуемой жизнью.

 

Я что-то не могу понять связи между GUI и представлением Адского синтаксиса...

 

Ну, я конечно тоже извеняюсь - фидошники subj-и не меняют... ;)

 

(на самом деле это вопрос принципиальный - subj можно точно

подобрать только к простым вопросам(кстати думаю что в перспективе эти инетные

ньюсы где можно работать по subj можно будет заменить каким-то роботом или БД,

все равно там уровень обсуждения обычно не высокий,

ну тоесть глубоко не копают) - как только копнуть чуть глубже, то подобрать

точный subj становиться почти не возможно, да и в общем-то разные изначально

темы(как сейчас :) ) почему-то начинают пересекаться...)

 

Тема использования какого-то спецязыка либо анализа Ада-текста всплывала

уже несколько раз - это или какой-то генератор GUI по тексту описаний

данных на Аде(нужен или анализатор Ады или может прицепиться к чему-то

готовому вроде debug info), либо все писать на каком-то спецязыке и уже

из него автоматом генерить и GUI, и описания данных для Ады и тд и тп...

Ну а насчет того что сильно много работы - если описание такого навороченного

языка как Ада в 20 кил на в общем-то не самом крутом для этого yacc влезло,

то только преставьте какой наворот можно слепить если потратить день-два,

и наворотить на нем кил 100. Ой :)

 

(кстати, насчет GUI - вот тут случайно ссылка попалась по теории и истории

http://dissertations.ub.rug.nl/FILES/faculties/arts/1993/g.bos/c3.pdf 552K)

 

 

Vladimir

PS Ну а исходно в этом топике меня интересовало вот что - нужно в общем

скомплектовать(сгруппировать) документацию, библиотеки и пр. инфу так,

чтобы любой новый чел мог быстро сам разобраться без посторонней помощи.

(тут, с одной стороны, излишек информации по библиотекам которые в данный

момент не нужны и тп только мешает, а с другой некоторые вещи прочитать

было бы полезно даже если нет на это времени. Ну и нужны точные указатели

где что искать тк многие вещи в доках есть, но их найти не так-то просто,

да и вообще "читать книги на ночь" это на любителя и нужно чтобы на это

было еще и время...)

В общем для этого есть предложение сделать это в два уровня - тоесть

общий список всего что есть по теме + уже указатели по нему. Тоесть

примерно то что там есть на сайте, плюс добавить еще один уровень

списков-указателей(просто как-то перегруппировать

похоже не получиться - если улучшится один параметр, то ухудшиться

другой и тд и тп. (ну например можно сократить объем/траффик(особенно

актуально для скорости получения и там где инет дорогой), но будет

чего-то не хватать и тд и тп) Тоесть проще просто дополнить списками

ссылок(комментариями) что где искать и тп.

Причем в "общий список" похоже надо включать все по теме, в том

числе и всякий малоценный хлам, который включать бы и не стоило - для

устранения дупов. Тоесть если не включать, то потом все равно кто-то

найдет эту поделку опять и пришлет ссылку - ну а если всякие такие

поделки в списке уже будут(в подразделе "малоценный хлам" :) ),

то дупов уже не будет... (кстати, нарыл либу на Аде для работы

через порты под дос с SB, в списках что-то такого не видел, вот сижу

и думаю, толи это я что-то новое открыл :), толи там где-то ссылка

на весь этот сайт есть :} )

В общем некоторое захламление "общего списка" похоже не избежно,

а вот уже в тематических списках-указателях все может быть

чисто-чисто... Ну и плюс ко всему всяких тем может быть просто очень

много - по потребностям, например, кому-то нужны высокоуровневые

библиотеки, а кому-то для embedded и драйверов наоборот то что

работает через порты в-в и тд и тп... В общем список указателей

получается не большой, и их можно без проблем плодить много,

по каждой интересной теме и тп.

Ну и в списках описание можно сделать(там где надо) не кратким,

а более подробным. Плюс разные варианты одного и того-же - допустим

работа через posix, вариант через "родные" библиотеки, через порты :),

ну и тд и тп, ну конечно отдельно философия на тему "как делать

более правильно" и тп...

Как идейка? ;}

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти