Ремесло программиста

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.

Вы здесь » Ремесло программиста » Валентина » Проект краткого синтаксиса

Проект краткого синтаксиса

Страница: 1 2  

Сообщений 1 страница 30 из 52

1

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Здесь я предлагаю всем желающим поучаствовать в создании краткого синтаксиса к языку (то есть такого который для написания программы, синтаксис для чтения будет обсуждаться позже).
Итак общая структуры программы есть паскалевский юнит:

Система: Тип_системы
Внешние системы: Список_имен_внешних_систем_через_запятую
Точка входа: Имя_функции_для_запуска_системы_как_самостоятельной_программы
Конструктор: Имя_функции_ответственной_за_подготовку_системы_к_работе
Интернациональные описания:
Идентификатор_на_национальном_языке=Идентификатор_на_английском
Структура
Открытая часть
    Список_и/или_описания_систем
    Список_функций
    Значение
Закрытая часть
    Список_и/или_описания_систем
    Список_функций
    Значение
Реализация функций
Список_описаний_функций
Система закончена

На данный момент рассматривается только участок

Система: Тип_системы
Внешние системы: Список_имен_внешних_систем_через_запятую
Точка входа: Имя_функции_для_запуска_системы_как_самостоятельной_программы
Конструктор: Имя_функции_ответственной_за_подготовку_системы_к_работе
Интернациональные описания: Идентификатор_на_национальном_языке=Идентификатор_на_английском

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

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

2

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25

utkin

utkin написал(а):

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

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

Вы тут хотите изобрести EBNF ?

Так как тему вопроса я так и не понял, то отвечаю как понял.

1) Не копировать паскаль.  У него недостаток нельзя раскидать классы по модулям из-за запрета на циклические связи.
2) Не копировать Си++ у него проблемы с линковкой этих модулей. Особенно это выражается в проблемах с глобальными переменными/объектами.

utkin написал(а):

Точка входа: Имя_функции_для_запуска_системы_как_самостоятельной_программы

А оно надо? Просто я к чему это такая редкая необходимость, что она кажется и ненужной.  Большинство объектов в QT это по сути библиотеки с функциями и структурами которые в точках не нуждаются. А те которые нуждаются их всего два или три вида. Это виджеты, потоки, плагины(сюдаже DLL). Их предкам тоже не нужна так как они наследуют черты и берут имена такой точки от предка. Остальным самостоятельность ненужна если конечно вы не планируете разработку своего ЦП?
Лучше рассматривать модель общения через сигналы/слоты.

utkin написал(а):

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

У вас все системы имеют жёсткую структуру и подчиняются принципу единоначалия(иерархичности).
А как насчёт кольцевых ссылок между модулями/системами?

utkin написал(а):

Система: Список, можно писать / Список /.

Как бы обще принято, что слешами выделяются регулярные выражения. Список выделяется запятой и группируется скобками. К примеру как в TCL.

utkin написал(а):

Конструктор: Имя_функции_ответственной_за_подготовку_системы_к_работе


Это избыточная информация. Имя для конструктора должно быть у разных систем одинаковое.

Отредактировано Павиа (2017-09-27 15:10:49)

3

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12

Точка входа: Имя_функции_для_запуска_системы_как_самостоятельной_программы

Вместо этого для запуска программы куда-то передаётся "вызвать функцию X системы Y".

4

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

И как сиё изволите  понимать? Пишем по одним правилам к примеру по русски, читаем по другим к примеру английским.

Нет конечно. По умолчанию предполагается два варианта. Более подробный предназначен для удобства чтения. Вы не обязаны им пользоваться вообще. Вы всегда сможете определить свой собственный и наслаждаться им. Проблема возникает из последнего пункта - Ваш будет непонятен мне, мой не понятен Вам. Поэтому будет общий, понятный всем. Беда №2 - То что удобно для чтения, абсолютно неудобно для записи и как правило наоборот. Безусловно подробный синтаксис будет иметь логическую связь с кратким, чтобы человеку не рвало шаблон. Собственно это одна из причин почему его надо делать позже.

Какой-то абсурд.

Мы все зажаты рамками своих стереотипов об устройстве мира. Мои отличаются от Ваших.

Вы тут хотите изобрести EBNF ?

Нет, конечно. Такое подобие будет строиться автоматически (Валентина-1 это умела).

Так как тему вопроса я так и не понял, то отвечаю как понял.

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

1) Не копировать паскаль.  У него недостаток нельзя раскидать классы по модулям из-за запрета на циклические связи.

Почему недостаток? Это фича :)

2) Не копировать Си++ у него проблемы с линковкой этих модулей. Особенно это выражается в проблемах с глобальными переменными/объектами.

А как делать?

А оно надо? Просто я к чему это такая редкая необходимость, что она кажется и ненужной.

Класс это набор описаний. Какое описание должно запускаться первым? Что должна выполнять программа? Вот в с++ есть main. Это жестко прописано. А здесь Вы можете написать не main. Верней не только main, а все что пожелаете.

Лучше рассматривать модель общения через сигналы/слоты.

Здесь стоит вопрос - кто будет первой скрипкой в оркестре?

У вас все системы имеют жёсткую структуру и подчиняются принципу единоначалия(иерархичности).

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

А как насчёт кольцевых ссылок между модулями/системами?

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

Как бы обще принято, что слешами выделяются регулярные выражения. Список выделяется запятой и группируется скобками. К примеру как в TCL.

Нет, здесь Список это собственное имя. Просто пример. Ну пусть там будет вместо Список Вертолет например. Это не встроеная возможность списка, это просто собственный идентификатор, определяемый программистом. Как TStringList например.
Ну вот отдаленной аналогией для Система: Тип_системы является Тип_системы=class в Паскале. Вот писать слово Система долго, можно обойтись всего двумя символами, необязательно слешами, например * Система *
Звездочка тоже не требует шифта.

Это избыточная информация. Имя для конструктора должно быть у разных систем одинаковое.

Почему должно? Кто так решил, с чем связано? Что мешает? Не вижу причины быть должным в данном случае. Отсутствует аргументация, а решение не очевидно.

Вместо этого для запуска программы куда-то передаётся "вызвать функцию X системы Y".

Да-да. Просто когда программа запускается, кто то же должен начать исполняться. Функций пятьсот, у всех равные права. Вот мы и назначаем виновника торжества.

5

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25
utkin написал(а):

Почему должно? Кто так решил, с чем связано? Что мешает? Не вижу причины быть должным в данном случае. Отсутствует аргументация, а решение не очевидно.

Люди нужен символ или знак. Он им нужен что-бы общаться. Передавать мысль от одного другому. Он нужен что-бы запоминать. Человек 90% информации воспринимает через глаза.
И уже после он видя символ выстраивает логическую цепочку.

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

Так вот новичку проще запомнить одно слово main init create execute и его использовать по всюду. 90% логики основана на сведении к предыдущему знанию. Если у него будет разнообразие он будет только путаться и тупить. Новичку нужно одно слово!

А писать в объявлении откуда мы начинаем работу просто избыточно. Взять тот-же бесик (GWBasic) у него исполнение всегда начиналось с первой строчки. Что упрощала синтаксис, но создавал проблемы с обучением так-как возникал вопрос куда вставлять данные. И приходилось через goto их перепрыгивать.

utkin написал(а):

Нет, здесь Список это собственное имя. Просто пример. Ну пусть там будет вместо Список Вертолет например. Это не встроеная возможность списка, это просто собственный идентификатор, определяемый программистом. Как TStringList например.

Во времена ДОС была разработана хорошая практика угловых и квадратных скобок. Вот почему люди о ней забывают?
Угловыми скобками описывался обязательны параметр квадратными опциональный(такой который вовсе можно не писать).

Пример на БНФ

переменная   : 'const' определитель ':'  род '='  значение постоянной ';'
                               | 'const' определитель ':'  род '='  '(' [значение   постоянной] ','  ...  ')' ';'
                               ;
значение постоянной : число
                              | строка
                              | 'true'
                              | 'false'
                              ;

Пример на ДОС стиле

const <определитель> : <род> = <значение>;
const <определитель> : <род> = true ;
const <определитель> : <род> = 'строка' ;
const <определитель> : record
                                          Name:String;
                                         Year:Integer;
                                         Highte:Real;
                                       end  = ('Вася', 18, 183.5) ;

Отредактировано Павиа (2017-09-27 21:41:48)

6

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25

Наконец-то я понял что вы хотите.

utkin написал(а):

Система: Список, можно писать / Список /.

Я бы не стал сокращать. Слова все знают, а символы ещё учить надо. Тем более на парсере это никак не влияет - так и так 3 строчки.

Код:
NeedSimvol(TS('Система'));
NeedSimvol(TS(':'));
Indefiner:=NeedIndefiner;
Код:
NeedSimvol(TS('/'));
Indefiner:=NeedIndefiner;
NeedSimvol(TS('/'));

А если хотите оптимизировать то предлагаю JSON, я только фигурные скобки круглыми заменил

Код:
Заголовок_системы:(Тип_системы, Список_имен_внешних_систем_через_запятую, Имя_функции_для_запуска_системы_как_самостоятельной_программы, Имя_функции_ответственной_за_подготовку_системы_к_работе)

Отредактировано Павиа (2017-09-27 21:35:13)

7

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12
utkin написал(а):

Функций пятьсот, у всех равные права. Вот мы и назначаем виновника торжества.

Обычно интерпретаторы умеют выполнять любую функцию.

8

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Люди нужен символ или знак. Он им нужен что-бы общаться. Передавать мысль от одного другому. Он нужен что-бы запоминать. Человек 90% информации воспринимает через глаза.

Ну вот есть знак. Допустим будет такой вариант:
!:: имя_функции_конструктора
Почему имя конструктора всегда должен быть каким-то одним? Не вижу логики. Так программист пойдет в начало описания и увидит строчку типа:

!:: Создатель_системы

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

Видя эти слова человек их ассоциирует с теорией изложенной в этой книге.

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

90% логики основана на сведении к предыдущему знанию.

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

Взять тот-же бесик (GWBasic) у него исполнение всегда начиналось с первой строчки.

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

Во времена ДОС была разработана хорошая практика угловых и квадратных скобок. Вот почему люди о ней забывают?

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

Я бы не стал сокращать. Слова все знают, а символы ещё учить надо. Тем более на парсере это никак не влияет - так и так 3 строчки.

Пофиг сколько в парсере строчек. Это проблемы парсера, а проблемы негров как известно шерифа не интересуют. Вы опять поклоняетесь своим компьютерным богам. Меня интересует как сделать приятной жизнь человека, а не трудоемкость работ для парсера.
Насчет самого слова думать надо. Допустим здесь можно оставить все как есть. А в других случаях? Писать Интернациональные описания: немного нудно и скучно. Вот сейчас задача продумать эти описания для конкретной секции, затем эти описания будут добавлены в файл описания диалекта и по нему уже потестятся для разбора данной секции. Затем следующая и т.д. В конце концов придет к разбору тела функции. Таким образом завершим первый этап - перевод программы во внутренне представление. Затем уже будет этап №2 - исполнение программы.

А если хотите оптимизировать то предлагаю JSON, я только фигурные скобки круглыми заменил

Это в описании системы? Вы бы стали сами так программировать?

Обычно интерпретаторы умеют выполнять любую функцию.

Да, понятно. Вопрос в том, кто будет первым. Вот в си++ известно кто первый - main. А здесь мы сами пальчиком показываем на того, кто начнет.

Собственно говоря сам клавиатурный фактор. Мы имеем русские буквы, символы без шифта (- = \ / * - + , .), символы с шифтом (! " № ; % : ? * ( ) _ ). Все прочие символы требуют переключения раскладки. Очень хорошо писать так, чтобы переключаться по минимуму и вообще супер как можно меньше нажимать шифт. Понятно что это утопия, но к этому нужно стремиться, если мы хотим облегчить жизнь программисту (а не парсеру). И поскольку разбор данной секции выполняется отдельно (изолированно от содержимого функций), знаки можно перегружать смыслом (но без фанатизма, чтобы человек не морщил лоб в попытке понять, что там на мониторе нацарапано). То есть здесь любой символ имеет совершенно иное значение, в сравнении с телом функции, так слешик это просто слеш, а не деление, звездочка это звездочка, а не умножение.

9

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25
utkin написал(а):

Да, понятно. Вопрос в том, кто будет первым. Вот в си++ известно кто первый - main. А здесь мы сами пальчиком показываем на того, кто начнет.

Так а кто сам говорил что поиск это лишняя трата времени?  Не важно что эта запись в начале файла, но файл таки придётся пролистать что-бы найти точку входа.
Во-вторых вы видимо не видели как часто задают вопросы новички. При переходи с паскаля на Delphi пишут Init и спрашивают почему не работает когда надо писать Create.
При переходи с Delphi на Си ищут Create и Destructor. А при переходи с Си на ассемблер пишут main и спрашивают почему не работает программ? Когда как в ассемблере мы должны указать имя точки старта.Даже в тех же дельфях при переходи от классов к потокам вместо Execute пишут код в Create и думают что он будет работать-параллельно.
Поэтому, что-бы люди не делали ошибок и нужно слово - одно слово.

utkin написал(а):

Ну вот есть знак. Допустим будет такой вариант: !:: имя_функции_конструктора

Если тебя могут понять неправильно, то тебя поймут неправильно. Говоря о символе я имел ввиду - слово.

utkin написал(а):

Это в описании системы? Вы бы стали сами так программировать?

Нет конечно! Я за использование слов пусть эта избыточно, зато всем понятно и безсправки. Да и системы создаются не так часто.

utkin написал(а):

Пофиг сколько в парсере строчек.

Это вы жаловались за сложность парсера.

utkin написал(а):

И это приводит к ошибкам проектирования.

Это только плохая метафора приводит к ошибкам. Но ведь есть и хорошие метафоры.

utkin написал(а):

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

У новичка нет ассоциаций с другими языками окромя русского.

utkin написал(а):

Мне нужен синтаксис языка. Чего тут непонятного?

Вы вместо того что-бы воспользоваться обще принятым описанием синтаксиса на ЕБНФ привели своё описание, которое разумеется никто не понял. Будим считать это примером текста программы.

utkin написал(а):

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

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

Вот вам пример моего синтаксиса

Система: <имя системы>[(<имя системы>)]
Внешние системы: <имя системы>, ...
На старт: <имя_функции>
Пуск: <имя функции>
Псевдонимы: <Идентификатор_на_национальном_языке>:=<Идентификатор_на_русском_языке>;...

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

Семантика:
Имя системы соответствует её типу. В круглых скобках указывается предок.
На старт - команда подготовки системы. аналог Init из паскаля. С целью соответствия RAII  думаю Create лишним, вместо него использовать отпочкование(инстацирование).
Пуск -  функция с которой начинается работы системы как некоторый процесс. Вызову этой функции предшествует вызов команды на старт.
Псевдонимы записываются через точку с запятой это просто имена собственные.

Отредактировано Павиа (2017-09-28 08:35:00)

10

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

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

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

Во-вторых вы видимо не видели как часто задают вопросы новички. При переходи с паскаля на Delphi пишут Init и спрашивают почему не работает когда надо писать Create.

Потому что в Делфи по умолчанию Create и Destroy завязаны на автоматику. Например, Free пытается вызвать Destroy. Это не значит что нельзя назвать по-другому. Например, в том же Паскале это не возбраняется. Можно насоздавать кучу например деструкторов с разными именами и параметрами, нет проблем. Так почему Паскалю можно, а мне нет? Новичок чтобы не ломать шаблон может написать конструктор Init и юзать его дальше. Create это на вроде переменной i в цикле - общеупотребительное выражение (ну и плюса автоматика как уже писал ранее). Вместо Destroy можно писать например Kill. Не будет работать вызов Free (точней будет - Destroy ведь определен ранее, но не правильно).

При переходи с паскаля на Delphi пишут Init и спрашивают почему не работает когда надо писать Create.

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

Если тебя могут понять неправильно, то тебя поймут неправильно. Говоря о символе я имел ввиду - слово.

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

Нет конечно! Я за использование слов пусть эта избыточно, зато всем понятно и безсправки. Да и системы создаются не так часто.

Тогда над этим надо крепко подумать.

Это вы жаловались за сложность парсера.

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

Это только плохая метафора приводит к ошибкам. Но ведь есть и хорошие метафоры.

Согласен. Надо думать, но одному долго и не факт, что получится.

У новичка нет ассоциаций с другими языками окромя русского.

В школе его могут пичкать Паскалем или Питоном (он сейчас набирает популярность как замена Бейсику).

Вы вместо того что-бы воспользоваться обще принятым описанием синтаксиса на ЕБНФ привели своё описание, которое разумеется никто не понял. Будим считать это примером текста программы.

Так тут беда, что нету синтаксиса! Нечего описывать! Вот чтобы написать все эти матерные ЕБНФ нужно чтобы было о чем писать. А тема об этом и есть чтобы родить синтаксис. Я привел просто шаблон для примерного представления о том, что должны делать конструкции, а самих конструкций нет еще.

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

Это понятно. В-1 это все делала сама. Ей пихали такой вот файл с описанием конструкций, а она давала более цивилизованный вид.

Пуск: <имя функции>

Пуск хорошая альтернатива Точке старта.
Псевдонимы тоже хорошо (коротко и понятно).

При написаниие программы разумеется его писать не стоит.

А сейчас важно понять что именно писать при написании программы. Блин пока цель объяснишь десять портянок текста уйдет.

Имя системы соответствует её типу.

Типа того :)

В круглых скобках указывается предок.

Это в другой секции наверно или вообще в этом нет смысла. Я могу любую другую систему описать как часть данной системы. Тут какие-то терки с теорией.

На старт - команда подготовки системы. аналог Init из паскаля. С целью соответствия RAII  думаю Create лишним, вместо него использовать отпочкование(инстацирование).

Тут фишка в том, что это и класс и объект одновременно. Вот Пуск это явно демонстрирует. С другой стороны данный модуль можно будет подключить к другой программе и использовать данную систему как класс для порождения других систем. А если запускать через Пуск, то это полноценная система (а не описание системы) с динамическим поведением. Поэтому тут надо аккуратно с теорией.
Итак, берем пока за основу синтаксис Павиа:

Система: <имя системы>[(<имя системы>)]
Внешние системы: <имя системы>[, <имя системы>].....
На старт: <имя_функции>
Пуск: <имя функции>
Псевдонимы: <Идентификатор_на_национальном_языке>:=<Идентификатор_на_русском_языке>;...

Что не нравится? Внешние системы - писать долго. Может быть вариант Требования: <имя системы>[(<имя системы>)]? Еще кандидаты: Использовать, Включить. Немного меньше символов при наборе текста программы. Вопрос №2, влияющий на правила разбора, вот эти двоеточия они обязательны? Или может можно использовать аналогично и без двоеточий (то есть оба варианта рассматривать?). И вопрос №3 - включить дополнительный синтаксический сахар или полностью заменить двоеточния дефисом?

Система - <имя системы>[(<имя системы>)]
Внешние системы - <имя системы>[, <имя системы>].....
На старт - <имя_функции>
Пуск - <имя функции>
Псевдонимы - <Идентификатор_на_национальном_языке>:=<Идентификатор_на_русском_языке>;...

Как вариант разрешить дефисы наравне с двоеточиями там где указываются имена_функций (то есть На старт и Пуск).
Чтобы избежать путаницы некоторые соглашения о записи.
Итак конструкция в общем виде описывается аналогично:

Система - <имя системы>[(<имя системы>)]

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

Система - Вертолет

11

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12

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

Именно это и подразумевал:

Обычно интерпретаторы умеют выполнять любую функцию.

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

Еще кандидаты: Использовать, Включить.

Несут разный смысл, первое - зависимость, второе - часть или запуск.

12

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Да, наверно это лишние термины. Тогда слово Требования? Стоит задача заменить Внешние системы на более короткое наименование.

13

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25

utkin
Мне как-то слово "требования" не нравится: в том смысле, что из оно из общего ряда выбивается. Может использовать слова "Нужны" или "ей нужны"

Система  - вертолёт;
Ей нужны - мотор, каркас;
Вводные:
   Связать(на старт,  Вертолёт.подготовка);
   Связать(пуск, Вертолёт.пуск);

Связать - сигналы и слоты. На старт и пуск это такие сигналы которые есть у каждого объекта.
подготовка и пуск слоты.

Отредактировано Павиа (2017-09-29 08:14:23)

14

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

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

Система - <имя системы>
Ей нужны - <имя системы>[, <имя системы>].....
На старт - <имя_функции>
Пуск - <имя функции>
Псевдонимы - <Идентификатор_на_национальном_языке>:=<Идентификатор_на_русском_языке>;...

Ну красиво же :).

15

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12

Вопрос №2, влияющий на правила разбора, вот эти двоеточия они обязательны?

Да, нужны двоеточия, а не черточки.

Ей нужны хороший вариант

Лучше просто "нужно".

На старт - <имя_функции>
Пуск - <имя функции>

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

На старт

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

16

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Да, нужны двоеточия, а не черточки.

ОК.

Система: <имя системы>
Нужно:  <имя системы>[, <имя системы>].....
Создание: <имя_функции>
Пуск: <имя функции>
Псевдонимы: <Идентификатор_на_национальном_языке>:=<Идентификатор_на_русском_языке>;...

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

Всегда после конструктора. Так ведь есть шанс нарваться на не готовую к работе систему и вообще смысл конструктора теряется.

Лучше "создание".

Может Подготовка? А то так по виду, как будто не систему будут создавать, а она чего-то создает...

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

Ну тут сложный вопрос, может что-то типа предусловий каких-нибудь? Но так слишком четко прорабатывать пока рано. Исправить позже можно.

17

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12
utkin написал(а):

Может Подготовка? А то так по виду, как будто не систему будут создавать, а она чего-то создает...

Для очевидности строго порядка - да. Системы подготавливаются и запускаются.
Если допускаются разные конструкторы, то логичнее "способы подготовки".

utkin написал(а):

Ну тут сложный вопрос, может что-то типа предусловий каких-нибудь?

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

18

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Стоп-стоп-стоп, не так быстро, я не успеваю за Вашей мыслью. Это ведь нужно только при самостоятельном старте. Если система в составе другой системы, можно также как и в объектах просто обращаться к отрытым частям. Многократный запуск программы с разными точками входа наверно не тривиальная задача.

19

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12
utkin написал(а):

не успеваю

А я ещё и поправки внёс - надо перечитывать полностью) Что с числом конструкторов?

не тривиальная задача.

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

20

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Один пока :).

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

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

"пуск X.Y"

Если так прописывать извне, снаружи модели, то существуют проблемы безопасности. Можно ведь попытаться состряпать какой-нибудь сканер систем, который там методом перебора, пытался выполнить
х.а
х.б
х.в
ну и в том же духе. Нужен надежный механизм доступа, чтобы нельзя было произвольно запускать все что захочется из открытой части системы (в закрытую, понятно, доступ только у самой системы). Ну например, вот аналогия в Делфи, есть же секции
private
protected
public
Их можно переобмозговать
Вот private получается закрытая часть
protected это для работы внутри систем
public для возможности запуска функций при старте системы как самостоятельной программы. То есть запускать программу можно будет только вызовом строго из определенного списка функций. Как быть с конструкторами не понятно, можно их вообще отменить, пусть стартовая функция берет на себя обязательства по подготовке системы к работе.
Предлагайте варианты.
Фактически мы сейчас стираем границы между системой, классом, компонентом и программой (а также функциями, так как они тоже системы)...

21

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25
utkin написал(а):

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

Ну красиво же .

Тогда если это декларации так и надо использовать декларативные слова.
Для декларации пишем «начало», а для  запуска как самостоятельную систему служебное слово «пуск»

utkin написал(а):

пусть стартовая функция берет на себя обязательства по подготовке системы к работе.

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

utkin написал(а):

ну и в том же духе. Нужен надежный механизм доступа,

А как же тестирование? Ну не писать же тесты вместе с системой в одном файле. А для тестов важно иметь возможность сразу войти в нужную функцию минуя все остальные.
Тем более вы сами хотели такой синтаксис. Когда части системы живут независимо - так как они тоже системы.
В принципе можно ввести налог «usage» - «погружение в систему», тогда если мы погрузились в систему то мы обходим уровень защиты.

Где-то я видел идею дружественных классов - не помню где.

MihalNik написал(а):

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

Хорошие слова. Только мне кажется вам стоит развить мысль.

22

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Это не хорошо. Пусть будет функция сбросперезагрузка.

И тут грабли - если дать возможность программе запускаться из разных точек, то и конструкторы могут/должны быть разными, универсальный конструктор может получиться очень громоздким + плохо сопровождаемым.

Хотелось бы запускать систему из внешне среды. Тогда внешняя среда может подготовить объекта к запуску и лучше если эта функция уже будет у самого объекта.

Вопрос идет не в этом. А в том, что у с++ например есть функция main. Она всегда стартует первой. А здесь будет много main'ов. Внешняя среда указывает какой main исполнить:

программа.старт_сервер
или
программа.старт_клиент

Мы получаем не систему-программу, а систему-пакет, в которой смешались в кучу люди-кони... и рука бойца колоть устала. Задача сделать так, чтобы все это не свалилось в вакханалию, Содом и Гомору, ужас в ночи... Чего-то у меня сегодня лирическое настроение  :rofl:
У нас уже не система, у нас функция-система-компонент-программа-пакет_программ. Надо теперь чтобы были цивилизованные и удобные механизмы для работы со всем этим бардаком.

С точки зрения унификации нет надобности вводить дополнительные служебные слова. Пусть это будет обычная функция.

Да, блин, проблема в другом! Не функция, а функции! Понимаете? Михальник предлагает возможность выбора и мне его идея нравится. Содержание есть, нужно придать форму.

А как же тестирование? Ну не писать же тесты вместе с системой в одном файле.

А в чем проблема? Что Вам мешает это делать? Мыслите шире, копайте глубже. Тем более контрактное программирование прямо вот просится в такой тест в составе системы.

А для тестов важно иметь возможность сразу войти в нужную функцию минуя все остальные.

Так если тест это часть системы, то как раз у теста проблем с доступом вообще-то и нет. Задача сделать так, чтобы снаружи кто попало не запускал что не надо, но имел возможность запускать разные вещи из одного флакона.

Тем более вы сами хотели такой синтаксис. Когда части системы живут независимо - так как они тоже системы.

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

В принципе можно ввести налог «usage» - «погружение в систему», тогда если мы погрузились в систему то мы обходим уровень защиты.

Нет, смотрите. Когда система вызывает систему, то она получает ее как возможность включения в качестве подсистемы. С этим все ОК. Речь идет о взаимодействии на уровне вызова из внешней среды. То есть получается три уровня:
1. Система работает с подсистемами, написанными внутри себя.
2. Система получает доступ к описанию систем из внешнего модуля и сводит работу с ними к п.1
3. Систему дергает чужеродная среда (кто-то запустил интерпретатор с системой и хочет от нее каких-то результатов). Вот для этого вопроса надо:
- обмозговать чего хотим и каким образом;
- спроектировать внутренне поведение системы и интерпретатора (в целях обеспечения безопасности модели и данных системы);
- придумать синтаксис.
Чтобы Вы опять не уехали в сторону в п.3 систему можно запустить по-разному. Вызвать сначала одну функцию, а при следующем старте например другую функцию. Это может кардинально менять поведение системы. Ну типа как встроенная возможность использовать ключей в Дос программах.
Ну вот есть команда dir - вывод на экран содержимого каталога, у нее куча параметров задаются ключами (типа вывести конкретный каталог или все каталоги)
Здесь все аналогично, только вместо ключей, мы указываем какую функцию запускать в системе и тем самым меняем ее поведение и реакцию на внешние раздражители.

Где-то я видел идею дружественных классов - не помню где.

Да полно где они есть, называются понтово - миксины. Хоть Питон, хоть Руби, не помню, вроде ЖабаСкрипт тоже. В Делфи всякие хелперы...

Хорошие слова. Только мне кажется вам стоит развить мысль.

Вот я тут немного пораспинался на тему того, как мне это все видится.

Пока же работа немного тормозится из-за неопределенности поведения систем.
http://sf.uploads.ru/t/8MTgH.png

23

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12

Нужен надежный механизм доступа, чтобы нельзя было произвольно запускать все что захочется из открытой части системы (в закрытую, понятно, доступ только у самой системы). Ну например, вот аналогия в Делфи, есть же секции
private
protected
public

Там это атрибуты структурирования программы, а не распределение доступа м/у разработчиками и/или пользователями системы.
Если любой разработчик может редактировать раздел private - безопасность притянута за уши, слова private/protected вызывают совершенно неверную ассоциацию.

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

Видел, что в AL-IV можно задавать произвольные поля при создании объекта (ранее тоже обдумывал такой подход), т.е. городить 100500 конструкторов ради этого не нужно.

Для декларации пишем «начало», а для  запуска как самостоятельную систему служебное слово «пуск»

Порядок следования будет не очевиден. Для подготовки и пуска - очевиден.

Хотелось бы запускать систему из внешне среды. Тогда внешняя среда может подготовить объекта к запуску и лучше если эта функция уже будет у самого объекта.
С точки зрения унификации нет надобности вводить дополнительные служебные слова. Пусть это будет обычная функция.
utkin написал(а):
ну и в том же духе. Нужен надежный механизм доступа,
А как же тестирование? Ну не писать же тесты вместе с системой в одном файле. А для тестов важно иметь возможность сразу войти в нужную функцию минуя все остальные.
Тем более вы сами хотели такой синтаксис. Когда части системы живут независимо - так как они тоже системы.

И я про то же.

И тут грабли - если дать возможность программе запускаться из разных точек, то и конструкторы могут/должны быть разными, универсальный конструктор может получиться очень громоздким + плохо сопровождаемым.

Почему? Если запуски - это функции, то и там могут быть свои входные параметры, а если конструкторподготовка всего 1, то делается только общая для всех входов работа.
Также тогда можно создать систему, сделать несколько копий и по-разному их запустить, сэкономя на общих вычислениях.

у с++ например есть функция main. Она всегда стартует первой. А здесь будет много main'ов. Внешняя среда указывает какой main исполнить

Main в С/плюсах - вообще статическая функция, не вызывающая конструкторов. Она нужна как точка взаимодействия для окружения. EXE никак физически не может иметь несколько точек входа.
А если у Вас своя ВМ, то такая main не обязательна.

Мы получаем не систему-программу, а систему-пакет, в которой смешались в кучу люди-кони...

А иначе мы получаем дублирование подключения кучи библиотек. Да, сами модули ещё надо отделить и как-то назвать, правильно расположить. При добавлении/удалении/переименовании надо править подключения в разных местах. Если надо заменить внешнюю библиотеку - в каждом проекте по отдельности и т.п. бессмысленная возня.
Она может быть и не бессмысленной, всё упирается в размер проекта. Но зачем завышать порог вхождения для создания небольших приложений?
Возможность же разделять системы никуда не деётся.

Задача сделать так, чтобы снаружи кто попало не запускал что не надо

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

24

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

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

Там это атрибуты в классе. И только, форма всего лишь часть программы.

Если любой разработчик может редактировать раздел private - безопасность притянута за уши, слова private/protected вызывают совершенно неверную ассоциацию.

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

Видел, что в AL-IV можно задавать произвольные поля при создании объекта (ранее тоже обдумывал такой подход), т.е. городить 100500 конструкторов ради этого не нужно.

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

Почему? Если запуски - это функции, то и там могут быть свои входные параметры, а если конструкторподготовка всего 1, то делается только общая для всех входов работа.

Для клиента и для сервера это могут быть например очень разные конструкторы. Общий конструктор это сознательное ограничение сферы применительности систем.

Main в С/плюсах - вообще статическая функция, не вызывающая конструкторов. Она нужна как точка взаимодействия для окружения. EXE никак физически не может иметь несколько точек входа.

Main это очень грубая аналогия мы никому не обязаны придерживаться данной идеи. Это просто способ донести до Павия некоторую проблему которую он никак не мог понять (большей частью из-за моего косноязычия). Касательно exe  нет его а значит точки входа ничем не ограничены. Точка входа в интерпретатор (exe) одна, но сколько будет пусков в системе решается здесь и сейчас всего тройкой человек (остальные участники форума никак себя пока не проявили).

А иначе мы получаем дублирование подключения кучи библиотек. Да, сами модули ещё надо отделить и как-то назвать, правильно расположить. При добавлении/удалении/переименовании надо править подключения в разных местах. Если надо заменить внешнюю библиотеку - в каждом проекте по отдельности и т.п. бессмысленная возня.
Она может быть и не бессмысленной, всё упирается в размер проекта. Но зачем завышать порог вхождения для создания небольших приложений?
Возможность же разделять системы никуда не деётся.

Вопрос как это описать красиво и всем понятно. Я предложил вести секцию аналогично Делфи.

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

Почему нет? Я могу просто перечислить список функций, которые позволено запускать извне, при старте программы. Ну в объявлении Пуск перечислить не одну функцию, а туеву хучу. Вопрос как это сделать грамотно. Пока и Вы и Павиа не мыслите масштабно. Да идея хороша, но надо ее развивать до конкретных процессов и синтаксисов, описывающих процессы.

25

  • Автор: ВежливыйЛис
  • Активный участник
  • ВежливыйЛис
  • Сообщений: 408
  • Провел на форуме:
    2 дня 13 часов
  • Последний визит:
    2021-07-13 18:36:29

Раньше не было у меня времени, а тут решил вдумчиво прочитать. И что я вижу?

utkin написал(а):

Идентификатор_на_национальном_языке=Идентификатор_на_английском

Расстрелять.

26

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12
utkin написал(а):

Почему нет? Я могу просто перечислить список функций, которые позволено запускать извне, при старте программы.

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

utkin написал(а):

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

В том всё и дело, что структурирование программы и безопасность - это разные вещи.
Если один объявляет интерфейс А, второй его реализацию Б, последнюю третий использует где-то - это никак не регулируется компилятором.
Если А и Б - модули, то к ним должен быть настроен соответствующий уровень доступа - только это может обеспечить безопасность.
Но не private/protected классов, задающие структуру программы. Сами по себе они могут только повысить надёжность кода, за счёт упрощения, т.е. снизить вероятность ошибки, но ничего не гарантируют, пока их можно свободно менять.

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

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

Для клиента и для сервера это могут быть например очень разные конструкторы. Общий конструктор это сознательное ограничение сферы применительности систем.

Конструктор - понятие довольно условное и обобщённое. Можно просто выделить минимальную память.
Также, если конструктор единственный, запись вида "подготовка: название_функции" - бессмысленна. Для устранения дублирования по теории нормализации эта функция-конструктор и должна просто называться как "подготовка".

27

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Расстрелять.

Там все старые данные, они были внесены до нашего обсуждения (я просто копировал текст). Кстати, это обсуждение нужно продолжать. Вот как это контролировать интерпретатором? Он должен будет анализировать, что там используются русские символы в юникодовой кодировке? Понятно в описании языка, а там могу написать что нужно писать по-русски, но программистов этого заставить сделать будет очень тяжело. То есть новичок, читая инструкции, будет возможно делать правильно. А вот остальные? То есть Вы предлагаете жестко отслеживать кодировку в данной секции?

Потому что после передачи текстового файла кто угодно его может сломать.

В аспектах есть картинка, где написано про Р-код. Сейчас схема планируется следующая - эта программа будет переводится во внутреннее представление. И хотя пока, что там ориентация на упрощение синтаксиса (то есть все равно текст), но уже слабочитаемый. В поздних версиях, когда все это будет работать можно будет перейти на нечитаемые нормальным человеком последовательности байт. Программа так и так преобразуется во внутреннее не текстовое представление (это связано с моделью вычислений - функции-то системы, а все системы примерно одинаково представлены внутри). Текстовое представление исходника нужно только человеку.
И потом был еще полет фантазии на аналогию явовских jar. То есть паковать исходники в zip (а jar это zip). Там ведь можно навешивать пароли и вообще уже продумывать безопасность, накладывать ограничения. Но пока все на уровне идей, никаких практических механизмов не придумал и ни где не смог подсмотреть. В общем можно немного усложнить жизнь любопытным, конечно идеальной защиты нет и не предвидится, но проблемы создать можно.

В том всё и дело, что структурирование программы и безопасность - это разные вещи.

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

Если один объявляет интерфейс А, второй его реализацию Б, последнюю третий использует где-то - это никак не регулируется компилятором.
Если А и Б - модули, то к ним должен быть настроен соответствующий уровень доступа - только это может обеспечить безопасность.

Если человек настроен изначально на деструктивные действия его сложно остановить в принципе в любой сфере деятельности, не только в программировании.
Читал интервью создателя Objective C (первого, эпловский 2.0 это разработка, которая проводилась без его участия). Он писал что у программирования два фактора сдерживающие и без того бурное развитие. Первое это несовершенная экономическая модель (отличная от материальной экономики). Второй вопрос - это отсутствие правил, регламентирующих доверие между объектами (отсюда и рождаются всякие GUID, интерфейсы, сертификаты и пр.). Он рассматривал этот вопрос на примере программирования на уровне министерства обороны США (он там как-то был завязан на военные разработки). Все это тормозится потому что нет доверия между модулями А и Б, потому что их написали разные программисты. То есть либо явные деструктивные действия либо ошибки могут привести к проблемам. И решить этот вопрос пока что никто не смог. Вон Мелкософт требует цифровых подписей для драйверов сторонних производителей, но это не фига не спасает от проблем. Я это к тому что это интерпретатор тоже не решит, раз уже многомиллиардные корпорации не в состоянии это сделать.

Но не private/protected классов, задающие структуру программы. Сами по себе они могут только повысить надёжность кода, за счёт упрощения, т.е. снизить вероятность ошибки, но ничего не гарантируют, пока их можно свободно менять.

Да, совсем полной защиты быть не может, но примитивно в секциях так можно описать, что запускать, а что нет. В свое время для журнала я писал статью "Рабство программиста". Там немного такие вещи рассматривались.

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

Можно явно указать, кто будет исполняться по умолчанию. Или это будет первая функция в списке. Решение есть, вопрос о том, нужно ли это решение вообще.

Можно просто выделить минимальную память.

А можно развернуться так, что мама не горюй. Например, потянуть шрифты с инета, как это делают шаблоны например в Вордпрессе (то есть там не обязательно хранить шрифты на сервере и уж тем более на локальном компе, откуда смотрит браузер, например у гугла есть свои шрифты https://fonts.google.com), просмотреть обновление данных распределенной БД (как это делают некоторые движки интернет-магазинов). Короче степень сложности конструктора не есть формализованная величина и просчитать что нужно только выделение памяти и этого достаточно никак не удается.

Для устранения дублирования по теории нормализации эта функция-конструктор и должна просто называться как "подготовка".

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

28

  • Автор: МихалНик
  • Администратор
  • Сообщений: 586
  • Провел на форуме:
    15 дней 9 часов
  • Последний визит:
    2022-12-14 01:09:12
utkin написал(а):

И хотя пока, что там ориентация на упрощение синтаксиса (то есть все равно текст), но уже слабочитаемый.

Эта защита от дурака, а не безопасность. Безопасность регулируется криптографией.

Здесь эти цели совпадают.

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

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

Вот разговор про это будет про безопасность.

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

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

Можно явно указать, кто будет исполняться по умолчанию. Или это будет первая функция в списке. Решение есть, вопрос о том, нужно ли это решение вообще.

Оно не нужно вообще для интерпретатора.

Короче степень сложности конструктора не есть формализованная величина и просчитать что нужно только выделение памяти и этого достаточно никак не удается.

Конструирование в общем случае понятие вообще не одномоментное, а значит весьма растяжимо.

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

Почему нельзя поручить часть работ с разных входов? Почему нельзя передать на вход чего-то создающую функцию, если связи м/у конструкторами и входами многие-ко-многим?

29

  • Автор: utkin
  • Цензор
  • Сообщений: 517
  • Провел на форуме:
    6 дней 17 часов
  • Последний визит:
    2020-01-16 09:53:03

Эта защита от дурака, а не безопасность. Безопасность регулируется криптографией.

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

Есть статистическое понятие надёжности, а есть строгая безопасность. Вы не можете, например, делать банковское ПО, целиком полагаясь на первое, но можете делать игровой движок.

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

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

Это понятно, но большего предложить не получится, а меньшее ограничивает ось зла - функция-система-компонент-программа-пакет_программ

Оно не нужно вообще для интерпретатора.

Предлагайте как должно выглядеть.

Конструирование в общем случае понятие вообще не одномоментное, а значит весьма растяжимо.

Я придерживаюсь мнения, что:
а) для системы в качестве описания подсистем для других более высокоуровневых частей программы нужен конструктор (а для системы как программы понятие конструктор и стартовая система сливаются в одно)
б) конструкторов может быть сколько угодно много.
в) деструктор может вызваться явно программистом для экономии памяти, но не это лишь возможность, а не требование (интерпретатор умеет удалять любую систему корректно - это обеспечивает модель вычислений).
Исходя из этих постулатов, я считаю что:
а) объявлять конструктор в описании надо.
б) надо уметь объявлять несколько конструкторов, а значит нельзя присвоить некоторое имя по умолчанию для конструктора (напоминаю, что в Дельфи можно создавать объекты, конструкторы которых могут называться не Create, Destroy же создается всегда, программист только перегружает его).

Почему нельзя поручить часть работ с разных входов?

Можно все, нет формализации процесса. Как узнать кому какой конструктор требуется?

Почему нельзя передать на вход чего-то создающую функцию, если связи м/у конструкторами и входами многие-ко-многим?

Дайте пример синтаксиса. Я пока слабо представляю суть предложения.

30

  • Автор: Павиа
  • Активный участник
  • Павиа
  • Сообщений: 355
  • Провел на форуме:
    18 дней 8 часов
  • Последний визит:
    2020-11-06 19:50:25
MihalNik написал(а):

Эта защита от дурака, а не безопасность. Безопасность регулируется криптографией.

MihalNik написал(а):

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

"Строгая безопасность" - гугол такой фразы не знает.
Безопасность это самое широкое понятие. Под которым находятся все остальные.

utkin написал(а):

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

Криптография тут излишне. Хотя вопрос о единственности(см соседнюю ветку форума) решается при помощи уникального идентификатора или же контрольной суммой. А эти понятия принципе относятся к  криптографии.

utkin написал(а):

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

Вообще-то критерием выбора является не открытость или закрытость, а её качественные показатели защищенности.

MihalNik написал(а):

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

Это администротаивно-распаредительная безопасность. Но она конечно не так надёжна как техническая(физическая).

Страница: 1 2  

Вы здесь » Ремесло программиста » Валентина » Проект краткого синтаксиса