http://kolmck.net/sf/SOL=IdealSpade4Programmer.rar

Ну хорошо, пусть будет отдельная ветка.
Сразу ответ D[u]fa на
зачем каждый раз писать do, почему б нельзя объявить массив как arr[... , ..., ...]


Мы же пишем begin, и нормально. Анализ текста значительно упрощается. Дело даже не в компиляторе. Человеку тоже проще, если есть открывающая скобка блока. Есть ведь и эквиваленты, кому само слово DO не нравится (и END).

Массив не надо так объявлять. Я долго думал, почему. Например, во избежание непонимания того, что если есть объявление [3,3,3], то можно обратиться как [i,j] и получить элемент-масив из 3 элементов. Если можно объявлять только [3][3][3], согласитесь, такой проблемы вообще нет. В конце концов, ][ ничем не хуже , ,но видно этот "символ" лучше.

Спрашивайте ещё. Я пока пытаюсь "победить" многозадачность (точнее многонитевость). Изучил адовские рандеву, мониторы модулы-2, активные объекты эктив-оберона - ничего мне не нравится пока. И вообще. Механизм защиты CATCH, который я предложил как черновой, мне самому трашно не нравится. В общем, голову ещё есть над чем поломать.

Хм!? Я так понял новый язык что-ли?

Правильно поняли. Раз уж началась разработка ЯП 5-го поколения, то хотелось бы напоследок получить идеальный ЯП 4-го. Но я так понял, что для меня лично никто стараться не собирается. Решил сам попробовать.

may be it's very nice ... if ever I could understand the docs, russian is not the most spoken language in the world and language translators do very bad working on technical words, why not write it directly in english ? ;-)

> [3] Dodfr   (16.12.07 22:23)
> russian is not the most spoken language in the world and
> language translators do very bad working on technical words,
> why not write it directly in english ? ;-)

Это все равно что человеку, которому нужна медицинская помошь, предложить сходить в туалет по той лиш простой причине, что в туалет ходят чаще, чем к врачу :-/

Well..I suppose homm is doing some joke as this is how google translated its words :

"It is still that someone needed medical Assistance, suggest go to the toilet on the requester simple reason that go to the toilet more often than to a doctor"

But whenever this this "joke" is not translated correctly, may be I could answer Homm in French and say (you'll see how fun it is to translate such words) :

"Puisque l'on parles de chiottes, tu pourrais te mettre dessus et devenir le roi des emmerdeurs".

> [5] Dodfr   (16.12.07 23:05)
> But whenever this this "joke" is not translated correctly

I also know english worst, but at first look it is right. :)


> be I could answer homm in French and say

I dont feel any reasons to try to rtanslate this phrase.

I only try to say what Vladimir write on language, which more comfortable for him, and reasons such as «most spoken language» at least funny.

Whenever I am french and I do all my programs and docs (and web sites) in english because I know that French is not a common language, it's a bit more work but more easy for everybody to access my jobs.

Тоесть про добавления и исправления в КОЛ
можно забыть раз появилась новая забава ?

Лучшеб с P-кодом до конца разобрались
чтоб у всех работало без ручных манипуляций...

Есть много языков программирования разных поколений. Но в 70 годы
был разработан язык MUMPS который в Амереке сразу же был и стандартизован. Я считаю что это самый лучший язык до сих пор. Приложения на нем писать можно в 100 раз быстрее чем на любом другом языке. При этом он еще и самый простой из всех. Ничего лишнего.

I am trying to compile... sorry, to translate to English smaller (2nd) specification now. (Even this work is taking too many time to do it and still the "thinking" stage is not finished it is delayed a bit). But what concerning about the (1st) large story... I'm sorry. It seems very large to do this work and may be better to take time to create first compiler / source editor for it instead.

Вот P-код - это и впрямь забава. Я просто исхожу из потребностей которые обнаружил при написани достаточно большого софта. Мне нужна надёжность, которую мог бы дать только какой-нибудь ядрёный язык типа Оберона или Ады, но заморочки этих языков меня не устривают. Малый размер - тоже нужен, но это не проблемы языка, а компилятора (и для обоих этих языков с удалением мёртвого кода есть проблемы). А если уже говорить о надёжности, то я сюда вкладываю очень много. Прога не должна зацикливаться, потоки не должны портить друг другу данные и влезать в dead-lock (а если влезли то должен быть способ распутать). Объекты должны сами себя убивать, а куча должна быть дефрагментирующаяся, чтобы прога могла работать практически вечно без перезапуска из-за сильной фрагментированности кучи. Но сборщик мусора мне не нужен, в его классическом варианте. Желательно максимум проверок отнести на этапы компиляции. Нужно средство тестирования, которое автоматически проведёт все нужные тесты после изменений (а не только те, про которые автор то бишь я в частном случае соизволил вспомнить после серии исправлений). Нужна параноидальность языка, избавляющая от параноидальности (или наоборотнедальновидности) программера, в общем. И при этом чтобы просто и без особых заморочек. Да, и ещё, всё это должно продолжать надёжно работать в условиях использования сторонних либ, написанных на довольно ненадёжном но увы распространённом С. Вы где-нибудь такой язык встречали? Вот и я не встречал.

Кажется, у меня получилось придумать и с многопоточностью что делать. Немного не так, как думал сначала (я про CATCH-переменные, если кто читал большой текст). Но что-то около того. Главное - нужна полная изоляция данных между потоками, контролируемая синтаксически. Кроме тех точек, где нужен контакт. Переменная может принадлежать только одному потоку в каждый отдельный момент времени. Для глобала - захват в исключительное использование блоком DO TRY, для прочих - передачей в теле сообщения. Завтра надеюсь закончить, и выложу тогда уже. Кстати, никто не знает, можно ли в винде загрузить одну и ту же dll в 2 разных участках памяти (или по крайней мере, чтобы её глобальные переменные для 2х экземпляров оказались в общем адресном постранстве в разных местах?) Что-то до сих ничего такого не встречал я. А надо (кажется).

Написано интересно, правда все еще плохо представляется все это вместе. На счет dll это вряд ли, разве что переименовать потом грузить. В SDK сказано что винда увеличивает кол-во ссылок на модуль и возвращает хэндл предыдуще загруженной библиотеки.

Но только если полные пути совпадают.

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

Если требуется действительно ветвление на этапе компиляции, то при наличии хорошего компилятора, вполне должно быть достаточно обычного оператора "DO IF" с анализом в условии значений констант и константных выражений: качественный компилятор не должен генерировать код для ветвей, условие на которых вообще никогда не выполняется.

Delphi так и делает, если константы нетипизированные.

Delphi так и делает, если константы нетипизированные.
Если бы этого было достаточно, мы бы не использовали {$IFDEF}. И в любом случае, слишком жёсткое ограничение. Типизированные константы - конёк Паскаля. И вообще-то, должно быть так, что константа - она и есть константа, типизированная она или не типизорованная. А в Delphi получается, что типизированная константа - это вовсе и не константа даже. А просто проинициализированная переменная. А, например, вот так:


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

А что, если это выражение, вызывающее функции? Я описываю класс функций, которые компилятор обязан уметь посчитать на этапе компиляции. Остальные - в силу интеллекта, а эти - обязан.

Как меня достали эти IFDEF'ы, вы бы знали... С ними чтение кода превращается в какой-то кошмар. На оптимизацию положено столько труда, и всё из-за несовершенства языка. Код мог бы быть намного короче, яснее, понятнее. Да даже те же асм-вставки выглядели бы яснее и понятнее. Согласитесь, условная компиляция в Delphi - это просто костыль для хромого. Препроцессор для языка, который изначально вроде бы в препроцессоре и не нуждался. (Как бы).

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

-------------------------------------
А если уже говорить о надёжности, то я сюда вкладываю очень много. Прога не должна зацикливаться, потоки не должны портить друг другу данные и влезать в dead-lock (а если влезли то должен быть способ распутать). Объекты должны сами себя убивать, а куча должна быть дефрагментирующаяся, чтобы прога могла работать практически вечно без перезапуска из-за сильной фрагментированности кучи. Но сборщик мусора мне не нужен, в его классическом варианте. Желательно максимум проверок отнести на этапы компиляции. Нужно средство тестирования, которое автоматически проведёт все нужные тесты после изменений (а не только те, про которые автор то бишь я в частном случае соизволил вспомнить после серии исправлений). Нужна параноидальность языка, избавляющая от параноидальности (или наоборотнедальновидности) программера, в общем. И при этом чтобы просто и без особых заморочек. Да, и ещё, всё это должно продолжать надёжно работать в условиях использования сторонних либ, написанных на довольно ненадёжном но увы распространённом С. Вы где-нибудь такой язык встречали? Вот и я не встречал.
--------------------------
А я встречал. И это уже давно работает. Все эти идеи давно реализованы
еще 70г. И сейчас существует и живет язык в котором это реализовано.
Велосипед изобретать можно но там это сделано лучше. Язык называется
MUMPS. Система в которой он реализован Cache даже продается книга
по этой системе на русском языке. В Москве есть представительство InterSystem. И на нем работают люди уже много лет Нет проблем с переменными в этом языке никаках. Все данные реализованы в виде дерева либо в памяти либо на диске. О возней с переменными в этом языке заниматься не приходится вообще. Надо записал в любую переменную надо прочитал из любой если там нет данных то возвращается пустая строка где надо удалил переменные. По завершению задачи все локальные переменные удаляются. Потоков тоже нет. Но есть многозадачность с поморщью команды JOB запускается подпрограмма. Все переменные всегда изолированы. Обмен осуществляется стандартными средствами. Блокировка переменных в языке команда LOCK. Это самый компактный и самый мощный язык.

А в Delphi получается, что типизированная константа - это вовсе и не константа даже

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

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

Вы слишком многого хотите от компилятора, это же не C++ с его многопроходным монстром. И для эмуляции IFDEF вполне достаточно первого случая, хотя удобнее, конечно, не строки, а Boolean.

Basically, Mumps has only one data type: string, although it does allow integer and floating point computations as well as logical expressions. Мне кажется, дальше читать уже не надо. Меня скритовые языки не интересуют.