|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
Так как никто не обратил на ссылку на Хабре я решил продублировать статью здесь. От MUMPS к MSH. В предыдущей статье я уже пытался рассказать народу о достоинствах такого малоизвестного языка программирования как MUMPS. Но наряду с его достоинствами у него имеются и недостатки о которых я и хотел бы поделиться в данной статье. Некоторые комментаторы которые удосужились взглянуть на этот язык кстати обратили на них внимание. Кроме того, я хочу предложить способы устранения этих недостатков в новом языке MSH. Первое впечатление, которое производит язык MUMPS, это то что он архаичен. Он был создан достаточно давно и будучи закрепленным в стандарте мало изменился по сравнению со своей 2-й редакцией. В MUMPS сообществе существует довольно сильное неприятие изменений этого языка. Но в реализациях пытаются вводить расширения для компенсации его недостатков, правда иногда крайне неудачно. Но несмотря на его недостатки идеология MUMPS очень продуктивна. По большому счету основной недостаток этого языка, это отсутствие объектов и системы обработки событий. Он не объектно ориентирован. Во первых, причина, как всегда, лежит в его истории. В момент его создания объектное программирование не было распространено. Язык был сразу стандартизован, что препятствовало его коренному изменению. Во вторых, включению в язык объектов препятствует отсутствие в языке декларации переменных. Короче, объекты необходимо в язык добавлять. Кроме того, я считаю, что современный язык программирования высокого уровня обязательно должен включать в себя развитую систему обработки событий. Из всех известных мне языков только ассемблер имеет средства обработки событий. Методология обработки событий широко применяется в практике программирования, как в визуальных библиотеках (Delphi, GTK, да и в других) , так и для построения операционных систем. Операционные системы на уровне библиотек имеют различные средства обработки событий. Обработка событий в MUMPS крайне неразвита и фактически сводится к обработке ошибок, правда команда ZTRAP может создать пользовательское событие. В качестве отправной точки для создания языка MSH я взял MUMPS не случайно. Это совершенный язык. Он в каком то смысле идеален. В нем нет противоречий, лишних конструкций. Небольшая, но мощная библиотека встроенных функций языка. Невероятная гибкость языка. Основным, но не единственным достоинством этого языка является организация и управление данными. Описание данных отсутствует. Поэтому любая переменная может выступать в различных видах, в зависимости от контекста. В одном контексте она может трактоваться как строка, в другом как число. Структурой любой переменной является дерево, однако переменная может быть и простой. Расположена переменная может быть как в оперативной памяти, так и на любом блочном устройстве, даже на другом континенте. Представление данных, как в оперативной памяти, так и на внешних носителях, почти одинаково и поэтому данные могут обрабатываться одними и теме же средствами языка. Язык имеет развитую систему обеспечения целостности данных. То есть, это полнофункциональная распределенная база данных. Конкретные реализации также имеют системы журналирования и дублирования данных. Язык имеет встроенную многозадачность со средствами синхронизации. Косвенный синтаксис и команда Xecute позволяют обрабатывать внешние команды, поступающие из вне программы. Первый недостаток устраняется очень просто. Так как в языке принципиально отсутствует декларативность, то декларативная часть описания объекта отбрасывается и остается только реализация объекта в виде стандартного модуля. А в язык добавляется точечный синтаксис для обращения к свойствам объектов. Имя публичного свойства объекта ассоциируется с точкой входа в модуле. Для организации наследования вводим дополнительную команду Extend, в аргументах которой перечисляем всех предков данного класса. А вот систему обработки событий надо разрабатывать полностью. Для этого в язык MSH были добавлены команды обработки событий: 1. EventCall — команда привязывает к событию программу обработки, 2. EventWait — команда ждет наступления заданного события, 3. EventDelete – команда удаляет событие, 4. EventTrap – команда порождает событие. Этих команд должно быть достаточно для обработки событий. События могут быть системными, это те, что порождены внешним окружением. Например, асинхронное открытие устройства или ошибки RunTime в программе. События могут быть порождены и приложением с помощью команды EventTrap, тогда это пользовательское событие. Необходимые параметры передаются программе обработки событий в качестве аргументов. Остальные изменения языка MSH по сравнению с MUMPS не столь принципиальны, но тем не менее должны улучшить его возможности. Начнем с локализации данных. В MUMPS принята своя терминология обозначения областей видимости данных. Аналогом глобалей MUMPS в других языках программирования являются данные расположенные в базах данных. Аналогом локалей MUMPS в языке Си являются глобальные и автоматические переменные. По умолчанию все переменные MUMPS являются глобальными переменными в терминологии языка Си. Для создания автоматических переменных по терминологии Си в MUMPS существует команда New в двух формах. Первая форма соответствует примерно декларированию переменных в языке Си. Все переменные перечисленные в этой команде становятся автоматическими переменными до конца подпрограммы. Вторая форма команды New аналогов в Си не имеет. Это так называемая исключительная форма команды New. В этом случае все переменные не перечисленные в этой команде становятся автоматическими в смысле Си до конца выполнения подпрограммы. Самих понятий глобальных и автоматических переменных в MUMPS нет, все они называются локалями. Такое положение вещей в MUMPS меня всегда напрягало. Неудобно в каждую подпрограмму включать команду New чтобы защитить переменные. Поэтому я решил отказаться от этого способа локализации данных. В MSH существует несколько областей видимости переменных. 1. Переменные локализованные внутри вызова подпрограммы, 2. Переменные локализованные внутри задания, 3. Переменные локализованные внутри приложения, 4. Переменные расположенные на внешних устройствах. А так как в MSH как и в MUMPS отсутствует декларирование переменных, для разграничения областей видимости пришлось использовать единственный известный и проверенный метод древнего Бейсика по префиксу переменной. Переменные локализованные внутри приложения имеют префикс %%. Переменные локализованные внутри задания имеют префикс %. Переменные расположенные на внешних устройствах имеют префикс ^. Все остальные переменные локализованы внутри вызова подпрограммы. Это позволило исключить чудесную команду New. Теперь по поводу структуры данных. В MUMPS одна структура данных для локалей и глобалей - это дерево. Переменные могут быть индексироваными и не индексироваными. Но в глобалях существует такое понятие, как сокращенная ссылка. Сокращенная ссылка сильно затрудняет как понимание программы, так и ее отладку. Кроме того, если в подпрограмме используется сокращенная ссылка, то такая подпрограмма не может быть использована для обработки локальных переменных, что нарушает целостность языка MUMPS. Поэтому в MSH сокращенная ссылка отсутствует. Чтобы язык MUMPS не потерял гибкости, в нем присутствует такая, очень сомнительная конструкция, как косвенный синтаксис. Который позволяет использовать в качестве имени переменной другую переменную, в которой находится имя первой переменной. Звучит несколько коряво, но столь же неудобно им и пользоваться. Эта конструкция языка вызывает много нареканий, поэтому в MSH эта конструкция исключена. А для того чтобы не потерять гибкость языка было решено отказаться от имени переменной и оставить только индекс. Первый индекс трактовать как имя переменной. Конечно, деревянная структура данных очень универсальна. Но она заведомо не оптимальна по скорости доступа для простых, не индексированных переменных. Поэтому в MSH добавлена еще одна структура данных — одномерный массив данных. Перейдем к командам языка. Аргументы отделяются от команды пробелом. В MUMPS есть 2 типа синтаксически разных команд. В командах первого типа следующая команда отделяется от предыдущей пробелом. В этих командах пробелы имеют существенное значение и лишние пробелы недопустимы. Их наличие приводит к синтаксическим ошибкам. Если в команде нет аргументов, то за командой следуют 2 пробела. Команды второго типа завершаются концом строки. Таких команд 3: For, If, Else. Фактически эти команды используются в блоке с другими командами и поэтому их синтаксис отличается. Кроме этого, эти команды в отличии от команд первого типа не имеют условия их выполнения. Все это в совокупности приводит к тому что писать наглядные программы неудобно. В MSH применена несколько другая стратегия синтаксиса. Первое, введен признак конца команды-';'. Пробел сохранен как разделитель между командой и аргументами, но их количество теперь значения не имеет. Второе, введено понятие блочных команд. Команда этого типа является началом блока, а концом блока является команда End. Условие выполнения команды применяется ко всем командам. Синтаксис становится более однородным. Команды блокировки. В MUMPS команда блокировки Lock используется в 2х формах: для блокировки и разблокировки. В MSH команда блокировки разделена на блокировку по чтению, блокировку по записи и разблокировку. Кроме того, для блокировок со временем ожидания используются системные функции. Блокировки используются в основном для синхронизации процессов и синхронизации обращения к данным в разных заданиях. В MSH синхронизация обращения к данным на внешних устройствах и данным уровня приложения выполнены на уровне языка и дополнительного использования команд блокировки не требуют. Команда If стала блочной и должна завершаться либо Else, либо End. Аргументов у этой команды нет, а условие выполнения команды распространяется на весь блок. Команда Else используется вместе с командой If и также может иметь условие выполнения. Тогда эта команда превращается в команду ElseIf. Коменда Else - блочная и должна завершаться либо командой Else, либо командой End. Аргументов у команды Else нет. Другой блочной командой является команда For. Эта команда реализует цикл. По содержанию команда For MSH близка к команде for языка Си. Команда for Си имеет 3 аргумента. 1-й аргумент инициализация цикла. В MSH этот аргумент исключен из команды For. Необходимая инициализация переменных выполняется перед циклом командой Set. 2-й аргумент в Си задает условие окончания цикла. В MSH условие окончания цикла перенесено в условие выполнения команд For и End. Это позволило исключить команды цикла While и do While, так как команда цикла без аргументов реализует эти циклы. 3-й аргумент в команде for Си изменение параметров цикла является аргументом команды For в MSH. В связи с циклами в MUMPS есть одна неудобная особенность. Внутри цикла его можно завершить с помощью команды Quit. Но вся беда в том, что для завершения подпрограммы используется эта же команда, и завершить подпрограмму внутри цикла невозможно. В MSH в качестве команды завершения цикла используется команда Break, а для завершения подпрограммы применена команда Return. Команда Quit исключена. Опыт программирования в MUMPS мне показал что в 90% случаев команда For используется для организации обхода дерева. А это не самая удобная команда. Она требует дополнительных обращений за данными. Поэтому в MSH введены 3 команды итераторов и системная функция обхода дерева. 1. команда Next- обход одного уровня дерева от начала до конца, 2. команда Back- обход одного уровня дерева от конца до начала, 3. команда Query- обход узла дерева на всю его глубину. В MUMPS отсутствует такая полезная команда как Case. В MSH она добавлена в нотации языка Pascal, которая показалась мне более удачной, чем в Си. При этом переменная выбора может быть любого типа. Команда Case MSH блочная и завершается командой End. Метки внутри команды локализованы внутри блока. Нет в MUMPS и такого понятия как константа, а вещь эта очень полезна, поэтому в MSH добавлена команда Const. Для организации наследования в MSH используется команда Extend. Кроме того из Си взята команда Include позволяющая компоновать текст программы из различных кусков. В MSH изменена система передачи параметров в подпрограммы и функции. В MUMPS точки входа в подпрограмму и метки отличаются тем, что у точек входа присутствует иногда список формальных параметров. Но вызвать подпрограмму по любой метке , а возможно и по метке + смещение ничего не мешает, правда передать параметры в этом случае не удастся. То есть, в общем метка от точки входа может ничем не отличаться. Этот подход несколько не логичен и некрасив. Кроме того, список фактических параметров фиксирует их число, что не есть хорошо. В Си вынуждены были с помощью костылей добавить возможность передачи переменного числа фактических параметров. В MSH я поступил по другому. Никакого списка формальных параметров в MSH нет. Обращение к подпрограммам и функциям происходит по меткам в модуле с передачей фактических параметров в традиционной форме. В подпрограмму фактические параметры попадают в специальном массиве аргументов, количество которых сохраняется в нулевом элементе массива. Кроме того, добавлены некоторые операции, самой значительной из которых является операция выбора в синтаксисе языка Си. Все это было сделано для того, чтобы создать современный, надежный , гибкий язык программирования информационных систем. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 09:47 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
вы уже много статей по MSH написали, но пока ни разу не показали его может все таки уже пора от слов так сказать к делу ? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 10:12 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
misha_sharТак как никто не обратил на ссылку на Хабре я решил продублировать статью здесь.Обратил. Сразу. Поэтому и не публиковал здесь ссылку на Вашу статью на Хабре, но раз Вы сами настаиваете ... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 10:17 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
DAiMor, Давно пора. Но попадаются непредвиденные препятствия. Все хотят увидеть законченный продукт. А до этого далеко. Программы трансляции в Pi код и выполнение этого кода в 0 версии я думаю есть.Для основных команд. Но такой сырой продукт представлять сообществу опасно. Мне бы очень вы помогли если бы в свой IDE включили MSH. Последнюю спецификацию и программы трансляции я тогда вам пришлю. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 12:35 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
Мне самому еще очень далеко до готового продукта, которым можно пользоваться, но я выложил. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 13:00 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
DAiMor, Так что насчет включения MSH в ваш проект IDE? Заодно и отладим вместе. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 14:26 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
misha_sharDAiMor, Так что насчет включения MSH в ваш проект IDE? Заодно и отладим вместе.Думаю, что до включения еще очень далеко, для начала мне нужно сделать поддержку хотя бы одной платформы, более-менее полноценно ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 15:10 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
misha_sharТак как никто не обратил на ссылку на ХабреОбратили. Почему молчим? Возможно, потому что обсуждать статью о несуществующем языке не очень интересно. О самой статье можно сказать, что она очень субъективна: изобилует эпитетами типа "удобно", каждый из которых порождает вопрос "удобно кому?". Причины популярности ЯП вообще штука туманная: есть примеры провала удачно спроектированных языков и успеха "уродцев". Поэтому непонятно, как исходя из голословных утверждений можно прогнозировать успех подобной затеи. PS. Всё сказанное выше - ни в коем случае не в обиду. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 16:07 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
Alexey Maslov, Теперь все понятно. А я думал что просто никто не прочитал. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 16:12 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
Alexey Maslov, полностью согласен. Когда я слышу от формулирующего задачу / постановщика / менеджера / начальника слово "удобно", я понимаю, что человек что-то хочет сказать, но пока сформулировать еще не в состоянии. Когда человек начинает понимать, о чем он говорит, то вместо слова "удобно" начинает говорить что-то более определенное. Если вся постановка задачи описана словами "сделать чтобы было удобно", или "удобный интерфейс" то понимаешь, что сейчас этот текст надо бы выбросить. К сожалению, такая возможность бывает не всегда. misha_shar, Хорошо бы описать что означают события на сервере и их механизм - от чего возникают, как попадают в job / в объекты / в компоненты и каков порядок исполнения программы. Это же сервер, это где-то там, может даже с той стороны планеты. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 16:27 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
ну яAlexey Maslov, полностью согласен. Когда я слышу от формулирующего задачу / постановщика / менеджера / начальника слово "удобно", я понимаю, что человек что-то хочет сказать, но пока сформулировать еще не в состоянии. Когда человек начинает понимать, о чем он говорит, то вместо слова "удобно" начинает говорить что-то более определенное. Если вся постановка задачи описана словами "сделать чтобы было удобно", или "удобный интерфейс" то понимаешь, что сейчас этот текст надо бы выбросить. К сожалению, такая возможность бывает не всегда. Под словом удобно каждый может понимать все что ему нравится. А я понимаю то что мне удобно или неудобно. Мне неудобно для каждой подпрограммы писать команду New и перечислять ее параметры, а затем следить за ними при модификации подпрограммы. Это слово не лучше и не хуже других. И что я понимаю или не понимаю из этого слова не следует. ну яХорошо бы описать что означают события на сервере и их механизм - от чего возникают, как попадают в job / в объекты / в компоненты и каков порядок исполнения программы. Это же сервер, это где-то там, может даже с той стороны планеты. Какое отношение описание механизма имеет к свойствам языка? Механизмы могут быть разными. Причем тут сервер? Язык может функционировать и на сервере и на клиенте. Работает приложение в среде ОС. В ОС возникают события которые обрабатываются приложением. В событиях где вы видите объекты? Как попадают в job? В Linux реализована обработка сигналов. Так и попадают у меня события в job. Можно и другие способы реализовать. В ОС для этого достаточно средств. Но какое отношение это имеет к спецификации языка? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 17:09 |
|
От MUMPS к MSH
|
|||
---|---|---|---|
#18+
misha_shar, Об event команде для mumps, в приложеном файле описание, того что хотелось получить :) однако .. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.10.2014, 20:10 |
|
|
start [/forum/topic.php?fid=39&msg=38791725&tid=1556781]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
150ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
others: | 273ms |
total: | 532ms |
0 / 0 |