![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
SOL (Соль) = Simple Objects Language
Vladimir Kladov © (2007-12-15 22:08:00)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, который я предложил как черновой, мне самому трашно не нравится. В общем, голову ещё есть над чем поломать.
AndreyRus (2007-12-21 17:11:00) [101]Язык ради языка - мертворожденный!
Vladimir Kladov (2007-12-21 16:09:00) [102]2 flip
Не могли бы Вы привести сравнительную таблицу для SOL, Component Pascal и Oberon-2?Чуть позже. Мне бы сейчас на English компактное описание перекинуть.
И второй вопрос. Вот меня как вычислителя
интересуют быстрые целочисленные операции над 64-битными числами, а в перспективе и 128-битными. SOL способен будет
предоставить минимальные удобства для комфортной работы с такими типами данных, но не в ущерб скорости?
Хоть какие. Что значит не в ущерб? Если используется хорошая библиотека (есть оверлод арифметики, это вообще хоть с какой разрядностью можно работать, да хотя бы и интервальные вычисления поддержать на формулах), инлайн-вставки делаются автоматом, вообще всё на стеке ФПУ будет бегать.
Необходимость нормального ЯВУ для полноценных вычислений давно уже назрел.
Ну я бы не сказал что для полноценных вычислений нет ничего. Тот же Фортран рулит. Мне хочется не столько вычислений, если честно, сколько многопоточности без траблов и тормозов. И побольше проверок на уровне компиляции, и поменьше траблов во врямя выполнения. Чего (мне кажется) я вроде бы добиваюсь, хотя и несколько может быть непривычно (аж три вида указателей).
Vladimir Kladov (2007-12-21 16:03:00) [103]2 hommи flip
Про многопроцессорность, многопоточность, и даже многомашинность:
Я придумал уже. Читаем во вчерашнем номере газеты. Про многомашинность (распределённые вычисления) я много не писал, пардон. Но должно быть и так понятно, что в данном случае (полная изоляция данных разных процессов-потоков) разницы нет. Единствееное, что для распределённых систем лучше подойдут задачи крупнозернистые, с минимальным обменом данными между ячейками - машинами.
Сегодя я выложил версию № (черт, опять 12 - забыл номер поменять). Отдельный блок DO TRY после некоторого размышления и сравнения с Ada решил выкинуть. Теперь функция сама является обработчиком, если в ней есть секции cATCH перем; и FINALLY. Заодно не нужны стали CONTINUE TRY и BREAK TRY, обходимся RETURN, семантика по умолчанию как в Аде - пере-возбуждение с передачей более высокому обработчику.
Vladimir Kladov (2007-12-21 15:55:00) [104]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 есть возможность запрограммировать нижний этаж на ассемблере. В яву конструкции высокого уровня для обработки непосресредственных прерываний от аппаратуры контроллеров - это нонсенс.
homm (2007-12-21 14:11:00) [105]> [47] flip (21.12.07 13:10)
> реализовать прозрачный и надежный параллелизм не только
> межъядерный, но и межпроцессорный,
Не совсем понятно чем многоядерность (лигическая организация проссоров) отличается от многопроцессорности.
> понимая под этим CPU+GPU
Мне не совсем понятно как о таком взиимодействии может идти речь, если у этих типов PU не только разные системы команд и исполняемый код (помоему сами видяшки и компилят код в свое внутренее представление), но и разный жизненный цикл у программы. Являются ли GPU наборы команд Тьюринг—полными?
misha_shar (2007-12-21 13:54:00) [106]Язык высокого уровня по возможностя не должен уступать Асемблеру.
В Асемблере широко используется обработка прерываний. Это альтернатива
линейному выполнению программного кода. Это принципиально другой
подход к программированию. В языках высокого уровня это открытие
Асемблера не используется его почему то никто не замечает хотя
потребность в этом есть. Чтобы решить эту проблему в Delphi
используется бесконечный цикл обработки сообщений. На уровне
языка это никак не решается. Язык имеющий такие свойства может
использоваться для управления процессами реального времени
например управлять ядерным реактором.
flip (2007-12-21 13:10:00) [107]Не могли бы Вы привести сравнительную таблицу для SOL, Component Pascal и Oberon-2? И второй вопрос. Вот меня как вычислителя интересуют быстрые целочисленныеоперации над 64-битными числами, а в перспективе и 128-битными. SOL способен будет предоставить минимальные удобства для комфортной работы с такими типами данных, но не в ущерб скорости? Ну и третий вопрос. Возможено ли в SOL будет реализовать прозрачный и надежный параллелизм не только межъядерный, но и межпроцессорный, понимая под этим CPU+GPU, а заодно и межхостовый по типу MPI и/или Mosix? Скажете слишком многого хочу? Думаю - нет. Необходимость нормального ЯВУ для полноценных вычислений давно уже назрел.
misha_shar (2007-12-21 08:37:00) [108]Посмотрел я SOL. И хочу высказать свои соображения по поводу языка.
1.На выполнение каждой команды можно наложить условие ее выполнения через :.
2.Почему блочной должна быть только одна команда DO. А что если
команды блочными будут еще и команды IF и FOR. Например
IF условие;
..
ELSEIF условие;
..
ELSE
..
ENDIF;
Команда выхода может быть одна например QUIT по которой можно
как завершать цикл в любом месте так и завершать программы-функции.
например для возврата значения QUIT выражение
причем завершать программу и функцию можно в любой точке программы
;
Тогда оператор цикла может быть например таким.
FOR i=100:1:200,316,415 ; параметры цикла могут отсутствовать
QUIT:j=15;может находиться в любом месте цикла
ENDFOR;
3.Описание типов ненужно. Как хранятся данные в машине меня не
интересует пусть всегда это будут массивы чисел. Мне тип переменной
нужен только в опредеренных случаях:
- вывод на внешние устройства и ввод - применять функции форматирования.
- использование индексов - такие пересенные всегда целые
- вычисление значений - операции однозначно диктуют тип результата
- там где мне надо - применять явное приведение типов например
функциями.
Vladimir Kladov (2007-12-20 21:21:00) [109]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... :) ).
Jon (2007-12-20 20:09:00) [110]Will the continued development of KOL suffer because of SOL?
Vladimir Kladov (2007-12-20 19:32:00) [111]А, пардон. Версия 12. Ну, не суть. Важно, что сегодня я это дело разгрыз. Если кто-то недоволен что ажно 3 (три) разновидности указателей, на то у меня резон такой: это даёт гигантские преимущества, и поэтому оправдано. Слабые указатели дают сборку мусора без сборщика мусора. Работа программиста - правильно организовывать структуры данных, и всё. Сольные указатели - в основном для целей многопоточности (собственно, другого применения как-то на горизонте и не наблюдается). Так что, при желании, ими пользоваться и необязательно. Зато сольные гарантируют синтаксический контроль н этапе компиляции того, что данные будут между потоками передаваться корректно, и не будет происходить нечаянное пересечение по данным. А это дорогого стоит.
Vladimir Kladov (2007-12-20 19:27:00) [112]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, для начала).
Бельчонок (2007-12-20 16:19:00) [113]>Чтобы это значило?
См. первый пост, там есть ссылка на документацию...
misha_shar (2007-12-20 16:00:00) [114]см. [0].
Чтобы это значило?
homm (2007-12-20 15:48:00) [115]> [38] misha_shar © (20.12.07 15:47)
> Кстати я хотел бы
> увидеть описание SOL и требования к нему
см. [0].
misha_shar (2007-12-20 15:47:00) [116]Вообще то речь идет о новом языке а не о MUMPSe. MUMPS слава богу
есть и будет независимо от того знаете вы о нем или нет. Я предлагаю взять
для SOL за основу MUMPS доработав его спецификации. Кстати я хотел бы
увидеть описание SOL и требования к нему чтобы понять о чем идет речь.
Я извиняюсь влез в дискусию вконце и совершенно случайно. И может не
понял о чем речь. Прошу меня извинить.
Jon (2007-12-20 14:31:00) [117]
> А в этой обсуждать SOL.
I agree. Any documentation in English yet?
Vedun (2007-12-20 13:45:00) [118]Есть предложение: для обсуждения MUMPSa создать отдельную ветку. А в этой обсуждать SOL.
В принципе соль - это типизированый язык. И сравнивать его с нетипизированым МУМПСом не совсем корректно.
Как и с паскалем и С.
По поводу эффективности. Мне кажется, при правильном и аккуратном написании кожа его эффективность в готовом виде зависит только от компилятора (и его автора).
homm (2007-12-20 12:14:00) [119]> [34] Barloggg (20.12.07 12:01)
> В-дерево дает обалденную скорость поиска
, что все равно бесконечно долго по сравнению с непосредственным вычисления нахождения члена класса (или функции) по известному на момент компиляции смещению.
Barloggg (2007-12-20 12:01:00) [120]ну MUMPS выглядит неплохо. интересно за ним надо таскать кучу библиотек?
лично я посмотрю на него поглубже.
сейчас делаю программу натурально на заказ. и все переменные храню как строки :)
что-то я не верю что мумпс быстрее при базовом типе "строка". это же бесконечные преобразования.
В-дерево дает обалденную скорость поиска и структуризации, но больше преимуществ я что-то не вижу.