Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 28 мар 2024, 22:31

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: 28 сен 2018, 23:32 
Не в сети

Сообщения: 350
Давайте разобьём тему на две - обсуждение облегчения работы с клавиатуры (спасибо за наводку про то, что cлово подхватится - я на это надеялся, но не на том слове кликал, а если уж слово выделено, то дальше через меню Инфо можно вызвать, например Alt-И И (исходники) или Ctrl-D (интерфейс). Хотя на самом-то деле, выделение слова - это лишнее действие. Курсор уже и так стоит на каком-то слове, или не стоит. Команды должны просто вычитать это слово из текста и оперировать над ним - так делает не только лисп, но и всякие современные IDE, вплоть до 1С.

Т.е. сокровенное знание действительно местами существует! Но давайте это вынесем.

И отдельно про семантику - это оставить тут.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 28 сен 2018, 23:41 
Не в сети

Сообщения: 350
SovietPony писал(а):
budden писал(а):
если мы хотим семантику REPL приближенную к семантике КП
Ясно. У нас разные цели. Я не заинтересован.
(Спрашивать зачем оно такое надо и продолжать спор я не буду)

Дело ваше, но я расскажу свою стратегию. Разработка ЯП и ИСР (IDE) к нему - это огромная масса работы, которая немыслима без инструментов. Но инструментов не может быть, если нет ЯП. Поэтому я в своей разработке начинаю с как можно более мощного начального инструмента и далее двигаюсь по спирали, добавляя недостающее. При этом нужно рассчитывать только на свои силы (на данный момент, только на 33% своих сил). А значит, каждый инкремент должен давать какой-то полезный инструмент, добавлять минимум сложности к системе и быть минимальным по трудоёмкости. За один круг система должна, сохранив сбалансированность, обрести немножко новых возможностей.

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

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

На всякий случай, какой REPL вас интересует?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 28 сен 2018, 23:47 
Не в сети

Сообщения: 350
SovietPony писал(а):
Сам же и ответил на свой вопрос - смотреть исходники DevDebug.

Отлично, теперь передо мной стоит следующая задача - развести кого-нибудь на то, чтобы он сделал эту работу за меня, даром, быстро и качественно :)


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 28 сен 2018, 23:49 
Не в сети

Сообщения: 350
Ну или хотя бы 2 из 3. «Качественно» оставим, остальное - опционально :D


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 сен 2018, 00:27 
Не в сети
Аватара пользователя

Сообщения: 67
Откуда: Equestria
budden писал(а):
На всякий случай, какой REPL вас интересует?

Нужен интерактивный интерпретатор для BareMetal BlackBox, где в ближайшее время графоний с гуями не предвидится. По назначению что-то типо unix shell почти полностью для тех же целей. Меня устраивает интерпретатор уровня StdInterpreter, но он слишком многословный и не удобный для интерактивного ввода. На будущее можно чуть сложнее для простых наколенных скриптов(автоматизации).


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 сен 2018, 00:57 
Не в сети

Сообщения: 350
budden писал(а):
Меня устраивает интерпретатор уровня StdInterpreter, но он слишком многословный и не удобный для интерактивного ввода

Я разрабатывал свой язык программирования около 2 лет. До этого ещё около 6 лет об этом мечтал, собирал кусочки. Но вот эта означенная вами задача мной ещё далеко не понята. Я только лишь заметил некоторые вещи. Например, в тикле (и баше) слово без кавычек - это, обычно, строковый литерал. А в КП слово без кавычек - это, обычно, имя переменной или процедуры. Чтобы вычислить переменную в тикле, нужно приписать доллар. А чтобы написать строковый литерал в КП - нужно заключить его в кавычки. Это различие долго было не замечено мной (и я даже по инерции в тикле долго ставил ненужные там кавычки). Но оно имеет глубокий смысл, который я понял не больше квартала назад.

Оказывается, в интерактивной работе литералы встречаются чаще, чем обращения к переменным. Но даже в скрипте на bash это уже не так. Заглянешь в скрипт - а там сплошные доллары. Поэтому баш для интерактивной работы в консоли и баш для скриптов необязательно должны совпадать!

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

В лиспе есть всего один диалект. С т.з. семантики лисп одинаково хорошо подходит и для интерактивности, и для программирования (и это - своего рода чудо, и это дошло до меня только сегодня, после ознакомления с докладом Евгения). С точки зрения же синтаксиса, лисп одинаково плохо подходит как для интерактивности, так и для программирования.

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

Последие баш-скрипты, которые я написал, полностью состоят из строчек вида

команда || умри-баш

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

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

Далее, баш уникален по своим возможностям. Его конвейеры позволяют строить целые системы из программ с помощью нескольких строчек кода. Ни один известный мне «обычный» ЯП такими возможностями не обладает. Чтобы сделать нормальный язык для автоматизации, нужно глубоко понять баш.

Если вы полезете в эту задачу без чёткого понимания, как надо, у вас получится скриптовый язык не лучше баша, с соответствующими кривыми практиками. Зачем он нужен? А если хотите сделать хорошо, вам нужно потратить много сил на изучение предыдущего опыта и проектирование. Я хочу хороший скриптовый язык, но у меня нет ресурсов даже на то, чтобы полностью осознать баш и тикль (хотя на тикле я написал IDE). Поэтому я ограничиваю свои цели (на данном этапе) только самым простым. А самое простое - не плодить сущностей, отложить. Пусть КП многословен, зато его не надо проектировать, он уже есть. Значит, нельзя сделать новых ошибок.

Вопрос же о гуях или их отсутствии тут второстепенен и ортогонален.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 сен 2018, 01:01 
Не в сети

Сообщения: 350
Но может быть, вы уже всё продумали - буду рад почитать ваше описание того, что вы хотите, в любой понятной форме.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 сен 2018, 15:42 
Не в сети
Аватара пользователя

Сообщения: 67
Откуда: Equestria
Нет, я ничего не продумывал. Иначе бы уже давно реализовал и забыл о текущем интерпретаторе.

Цитата:
Последие баш-скрипты, которые я написал, полностью состоят из строчек вида
В любом шелле Борна есть можно набрать:
Код: "OBERON"
  1. set -e # останавливаться на ненулевом коде выхода
  2. set -x # печатать исполняемые строки
Что лично я использую в каждом скрипте. Этого достаточно.
То что шелл Борна убог - спору нет, конечно. И тупо копировать его я бы не стал.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 сен 2018, 17:36 
Не в сети

Сообщения: 350
Ну и что вы хотите? Допустим, лисп. Лисп многословен. Без подсветки скобок практически невозможно им пользоваться. Методы вызывать будет нельзя (т.к. через Meta). А при реализации через компиляцию - можно. Все остальные интерпретаторы - сложнее. Ну, можно ещё про подобие тикля поговорить. В будущем я хочу сделать подобие тикля, так что тут нам может оказаться по пути. Тикль мне нравится больше баша, правда, умеет он меньше (совсем недавно это обсуждалось на ЛОРе:


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 сен 2018, 23:18 
Не в сети

Сообщения: 350
Короче, основное, чего не хватает сейчас для реализации моего плана - это операции "импортировать всё из N модулей с непересекающимися именами и реэкспортировать". Вроде же такого нет? Или есть? И возможно, я не вижу каких-то дыр...


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club