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. Мне кажется, дальше читать уже не надо. Меня скритовые языки не интересуют.

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

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

S1 := 'Ятакидумал';
if S = S1 then

Вот в этом примере всё очень однопроходно. Я к Delphi  C/C++ отношусь именно как к навороченному макроассемблеру. Я от него уже не хочу ничего, спасибо за то, что уже есть. Но стало маловато.

А зря там много интересного.
MUMPS исторически был создан как язык интерпритатор. И в таком
виде существует до сих пор. Это связано с тем что некоторые конструкции
языка не поддаются компиляции в принципе. Таких конструкций 2.
Это косвенный синтаксис и команда XECUTE. В остальном все остальное
прекрасно компилируется. Последняя реализация языка это CACHE фирмы
InterSystem. В этой реализации применяется компиляция промежуточного
P-кода. Называть этот язык скриптовым у меня язык не поворачивается.
Это мощный развитый компактный язык программирования. Который на много
превосходит и С и Pasсal.  На этом языке построена бала операционная система
DSM-11. И язык выполнял все функции как языка так и операционной системы.
Это язык будущего. И вот почему.  В язык встроена
иерархическая база данных и она является неотемлемой частью этого языка.
База построена как B-дерево. (Кнут.3-том). Такое дерево строится на диске
и в оперативной памяти. Все переменные являются  деревьями на
B-дереве в памяти. При старте Cache оно создается при стопе все уничтожается.
Управление переменными осуществляет B-деревом в памяти. В любой момент
любая переменная создается и в любой момент удаляется. Никаких сборщиков
мусора и других обслуживающих программ не надо. Библиотека встроенных
функций состоит из 12 штук. Так возможностей у ней больше чем у библиотеке
в  Pasсal. Там кстати давно есть и функция аналогичная Parse. Но возможностей
у нее больше. Так как она может применяться как в правой так и в левой части.
И вырезать может любое поле. Изобретать свой язык не познакомившись
с MUMPSom это по моему идти в неверном направлении по давно
пройденному пути. Не нравится язык. Посмотри какие команды реализованы.
Как сделано управление переменными. Какая библиотека встроенных функций.
Я лично считаю что в MUMPSе самая развитая система управления данными.
Не имеющая аналогов в других языках. Команды NEW,KILL,ZKILL,SET,MERGE.
Есть книга по CACHE - Вольфганг Кирстен и др. Постреляционная
СУБД Cache 5 Об'ектно-ориентированая разработка приложений. Перевод с
английского.

дело не в том что он интерпретатор компилятор тоже есть. Ну и что? В MUMPS нет нормальных структурных типов данных, модулей (файлы - это ещё не модули), указателей, ОО, шаблонов, ... . Я посмотрел примеры кода. Бэйсик это. Модерн, но Бэйсик. Или у вас есть сведения, что он может использоваться для эффективных вычислений?

Об'ект по вашему это не структура? Типов данных там действительно нет
в базовом языке хотя в объектах эта галиматья вся есть.  Дерево само
является структурой причем любой и динамически изменяемой. Когда я
разрабатываю приложение я проектирую дерево а затем навешиваю
программы обработки. Какого типа переменная неважно. Важно чтобы
там были данные и их можно было обработать. Хотел бы я знать какие
вычисления на MAMPSe нельзя сделать? Указатели в языке есть и они
реализованы косвенным синтаксисом и передачей параметров по имени.
Где вы там обнаружили файлы для меня загадка.

У вас есть бенчмарки, доказывающие, что код мампса ничем не хуже по скорости кода С# хотя бы (считая что С# вдвое уступает С++)? Да читал я описание. Есть проекты размером больше 100 000 строк? Никаких дедлоков нет, исключения обрабатываются, один ажур спложной? Вы сами положа руку на сердце доверите программе на мампсе управление атомной электростанцией? (Я даже и Аде не доверяю, посл более близкого знакомства. Хм, софт для ракеты Ариан-5 был на Аде, а взорвалась она все-таки, в основном не столько из-за софта, правда, но в конечном счёте из-за него, родного). Вот не могу я поверить, что ЯП моей мечты давно существует, но все почему-то пользуются чем угодно, только не им. О Мампсе от вас первый раз услышал. Так не бывает. Если язык так хорош, как вы говорите, все уже давно выкинули бы на помойку и С/C++ и все #-языки, и Паскаль/Модулу/Оберон, и писали бы себе на мампсе. И не придумывал бы D, Java и прочая с ними.

misha_shar, назовите крупный проект созданный на нем, просто язык с 60 годов... а слышу первый раз от вас здесь =)

CACHE

O subj я ранее читал достаточно много, концепция мне очень понравилась, хотя в живую я с ним не встречался. Проблема его нераспространенности, равно как и SOL в том, что я писал ранее...

Я с 70г работаю на MUMPSe и только ему я бы даверил общее
управление всей электростанцией. Более надежной и простой системы
в мире не существует. Объем кода на MUMPSe может быть в зависимости
от задачи меньше на порядок. И его намного легче сопровождать.
А вот обработку прерываний от атомного блока я бы вынужден написать на
С в QNX системе. Потому что нет реализации MUMPSa в реальном времени.
Эта система разделения времени. Она очень надежна и хорошо обслуживает
много пользователей. Но это проблемы конкретной реализации а не языка.
Теперь более подробно о конструкциях языка. И язык С и PASKAL это
типизированые языки а MUMPS нетипизированый язык.
И подходить к ни с одними и теми же мерками нельзя.
Это 2 разных мира. Объект это модель и она должна существовать
прежде всего в голове. И на разных языках описание оъекта будет
выглядеть по разному. И бессмыслено в нетипизированом языке искать
описание объекта. Его описания там нет. Но это не значит что нет
объектов. Они есть. В MUMPSe объект это дерево. Любой объект должен
обладать 3 мя свойствами.
1,Локализовать переменые внутри объекта.
2.Обеспечить наследование.
3.обеспечить полиморфизм.
Всеми этими свойствами деревянная структура обладает от рождения и
никаких дополнительных ухищрений не требует. Правда в дереве нет
методов. Но это не проблема. Каждому дереву можно по имени сопоставить
модуль с программами обработки. Хотя в MUMPSe я никогда этого не
делаю за ненадобностью. Программы обработки я пишу всегда для
выполнения определенных функций над любым деревом.
Теперь по поводу программ. В MUMPSe я работаю всегда в определенной
области. Каждая область локализует данные и программы. В каждой
области они свои за исключением общей библиотеки. То что в Pascale
называется модулем (Unit) в MUMPSe называется программой. Хотя
точнее было бы назвать это блоком кода. То что в Pascale программы
и фунцкции здесь точки входа. В принципе в блок можно войти с
любой строки кода. Один и тотже программный блок может
использоваться поразному и как программа и как функция и как
продолжение программы(если точка входа не имеет передаваемых параметров).
Все зависит каким образом вы к этому блоку обратились.
Если по команде DO то это программа, если внутри команды SET то это
функция, если по команде GO то это продолжение вашей программы.
Все зависит от конкретной потребности.
Теперь о том что вы первый раз о нем слышите. Вообще то
незнание это не аргумент. И если все (в том числе я) работают
на Windows это не значит что это хорошая операционная система.
Более того это плохая ОС. Этот язык распространен в США где и
был разработан, в Англии, Австралии, Бразилии и других странах СНГ.
В Союзе существовало общество MUMPS которое возможно существует
и до сих пор.Это собщество сегодня вращается вокруг представительств
InterSystem в Москве и Хабаровске. На MUMPSe активно работали
в Москве, Ленинграде,Воронеже,Новосибирске,Томске,Хабаровске
,Владивостоке. Издаются книги. Не распостранен язык из за
безобразного менеджемента. Но к достоинствам языка это не
имеет никакого отношения. Язык конечно имеет недостатки но они
все устранимы при правильном подходе. Где используется MUMPS.
Все военные госпитали США по всему миру работают на этой системе.
Хотя реализованных проектов на нем очень много. Я сам разрабатываю
систему бухгалтерского учета с 80годов. Сейчас уже 5 версий этого
комплекса у нас функционирует.У меня серверная часть
написана на MUMPSe. Есть заказчики которых мы необслуживаем
уже много лет а они до сих пор работают на этой системе и она
надежно функционирует.

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

т.е ни одного проекта вы не назвали.. конкретного проекта...

вобщем не стоит тему про SOL превращать в тему про MUMPS.

> [28] misha_shar ©   (20.12.07 07:25)

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

Насчет ссылок. Чтобы понять почему их нет. Надо немного разобраться
с системой управления данными в языке. Данные управляются с помощью
B-дерева. B-дерево это структура блоков в памяти или на диске. И к
логической структуре хранимых данных никакого отношения не имеет.
В это дерево можно записывать любые данные индексированые или нет
и вообще любые. B-дерево не вникает в содержимое данных. С увеличением
данных оно растет сбалансировано и все. Единственное требование
они должны быть поименованы и эти имена должны быть уникальны.
Дерево хранит даные выдает их по требованию и если их нет то
возвращает пустую строку или удаляет их по требованию. Причем
данные могут находится в различных местах и это место можем в
любой момент измениться. Поэтому адресная ссылка на данные бессмыслена.
Данные в дереве хранятся только те значение которым присвоено.
Пустые значения не хранятся.
Обработка ошибок. Обработка ошибок в MUMPSе в зачаточном состоянии.
Острой необходимости в ней нет. Во время исполнения встречаются
как правило только 2 ошибки. 1-<UNDEF> неопределенная переменная
эта ошибка может быть подавлена в параметрах языка. И <DIV> деление
на 0. Эта ошибка подавлена быть не может ее надо обрабатывать
с помощью обработчика ошибок. Обработчик сделан просто и со вкусом.
В системную переменную пишешь точку входа в обработчик ошибок и все.
При возникновении ошибки управление передается в эту точку. Писать
блоку try finale не в стиле MUMPSa так как программа может перейти
на любую строку а блоки это плохо переносят.
Насчет бытродействия. С и MUMPS языки с различными возможностями.
В С нет встроенной базы данных. А с любой другой С будет на порядки
медленней MUMPS. В рекламных материалах InterSystem приводится
сравнение MUMPS с Ораклом. Так они считают что на больших данных
Оракл в 200 раз медленнее. Но реклама есть реклама. Из моего опыта.
Как только появились персоналки у меня небыло реализации MUMPSa и я
написал бухгалтерию в Delphi в качестве базы использовав InterBase.
Быстодействие меня не устроило и я с помощью обработок на сервере
попытался его улучшить. Мне это удалось в 2 раза. Потом в Москве
Фетисов написал реализацию MUMPS. И я на ней переписал бухгалтерию.
Так вот без всяких оптимизаций мое приложение на одних и тех же
данных работало в 20 раз быстрее. С ростом объемов данных разница
в быстродействии еще увеличивается.

> С ростом объемов данных разницав быстродействии еще увеличивается.

:)

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

сейчас делаю программу натурально на заказ. и все переменные храню как строки :)

что-то я не верю что мумпс быстрее при базовом типе "строка". это же бесконечные преобразования.
В-дерево дает обалденную скорость поиска и структуризации, но больше преимуществ я что-то не вижу.

> [34] Barloggg   (20.12.07 12:01)
> В-дерево дает обалденную скорость поиска

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

Есть предложение: для обсуждения MUMPSa создать отдельную ветку. А в этой обсуждать SOL.
В принципе соль - это типизированый язык. И сравнивать его с нетипизированым МУМПСом не совсем корректно.
Как и с паскалем и С.
По поводу эффективности. Мне кажется, при правильном и аккуратном написании кожа его эффективность в готовом виде зависит только от компилятора (и его автора).

> А в этой обсуждать SOL.


I agree. Any documentation in English yet?

Вообще то речь идет о новом языке а не о MUMPSe. MUMPS слава богу
есть и будет независимо от того знаете вы о нем или нет. Я предлагаю взять
для SOL за основу MUMPS доработав его спецификации. Кстати я хотел бы
увидеть описание SOL и требования к нему чтобы понять о чем идет речь.
Я извиняюсь влез в дискусию вконце и совершенно случайно. И может не
понял о чем речь. Прошу меня извинить.

> [38] misha_shar ©   (20.12.07 15:47)
> Кстати я хотел бы
> увидеть описание SOL и требования к нему

см. [0].

см. [0].
Чтобы это значило?

>Чтобы это значило?

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

Any documentation in English yet?


No yet. I just finished "thinking" about multi-threading. So, I can start now translate basic description into English.

Всё, получилось с мультипоточностью. Я сейчас выложил 11-ю версию.

Глобальные переменные теперь все threadvar (термин Delphi), других нет.
Мне пришлось изобрести третий вариант указателя, который я назвал sole-указателем. Он может показывать на какие-то данные только сольно, никакой другой указатель больше не может ссылаться на те же данные. В результате появляется целая категория SOLE-структур, полями которых могут быть из указателей только SOLE-указатели. В итоге эти SOLE-структуры могут образовывать в динамической памяти только строго иерархические деревья объектов.

А нужно всё это для обмена большими данными между потоками-процессами. Это - решение. Хотя и несколько тяжёлое, но гарантирует полную изоляцию данных разных потоков, и при этом можно быстро перебрасывать огромные структуры и деревья структур в теле сообщений, не передавая данные как плоские потоки байтов. Просто владелец указателя меняется и всё. От захвата данных соответственно отказался (предыдущая идея -
DO переменные TRY ....
 работа с перемнными
CATCH
 ...
END метка; - больше это не нужно. Оставил только ограничитель времени, для рил-тайм систем.

Можно переводить на английский, и начинать делать редактор и транслятор (хотя бы в C или Pascal, для начала).

А, пардон. Версия 12. Ну, не суть. Важно, что сегодня я это дело разгрыз. Если кто-то недоволен что ажно 3 (три) разновидности указателей, на то у меня резон такой: это даёт гигантские преимущества, и поэтому оправдано. Слабые указатели дают сборку мусора без сборщика мусора. Работа программиста - правильно организовывать структуры данных, и всё. Сольные указатели - в основном для целей многопоточности (собственно, другого применения как-то на горизонте и не наблюдается). Так что, при желании, ими пользоваться и необязательно. Зато сольные гарантируют синтаксический контроль н этапе компиляции того, что данные будут между потоками передаваться корректно, и не будет происходить нечаянное пересечение по данным. А это дорогого стоит.

Will the continued development of KOL suffer because of SOL?

Since I run under Zoomer, a LOT of things were introduced, fixed, extended in KOL. Any my project only improve it. (May be a year later when a good compiler will be ready for SOL... :) ).

Посмотрел я SOL. И хочу высказать свои соображения по поводу языка.
1.На выполнение каждой команды можно наложить условие ее выполнения через :.
2.Почему блочной должна быть только одна команда DO. А что если
команды блочными будут еще и команды IF и FOR. Например
IF условие;
..
ELSEIF условие;
..
ELSE
..
ENDIF;
Команда выхода может быть одна например QUIT по которой можно
как завершать цикл в любом месте так и завершать программы-функции.
например для возврата значения QUIT выражение
причем завершать программу и функцию можно в любой точке программы
;
Тогда оператор цикла может быть например таким.
FOR i=100:1:200,316,415 ; параметры цикла могут отсутствовать
QUIT:j=15;может находиться в любом месте цикла
ENDFOR;
3.Описание типов ненужно. Как хранятся данные в машине меня не
интересует пусть всегда это будут массивы чисел. Мне тип переменной
нужен только в опредеренных случаях:
- вывод на внешние устройства и ввод - применять функции форматирования.
- использование индексов - такие пересенные всегда целые
- вычисление значений - операции однозначно диктуют тип результата
- там где мне надо - применять явное приведение типов например
  функциями.

Не могли бы Вы привести сравнительную таблицу для SOL, Component Pascal и Oberon-2? И второй вопрос. Вот меня как вычислителя интересуют быстрые целочисленные операции над 64-битными числами, а в перспективе и 128-битными. SOL способен будет предоставить минимальные удобства для комфортной работы с такими типами данных, но не в ущерб скорости? Ну и третий вопрос. Возможено ли в SOL будет реализовать прозрачный и надежный параллелизм не только межъядерный, но и межпроцессорный, понимая под этим CPU+GPU, а заодно и межхостовый по типу MPI и/или Mosix? Скажете слишком многого хочу? Думаю - нет. Необходимость нормального ЯВУ для полноценных вычислений давно уже назрел.

Язык высокого уровня по возможностя не должен уступать Асемблеру.
В Асемблере широко используется обработка прерываний. Это альтернатива
линейному выполнению программного кода. Это принципиально другой
подход к программированию. В языках высокого уровня это открытие
Асемблера не используется его почему то никто не замечает хотя
потребность в этом есть. Чтобы решить эту проблему в Delphi
используется бесконечный цикл обработки сообщений. На уровне
языка это никак не решается. Язык имеющий такие свойства может
использоваться для управления процессами реального времени
например управлять ядерным реактором.

> [47] flip   (21.12.07 13:10)
> реализовать прозрачный и надежный параллелизм не только
> межъядерный, но и межпроцессорный,

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


> понимая под этим CPU+GPU

Мне не совсем понятно как о таком взиимодействии может идти речь, если у этих типов PU не только разные системы команд и исполняемый код (помоему сами видяшки и компилят код в свое внутренее представление), но и разный жизненный цикл у программы. Являются ли GPU наборы команд Тьюринг—полными?

misha_shar

1.На выполнение каждой команды можно наложить условие ее выполнения через :.
это про что?

Почему блочной должна быть только одна команда DO. А что если
команды блочными будут еще и команды IF и FOR. Например
IF условие;
..
ELSEIF условие;
..
ELSE
..
ENDIF;

Синтаксический анализатор проще, и не только для компилятора или раскраски синтаксиса это важно. Мне как человеку тоже удобней, если каждому END соответствует DO или BEGIN. IF и WHILE без DO и END у меня есть.

Вообще, при желании вообще можно сделать внешний моддинг для конструкций. Вообще всё будет выглядеть максимум как в любимом Паскале или C. Просто я предложил форму, которая отличается от современных (вредных) стандартов и предлагает стиль.

QUIT Семантическая составляющая слова quit - тишина. А мне нужен RETURN результата. Не зря же я все процедуры и функции называю функциями, даже если они ничего не возвращают. Слово BREAK - единственное, которое мне не нравится в смысле семантики, но оно уже просто въелось в привычку.

FOR i=100:1:200,316,415 ; параметры цикла могут отсутствовать
QUIT:j=15;может находиться в любом месте цикла
Это я вообще не понял, что там после i написано, что такое QUIT:j=15 - тоже не понял. В Соль такого нет. Если вы имеете в виду
IF j=15 THEN RETURN; то вот эта запись мне как человеку с традиционным опытом понятней на порядок. Как и DO i=100 TO 200 LOOP (что там у вас 5 чисел делают я вообще не понял. Мы же договорились здесь обсуждать Соль. Что вы народ путаете (пугаете)?

Описание типов ненужно. Как хранятся данные в машине
Описание типов в моём языке делается не для того, чтобы определить, как хранятся данные в машине. А для того, чтобы математечески точно указать, в каких диапазонах числа, с какой точностью/шагом, какой размерности массивы и т.д.
там где мне надо - применять явное приведение типов - и к каким типам вы "приводить" собираетесь, если нет их описания? В SOL можно не описывать типы. Разве нет этого в тексте. В этом случае эта работа, определить какие лучше использовать представления и разрядности - на компиляторе. Но есть задачи по управлению физическими объектами, по решению физически задач, задач планирования, логики и т.п., где тип данных является частичным условием задачи. То, что вы таких задач не решаете, не значит, что у других людей таких задач нет. Вычисления - это всегда вещи из реального мира, и уних есть меры.

Язык высокого уровня по возможностя не должен уступать Асемблеру.
В Асемблере широко используется обработка прерываний. Это альтернатива
линейному выполнению программного кода. Это принципиально другой
подход к программированию. В языках высокого уровня это открытие
Асемблера не используется его почему то никто не замечает хотя
потребность в этом есть. Чтобы решить эту проблему в Delphi
используется бесконечный цикл обработки сообщений. На уровне
языка это никак не решается. Язык имеющий такие свойства может
использоваться для управления процессами реального времени
например управлять ядерным реактором.
Было бы очень неправильно что-то вырезать отсюда, поэтому цитирую полностью. Откройте учебник или справку по Delphi, остановитесь на словах try, except, finally. Или вы прерывния от таймера собираетесь напрямую перехватывать? Если что, в SOL есть возможность запрограммировать нижний этаж на ассемблере. В яву конструкции высокого уровня для обработки непосресредственных прерываний от аппаратуры контроллеров - это нонсенс.

2 homm и flip

Про многопроцессорность, многопоточность, и даже многомашинность:
Я придумал уже. Читаем во вчерашнем номере газеты. Про многомашинность (распределённые вычисления) я много не писал, пардон. Но должно быть и так понятно, что в данном случае (полная изоляция данных разных процессов-потоков) разницы нет. Единствееное, что для распределённых систем лучше подойдут задачи крупнозернистые, с минимальным обменом данными между ячейками - машинами.

Сегодя я выложил версию № (черт, опять 12 - забыл номер поменять). Отдельный блок DO TRY после некоторого размышления и сравнения с Ada решил выкинуть. Теперь функция сама является обработчиком, если в ней есть секции cATCH перем; и FINALLY. Заодно не нужны стали CONTINUE TRY  и BREAK TRY, обходимся RETURN, семантика по умолчанию как в Аде - пере-возбуждение с передачей более высокому обработчику.

2 flip

Не могли бы Вы привести сравнительную таблицу для SOL, Component Pascal и Oberon-2? Чуть позже. Мне бы сейчас на English компактное описание перекинуть.

И второй вопрос. Вот меня как вычислителя
интересуют быстрые целочисленные операции над 64-битными числами, а в перспективе и 128-битными. SOL способен будет
предоставить минимальные удобства для комфортной работы с такими типами данных, но не в ущерб скорости?
Хоть какие. Что значит не в ущерб? Если используется хорошая библиотека (есть оверлод арифметики, это вообще хоть с какой разрядностью можно работать, да хотя бы и интервальные вычисления поддержать на формулах), инлайн-вставки делаются автоматом, вообще всё на стеке ФПУ будет бегать.

Необходимость нормального ЯВУ для полноценных вычислений давно уже назрел.
Ну я бы не сказал что для полноценных вычислений нет ничего. Тот же Фортран рулит. Мне хочется не столько вычислений, если честно, сколько многопоточности без траблов и тормозов. И побольше проверок на уровне компиляции, и поменьше траблов во врямя выполнения. Чего (мне кажется) я вроде бы добиваюсь, хотя и несколько может быть непривычно (аж три вида указателей).

Язык ради языка - мертворожденный!

>Язык ради языка - мертворожденный!
это про что?

Vladimir Kladov, я как то пропустил.. а под какую ось все планируется?

под какую ось все планируется
Под все оси, под всё железо, под FPGA, под всё, что угодно. Это универсальный язык, и ему начхать даже на то, какая система счисления в этой машине.

Это язык не ради языка, а ради больших задач. Что такое многопоточность в макроассемблере под названием Delphi, я уже прочувствовал.

Я конечно всю документацию не читал, то ли терпения не хватило, то ли времени... но на сколько я понял, пока получается только компилятор, как в FPC, т.е. о RAD даже речи не идёт, всё ограничивается простым (ну или навороченым) текстовым редактором? Если нет, то придётся с нуля писать кучу библиотек, так когда же ждать бету (хотя бы под виндоус)?

Нет про RAD речь действительно не идёт. Сначала делается компилятор и редактор, потом библиотек, а уже потом RAD. По-моему, RAD возникает как расширенное средство редактирования исходного кода, в виде связи между визуальными компонентами и исходным текстом, или иначе - в виде ещё одного внешнего представления исходного кода.

А посмотреть и попробовать сам язык можно? Хоть какой то транслятор
есть? Вообще кроме документации еще что нибудь есть?

Я документацию выложил, см. первый пост. Самого языка ещё нет, а вам уже компилятор подавай. Компилятор я думаю начать делать в ближайшее время. Только сначала переведу на английский хотя бы сжатое описание. Длинное описание - это последовательность непоследовательных мыслей, скорее. В кратком описании есть практически всё, и синтаксис, и семантика, и даже кратенькие примерчики. Длинное описание имеет смысл читать, если заинтересовало сжатое. Совсем краткое (справочник) я думаю вообще убрать. Кстати, если кому интересно попробовать составить БНФ или ЕБНФ схему синтаксиса, я был бы не против. К моему сожалению, я не считаю, что БНФ даёт хоть какую-то пользу, я её даже читать не могу, не приемлет мой мозг, для меня это что-то write-only текста. Но интересно было бы всё-таки иметь формальное описание синтаксиса, чтобы просто численно сравнить сложность (есть такое сравнение, проделанное для порядка дюжины языков. Кажется мне, оно несколько субъективно и Оберон получается самым простым ЯВУ. К сожалению, стандарт Оберона-2 мало что может, а расширения - это уже не он сам).

Хорошо я так понял идет обсуждение спецификаций языка.
Предлагаю сделать набор операций расширяемым. Где нибудь в
начале программы дополнительным операциям сопоставить программы
выполнения этих операций определенного типа. А затем компилятор
заменяет операцию на обращение к функции.

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

Сегодня я выложил версию 14. Добавил про сравнение типов и чуть более подобно описал, что такое шаблоны (абстрактная запись алгоритмов без привязки к конкретным типам данных) и как с ними бороться. Английский уже 2/3 готовы. Надеюсь успеть за выходной.

Приветствую, тезка.
Эээ.
Как я понял от GOODWELL почти ничего не осталось. Жаль . Он мне больше нравился. Я даже некоторые идеи подогнал для своего мега языка :)

Теперь по теме

> В языке Паскаль существует правило, запрещающее изменять
> значение счётчика цикла в теле цикла. Возможно, это сделано
> для того, чтобы не мешать компилятору оптимизировать выполнение
> цикла. В Си такого ограничения не существует. Думается,
> что в простом языке такого ограничения так же не должно
> быть. Не изменяется - хорошо, изменилось - в чём проблема?
>  Ведь всё равно данное ограничение обходится в том же Паскале
> переписыванием цикла типа for на цикл типа while.

А возможно это сделано для для того чтобы выделить цикл со счетчиков в отдельную конструкцию. Поскольку семантически они немного разные. И эмулировать цикл с постусловием циклом с предусловием тоже, имхо, не совсем хорого.


> В отличие от Паскаль-подобных языков, мы не будем разрешать
> размещать функции вложенными друг в друга. Это, по крайней
> мере, упростит разработку компилятора.

Сильный аргумент :). Но непоследовательно в одном случае усложнять компилятор (определение типов) а в другом упрощать. Вложеные функции иногда удобны хотя бы для ограничения видимости.


> Посмотрите, что произойдёт в случае, если мы так же введём
> в язык ограничение на число передаваемых функции параметров.
>  Например, одним-единственным возможным параметром (упрощать,
>  так упрощать!).

Я предлагаю еще упростить. Сделать функцию объектом с методом напимер execute и полями, которые по сути параметрами будут. (В данном случае это не стеб). Идею дарю. Конечно компилятор немного усложнится (ничего в другом можно упростить :) ) - ему придется проверять инициализированы ли все поля до вызова (хотя тут и значения по умолчанию могут быть). Зато есть плюсы. Например повторный вызов если изменен только один параметр короче будет.
А параметры константы, in out ref и все прочие декларации как? Как описание полей структуры? Или функция возвращает тоже структуру?

Все. жена пришла из душа :)
Удачи в новом начинании.

Вложеные функции иногда удобны хотя бы для ограничения видимости.

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

(В
данном случае это не стеб). Идею дарю А в остальных случаях - стёб? Спасибо но мне не надо такой идеи. Дочитаете до моих методов, поймёте что в этом смысле они у меня как в Обероне - просто функции.

А параметры константы, in out ref и все прочие декларации как? Не неужны. Читайте внимательно. Надо, чтобы изменялось внутри функции - передаём указатель. Если передаём массив по значению, и внутри он изменяется (а раз по значению, то не изменяется снаружи), компилятор ругается, но делает как приказано. Передаётся по значению, но не изменяется, компилятор передаёт указатель неявно. Хотим, чтобы массив изменился на самом деле - передаём указатель на весь массив. В 2х последних случаях компилятор молчит, и передаётся указатель.

Или функция возвращает тоже
структуру? Не вижу никаких проблем с возвращением структуры или массива.

English verion of short (but not very short) specification is ready:
http://kolmck.net/sf/SOL%20-%20short%20description.English.htm

Sorry for my English but you know that it is not my native language.

Заодно русский вариант поправил. Кстати, если кто-то (вдруг) осилил полное описание и обнаружил, что в коротком чего-то важное забыто или не совпадает, пожалуйста, подскажите на недостатки.

Стеб только тут "Сильный аргумент :)." В остальном просто попытка понять идею путем уточнения непонятных моментов.  

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

Насколько я понял главной целью языка не является упрощение и оптимизация копмилятора. К томуже вложеность тут не играет роли. Разве в Соль нельзя вызвать функции рекурсивно? При том что "Область определения функции - весь модуль" они могут тоже довольно запутано вызываться. Так что, имхо, это не агрумент.


> Читайте внимательно. Надо, чтобы изменялось внутри функции
> - передаём указатель.
Читаю. Не все еще прочитал, но вряд ли дальше это описывается.
Допустим есть такое определение  на неком гипотетическом языке. Но суть думаю понятна будет.
function name(s:string; in x:Type; inout io:Type  ;out e:TError):Type;
Параметр x должен быть инициализирован до вызова, не может менятся внутри функции. e - должен быть инициализирован внутри функции.  io - передается по ссылке. Т.е. это дает определенный контроль за вызовом функции.
Как это описать в Соль? Я пока не нашел. В принципе в некоторых случаях можно все "выходы" функции возвращать в результате-кортеже. А то, что какойто входной параметр может менятся у вас указывается ссылкой на него. Но вообщем я не пришел к заключению как лучше (У меня тоже возникла похожая идея. Обобщить функцию до отношения между кортежами).

> [66] vpbar ©   (23.12.07 15:33)
> К томуже вложеность тут не играет роли.

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

>>homm ©   (23.12.07 15:46) [67]
Ээ. Дык в делфи например это работает. И без всякой трасировки.

> [68] vpbar ©   (23.12.07 16:08)
> И без всякой трасировки.

Ну а как, тогда? Может указатель на начало стека родительской процедуры всегда сохраняется?

>  Как только последняя такая ссылка исчезает...., объект разрушается.
>  При этом все "слабые" указатели, указывающие на этот объект,
>  автоматически получают значение NIL.

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

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

function name(s:string; in x:Type; inout io:Type  ;out e:TError):Type;
Тут штука в том, что по неизвестной мне причине разработчики компиляторов избегают анализа между процедурами, т.е. стараются сделать так, чтобы компилятор рассматривал каждую процедуру/функцию как "чёрный" ящик. Это наверняка упрощает дело, но я собираюсь выполнять такой анализ. Т.е. когда компилируется A, вызывающая B, то даже если ещё не готов результат компиляции B полностью, для неё уже точно будет известно о каждом параметре, есть ли (возможны ли) попытки изменить параметр внутри функции B, или если не в ней самой, то в тех функциях, которые она вызывает, передавая адрес своего параметра вместо самого параметра в качестве параметра тех функций.

Соответственно, компилятору это и так известно. Человеку это и не интересно, для него известно точно, что если передаётся адрес явно, то параметр может измениться (он хочет чтобы он изменился), а если передана просто переменная, то измениться она не может. Это упрощает, хотя может быть и не очень (и совсем не) эффективно, если передаётся большая структура или массив по значению, и модифицируется внутри (но я думаю и с этим случаем маленько побороться - техникой copy-on-write, например).

Так, я кажется забыл написать, что я собираюсь инициализировать все переменные значением по умолчанию. В голове-то оно у меня есть, потому что уже отвечал в письме товарищу одному, да. Но, видимо, я забыл подыскать место в текстах, куда это впихнуть. В общем, это обязательный момент, и касается всех переменных, локальных и глобальных, и не только указателей. Оставался ещё открытым вопрос насчёт динамических массивов, будут ли они неявно инициализироваться по Allocate (наверное, всё-таки нет, кроме случая массива указателей, указатели всегда должны быть равны NIL изначально). Если инициализатора у переменной нет, то нулями (но тогда 0 должен быть в диапазоне, а если нет нуля в диапазоне, и нет инициализатора, то ругаться будет и откажется дальше компилить).

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

При этих условиях const, in, var и out - совершенно ненужный семантический мусор для параметров. Немножко междупроцедурного анализа, и всё само собой устаканивается (с одним различием - указатель или значение). Разумеется, надо контролировать весь граф вычислений, что кому и когда присваивается, но на это компилятор и нужен, по-моему.

Вариант с полным разделением входов-параметров от выходов-структуры мне приходил в голову. Но я отказался сразу же. Неудобно это. Функциональными языками попахивает. Как бы идея и неплохая, но лишней мороки может быть много с переходом мышления на такую линию. (У меня и так несколько революций в языке).

Вот интересно: никто даже не трогает проблему сборщика мусора. Наверное, программеры Delphi просто мало знают, о чём идёт речь, и почему моё решение проблемы GC - это кровавая революция с отрубанием голов всех ныне сущих языков с GC, включая Java, Oberon и всего .NET.

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

Я даже понимаю, что проблема шаблонного программирования не понятна программерам на Delphi. Ну нету в Delphi шаблонов, и не надо: обходимся же динамическим полиморфизмом (указатель функции как параметр алгоритма).

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

В общем, пойду-ка я и правда попробую составить что-то типа сравнительных таблиц. Я не уверен, что хорошо знаю некоторые малораспространённые языки, вроде Ады или Оберона, но если что, меня поправят.

> Так, я кажется забыл написать

Кажеться, хотя я почти догадался что это так. Про указатели есть то что они инициализируются нилом, а про остальное нет.

> При этих условиях const, in, var и out - совершенно ненужный
> семантический мусор для параметров.
Может быть, может быть. Просто мне больше нравится сказать компилятору что данный out парамеот должен обязятельно быть изменен в функции.


> Функциональными языками попахивает

Еще как :).

>  никто даже не трогает проблему сборщика мусора

Вы выложите тему в прочее, там Зотов (если не ошибаюсь может и Шевченко, давно было это) с вами поспорит. По-поводу неопределенности вызова деструктора, финализаторов и прочего. По мне у вас интересное решение. Но пока я не представляю как будут организованы сложные структуры данных с вашими разношерстными указателями. У сборщик мусора есть - и хорошо. Нет - и тоже не проблема, имхо.

Ну нету в Delphi шаблонов, и не надо

Прошу прощения. Тыкнул не туда. Продолжаем.

> Ну нету в Delphi шаблонов, и не надо

Надо. Мне, по крайней мере. Но тут у вас, вроде ничего революционного. В том же nemerle и haskel-е похожий подход.

vpbar>  При этом все "слабые" указатели, указывающие на этот объект,
>  автоматически получают значение NIL.

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

Где было обсуждение?

Сделать можно, 2мя способами. 1) "умные указатели". Каждый блок в памяти (который в SOL всегда является динамическим объектом с VMT, будь он структура, или динамический массив) обратно ссылается на smart-pointer (это термин С++, как они там с этим борются), по памяти никак не перемещаемый, а все указатели на объект указывают не на объект, а не смарт-поинтер. Надо присвоить NIL - это значение записывается в smart-указатель, и вуаля.

Мне это решение не очень нравится, т.к. требуется двойная косвенность.

2) Теперь простой вариант, хотя и кажется на первый взгляд неэффективным. Каждый указатель - это 2 адреса: один на сам объект второй - на следующий в циклической цепочку указателей на тот же самый объект. И опять, динамический объект обратой ссылкой смотрит на один из указателей, которые смотрят на него. А т.к. все такие указатели образуют кольцо, то они все перечислимы, сколько бы их ни было. И всегда можно пройтись по кольцу, и присвоить всем указателям NIL (причём, обоим адресам в этих указателях, разорвав кольцо).

Этот вариант кажется неэффективным. На самом деле, он эффективнее вдвое, чем первый. Ведь не часто бывает так, что на одно и то же указывает сразу слишком много указателей. Ну, указатели стали вдвое больше, нужно два адреса хранить. Не думаю, что из-за этого возникнут проблемы с нехваткой памяти. Зато косвенность остаётся одноуровневая.

Впрочем, можно и оба варианта реализовать, и просто переключаться в опциях.

Обратная ссылка из динамического объекта на "свои" указатели позволяет сделать ещё одну важную и полезную вещь: автоматическую дефрагментацию кучи (в обоих приведённых вариантах). Если программа должна работать долго, памяти требует прилично, память постоянно выделяет и освобождает, кусками весьма разного размера, и куча не дефрагментируется, то рано или поздно придёт капец, и нельзя будет выделить блок сколько-нибудь приличного размера хотя бы и в несколько сот килобайт. Потребуется перезагрузка. Но для алгоритмов с непрерывным циклом это может быть недопустимое решение проблемы. Разумеется, дефрагментация должна быть опциональна.

(Чего я это пишу по новой? Это уже всё написано в большом тексте).

> [74] Vladimir Kladov ©   (23.12.07 17:27)
> Впрочем, можно и оба варианта реализовать, и просто переключаться
> в опциях.

Вот поменьше бы опций :)
А что вернет sizeof(p) во втором варианте?

> При этих условиях const, in, var и out - совершенно ненужный
> семантический мусор для параметров.
Может быть, может быть. Просто мне больше нравится сказать компилятору что данный out парамеот должен обязятельно быть
изменен в функции.
Ну и скажите, описывая параметр как указатель. Если не изменяется, всегда передавайте по значению. Результат будет тот же: компилятор использует указатель для агрегатов. Проблемы?

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

Не надо шаблонов? Может и не надо. Copy-paste тоже метод, хотя вместе с умножением кода умножаются и ошибки. Причём не линейно, а гораздо быстрее.

Функциональные языки меня не интересуют. Привычка. А может, склад ума такой. И неэффективные они, кроме некоторых очень узких классов задач вроде моделирования ИИ. Я их не собираюсь отменять, пусть живут. Мне императив нужен, прямой как палка.

Вот поменьше бы опций :)

Опции всё-таки бывают нужны. Как-то же надо задавать компилятору, что мы от него хотим: быстроту или компактность, дефрагментацию или нет, и вообще для какой платформы и в каком виде результат выдавать?


А что вернет sizeof(p) во втором варианте?

Что такое sizeof, зачем он вообще нужен и с чем его едят в языке, в котором размером данных занимается компилятор и самый нижний уровень программирования?

>>Vladimir Kladov ©   (23.12.07 17:27) [74]

> Где было обсуждение?

Гдето в "прочее", но давно (месяца два назад). И щас не могу найти. Видно в архив ушло.

> Сделать можно
Дык я знаю.
homm ©   (23.12.07 17:35) [75]
А ничего. Ибо sizeof нет в Соль

> [77] Vladimir Kladov ©   (23.12.07 17:46)
> Что такое sizeof, зачем он вообще нужен и с чем его едят
> в языке, в котором размером данных занимается компилятор
> и самый нижний уровень программирования?

Хороший ответ :) Наверное все же застявлю себя седня прочесть описание :)

>>homm ©   (23.12.07 17:48) [79]
Прочитайте. Весьма любопытно.

> Vladimir Kladov ©   (23.12.07 17:41) [76]
> > Не надо шаблонов? Может и не надо.
>
Это вы с кем беседуете?

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

> [81] homm ©   (23.12.07 18:46)

Прошу прощения. Впредь постараюсь воздержатся от коментариев, пока не прочту хотябы пару экранов :)

Это девочка Маша. Маша урониля мячик.  Маша сходи туда -
 сюда.


О чем это я... Предлагаю все -таки подумать о том, чтобы переменные объявлялись. Это вполне просто и естественно. В человеческой речи обычно выделяется первое упоминание об обьекте. Так почему бы и Соль не сделать так.
К тому же homm ©   (23.12.07 18:46) [81] прав. Какие в Соль  есть методы сказать что это новая переменная с тем же именем, а не присваивание старой.
Допустим у нас есть переменная XXX = 10.
Ниже мы хотим новую переменную, причем почему-то приходим к такому же имени (ну бедная фантазия, например, при сходном назначении переменных)
XXX=100.
И все. Компилятор посчитает что это присваивание. Тип совпадает - ошибок нет. Но мы будем полагать что у нас другая переменная. А про ту XXX которая выше ма забудем, до той поры пока не заотлаживаемся до сыта. Или ради простоты нужно заставить программиста помнить все переменные.

Допустим у нас есть переменная XXX = 10.
Ниже мы хотим новую переменную, причем почему-то приходим к такому же имени (ну бедная фантазия, например, при сходном
назначении переменных)
XXX=100.
И все. Компилятор посчитает что это присваивание.
И чем жта ситуация отличается от случая, когда переменная XXX объявлена выше? И там, и там - присваивание.

Кстати, я же не запрещаю объявлять. Пожулуйста, берите и объявляйте:


Чем не объявление? Но объявить другую переменную X во вложенном блоке таким же способом уже нельзя, компилятор заругается.

А, кстати, выложил версию. Всё, что добавил, касается забытого и чуть не утраченного про инициализацию всех переменных, особенно указателей, так же перенёс в краткое описание про явное напоминание о присваивании LOOP- и SOLE-указателю (тоже ведь забыл), и решил "упростить" конструкцию присваивания значения указателю на массив:
P = M[ 6 TO 10];

Долго раздумывал. Конструкция какая-то не такая. Но ничего, зато удобно. Выглядит и правда проще.

> [85] Vladimir Kladov ©   (23.12.07 20:03)
> P = M[ 6 TO 10];

Basic? Почему не P=M[6..10]; ?

>>Vladimir Kladov ©   (23.12.07 20:00) [84]
Хм. то есть запрещено перекрывать определения. В принципе тоже вариант встречается. Со своими +-
ЗЫ. просто любопытно. Вы знаете Xerion и nemerle?

> [86] ANTPro ©   (23.12.07 20:52)
> > P = M[ 6 TO 10];
>
> Basic? Почему не P=M[6..10]; ?

Смотри внимательнее, это не объявление, это операция присвоения указателю P участка массива M с элементами от 6 до 10.

>>ANTPro ©   (23.12.07 20:52) [86]
А какая разница. Просто по желанию создателя диапазано в Соль описываются имено так. a TO b

> [88] homm ©   (23.12.07 21:00)

Я вижу.

> [89] vpbar ©   (23.12.07 21:00)

Как в бейсике. Ну или похоже.

Я пока еще не читал осоль может, что-то не правильно понял. Но не стоит стили нескольких языков смешивать.

http://kolmck.net/sf/Geometry_vs_Cosmology.htm

Владимир, спасибо большое за материал. Описание соли (соля?) я так и не дочитал, но наткнулся на эту статью. Равномерность расширения правда застявляет задуматься, правда не опровергая на прямую БВ. От строк о вечности и равномерном развитии вселенной и правду на душе спокойнее стало :)

Кому не нравится TO, можно писать to. Можно ещё и эквивалент придумать. Только не '..' - сильно смахивает на опечатку при попытке написать число с ПТ. Я бы взял ->, но очень не хочется (догадаётесь сами, почему).

А что меня за отсутствие типа Boolean не ругает никто? Я для чего проект языка выставил на обозрение - чтобы не получилось как у Вирта, всё сам придумал, ни с кем не посоветовался, а потом в языке остаются перлы типа with, большего приоритета and/or, чем <, > и всякое такое. Я, кстати, думал, как же ввести boolean не вводя его в язык. Вот придумал, кажется: запрет на приведение типов с меньшим диапазонам к большему, и диапазонов с разным шагом, неявно, без преобразующей функции. Ещё подумаю над этим, но, кажется, этого должно хватить. Преобразуюзую можно на шаблонах сделать, как бы общую для всех (точнее, набор: обрезающие, выставляющие при выходе за диапазон ноль, со специальным параметром по умолчанию, генерирующие исключение, ... ).

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

Мне вот не нравится бесконечное множество типов.
Вернет ли истину сравнение типов, один из которы  от 5 до 10, а второй не определе (т.е. число по умолчанию)

> Vladimir Kladov ©   (24.12.07 15:31) [92]



> Я для чего проект языка выставил на обозрение

Да кто же Вас знает.


> А что меня за отсутствие типа Boolean не ругает никто

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


- такое работать будет? Или нужно задавать операцию (функцию) '-' для этих типов.
А такое?

IF a*b+c THEN. судя по этому "Арифметические с целыми числами не являются циклическими." работать не должно (или невсегда будет). Хотя было бы интересно, можно было бы упростить и исключить AND и OR

Если Вы все же выложили описание языка для критики, то продолжу.
Цитатах текст их SOL=IdealSpade4Programmer вчерашней версии.


Переменная-массив так же может быть присвоена переменной-
массиву подходящей размерности.

Спроверкой совместимости типов элеметов, разумеется? А как с приведением типов. Есть ли механизм описанния явного приведения типа для элементов массива .
Вы конечно говорите что "8. Приведение типа. Никогда и ни при каких обстоятельствах. Раз уже все атомарные типы данных эквивалентны, и по сути, являются числами с плавающей точкой, то и приведение типа не требуется." но в Vladimir Kladov ©   (24.12.07 15:31) [92] заново придумаваете запрет на приведение и упоминаете о какой то "преобразующей функции". В этом контексте под приведением понимать преобразующую функци.
Т.е.
TYPE Bit = 0 TO 1;
TYPE Bits = [10]Bit;
TYPE Arr = [10]Integer;
B:String; A:Arr;
....
A=B // так  вроде нельзя. Запрет на приведение типов к большему диапазону
Цикл делать?

Допускается присваивать  динамическому массиву массив статический (но не наоборот).

А почему бы не присваивать статический массив динамическому? Или придется явно копировать. Опять цикл.

PS. Так есть приведение типов или нет?

>  Вот придумал, кажется: запрет на приведение типов с меньшим
> диапазонам к большему,

Еще.
Т.е. так нельзя
Y=0.4;
X=1;
...
Y=X;
Оригинально. Обычно наоборот. Если больший диапазон приводится к меньшему- то явно. Дабы понимать что может быть потеря точности (в SOL - ислючение).

> [95] vpbar ©   (24.12.07 19:38)
> Допускается присваивать  динамическому массиву массив статический
> (но не наоборот).
> А почему бы не присваивать статический массив динамическому?

Чукча либо не писатель, либо не читатель :)

> homm ©   (24.12.07 20:24) [97]

Да. Точно. Прошу прощения. Не о том прочитал. :( Просто язык необычен, что такие очевидные весчи не воспринимаются.

Есть проверка. Кстати из того, что X=0.4 и Y=1 еще не следует, что Y диапазон меньше (т.е. что оно целое). Тем более, если компилятор видит дальше Y=X, то он прекрасно понимает, что 0.4 так же является допустимым значением для Y, т.е. оно уже дробное. Он должен учесть все присваивания, если нет объявления явного диапазона.

Выложил 15 версию и заодно начало сравнительной таблицы (разумеется, все критерии подобраны специально так, чтобы представить SOL в самом выгодном свете, по сравнению со всеми языками. Моё мнение в принципе не может быть объективным:) ): http://kolmck.net/sf/SOL%20vs%20others.htm

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

Дописал в версии 15 про тип "булев". Нет такого типа, есть более строгое правило: запрет на неявное присваивание большего диапазона к меньшему (но чуть чуть сложнее, так что в итоге и булев к вещественному неявно не привести).

Ну мало ли что там в С. В С много вещей, с которых не стоит брать пример. Просто не надо так делать, и всё. Правительство Канады это прекрасно понимает. И я понимаю.

Кстати, ответы на большинство вопросов есть в кратком но не самом кратком описании.

А которых (ответов) нету, я буду дописывать. Краткое описание должно превратиться в полную (но не водянистую) спецификацию, в конечном итоге.

Вот ведь странно: сделаешь, чтобы := было, будут Сишники ругать, сделаешь чтобы = - паскалисты. И так, и так чтобы было сделаешь - все недовольны. Форма != (<>) содержанию. Это разные вещи.

> http://kolmck.net/sf/SOL%20vs%20others.htm

Понравился параметр «наличие каких-либо средств в языке» :) Это что? :)

Там же заголовок у таблицы есть Распараллеливание потоков вычислений (процессов)

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

D, Scheme, Lisp, Ocaml, Haskell - хотя бы с ними ознакомиться надо.

С D ознакомился до того как начал: мертворождённый недоСи. Прочие являются функциональными языками программирования и императивному не имеют практически никакого отношения. Сорри.

Теперь о баранах. Вот такая мысль насчёт циклов.

1) Переменную можно менять в цикле. Но синтаксис должен быть особый. 2 варианта:
i LOOP = выражение;
CONTINUE i LOOP = выражение;

Тогда уже точно видно, что программер прекрасно понимает, что он меняет переменную цикла. И компилятор соглашается. Иначе - ошибка.

2) Переменная имеет после выхода из цикла то значение, которое должна иметь. Но использовать её вне цикла можно только 2 способами:
- в выражениях, на чтение,
- для организации следующего цикла (или внутри следующего цикла).

Всё: проблема неверного использования, которой все запрещатели так боялись исключена.

Я обновил таблицу. Поправил там, кое-чего дописал. Если у кого-то есть глубокий опыт возни с Явой или С#, просьба подсказать, что вместо ? ставить напротив (про Аду и PL/1 я уж сам как-нибудь).

Вообще-то D - это скорее облагороженный С++, ну да ладно. О вкусах не спорят.
Scheme, Lisp - не являются чистыми функциональными языками. На них можно писать и в императивном, и в функциональном стиле. При этом они (по крайней мере, Схема) хорошо соответствуют принципу простоты.
А почему императивность, кстати? В значительной мере случаев функциональный подход дает более простые и наглядные решения.
И, наконец, эти (и многие другие) языки интересны своими особенностями, независящими от парадигмы. В Хаскеле, к примеру, нет никаких шаблонов, есть статическая типизация и тем не менее нет никакой необходимости делать несколько реализаций одного алгоритма для данных разных типов.

Это не та простота, которая мне нужна. Я, например, не перевариваю много скобок. После двух вложенных скобок у меня уже глаза разбегаются. Но дело не в скобках. Мне это просто непонятно. Я сдал экзамен по Лиспу лет 15 назад на 4, и уже через месяц забыл всё. И он мне до сих пор не понадобился. Значит, не нужен.

Хотел бы я посмотреть на редактор html, наприсанный на lisp'е. Нет такого? Точно не нужен. Потому и императивность. Иди туда, потом сюда. Если здесь камень, поверни назад, повтори всё сначала. Это то, что я понимаю. И не надо мне никаких Лиспов. Пусть на ФЯ пишут те, кому это надо. По мне, так это вообще write-only код. (Читабельность - нулевая).

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

---------------------
Так, я обновил большой текст (насчёт обработки исключений, и про циклы). Средние обновлю завтра уже.

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

--------------
Ещё раз поправил Что-то много в большом тексте осталось устаревших конструкций и описаний, по объявлениям функций прошёлся на этот раз.

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

в одном месте написал myvar = 10, в другом mivar = 11. ошибся типа. и потом столетиями ошибку ищем.  или я не так понял ?

да и "Оператор присваивания в выражении" не настолько уж великое зло, как кажется.
почему ж лишать "if (i=somefunc()) ?"

в пнях еще кажется для этого даже спец-опкоды ввели, настолько удобно.

> [108] GMax   (25.12.07 21:36)
> в пнях еще кажется для этого даже спец-опкоды ввели, настолько
> удобно.

Ага, ввели и никому не сказали :)

myvar = 10, в другом mivar = 11
такие вещи решаются просто. Даже если вы используете нотепад вместо редактора, который должен предлагать подсказки. Если после второго присваивания вы так и будете использовать mivar, то ошибки и нет. А если нигде больше не она не упоминается, компилятор предупреждает, что mivar присвоена, и не используется. А если вы употребили неверное имя в выражении а не в левой части присваивания, то это уже не предупреждение, а ошибка: переменная не инициализирована.

По мне, делать где-то там наверху (да даже и в том же блоке) кучу деклараций - бессмысленно. Когда вы читаете текст, туда-сюда не набегаешься. И никто не запрещает переменные "объявлять". Пишете в начале все присваивания начальных значений - вот вам блок объявлений.

Да, обновил про unsafe-маркер, и средние описания. Теперь там про циклы тоже есть.

Думаю, что компиляцию надо делать в простой код на С. Одна беда: поддержки исключений в нём как-то не очень чтобы наблюдается. Надо что-то замутить эдакое, чтобы результат был более-менее платформенно-независимый. Идеи есть (кроме использовать C++)?

>>Vladimir Kladov ©   (26.12.07 16:10) [111]
Java :) или Forth.
А вообще поддержка исключений есть в Windows (Linux и прочее вроде тоже) и аппаратно должна поддерживаться. А обернуть это можно хоть на асемблере.

Компиляторы С есть для всех платформ и даже не платформ (FPGA). JIT-код из простого C-кода сделать проще, чем наоборот. Потому что внутри Ява недалеко ушла от Форта. Стековая машина в принципе не подходит для представления кода на не-стековых машинах (хотя обратное верно). Потому и С.

Я знаю, что поддерживается аппаратно. На PC. Но PC - не единственная платформа. Меня не интересует получить код только для PC и заточить компилятор для одной платформы. Пожтому ассемблер даже не рассматривается.

>>Vladimir Kladov ©   (26.12.07 18:20) [113]
Вот и я о том, что лучше С зверя нет. В данном случае, в качестве промежуточного языка.  А поддержку исключения и в С вроде можно сделать вон в асме http://www.wasm.ru/article.php?article=Win32SEHPietrek1 делают же.

да при чём тут асм вообще, ПЦ в частности и Win32 тем более? Надо же генрировать платформенно-независимый C-код на выходе. Как работать с SEH на асме, я давно знаю.

>>Vladimir Kladov ©   (26.12.07 20:09) [115]
Владимир, я это "Компиляторы С есть для всех платформ" тоже  знаю  "Но PC - не единственная платформа" и это тоже.
Если можно было бы генерировать платформенно-независимый С-код, то зачем всякие Java. Писали бы на С, если он такой кросплатформеный. (Хотя можно, конечно #ifdef и вперед).  
Да и реализовывать исключения , имхо, придется для конкретных платформ.

Вообщем, прошу прощения, что лезу. В дальнейшем буду только читать.

homm ©   (25.12.07 21:39) [109]
>> [108] GMax   (25.12.07 21:36)
>> в пнях еще кажется для этого даже спец-опкоды ввели, настолько
>> удобно.
>Ага, ввели и никому не сказали :)
RTFM :-)  kol.pas USE_CMOV
правда введен все же с P6, поэтому Кладов не рекомендует... вплоть до неподержки в будущем языке ;-)

>Vladimir Kladov ©   (26.12.07 16:05) [110]
>>myvar = 10, в другом mivar = 11
>такие вещи решаются просто. Даже если вы используете нотепад вместо >редактора, который должен предлагать подсказки. Если после второго >присваивания вы так и будете использовать mivar, то ошибки и нет.

а если ошибка случилась два раза ? например через copy/paste ? или еще каким способом ? в длинных текстах вполне легко такое случайно сделать.

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

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

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

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

С циклами, я так понял, возражений нет: параметр цикла в функции может быть только параметром функции и использоваться на чтение, но внутри цикла может быть присвоен тремя способами:
i LOOP = выражение;
CONTINUNUE i LOOP = выражение;
BREAK i LOOP = выражение;

Мой аргумент, что отсутствие необходимости вводить дубликат параметра цикла уменьшает ошибки. А эффективность не страдает - если переменную цикла не менять внутри.

Я пока не обновляю сегодня: много было работы, не успел написать свою мысль насч1т рейтинга похожести и перегруженных функций.

Меня "вдохновляет" на отказ от объявлений опыт самого успешного языка всех времён - Фортрана. Я сам писал на Фортране, и чесное слово - никаких проблем из-за того, что не надо было объявлять простые переменные (массивы надо было, конечно) - не было вообще. Было только правило присвоения типа переменным по умолчаню: всё, что начинается на I,J,K,L,M,N - целые, прочие - вещественные. Раз у меня таких правил нет, нужны немного другие. Вот я и ввожу - тип переменной - по тому что ей присваивается, какими операциями с ней манипулируют, в каких случаях она используется.

хоть на СИ и не пишу, но мне в нем нравится что можно объявить переменную и сразу присвоить ее..

Если я не ошибаюсь, в чистом C так сделать нельзя всё-таки. Но объявлять можно в блоке, а не только в начале функции. И при этом (что глупо, и точно приводит к ошибкам, создавать новую переменную с таким же именем). Хотя я могу и приврать: давно на С серьёзно не работал.

С Новым Годом!
В новой версии описания вводится принцип синтаксического нигилизма: теперь блоки могут оформляться в 4 разных стилях: SOL, Ада-Оберон, Алгол-Паскаль, Си-Ява-Ди. Но это всё синтаксический сахар. Главное: пришлось добавить понятие параметризованного типа. Правда, ограничился одним параметром (тоже типом) Понадобилось чтобы можно было определить List(Data) от произвольного типа Data. Кажется, это называется статический полиморфизм типов. Ну лишь бы работало, как называется - не важно.

Большое описание стало великовато, разбил на 2 части. В принципе, сейчас и краткое вполне подробно, достаточно для основного значкомства:
http://kolmck.net/sf/SOL%20-%20short%20(but%20not%20very%20short)%20description.htm

(в архиве оно тоже есть).

Хотел высказаться по поводу организации потоков. По моему
принятая в описании схема правильна. Правда в терминах ОС это уже не
потоки а задачи. С моей точки зрения данные в потоке безусловно должны
быть локализованы. Такая схема применяется в MUMPSe и она себя

полностью оправдывает. Там есть команда JOB которая запускает поток.
А необходимые данные передаются как фактические параметры в процедуру.
В MUMPSe запуск потока и вызов процедуры почти ничем не отличаются.

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

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

Я не знаю как там в мумпсе, у меня изоляция данных (между потоками) - в одном адресном пространстве. (Т.е. это всё-таки потоки а не процессы). Поэтому передача большой порции данных из одного потока другому практически ничего не стОит. Данные остаются на месте, передаются sole-указатели и sole-деревья (сложные структуры можно "разобрать" на sole-дерево перед передачей, потом при приёке снова "собрать").

Что касается отладки, то например Вирт имеет по этому поводу очень интересное мнение. Он читает, что пошаговый отладчик чрезвычайно вреден, и именно отсутствие такой возможности приводит к написанию безошибочных программ, не нуждающихся в отладке. Мнение, вообще, несколько спорное. Но для многопоточного приложения, похоже, пошагоая отладка, и правда часто настолько затруднена, что пошаговый отладчик - как тот горшочек с мёдом: вроде бы и есть, а как бы уже и нет его.

> Меня "вдохновляет" на отказ от объявлений

я меня пугает...
всё-таки мож добавить хоть какими-нибудь директивами препроцессора (хоть как-нибудь!), и при желании сообщение "не объявленная переменная", пусть даже ошибки не будет возникать.

Просто вы не писали на Фортране. Отсутствие объявления - это то же объявление. Первое присаивание - чем хуже объявления? А я не вижу смысла и меня раздражают объвления заранее. Какой в них толк для простых переменных, за десятки строк от места использования?

Вставил ещё кусочек текста.

У современного поколения программистов отсутствие необходимости объявлять переменные способно вызвать страх уровня фобии. Причина, видимо, в том, что они с самого начала своей программистской карьеры оказались в ситуации чрезвычайно "скользкого паркета". В современных объектных языках вроде Object Pascal (Delphi) или C++ ситуация действительно такова, что стоит убрать правило, заставляющее объявить простые локальные переменные, и "ноги повиснут в пустоте" практически без опоры. Первопричина - в таких правилах определения областей видимости имён переменных, полей структур, при которой из одного только имени нельзя сказать, является ли оно локальной, глобальной переменной, параметром функции, константой, именем процедуры, метода объекта или полем класса (если текущая функция - это метод класса). И ничего нельзя сказать до тех пор, пока не будет обнаружено ближайшее сверху (в области видимости) объявление.

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

Но стоит в методе устранить всего лишь обращение к полям своего объекта "по умолчанию", и возможность обращаться к глобальным переменным без указания спецификации модуля (в виде МОДУЛЬ.ПЕРЕМЕННАЯ), и запретить опускать скобки при вызове процедуры или функции даже в случае отсутствия фактических параметров ( foo() ), и у нас остаются только именованные константы, локальные переменные и имена параметров, именуемые простыми (а не составными) идентификаторами. Константы легко выделить, например, соглашением об именовании их только в верхнем регистре (например PI, или INVALID_HANDLE_VALUE),  у параметров есть описание в начале функции, и остаются только локальные переменные. И зачем нам тогда их предварительно объявлять? "На память" о прошлых фобиях "скользкого пола"?

English (new) version of the SOL specification is available at:
http://kolmck.net/sf/SOL-EN-description.htm

да в принципе пох.. нужно объявлять их или нет.. но как компилятор поймет, что нужен определенный тип переменной?

к примеру сделаю я:

i := 0;
и потом то то типа .....(i, sizeof(i));

и как он поймет что мне надо именно Integer тот что 4 байта?)

или придется отказаться от таких конструкций?

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

дык о том речь и идет. что как предлагает Владимир не объявлять локальные переменные. Я то знаю что мне надо, а вот компилятор телепатить будет что ли =)

собсно и?)

sizeof это константа, которую компилятор и вычисляет(в делфях я имею ввиду)

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

> [135] D[u]fa   (09.01.08 10:53)
> опять ж как он узнает размер?

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

sizeof бывает нужен в языках с адресной арифметикой. В SOL нет адресной арифметики, вообще. Некоторые вещи могут казаться странными. Отсутствие деклации типа данных - это совсем не то же самое, что в JScript, когда переменная принимает тот тип, какой захочется. Это не вариант но формально - что-то вроде него. Казалось бы, могут возникнуть проблемы если одной и той же переменной присваивать и строку, и число. Но - не возникнут. Потому что агрегаты (массивы, структуры) - всё-таки отличаются от простых переменных. И объявлять их (хотя бы размерности массивов или число размернойстей) - придётся. А с числовыми - пусть компилятор выберет лучшее представление. Я вобще думаю для простого варианта компилятора рассмотреть штуки 4 целых форматов (int64, int32, uint8, uint1), и пару-тройку вещественных (flt32, flt64, flt80), и этим обойтись пока. Лучше сделать упор на возможность разрабатывать свои "классы" чисел, чтобы можно было делать программ для нестандартных процессоров (типа 4-битных контроллеров).

Сегодня опять "придумал" фишку. На этот - как однозначно "победить" проблемы возможного недопонимания переопределённых операций над структурными типами и массивами. Надо писать A = A [+] B; И всё - проблема исчезла. Вот почему, например, Вирт не хотел в Обероне переопределять арифметику: он не желал получить проблем с двусмысленностью. Всё, двусмысленности нет. (Разумеется я предусматриваю исключение для функций-шаблонов, в которых параметры не доопределены).

Про 4 нотации читали уже? Я сегодня выкладываю новую версию описания. Хорошо, что написание кода синтаксического разбора ещё не очень далеко продвинулось. Ещё кое-что уточняется, мелочи вроде Ptr1 SOLE = LOOP Ptr2; появляются (точная спецификация вида указателя которому и от которого присваивание идёт).

> Просто вы не писали на Фортране

Ну... на Васике писал, на 1с и т.п.
Ладно, переживём отсутствие предупреждений на не объявленные переменные. В крайнем случае, можно lint написать.
Прочитал описание (пока недостаточно внимательно). Очень неплохо. Хотя немного напрягло большое количество вариантов синтаксиса. Трудно для освоения, но это тоже не беда. :)) Да! кстати, это нарушает правило "50.Не путайте привычность с читаемостью" (Ален И. Голуб. С и С++ Правила программирования М:Бином 1996). Думаю лучше основной синтаксис привести в наиболее читаемый вид. В перспективе подготовить рекомендации по оформлению текстов программ.
А в целом достойно.
Желаю Вам Владимир творческих успехов.

Я думаю, вы меня поймёте лучше, если 7 лет подряд будете писать только на С/C++/Java/JScript, потом лет 7 подряд только на Паскале, а потом снова попробуете что-нибудь написать на С/C++. Становится невозможно не только писать, но и прочитать - проблема. Я же не заставляю учить ВСЕ 4 варианта синтаксиса. Наоборот, делается конвертер, и каждый изучает только тот вариант, который ему ближе. Открываете чужой модуль в редакторе, а он автоматически перестроен к вашей любимой нотации.

Я обновляю. Also english version of a comparison SOL vs others available now: http://kolmck.net/sf/SOL_vs_others-EN.htm

Из последних изменений: [+] и другие знаки в квадратных скобках - для операций с массивами, аналогично (+) и т.п. - для переопеределённых операций. Кроме шаблонов функций. Дальше: тип результата :NIL для процедуры, т.е. функция, ничего не возвращающая, описывается явно. Дальше: все перегруженные функции должны иметь номер версии. Не перегруженные тоже могут иметь номер версии.

Да, запретил для безблочных вариантов цикла и IF вариант с пустым оператором. С пустым блоком - можно. И язык переименовал: Safe Objective Language. А то на Simple уже немножко не дотягивает. Но пока достаточно простой всё ещё.

Не получилось сразу обновить. Сейчас только обновил.

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

зы. имхо конечно

Сложно потому только что я лично не писал до сих пор полных компиляторов с полных ЯВУ, в основном ассемблерами баловался (правда, один раз в молодости месяца за 3 получился рабочий компилятор с подмножества С в П-код, но это можно объяснить только невероятной наглостью: я же не знал что это так сложно). А так, в принципе, ничего сверх-сложного. Вполне сравнимо с Паскалем и наверняка проще С++. Пока пишу синтаксический анализатор. Даже 4 нотации не так сложны, как можно было бы подумать. Сейчас впереди вижу одну больую сложность: надо как-то реализовывать вычисление константных функций на этапе компиляции, т.е. фактически как бы компилировать код, вызывать его на выполнение, и результат использовать всё ещё в компиляторе. Получается, что эта часть компилятора - сама платформо-зависимая (код ведь должен быть выполнимым на той же платформе где запущен сам компилятор). Для полной платформо-независимости можно сделать свой П-код, специально для этого этапа, и эмулятор П-машины. Это если что.

И хотя я уже к Дельфям не прикасаюсь чаще раза в пол года, стараюсь иногда заглядывать сюда по старой памяти. Владимир, я просто восхищен вашим трудолюбием и количеством наработок! Моё уважение. Желаю успехов в ваших начинаниях! )

Выброси константные функции и всего то делов. В простом языке это не надо. Надо будет заведу переменную и вычислю.

Нет, не выброшу. Это можно сказать треть всех инноваций. Кстати, я язык переименовал. Хоть я и стремился сделать как можно проще (и надеюсь, что это вышло почти), надёжность дороже. Константные функции дают очень много, в том числе для надёжности. Ведь вычисление происходит (в случае константного аргумента) - во время компиляции, а не во время выполнения Недостаток времени выполнения в том, что до вычисления, при котором всё ломается, во время тестирования, может и не дойти. А если константа - вычислится всегда.

Обновил. Добавилась параметризация модуля. Одной числовой константой всего, но лчно мне хватит.

Владимир!! Успехов! Очень долго читал, и пока только общие впечатления - настоящая поэма! Правда основание слишком широкое - мультиплатформенность при всех заявленых опциях... Огромное количество библиотек для разных процессоров, отладка на виртуальной машине(ах)... Библиотеки под разные ОС... По сравнению с этим KOL - это совсем небольшой проект.
Вместе с тем, очень надеюсь, что появится первая реализация, которую можно будет поторогать руками.
Завтра продолжу читать, а то у нас тут уже семь утра...

Здравствуйте, Владимир.
Как успехи на поприще разработки нового языка программирования ?

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

with способен только запутать, но никак не упростить. Кто видел, тот знает.

все хорошо в меру, но его отсутствие сделает синтаксис для такой замечательной возможности ООП как инкапсуляция громоздким...
Может быть ввести некоторые ограничения и особую фому записи? Например сделать невозможность вложенности этого оператора, а внутри его тела использовать специальную форму доступа с полям допустим что-то в духе:


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

Сокращать запись - себе дороже. Программу пишут один раз, а исправляют и подправляют, да и читают просто - десятки и сотни раз. Ну и зачем себе сложности устраивать? Посмотрите, как код пишется в C# - все пишется полностью и без никаких with. При этом при наборе текста чаще всего достаточно вообще одну буквц набрать, и наиболее подходящее имя высвечивается туту же, остаётся только enter нажать. Куда уже короче?

Смысл не в самой короткой записи, а в самом надёжном коде (и при том достаточно эффективном - хотя бы за счёт константых функций, т.е. выполнении на этапе компиляции значительной части проверок), я так понимаю. Вот этот фокус со вставкой строк на языках SQL и прочая - ни в каком C# даже близко не лежало. Может, там что другое предлагается, но я пока не нашёл, хотя немножко программировать на нём попробовал.

Я ещё посмотрел (спустя полгода), и в отличие от предыдущих набросков, изменений практически нет. Единственное, что надо бы выкинуть слово PUBLIC (всё публичное по умолчанию), и оставить HIDDEN, и писать его всё-таки перед каждым объявлением чего-либо скрытого. И вернуться к варианту, когда легальный доступ к скрытому идёт через составное имя HIDDEN. Типа MyObject.HIDDEN.Field1. Немножко меняется IMPORT, всё остальное пока так же. Еще есть смысл для конкатенации строк использовать оператор ',', а не ||. Или как вариант, или всегда. А так - в общем мне самому понравилось. Специально надолго отложить, чтобы самому этот сумбур попытаться воспринять как с листа.

А делать можно именно как компилятор в код на паскале, Си, С# - без особой разницы. Для большей скорости отладки можно делать паскаль-код, и подсовывать его Delphi-компилятору, а для конечной сборки делать выход, к примеру, на Си. Компилятор, который сразу делает маш-код - не самоцель. В общем, это явзык высокого уровня следующего порядка высокости, после Си или Паскаля, можно даже считать его case-средством.