Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, Mr.Cat, Вы писали:

MC>>Здравствуйте, Mamut, Вы писали:
M>>>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.
MC>>Не, ну есть же люди, которые, например, используют типографскую раскладку — и везде ставят елочки, многоточия, длинные тире и т.п.

E__>И это правильно, если текст предназначен для чтения людьми. Обычно в этом случае используется не plain text, а что-то из языков разметки, который позволяеь задать в том числе и кодировку. Для текста программы это бесмысленно.

На самом деле очень большое число проблем с кодом возникает из-за того, что программисты не учитывают того, про текст программы должен быть в первую очередь предназначен для чтения людьми. Ведь компилятору глубоко фиолетово будет переменная называться price, PRiCe, myMEGA_BOTVA или g789_tyRdfgmls, но вот для людей, которым надо будет разбираться с кодом, это совсем нетак.

Здравствуйте, Курилка, Вы писали:

MC>>>Здравствуйте, Mamut, Вы писали:
M>>>>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.
MC>>>Не, ну есть же люди, которые, например, используют типографскую раскладку — и везде ставят елочки, многоточия, длинные тире и т.п.

E__>>И это правильно, если текст предназначен для чтения людьми. Обычно в этом случае используется не plain text, а что-то из языков разметки, который позволяеь задать в том числе и кодировку. Для текста программы это бесмысленно.

К>На самом деле очень большое число проблем с кодом возникает из-за того, что программисты не учитывают того, про текст программы должен быть в первую очередь предназначен для чтения людьми. Ведь компилятору глубоко фиолетово будет переменная называться price, PRiCe, myMEGA_BOTVA или g789_tyRdfgmls, но вот для людей, которым надо будет разбираться с кодом, это совсем нетак.

Я не про то. Просто, ИМХО, читабельность кода от ввода не аски символов не улучшится особо. Зато проблем можно отхватить выше крыши. Пока еще далеко не везде используется юникод(хотя я двумя руками за форсирование этого процесса), это принесет ненужные костыли на ровном месте.

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, Курилка, Вы писали:

MC>>>>Здравствуйте, Mamut, Вы писали:
M>>>>>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.
MC>>>>Не, ну есть же люди, которые, например, используют типографскую раскладку — и везде ставят елочки, многоточия, длинные тире и т.п.

E__>>>И это правильно, если текст предназначен для чтения людьми. Обычно в этом случае используется не plain text, а что-то из языков разметки, который позволяеь задать в том числе и кодировку. Для текста программы это бесмысленно.

К>>На самом деле очень большое число проблем с кодом возникает из-за того, что программисты не учитывают того, про текст программы должен быть в первую очередь предназначен для чтения людьми. Ведь компилятору глубоко фиолетово будет переменная называться price, PRiCe, myMEGA_BOTVA или g789_tyRdfgmls, но вот для людей, которым надо будет разбираться с кодом, это совсем нетак.

E__>Я не про то. Просто, ИМХО, читабельность кода от ввода не аски символов не улучшится особо. Зато проблем можно отхватить выше крыши. Пока еще далеко не везде используется юникод(хотя я двумя руками за форсирование этого процесса), это принесет ненужные костыли на ровном месте.

С этим-то согласен, просто у тебя противопоставление получилось не совсем корректное, код оно тоже предназначен для чтения, но, вместе с тем, предназначен для модификации, а извращённые символы тут в основном мешают, о чём, собственно мамут тут уже не раз написал.

Здравствуйте, Курилка, Вы писали:


E__>>Я не про то. Просто, ИМХО, читабельность кода от ввода не аски символов не улучшится особо. Зато проблем можно отхватить выше крыши. Пока еще далеко не везде используется юникод(хотя я двумя руками за форсирование этого процесса), это принесет ненужные костыли на ровном месте.

К>С этим-то согласен, просто у тебя противопоставление получилось не совсем корректное, код оно тоже предназначен для чтения, но, вместе с тем, предназначен для модификации, а извращённые символы тут в основном мешают, о чём, собственно мамут тут уже не раз написал.

Просто стандарт для хранения кода по-умолчанию — текст(и на это многое завязано). Для какой-нибудь публикации для прочтения людьми — доки, пдф и прочее. Так вот последние обычно хранятся как файлы, т.е. бинари, и туда вставляй хоть картинки, хоть хитросимволы — никто не пострадает. Я в этом смысле имел ввиду. Хранение кода в .doc — кошмарный сон, а для текста ничего вполне.

Здравствуйте, Mamut, Вы писали:

M>>>Описанная схема напоминает механимз слоты/сигналы, что есть в Qt, но с дополнительными плюшками и сахаром. Согласен, похожая схема была бы интересна, как дополнение к существующим инструментам.
B>>Спасибо! Сегодня какой-то удачный день. За пол года сегодня ты второй кто эту фишку понял. До этого было сплошное фи. Если так и дальше пойдет, то еще через полгода появятся въехавшие в гуппирование и в реализацию. Это уже будет перелом. Пока въехавших нет.

M>Ну если ты не можешь внятно объяснить, что это такое, то

Скорее, не "что это", а "зачем это". Само по себе "группирование" — это пустой звук, надо было ему сразу объяснить, с какой целью производится группировка. Насколько я понял, всю работу выполняет некий логический интерпретатор. От "тупого" реактивного программирования его схема отличается логическими вычислениями, которые запускаются либо для каждого некоего элемента, либо для группы. Причем, с ходу даже как-то не придумать, как этими логическими вычислениями "посахарить" обычные рективные программы, например твои слоты. Это нужен именно внешний интерпретатор, эмулирующий мнгогозадачность, отличную от предоставляемой родными потоками и примитивами синхронизации. Например, в обычной многопоточной программе оператор И/ИЛИ над внешними событиями не имеет смысла, ибо нет некоего цикла вычислений, задающего рамки, в которых можно было бы эти операторы И/ИЛИ применять. В общем, не посахаришь ты слоты QT до показанного варианта.

Это действительно что-то вроде пролога, с прикрученной императивностью. То бишь, декларативно задаются императивные блоки, выполняемые в некие моменты вычислений... Скажу честно, интересный ход мыслей... Сразу вспоминается задача моделирования аппаратуры, которая достаточно сложна на императивных языках, но была бы проще на порядки на Ладе. Просто у автора трудности с терминологией (опыт VB оказался скорее вреден), поэтому не может объяснить тривиальных вещей. Для простоты понимания держите в голове, что вычисления производятся интерпретатором, причем, интерпретатор — это не аналог некоей современной VM, работающей по байт-коду, а "внешний вычислитель", типа допиленного интерпретатора Пролога. Соответственно, понятие потока исполнения тоже отличается от оного в императивных программах. Поток исполнения блока юзверьского кода тут вызывается из некоей точки вычисления интерпретатора. То бишь, физический поток исполнения, похоже, всего один, но можно писать многопоточные с логической т.з. программы.

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

Здравствуйте, batu, Вы писали:

AVK>>Поскольку объяснить ты не в состоянии уже долгое время, то понятность внутри твоей головы тебе только кажется.
B>Некоторые понимают. Или вопросы задают. И я даже отвечаю. И это правильно. А когда говорят что ничего не понятно, я вряд ли могу помочь.

Значит тебе твой чудо-язык придется делать одному до релиза, так как пока ты не объяснишь все другим, эти другие тебе помогать не будут.

B>Если вы комментируете мою самокритику, то рекомендую вам быть таким же самокритичным.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:

AVK>>>Поскольку объяснить ты не в состоянии уже долгое время, то понятность внутри твоей головы тебе только кажется.
B>>Некоторые понимают. Или вопросы задают. И я даже отвечаю. И это правильно. А когда говорят что ничего не понятно, я вряд ли могу помочь.

VD>Значит тебе твой чудо-язык придется делать одному до релиза, так как пока ты не объяснишь все другим, эти другие тебе помогать не будут.
Я не настолько наивен, что бы ожидать помощи. Один и делаю. А насчет понимания, я все написал. Там думать надо. Это необычный подход. И опыт прежних языков угадывается, но сильно отличается по внутреннему содержанию. Пока я не видел ни одного, кто бы внимательно и вдумчиво прочитал хотя бы три раздела.

B>>Если вы комментируете мою самокритику, то рекомендую вам быть таким же самокритичным.

VD>Странный ты. AVK высказал разумную мысль. В отличии от тебя язык он свой не предлагал, и твой не критиковал. Что же ему быть самокритичным то?
КАКУЮ МЫСЛЬ? Я внимательно слежу и благодарен именно за мысль. Сформулируй, и я немедленно извинюсь.

Здравствуйте, batu, Вы писали:

B> Я не настолько наивен, что бы ожидать помощи. Один и делаю. А насчет понимания, я все написал. Там думать надо. Это необычный подход. И опыт прежних языков угадывается, но сильно отличается по внутреннему содержанию. Пока я не видел ни одного, кто бы внимательно и вдумчиво прочитал хотя бы три раздела.

Да, да. Это как в том анекдоте...
— Милый. Будь осторожен. По телевизору передали что какой-то идиот едет по встрчке.
— Один? Да их тут тысячи!

B>КАКУЮ МЫСЛЬ? Я внимательно слежу и благодарен именно за мысль. Сформулируй, и я немедленно извинюсь.

Очень простую:

Поскольку объяснить ты не в состоянии уже долгое время, то понятность внутри твоей головы тебе только кажется.

В прочем всегда есть шанс, что тот кого не понимают окружающие — это гений сильно опередивший время. В одном случае на миллиард так и случается.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, batu, Вы писали:


VD>Очень простую:
VD>

VD>Поскольку объяснить ты не в состоянии уже долгое время, то понятность внутри твоей головы тебе только кажется.

VD>В прочем всегда есть шанс, что тот кого не понимают окружающие — это гений сильно опередивший время. В одном случае на миллиард так и случается.
Думаю вы сильно преувеличиваете. Куда чаще встречается просто лень. На самом деле думать это сложное занятие.

Здравствуйте, batu, Вы писали:

VD>>В прочем всегда есть шанс, что тот кого не понимают окружающие — это гений сильно опередивший время. В одном случае на миллиард так и случается.
B>Думаю вы сильно преувеличиваете. Куда чаще встречается просто лень. На самом деле думать это сложное занятие.

И это говорит человек, который поленился в документации не только не указать каким образом LADA облегчит жизнь по сравнению с, но даже не узнать что NOD пишется как GCD. И это говорит человек который до сих пор поленился разобраться с github/googlecode/sf. HIBT?

Здравствуйте, maykie, Вы писали:

M>Здравствуйте, batu, Вы писали:

VD>>>В прочем всегда есть шанс, что тот кого не понимают окружающие — это гений сильно опередивший время. В одном случае на миллиард так и случается.
B>>Думаю вы сильно преувеличиваете. Куда чаще встречается просто лень. На самом деле думать это сложное занятие.

M>И это говорит человек, который поленился в документации не только не указать каким образом LADA облегчит жизнь по сравнению с, но даже не узнать что NOD пишется как GCD. И это говорит человек который до сих пор поленился разобраться с github/googlecode/sf. HIBT?
Чем то напомнило анекдот про Вовочку, когда он увидел как отец с мамой сексом занимаются.
-И эти люди запрещают мне в носу ковыряться!

Здравствуйте, batu, Вы писали:

XC>>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?
B>Да. Только почему "запихать"? Так оно и есть..Объект-инструкция..
B> А почему бы и нет?
А, собственно, зачем? У инструкции никакого поведения нет. Поведение есть у компилятора, который на основе набора инструкций должен породить программу для целевой машины. При этом эта программа зачастую достаточно сильно отличается по структуре от структуры исходной программы.
Задача "объекта-инструкции" сводится к тому, чтобы хранить данные, необходимые для компилятора. И это мало кому интересно — потому, что код компилируется один раз, а исполняется — миллионы раз.
Ну, то есть устройство компилятора само по себе конечно же интересное дело — вон как народ по соседству бурлит насчёт всех этих GLR парсеров и прочего. Но проектировать из этого язык... Язык нужен для человека, а не для компилятора. К тому же в компиляции процесс лексического и синтаксического разбора — далеко не самая интересная задача. Дальше-то вы что будете делать? Каким образом вы собираетесь порождать целевой код? Или это будет чистая интерпретация?

Здравствуйте, batu, Вы писали:
B>которые привели к созданиям этих объектов. Ну, на заре компьютерной техники на такие нюансы не обращали внимания. Как и на то, что нет английской буквы "а" и русской буквы "а". Есть знак "а" который в разных языках ассоциируется в разные алфавиты. В тексте никогда не возникает вопрос "это русская буква Р?". Этот вопрос имеет смысл только в устной речи, когда необходимо установить обратную ассоциацию из алфавита в знак.
Это заблуждение. Русская А и английская A — совершенно разные знаки. Это видно, к примеру, в хороших шрифтах — начертания знаков отличаются. Точно так же и все внешне похожие друг на друга кириллические и латинские символы являются на деле разными. У них разное происхождение, разная фонетика, разные традиции начертания.
Я понимаю, это трудно понять, и разница кажется неочевидной — особенно людям, воспитанным на шрифтах, полученных тупым заимствованием латиницы (в особо вопиющих случаях букву Я могли получать разворотом R). Посмотрите в таком случае на какие-нибудь арабские или другие языки с принципиально другими алфавитами. Практически в каждом алфавите земли есть знак, похожий на O. Считать его из-за этого тем же знаком никто не станет.
Далее: как раз в устной речи никакой проблемы идентификации знаков не стоит — там вообще нет ни знаков, ни алфавитов. Есть фонемы. Только в письменной речи могут возникать проблемы интерпретации — puma это рита или пума.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, batu, Вы писали:
B>>которые привели к созданиям этих объектов. Ну, на заре компьютерной техники на такие нюансы не обращали внимания. Как и на то, что нет английской буквы "а" и русской буквы "а". Есть знак "а" который в разных языках ассоциируется в разные алфавиты. В тексте никогда не возникает вопрос "это русская буква Р?". Этот вопрос имеет смысл только в устной речи, когда необходимо установить обратную ассоциацию из алфавита в знак.
S>Это заблуждение. Русская А и английская A — совершенно разные знаки. Это видно, к примеру, в хороших шрифтах — начертания знаков отличаются. Точно так же и все внешне похожие друг на друга кириллические и латинские символы являются на деле разными. У них разное происхождение, разная фонетика, разные традиции начертания.
Я согласен со всем, и даже с тем что это разные знаки. В том смысле как вы это представили. Ту же русскую "а" можно считать разной в разных шрифтах. А можно и одинаковой. Разница в формировании изображения. Ну, так с другой стороны можно и считать одинаковой. С другими правилами формирования изображения. Вы предпочитаете считать их разными? Имеете право. Вопрос только в том, какую полезность можно получить из этого предпочтения. Я считаю что можно обойтись одним кодом. Вы считаете что лучше иметь два кода? Так удобнее? И для больших и маленьких букв тоже разные? Понимаю такой подход на заре компьютерной техники, но современные графические возможности принтеров и мониторов вполне позволяют обойтись и одним кодом.

S>Я понимаю, это трудно понять, и разница кажется неочевидной — особенно людям, воспитанным на шрифтах, полученных тупым заимствованием латиницы (в особо вопиющих случаях букву Я могли получать разворотом R). Посмотрите в таком случае на какие-нибудь арабские или другие языки с принципиально другими алфавитами. Практически в каждом алфавите земли есть знак, похожий на O. Считать его из-за этого тем же знаком никто не станет.

Разница в воспитании не причем. Повторюсь. Ассоциация знака на фонемы и на алфавит в разных языках однозначно разная. Что ж тут возражать. А вот считать можно и одним и не одним знаком. Дело вкуса.

S>Далее: как раз в устной речи никакой проблемы идентификации знаков не стоит — там вообще нет ни знаков, ни алфавитов. Есть фонемы. Только в письменной речи могут возникать проблемы интерпретации — puma это рита или пума.
Прекрасный пример демонстрирующий что нет знаков русских и английских. Есть разная ассоциация этих знаков в разных языках.
Я говорил о другом. Если вы захотите собеседнику сказать какой первый знак у вас в примере, вы вынуждены будете произнести либо русское "р", либо английское "п".
С уважением!

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, batu, Вы писали:

XC>>>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?
B>>Да. Только почему "запихать"? Так оно и есть..Объект-инструкция..
B>> А почему бы и нет?
Раз 5 перечитал. Не уловил логику. Извини.
S>А, собственно, зачем? У инструкции никакого поведения нет. Поведение есть у компилятора, который на основе набора инструкций должен породить программу для целевой машины.
И что имеется ввиду под поведением?
Компилятор работает на основе синтаксиса. О каком наборе инструкций идет речь?
А если целевая машина принимает на входе объекты? Логично тогда ожидать что компилятор должен создать объекты? Не надо зацикливаться на том, что целевая машина это воспринимает только коды процессора.
И, наконец, не понял что именно следует из вашего замечания.

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


S>Задача "объекта-инструкции" сводится к тому, чтобы хранить данные, необходимые для компилятора. И это мало кому интересно — потому, что код компилируется один раз, а исполняется — миллионы раз.
S>Ну, то есть устройство компилятора само по себе конечно же интересное дело — вон как народ по соседству бурлит насчёт всех этих GLR парсеров и прочего. Но проектировать из этого язык... Язык нужен для человека, а не для компилятора.
Спорное утверждение.
К тому же в компиляции процесс лексического и синтаксического разбора — далеко не самая интересная задача. Дальше-то вы что будете делать? Каким образом вы собираетесь порождать целевой код?
По-моему ответил.
Или это будет чистая интерпретация?

И интерпретация и компиляция.
Интерпретация применяется как текстовый процессор. Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
Например, если в тексте 7+5 почему бы не выполнить оператор сложения? Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.

Var Boolean Debug=True
...
..
If F then {Print "a"}
...

А затем поступит в компилятор.. и т.д..
Единственная разница, что у меня все операторы могут выполняться как интерпретаторы.

Здравствуйте, batu, Вы писали:

B>И интерпретация и компиляция.
B>Интерпретация применяется как текстовый процессор.
Неясно. Текстовыми процессорами у нас называли то ли MultiEdit, то ли препроцессор вы имеете ввиду?

B>Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
Почему бы и нет, а надо? А когда? А как?

B>Например, если в тексте 7+5 почему бы не выполнить оператор сложения?
7+5 традиционно выполняет компилятор через оптимизацию. Собственно 7+5 выполнить очень легко при обработке AST выражения. На пальцах это очень просто. Вопросы возникают если X+Y могут быть выполнены на этапе компиляции, но это не int. Вы к этому готовы?

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

Здравствуйте, fddima, Вы писали:

F>Здравствуйте, batu, Вы писали:

B>>И интерпретация и компиляция.
B>>Интерпретация применяется как текстовый процессор.
F> Неясно. Текстовыми процессорами у нас называли то ли MultiEdit, то ли препроцессор вы имеете ввиду?
Препроцессор.

B>>Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
F> Почему бы и нет, а надо? А когда? А как?
Иногда надо. Например включить в текст документа операторы отладки, или в тексте документа открыть/скрыть данные доступные для одного сотрудника и закрытые для другого. Или сформировать бланк документа изменяя какие то данные, типа нового заказчика.

B>>Например, если в тексте 7+5 почему бы не выполнить оператор сложения?
F> 7+5 традиционно выполняет компилятор через оптимизацию. Собственно 7+5 выполнить очень легко при обработке AST выражения. На пальцах это очень просто. Вопросы возникают если X+Y могут быть выполнены на этапе компиляции, но это не int. Вы к этому готовы?
Если там есть значения и нет проблем с типами почему бы и нет.

B>>Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.
F> Непонятно (и ниже тоже). Вы взялись за не простую вещь, — будьте строги прежде всего к себе в формулировках. Оператор он оператор. Оператор не интерпретатор, так же как чайник не красное. Ошибки в формулировках как правило говорят или о неумении выразить свои мысли, или о каше в голове, или ничего не говорят. В любом случае какие бы умные мысли вы бы не выражали — если вы их выражаете неправильно — это минус только вам. Так что этот параграф попал в разряд магии.
Имелось ввиду оператор выполнится в режиме интерпретатора. Согласен что не точность. Но не каша. Спасибо за замечание. Про сценарий не пишу подробно потому что там много надо писать. Считаю в таком виде пока достаточно. Вопрос же был не о нем.

Здравствуйте, batu, Вы писали:

B>И что имеется ввиду под поведением?
Под поведением имеется в виду то, которое из стандартного определения объекта: объект суть сущность, обладающая идентичностью, состоянием, и поведением.
То есть — способность объекта реагировать на посылаемые ему сообщения, возможно изменяя своё состояние.
Пока понятно?

B>Компилятор работает на основе синтаксиса. О каком наборе инструкций идет речь?
В общем-то, о любом — и о наборе входных инструкций (или любых других элементов языка), и о наборе выходных инструкций.

B>А если целевая машина принимает на входе объекты? Логично тогда ожидать что компилятор должен создать объекты?
Ну, во-первых, я с такими целевыми машинами не встречался. Они все до единой, по какому-то странному сговору, принимают набор инструкций на некотором языке. Во-вторых, не очень понятно, что значит "создать объекты". Кто, скажем, эти объекты будет уничтожать?
B>Не надо зацикливаться на том, что целевая машина это воспринимает только коды процессора.
Я не зацикливаюсь. Целевой машиной может быть jvm, в которой свой набор инструкций. Или, к примеру, мы можем говорить о компиляции в MSIL — объектно-ориентированный ассемблер. То, что в MSIL никаких объектов по-прежнему нет, объяснять нужно?

B> При этом эта программа зачастую достаточно сильно отличается по структуре от структуры исходной программы.
B>Ну, отличается. Это хорошо или плохо?
Это, в общем случае, хорошо. Потому что позволяет сделать скомпилированную программу эффективнее исходной.
B>По моему плохо. Я бы предпочел что б не отличалось. И это тоже можно сделать, если целевая машина будет моделировать машину Тьюринга с дополнительной адресной лентой, а не исполнять инструкции подряд.
А я бы предпочёл, чтобы скорость света была на пару десятков порядков выше. Шутка.
Поймите, я говорю о том, что если в исходном языке есть конструкция "for i=0 to 10 {...}", то нет никакой гарантии в том, что в выходной программе останется хоть что-то, напоминающее по своей семантике for. В самом простом случае компилятор может развернуть цикл, в сложном — вообще упростить всё вычисление до константы. А вы наивно предлагаете создавать объекты для всего, встреченного компилятором. Зачем нам i в целевой программе?

ИB>спользуя конвейерную технологию это практически никак не повлияет на скорость зато позволит создать прямую связь между объектами создаными компилятором и текстом программы, что в свою очередь значительно упростит документирование, сопровождение и создание отладочных средств.
Можно, я не буду обсуждать скорость машины Тьюринга? Давайте поговорим про документирование и сопровождение. Вот, скажем, вы видели реальную программу? Ну там, hello world на C#?
Там связь между "объектами, созданными компилятором" и текстом программы весьма непрямая. Давайте попробуем раскрыть тему и пояснить мне, где здесь сложности документирования и сопровождения? Очень редкий C#-программист может сопоставить текст hello world и инструкции x86, в которые он превращается после работы компилятора и jit. Но никто и никогда не занимается документированием программы в терминах "целевого кода".

S>>Ну, то есть устройство компилятора само по себе конечно же интересное дело — вон как народ по соседству бурлит насчёт всех этих GLR парсеров и прочего. Но проектировать из этого язык... Язык нужен для человека, а не для компилятора.
B>Спорное утверждение.
Ну попробуйте оспорить, раз оно спорное. Вы вообще роль языков программирования в современной индустрии ПО как себе представляете?

B>По-моему ответил.
По-моему нет.

B>И интерпретация и компиляция.
B>Интерпретация применяется как текстовый процессор. Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
Текстовый процессор бесконечно далёк от интерпретации. Зачем вы его упоминаете? Вот, например, я пользуюсь текстовым процессором Microsoft Word версии 14. Он, конечно, занимается интерпретацией вводимых в него текстов документов — ну, скажем, угадывает, что после точки должно начаться новое предложение и предлагает мне начать дальнейший текст с заглавной буквы. Но это совсем не то, чего мы ожидаем от среды программирования.

B>Например, если в тексте 7+5 почему бы не выполнить оператор сложения? Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.
Не очень понятно, что значит "выполнится как интерпретатор"? У меня закрадывается подозрение, что вы используете стандартные термины каким-то очень нешаблонным способом. В частности, здесь субъект и объект явно перепутаны местами.
Обычно интерпретатор занимается выполнением операторов.
Ну вот, к примеру, интерпретатор читает предложение LET Z = X+Y. Он сразу интерпретирует его как инструкцию завести в виртуальной машине переменную с именем Z и положить в неё результат выполнения оператора + над переменными X и Y. И немедленно выполняет.
Но сам оператор + здесь ничего не делает. Это всего лишь идентификатор, который помогает интерпретатору понять, что нужно делать.

B>А затем поступит в компилятор.. и т.д..
Что именно затем поступит в компилятор? И что именно делает у вас компилятор?
B>Единственная разница, что у меня все операторы могут выполняться как интерпретаторы.
Разница между чем и чем, простите?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, batu, Вы писали:

B>>И что имеется ввиду под поведением?
S>Под поведением имеется в виду то, которое из стандартного определения объекта: объект суть сущность, обладающая идентичностью, состоянием, и поведением.
S>То есть — способность объекта реагировать на посылаемые ему сообщения, возможно изменяя своё состояние.
S>Пока понятно?
Так понятно. Инструкции также могут обладать всеми этими качествами. Не вижу противоречия.

B>>Компилятор работает на основе синтаксиса. О каком наборе инструкций идет речь?
S>В общем-то, о любом — и о наборе входных инструкций (или любых других элементов языка), и о наборе выходных инструкций.
Входные это о целевой машине идет речь? А выходные это результат работы компилятора? И с чем не соглаcие? С тем что компилятор работает на основе синтаксиса?

B>>А если целевая машина принимает на входе объекты? Логично тогда ожидать что компилятор должен создать объекты?
S>Ну, во-первых, я с такими целевыми машинами не встречался. Они все до единой, по какому-то странному сговору, принимают набор инструкций на некотором языке.
И что мешает набор инструкций считать объектами?
Во-вторых, не очень понятно, что значит "создать объекты". Кто, скажем, эти объекты будет уничтожать?
А зачем все уничтожать? Кое-что пусть и остается. Как документ.
B>>Не надо зацикливаться на том, что целевая машина это воспринимает только коды процессора.
S>Я не зацикливаюсь. Целевой машиной может быть jvm, в которой свой набор инструкций. Или, к примеру, мы можем говорить о компиляции в MSIL — объектно-ориентированный ассемблер. То, что в MSIL никаких объектов по-прежнему нет, объяснять нужно?
Не нужно. Только если их нет где-то, не означает что их нет нигде. У меня есть.

B>> При этом эта программа зачастую достаточно сильно отличается по структуре от структуры исходной программы.
B>>Ну, отличается. Это хорошо или плохо?
S>Это, в общем случае, хорошо. Потому что позволяет сделать скомпилированную программу эффективнее исходной.
B>>По моему плохо. Я бы предпочел что б не отличалось. И это тоже можно сделать, если целевая машина будет моделировать машину Тьюринга с дополнительной адресной лентой, а не исполнять инструкции подряд.
S>А я бы предпочёл, чтобы скорость света была на пару десятков порядков выше. Шутка.
S>Поймите, я говорю о том, что если в исходном языке есть конструкция "for i=0 to 10 {...}", то нет никакой гарантии в том, что в выходной программе останется хоть что-то, напоминающее по своей семантике for. В самом простом случае компилятор может развернуть цикл, в сложном — вообще упростить всё вычисление до константы. А вы наивно предлагаете создавать объекты для всего, встреченного компилятором.
Ну, и я так понимаю. Видимо одинаковые книжки читали. Могу еще пример преобразования выражений привести. Вот только ироническое "наивно" не принимаю. Да предлагаю, и отнюдь не наивно. Хотя спорно.
Зачем нам i в целевой программе?
А для формирования сообщения в случае необходимости в терминах исходника. И для сопровождения, для документирования.

ИB>>спользуя конвейерную технологию это практически никак не повлияет на скорость зато позволит создать прямую связь между объектами создаными компилятором и текстом программы, что в свою очередь значительно упростит документирование, сопровождение и создание отладочных средств.
S>Можно, я не буду обсуждать скорость машины Тьюринга? Давайте поговорим про документирование и сопровождение. Вот, скажем, вы видели реальную программу? Ну там, hello world на C#?
S>Там связь между "объектами, созданными компилятором" и текстом программы весьма непрямая. Давайте попробуем раскрыть тему и пояснить мне, где здесь сложности документирования и сопровождения? Очень редкий C#-программист может сопоставить текст hello world и инструкции x86, в которые он превращается после работы компилятора и jit. Но никто и никогда не занимается документированием программы в терминах "целевого кода".
И напрасно не занимались. Только не в терминах целевого кода, а в терминах исходника.

S>>>Ну, то есть устройство компилятора само по себе конечно же интересное дело — вон как народ по соседству бурлит насчёт всех этих GLR парсеров и прочего. Но проектировать из этого язык... Язык нужен для человека, а не для компилятора.
B>>Спорное утверждение.
S>Ну попробуйте оспорить, раз оно спорное. Вы вообще роль языков программирования в современной индустрии ПО как себе представляете?

B>>По-моему ответил.
S>По-моему нет.
Ну, на уровне современной индустрии ПО, я, конечно, не смогу ответить. Язык он для человека что б писать, и для компилятора что б он тоже чего-то в нем понимал. Было б странно если б языки только для человека, а каким боком он тогда нужен если его компилятор не понимает?

B>>И интерпретация и компиляция.
B>>Интерпретация применяется как текстовый процессор. Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
S>Текстовый процессор бесконечно далёк от интерпретации. Зачем вы его упоминаете? Вот, например, я пользуюсь текстовым процессором Microsoft Word версии 14. Он, конечно, занимается интерпретацией вводимых в него текстов документов — ну, скажем, угадывает, что после точки должно начаться новое предложение и предлагает мне начать дальнейший текст с заглавной буквы. Но это совсем не то, чего мы ожидаем от среды программирования.

B>>Например, если в тексте 7+5 почему бы не выполнить оператор сложения? Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.
S>Не очень понятно, что значит "выполнится как интерпретатор"? У меня закрадывается подозрение, что вы используете стандартные термины каким-то очень нешаблонным способом. В частности, здесь субъект и объект явно перепутаны местами.
S>Обычно интерпретатор занимается выполнением операторов.
S>Ну вот, к примеру, интерпретатор читает предложение LET Z = X+Y. Он сразу интерпретирует его как инструкцию завести в виртуальной машине переменную с именем Z и положить в неё результат выполнения оператора + над переменными X и Y. И немедленно выполняет.
S>Но сам оператор + здесь ничего не делает. Это всего лишь идентификатор, который помогает интерпретатору понять, что нужно делать.

B>>А затем поступит в компилятор.. и т.д..
S>Что именно затем поступит в компилятор? И что именно делает у вас компилятор?
B>>Единственная разница, что у меня все операторы могут выполняться как интерпретаторы.
S>Разница между чем и чем, простите?
Между вашим представлением, и тем что я предлагаю. Здесь, действительно, разница есть. Возможно терминологическая. Но большая. Потому если продолжать это будет очень длинно. Если пожелаете, то продолжу.
С уважухой!

Здравствуйте, batu, Вы писали:

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

B>>>Компилятор работает на основе синтаксиса. О каком наборе инструкций идет речь?
S>>В общем-то, о любом — и о наборе входных инструкций (или любых других элементов языка), и о наборе выходных инструкций.
B>Входные это о целевой машине идет речь?
Входные — это то, что пишет пользователь.
B>А выходные это результат работы компилятора?
Да.
И с чем не соглаcие? С тем что компилятор работает на основе синтаксиса?
С тем, что входные инструкции в виде объектов зачем-то нужны после того, как отработает компилятор.

B>И что мешает набор инструкций считать объектами?
Отсутствие у них состояния и поведения.
B>А зачем все уничтожать? Кое-что пусть и остается. Как документ.
Документ не имеет никакого отношения к объектам-инструкциям. Рассмотрите документирование кода на примере javadoc. Вы знакомы с этим явлением?

B>Не нужно. Только если их нет где-то, не означает что их нет нигде. У меня есть.
А у вас уже есть целевая машина?

B>Ну, и я так понимаю. Видимо одинаковые книжки читали. Могу еще пример преобразования выражений привести. Вот только ироническое "наивно" не принимаю. Да предлагаю, и отнюдь не наивно. Хотя спорно.
Ну мне описанное кажется немножко наивным. Возможно, это у меня как раз опыта в языкостроении не хватает.

B>Зачем нам i в целевой программе?
B>А для формирования сообщения в случае необходимости в терминах исходника. И для сопровождения, для документирования.
Непонятно. Для сопровождения и документирования достаточно сопровождать и документировать исходник. См. опять же javadoc и XML comments в C#.
Формирование соощения в терминах исходника — крайне редкая необходимость. Кроме того, потребности по формированию этого сообщения совсем другие, чем потребности исполняющей среды по реализации семантики вашей программы.
Приведу такой пример из реального мира: вот у нас бывают исключения в .Net. В исключении для удобста отладки и формирования сообщений приклеен стек вызовов. Сам по себе стек вполне себе объектно-ориентирован (хотя объекты, из которых он состоит, immutable, и общему определению объекта не очень удовлетворяют). Но это не означает, что к исключению приклеивают тот самый стек, который используется внутри исполняющей машины. Никто не создаёт объект StackFrame при каждом вызове подпрограммы. StackTrace собирается из доступной информации только в момент выброса исключения. А для исполнения используется обычный стек x86.
Это сделано не потому, что разработчики CLR не смогли применить передовые концепции, а потому, что они были бы слишком дорогими — производительность была бы ниже всякой критики.


S>>Там связь между "объектами, созданными компилятором" и текстом программы весьма непрямая. Давайте попробуем раскрыть тему и пояснить мне, где здесь сложности документирования и сопровождения? Очень редкий C#-программист может сопоставить текст hello world и инструкции x86, в которые он превращается после работы компилятора и jit. Но никто и никогда не занимается документированием программы в терминах "целевого кода".
B>И напрасно не занимались. Только не в терминах целевого кода, а в терминах исходника.
Я уже писал про javadoc и XML comments?

S>>Ну попробуйте оспорить, раз оно спорное. Вы вообще роль языков программирования в современной индустрии ПО как себе представляете?

B>Ну, на уровне современной индустрии ПО, я, конечно, не смогу ответить. Язык он для человека что б писать, и для компилятора что б он тоже чего-то в нем понимал. Было б странно если б языки только для человека, а каким боком он тогда нужен если его компилятор не понимает?
Я имею в виду, что язык нужно проектировать так, чтобы было удобно человеку. Удобство компилятора — вещь вторичная.
Поэтому преимущества типа "а тут у нас упрощается лексический анализ" являются мнимыми.

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

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