см. [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 мало что может, а расширения - это уже не он сам).