Ada_Ru форум

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

GUI: ???? ? ????

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

Сообщения

Vladyslav Kozlovskyy
GUI: ???? ? ????
2005-08-16 07:31:02

Чего я хочу:

 

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

 

просто написать:

type Person is record

name ...

surname ...

sex ...

status ...

age ...

end record;

 

...

p : Person;

 

...

EditPerson(p);

 

И получить как минимум такое:

+-------------------------------------+

| name: [________________________] |

| surname: [________________________] |

| sex: [ male [V]] |

| status: [ married [V]] |

| age: [ 29 ] |

|-------------------------------------|

| [ OK ] [ Cancel ] |

+-------------------------------------+

 

- если мне эта реализация не нравится - поправить то что не нравится:

person.ads person.gui

with Person;

package Person is package PersonUI is

type sex is (male, female); pragma UI_Representation(tp=>Person.sex, control=>Radiobox);

-- по дефолту было: DropDownList ... end PersonUI;

p : Person;

 

...

EditPersonUI(p);

 

И получить такое:

+-------------------------------------+

| name: [________________________] |

| surname: [________________________] |

| sex: +------------+ |

| | (*) male | |

| | ( ) female | |

| +------------+ |

| status: [ married [V]] |

| age: [ 29 ] |

|-------------------------------------|

| [ OK ] [ Cancel ] |

+-------------------------------------+

 

- если меня размещение не устраивает:

 

person.ads person.gui

with Person;

 

package Person is package PersonUI is

type sex is (male, female); pragma UI_Representation(tp=>Person.sex, control=>Radiobox);

-- по дефолту было: DropDownList

-- описание GUI-интерфейса без координатной привязки (сродни HTML):

pragma UI_Components_Layout( filename => "frame1" );

-- frame1 - файл GUI-билдереа end PersonUI;

 

...

p : Person;

 

...

EditPersonUI(p);

 

И получить что-то типа такое:

+-------------------------------------------------------------------------+ | name: [________________________] surname: [________________________] | | | | status: [ married [V]] sex: +------------+ | | | (*) male | | | age: [ 29 ] | ( ) female | | | +------------+ | |-------------------------------------------------------------------------| | [ OK ] [ Cancel ] | +-------------------------------------------------------------------------+

- если же меня реакция на события не устраивает:

person.ads person.gui

with Person;

 

package Person is package PersonUI is

type sex is (male, female); pragma UI_Representation(tp=>Person.sex, control=>Radiobox);

-- по дефолту было: DropDownList

-- описание GUI-интерфейса без координатной привязки (сродни HTML):

pragma UI_Components_Layout( filename => "frame1" );

procedure OnInit; -- frame1 - файл GUI-билдереа procedure OnDeInit;

Procedure OnPressOk; pragma UI_Initialization( callback=>Person.OnInit );

pragma UI_DeInitialization( callback=>Person.OnDeInit );

pragma UI_OkButton_Event( event=>OnPress,

... callback=>Person.OnPressOk

p : Person; ); end PersonUI;

 

...

EditPersonUI(p);

 

- если же меня и ЭТО не устраивает...

 

то вытираю person.gui нафиг и пишу все руками :)

 

 

 

Основная идея типа такая:

 

максиму по-дефолту

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

если не нравится все - переделывается с нуля

 

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

Чего я хочу:

 

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

 

Запросто!

 

Это действительно слишком простой и достаточно легко реализуемый пример. Я в состоянии сделать программу, когда мышкой тыкаешь на объявление типа, вызываешь всплывающее меню, выбириешь "сделать шаблон интерфейса редактирования", ждешь пару секунд и получаешь результат. Потом можешь его под себя подгонять. :(

 

Только для этого базовую инфраструктуру дизайнера иметь надо.

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello Vadim,

 

Tuesday, August 16, 2005, 12:13:02 PM, you wrote:

 

Vladyslav Kozlovskyy wrote:

Чего я хочу:

 

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

 

Запросто!

 

Это действительно слишком простой и достаточно легко реализуемый пример.

Пример действительно простой :(

 

Как насчет реализации ссылок и коллекций? Это головная боль для всех гуи-билдеров

 

type Enterprise is record ... end record;

type Enterprise_Ptr is access Enterprise;

type EnterprisePtr_Array is array(1..50) of Enterprise_Ptr;

 

type Employer is record

...

Workplace : Enterprise_Ptr; -- как показывать? PreviousWorkplaces : EnterprisePtr_Array; -- а это как?

end record;

 

 

 

Я в состоянии сделать программу, когда мышкой тыкаешь на объявление типа, вызываешь всплывающее меню, выбириешь "сделать шаблон интерфейса редактирования", ждешь пару секунд и получаешь результат. Потом можешь его под себя подгонять. :(

 

Выглядит очень заманчиво... аж подозрительно :(

 

Но что-то не так. Чтото, концептуальное, базовое ускользает... но что?

Слишком все сложно получается. Должно быть проще! Я чувствую!

 

 

 

Только для этого базовую инфраструктуру дизайнера иметь надо.

Отож бо й воно!

 

 

 

--

Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

 

 

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

 

Я в состоянии сделать программу, когда мышкой тыкаешь на объявление типа, вызываешь всплывающее меню, выбириешь "сделать шаблон интерфейса редактирования", ждешь пару секунд и получаешь результат. Потом можешь его под себя подгонять. :(

 

Выглядит очень заманчиво... аж подозрительно :(

 

Поищи в интернете Auto Text_IO. Оно делает что-то подобное, только для Text_IO. Если заложенные в него идеи нам подходят, то нет проблем - используем их подменив вызовы Text_IO на виждеты UI.

 

;)

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello Vadim,

 

Tuesday, August 16, 2005, 2:47:18 PM, you wrote:

 

Vladyslav Kozlovskyy wrote:

 

>Я в состоянии сделать программу, когда мышкой тыкаешь на объявление >типа, вызываешь всплывающее меню, выбириешь "сделать шаблон интерфейса >редактирования", ждешь пару секунд и получаешь результат. Потом можешь >его под себя подгонять. :(

 

Выглядит очень заманчиво... аж подозрительно :(

 

Поищи в интернете Auto Text_IO. Оно делает что-то подобное, только для Text_IO. Если заложенные в него идеи нам подходят, то нет проблем - используем их подменив вызовы Text_IO на виждеты UI.

 

ХАЧУ-ХАЧУ-ХАЧУ-ХАЧУ!!! КАК? :)))

 

 

Для генеринья диалоговых окон для заполненняи даными - само ОНО!

 

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

 

 

[[active window]] [window]

[windows]

[window]

[window]

[windows]

[window]

 

[window]

 

 

Глянтьте, ГУИ можно легко представить графом, где в каждом узле - по окну (точка взаимодействия с юзером). Наверное можно описать правила перехода из узла в узел (и события, когда такой переход возможен)

Может это как-то можно использовать?

 

;)

 

--

Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

 

 

 

 

--

Best regards,

Vladyslav

On Tue, 16 Aug 2005 10:31:02 +0300, Vladyslav Kozlovskyy <dbdeveloper@...> wrote:

 

Чего я хочу:

 

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

 

просто написать:

type Person is record

name ...

surname ...

sex ...

status ...

age ...

end record;

 

...

p : Person;

 

...

EditPerson(p);

 

точно. Типа того ;)

 

Только прагмы нафиг - проще добавить названия и параметры прямо в запись.

Тоесть что-то типа FieldName : string = 'Enter NAME: ' и тп.

Параметры настройки можно аналогично - сразу инитятся по умолчанию,

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

 

 

Кстати, как такая идея - что-то типа понятного текстового конфига,

где прописаны все настройки и координаты - тоесть чтобы подкручивать

можно было как руками, так и редактором меню.

 

 

 

...

EditPersonUI(p);

 

- если же меня и ЭТО не устраивает...

 

то вытираю person.gui нафиг и пишу все руками :)

 

 

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

 

Тоесть редактор покажет сразу все настройки которые есть - эта фигня

с прагмами имеет подводные грабли ;) что что-то можно и не знать...

 

Тоесть параметр хоть и установлен по дефолту, но он существует,

а значит должен быть виден при настройке! (вкрутка по дефолту

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

показать все внутренние настройки которые есть!)

 

 

 

Основная идея типа такая:

 

максиму по-дефолту

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

 

точно

 

если не нравится все - переделывается с нуля

 

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

платформой, тоесть можно только менять например

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

что не может платформа уже нельзя. Тоесть только

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

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

разных вариантов/подпрограмм.

 

Vladimir

PS Еще надо рассмотреть вариант текстового шаблона

по типу как в веб/почтовых программах... Кстати,

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

платформ? :)

 

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

Hello teplouhov,

 

Tuesday, August 16, 2005, 5:47:29 PM, you wrote:

 

On Tue, 16 Aug 2005 15:56:08 +0300, Vladyslav Kozlovskyy

<dbdeveloper@rambler.ru> wrote:

Tuesday, August 16, 2005, 2:47:18 PM, you wrote:

Vladyslav Kozlovskyy wrote:

...

 

Глянтьте, ГУИ можно легко представить графом, где в каждом узле - по окну (точка взаимодействия с юзером). Наверное можно описать правила перехода из узла в узел (и события, когда такой переход возможен)

Может это как-то можно использовать?

 

Держите тогда и противоположную идейку, до кучи ;)

(собсно давно вертиться, только до конца не решил куда приткнуть :) )

 

Всякие ссылочные структуры вроде графов/списков/деревьев/и тп

конечно сильно круты по скорости, но надо ли тут это?

Что-то мне так кажется что несколько лишних килобайт в цикле

это такая мелоч по сравнению с мегабайтами графики гуи...

 

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

рекурсивного спуска и тп, то от этого нельзя случайно получить

какой-то выигрышь по удобству/возможностям?.. (обычно интерпретация хоть и медленнее, но зато имеет большие возможности)

кто запрещает на ходу писать машкоды а потом запустить?

 

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

сопроцессора и выполняет - скорость - круче многих математических библиотек :)

 

Хотя в Аде такой фикус не пройдет - забракуют, как опасный (и

правильно сделают! :)

 

 

Например в цикле крутить какие-то программы или шаблоны и тп,

строить какие-то программы или правила динамически и тд...

 

угу. на этой идее целая индустрия свою икру жрет - XML/SOAP/и иже с ними

(ну это так, мысли вслух :) )

Оно же ;)

 

 

Vladimir

PS Анализ шаблонов с умными скобками (вроде [] {} | & ) возможно каким-то боком можно приурочить... Так-же для шаблона возможно

будет актуальна более короткая запись вроде обратной польской

или какой-нить изврат вроде smalltalk...

Никто не запрещает уже использовать скриптовые языки в Аде - уже есть (то шо я знаю) биндинги LUA, GUILE, TCL/TK)

 

PPS А вообще, если нужна какая-то логика и/или отображение

состояния(например какой-то пункт меню запрещен пока не включен

другой, проверка данных по шаблону и тд и тп), то можно подумать над вынесением этой структуры данных и логики в отдельную стандартную библиотеку...

Я так полагаю, если нам удастся создать более-менее нормальный GUI- паттерн построенный на графах и машине(ах) состояния, то скорее всего до либы само дойдет, ежели используется другой путь - тогды - не судьба :(

 

(Хотя надо еще подумать может такие извраты

идеологически лучше вообще запретить)

Знатоки? Ваше слово :)

 

 

 

Мечтаем дальше :)

 

 

У меня тут еще круче идейка была (уж больно нужна была в автоматизации предприятий (чем до недавнего времени занимался):

 

Прикрутим ее, например, к Аде:

 

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

транслятор (абсолютно (по возможности) одинаковый синтаксис).

Причем компилятор должен знать про транслятор (он должен

быть частью RTS) и готовить под него данные. Тогда:

 

 

package ForTranslator is

 

type a is (one, two, three);

 

type b is record ... end record;

 

procedure aa(value : a);

function bb return b;

 

end ForTranslator;

 

...

 

with SecretDate; -- этот пакет интерпретатору недоступен :)

 

-- а вот эти - да:

published with ForTranslator;

published with Ada.Text_IO; published use Ada.Text_IO;

 

procedure Main is

vv : published integer; -- и эта переменная тоже

begin

 

vv := GetSomething;

 

-- интерпретатор получает доступ ко всем данным, помеченым как published eval( " declare var : ForTranslator.b; begin ForTranslator.aa(ForTranslator.a'(one)); var := ForTranslator.bb; put(vv'img); end; ");

 

-- можно и так:

declare

s : string := " declare var : b; begin aa(one); var := bb; put(vv'img); end; ";

begin

published use ForTranslator;

vv := 200;

eval(s); -- здесь "ForTranslator" в тексте можно опустить

end;

 

-- еще бы придумать, как значения из него возвращать... цены б ему не было :) end;

 

 

Классная штукенция получилась бы! К тому же интерпретатор можна было бы использовать для отладки частей программы без перекомпиляции.

Представьте, как ускорилась бы разработка!

 

Но-с не судьба :(

 

 

--

Best regards,

Vladyslav

On Tue, 16 Aug 2005 15:56:08 +0300, Vladyslav Kozlovskyy <dbdeveloper@...> wrote:

Tuesday, August 16, 2005, 2:47:18 PM, you wrote:

Vladyslav Kozlovskyy wrote:

...

 

Глянтьте, ГУИ можно легко представить графом, где в каждом узле - по

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

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

 

Может это как-то можно использовать?

 

Держите тогда и противоположную идейку, до кучи ;)

(собсно давно вертиться, только до конца не решил куда приткнуть :) )

 

Всякие ссылочные структуры вроде графов/списков/деревьев/и тп

конечно сильно круты по скорости, но надо ли тут это?

Что-то мне так кажется что несколько лишних килобайт в цикле

это такая мелоч по сравнению с мегабайтами графики гуи...

 

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

вплоть до анализа(интерпретации) какой-то текстовки в цикле самыми

тормозными методами(но простыми и понятными в написании) вроде

рекурсивного спуска и тп, то от этого нельзя случайно получить

какой-то выигрышь по удобству/возможностям?.. (обычно интерпретация

хоть и медленнее, но зато имеет большие возможности)

Например в цикле крутить какие-то программы или шаблоны и тп,

строить какие-то программы или правила динамически и тд...

 

(ну это так, мысли вслух :) )

 

Vladimir

PS Анализ шаблонов с умными скобками (вроде [] {} | & ) возможно

каким-то боком можно приурочить... Так-же для шаблона возможно

будет актуальна более короткая запись вроде обратной польской

или какой-нить изврат вроде smalltalk...

PPS А вообще, если нужна какая-то логика и/или отображение

состояния(например какой-то пункт меню запрещен пока не включен

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

над вынесением этой структуры данных и логики в отдельную стандартную

библиотеку... (Хотя надо еще подумать может такие извраты

идеологически лучше вообще запретить)

 

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

teplouhov@... wrote:

 

PS Еще надо рассмотреть вариант текстового шаблона

по типу как в веб/почтовых программах... Кстати,

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

платформ? :)

 

Уже значится ;)

 

 

--

Vadim Godunko

Vladyslav Kozlovskyy wrote:

 

PPS А вообще, если нужна какая-то логика и/или отображение

состояния(например какой-то пункт меню запрещен пока не включен

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

над вынесением этой структуры данных и логики в отдельную стандартную

библиотеку...

 

Я так полагаю, если нам удастся создать более-менее нормальный GUI-

паттерн построенный на графах и машине(ах) состояния, то скорее всего до

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

 

Здесь можно подумать о генерации кода по а-ля UML диаграмме состояний. Ничего невозможного я в этом не вижу.

 

 

(Хотя надо еще подумать может такие извраты

идеологически лучше вообще запретить)

 

Не надо. У них есть своя правда. Например, с их использованием можно отказаться от вложенности циклов обработки сообщений, что очень важно для сложных многопоточных программ.

 

 

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

транслятор (абсолютно (по возможности) одинаковый синтаксис).

Причем компилятор должен знать про транслятор (он должен

быть частью RTS) и готовить под него данные. Тогда:

 

Наличие интерпретатора языка в среде разработки интерфейсов пользователя как правило очень нужная штука.

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

Hello Vadim,

 

Wednesday, August 17, 2005, 8:35:03 AM, you wrote:

 

Vladyslav Kozlovskyy wrote:

 

Я так полагаю, если нам удастся создать более-менее нормальный GUI- паттерн построенный на графах и машине(ах) состояния, то скорее всего до либы само дойдет, ежели используется другой путь - тогды - не судьба :(

Здесь можно подумать о генерации кода по а-ля UML диаграмме состояний. Ничего невозможного я в этом не вижу.

Я тоже об этом подумываю. Но там очень много подводных камней -

слишком много нужно держать информации, а как ее еффективнее скрыть (принцип - вижу только то что нужно) не знаю :( К тому же пока я не вижу пути сделать обратимые (с возможностью реинжениринга) диаграмы состояний (диаграма->код->диаграма) а это для меня не менее важно

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

транслятор (абсолютно (по возможности) одинаковый синтаксис).

Причем компилятор должен знать про транслятор (он должен

быть частью RTS) и готовить под него данные. Тогда:

 

Наличие интерпретатора языка в среде разработки интерфейсов пользователя как правило очень нужная штука.

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

с своим собственным транслятором? У них же один фронт-енд (уже не куча работы минус) нужно только компилить в промежуточный код, кешировать и исполнять. Разве это невыполнимо? :(

 

 

 

 

--

Best regards,

Vladyslav

Vladyslav Kozlovskyy wrote:

 

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

с своим собственным транслятором? У них же один фронт-енд (уже не куча

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

исполнять. Разве это невыполнимо? :(

 

Я так думаю, что тут имеет смысл предоставить слово одному из всемирноизвестных Представителей Корпоративных Интересов, а именно... Сергею Игоревичу. ;)

 

У него лучше получится рассказать о всех мытарствах, располагающихся на пути от frontend-а до нормального интерпретатора.

 

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

teplouhov@... wrote:

 

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

Сильно зависит от размера проекта... Два с половиной часа это быстро?

PS Вот чего я не понял - нафига они свой парсер и тп изобретали, если это все можно было прикрутить готовое от исходников gnat... Некоторым наверно нравится процесс :)

 

Исходники GNAT сначала понять нужно... А потом становится понятно, что структура GNAT-а ориентирована на модель "один процесс - один модуль". Заставить его обработать модуль, "забыть" о нём, и обработать ещё один - весчь достаточно трудная.

 

 

--

Vadim Godunko

On Wed, 17 Aug 2005 09:36:20 +0300, Vladyslav Kozlovskyy <dbdeveloper@...> wrote:

Wednesday, August 17, 2005, 8:35:03 AM, you wrote:

Vladyslav Kozlovskyy wrote:

...

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

как правило очень нужная штука.

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

 

имеешь ввиду интерпретатором?

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

ну как адаптер и контроллер :) )

Для Ада вроде как есть уже AdaScript - BUSH.

www.pegasoft.ca

 

Да и LUA по синтаксису ближе к Аде.

 

У них же один фронт-енд (уже не куча работы минус) нужно только компилить в промежуточный код, кешировать и исполнять. Разве это невыполнимо? :(

 

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

 

Vladimir

PS Вот чего я не понял - нафига они свой парсер и тп изобретали,

если это все можно было прикрутить готовое от исходников gnat...

Некоторым наверно нравится процесс :)

 

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

On Wed, 17 Aug 2005 18:57:41 +0400, Vadim Godunko <vgodunko@...> wrote:

teplouhov@... wrote:

 

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

 

Сильно зависит от размера проекта... Два с половиной часа это быстро?

 

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

 

То что можно написать за день менее 100К, хоть руками,

хоть с генератором думаю не сильно больше будет - а такой

файл он откомпилирует очень быстро. Все остальное кроме

этого модуля без изменений так что перекомпилировать не нужно.

 

 

PS Вот чего я не понял - нафига они свой парсер и тп изобретали,

если это все можно было прикрутить готовое от исходников gnat...

Некоторым наверно нравится процесс :)

 

Исходники GNAT сначала понять нужно... А потом становится понятно, что

 

да там все понятно вроде сходу...

 

Хотя конечно что-то вроде доки на общие соглашения и правила

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

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

рунтайм :)

 

структура GNAT-а ориентирована на модель "один процесс - один модуль".

 

не плохо расфасован - редкий случай когда от большого числа

файлов есть польза... (mgnat тут целый час распаковывал - файлов

раз в 10 больше, и толку нету - похоже что-то от мелкософта туда

добавили, наверно либу какую-то ;))) Бум смотреть когда через

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

уже второй день его пережевывает... :/ )

 

Заставить его обработать модуль, "забыть" о нём, и обработать ещё один -

весчь достаточно трудная.

 

проинитить не долго...

К тому-же можно и просто на мясо - процедур надергать да подправить.

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

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

и другими фичами...

 

Vladimir

 

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

On Tue, 16 Aug 2005 17:20:40 +0300, Vladyslav Kozlovskyy <dbdeveloper@...> wrote:

Tuesday, August 16, 2005, 5:47:29 PM, you wrote:

On Tue, 16 Aug 2005 15:56:08 +0300, Vladyslav Kozlovskyy

<dbdeveloper@...> wrote:

Tuesday, August 16, 2005, 2:47:18 PM, you wrote:

Vladyslav Kozlovskyy wrote:

...

Держите тогда и противоположную идейку, до кучи ;)

(собсно давно вертиться, только до конца не решил куда приткнуть :) )

 

Всякие ссылочные структуры вроде графов/списков/деревьев/и тп

конечно сильно круты по скорости, но надо ли тут это?

Что-то мне так кажется что несколько лишних килобайт в цикле

это такая мелоч по сравнению с мегабайтами графики гуи...

 

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

вплоть до анализа(интерпретации) какой-то текстовки в цикле самыми

тормозными методами(но простыми и понятными в написании) вроде

рекурсивного спуска и тп, то от этого нельзя случайно получить

какой-то выигрышь по удобству/возможностям?.. (обычно интерпретация

хоть и медленнее, но зато имеет большие возможности)

кто запрещает на ходу писать машкоды а потом запустить?

 

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

сопроцессора и выполняет - скорость - круче многих математических

библиотек :)

 

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

С парсера сразу тупо на выполнение и нет проблем.

 

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

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

 

 

Хотя в Аде такой фикус не пройдет - забракуют, как опасный (и

правильно сделают! :)

 

если набор функций ограничен и всякие зацикливания не возможны,

то почему бы и нет...

 

Кстати, может тут еще вспомним про всякие редакторы

формул вроде mcad 2.0, или на потом? :)

Он кстати хранит формулы в файле как текст, примерно то

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

уже формулу будто настоящая :)

 

 

...

Мечтаем дальше :)

...

 

Функция eval есть в лиспе, тут она может отличаться только скобкой

с другой стороны ;)

 

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

прикрутить как библиотеку к программе)

 

А вот всякие declare и тп явно для этого лишнии - все-же это хорошо

только для компилятора, чтобы можно было выкинуть нафиг при компиляции

половину информации...

 

Тоесть тут надо подумать либо над исполнением списков(или графов?)

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

или текста.

 

Vladimir

 

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

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

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