SOL (Соль) = Simple Objects Language

← →
misha_shar © (2007-12-20 16:00) [40]

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

← →
Бельчонок (2007-12-20 16:19) [41]

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

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

← →
Vladimir Kladov © (2007-12-20 19:27) [42]

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, для начала).

← →
Vladimir Kladov © (2007-12-20 19:32) [43]

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

← →
Jon © (2007-12-20 20:09) [44]

Will the continued development of KOL suffer because of SOL?

← →
Vladimir Kladov © (2007-12-20 21:21) [45]

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... :) ).

← →
misha_shar © (2007-12-21 08:37) [46]

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

← →
flip (2007-12-21 13:10) [47]

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

← →
misha_shar © (2007-12-21 13:54) [48]

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

← →
homm © (2007-12-21 14:11) [49]

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

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

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

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

← →
Vladimir Kladov © (2007-12-21 15:55) [50]

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 есть возможность запрограммировать нижний этаж на ассемблере. В яву конструкции высокого уровня для обработки непосресредственных прерываний от аппаратуры контроллеров - это нонсенс.

← →
Vladimir Kladov © (2007-12-21 16:03) [51]

2 homm и flip

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

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

← →
Vladimir Kladov © (2007-12-21 16:09) [52]

2 flip

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

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

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

← →
AndreyRus © (2007-12-21 17:11) [53]

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

← →
D[u]fa (2007-12-21 17:24) [54]

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

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

← →
Vladimir Kladov © (2007-12-21 18:48) [55]

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

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

← →
Бельчонок (2007-12-21 21:12) [56]

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

← →
Vladimir Kladov © (2007-12-22 07:41) [57]

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

← →
misha_shar © (2007-12-22 07:56) [58]

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

← →
Vladimir Kladov © (2007-12-22 10:16) [59]

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

← →
misha_shar © (2007-12-22 14:14) [60]

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

← →
Vladimir Kladov © (2007-12-22 19:03) [61]

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

← →
Vladimir Kladov © (2007-12-22 19:06) [62]

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

← →
vpbar © (2007-12-23 00:31) [63]

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

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

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

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

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

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

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

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

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

← →
Vladimir Kladov © (2007-12-23 02:10) [64]

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

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

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

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

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

← →
Vladimir Kladov © (2007-12-23 10:21) [65]

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.

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

← →
vpbar © (2007-12-23 15:33) [66]

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

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

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

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

← →
homm © (2007-12-23 15:46) [67]

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

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

← →
vpbar © (2007-12-23 16:08) [68]

>>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]
> > Не надо шаблонов? Может и не надо.
>
Это вы с кем беседуете?

SOL (Соль) = Simple Objects Language Найти похожие ветки