Язык_программирования_РС/Б

Не ленимся уделить 30сек на комент!

 

А почему не пойти дальше?
Например, взять Windows'98 для начала и все её файлы переименовать на русские, чтобы ни одного файла с английскими буквами не было! )
ИМХО: Чушь! Ибо я в Excel путаюсь с русскими именами. Когда ставлю 3D-MAX или подобное, никогда не пользуюсь руссификатором, так-как начинаю сильно путаться во всём!

 

Russian? No I fix it.
Кстати говоря, до того как выложил в сеть, я и подумать не мог что русский является большой проблемой,
потому мне важно ваше мнение о идее в посте №40, если это булщет то почему.

 

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

 

Закончил работу над черновой версией синтаксиса, ознакомиться можно здесь(! много букв).
Если у вас есть немного свободного времени, прочитайте и отпишите своё мнение (особено касательно корректности keywords).

 

AlexCab

напишите 10ток коротких примеров показывающих ключевые моменты как вы их видите.
(хотя, имхо, начинать с документирования это как начинать украшать и подавать торт до замешивания теста и печки)

 

qqwe

Обязательно напишу но когда будет готов компилятор(какой толк от примеров если их нельзя собрать).

Это скорей рецепт для торта

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

 

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

->
неудобно. частый оператор и 3 кнопки в ен + коллизия со ссылками из С.

THEN
если вы уже используете С-стайл ограничители, то зачем вам это?

STRCT
это что за ужас? вам лишнюю букву нажать трудно или U не любите?

IF WMsg == WM_CREATE, WM_SIZE, WM_DESTROY
THEN: \\Code for "WM_CREATE"
THEN: \\Code for "WM_SIZE"
THEN: PostQuitMessage(0) \\WM_DESTROY
END:
какая жуткая форма записи свитчей-кэйсов. кроме того, она пересекается с туфлеобразным
1,3,6,7 -> WRect.Top.X,WRect.Top.Y,WRect.Down.X,WRect.Down.Y

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

 

AlexCab

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

и, да. не пишут сразу компилятор. сперва пишут 10ток интерпретаторов. сперва с построчной интерпретацией, потом с байткодовой. а потом, когда и если все пойдет - пишут компилер или встраивают в существующий тулчейн.

хороший тутор по этому делу у кернигана и пайка в "программном окружении юникс"

 

qqwe

Не обежайтесь это было to all.

Часто используется оператор "copy" - "=",
"->" - это оператор "move", я его использовал в примерах для наглядности.

Стиль "С" удобен для записи в одну строку например: IF A == B {\*Something do*\}
Когда конструкция занимает несколько строк она становится гораздо менее читабельной(особенно если программист не оформляет текст).

Fix.

Такой формат предназначен для коротких "свитчей" для больших есть "CASE".

Это краткий способ записи можно вот так:
1 -> WRect.Top.X; 3 -> WRect.Top.Y; 6 -> WRect.Down.X; 7 -> WRect.Down.Y

Приоритеты: практичность, гибкость

Думаю использование разных стилей в разных частях программы улучшит
её читабельность, например вы можете использовать стиль "С" для маленьких
блоков кода, а паскаль(хотя это скорей питон так как нужно выравнивать в колонку)
для объединения маленьких в большие.

Но вы правы синтаксис очень сырой.

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

Честно говоря не задумывался, это скорей "свой лунопарк".

Синтаксис очень сложен, прямая интерпретация не возможна, так или иначе необходима предварительная трансляция.
В общем то я планирую действовать следующим образом: Препроцессор -> Трансляция в байт код -> Трансляция в асм -> Сборка исполняемого файла.

Спасибо покуримс.

 

AlexCab
А в каких кодировках компилятор жуёт сорцы? И есть ли какая-нибудь синтаксическая конструкция, позволяющая указать кодировку сорца? А если есть несколько сорцов от разных авторов и все в разных кодировках, эти сорцы удастся, скомпилировав, скомпоновать в один бинарник?

 

r90

По умолчанию в UTF8, но можно задать в "startfile"(startfile - текстовый файл содержащий настройки компиляции, пути включаемых файлов, и тп.(его кодировка может быть задана
в командной строке компилятора))для всех SOURCE файлов.

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

Разумеется, перед анализом компилятор транслирует, загруженный с диска исходный файл, в UTF16, из любой другой кодировка.

 

AlexCab
Неплохо. Мне не понравилось лишь:

По умолчанию естественным было бы использовать кодировку локали.

 

r90

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

 

AlexCab
Если человек писал проект без мысли о том, что кто-то его будет собирать на другой машине, то по-любому придётся ковыряться в makefile и коде проекта, без этого он не соберётся. А вот писать код в жёстко забитой кодировке может быть неудобно. Если локаль ru_RU.utf8, а весь код в utf-8 -- это действительно неудобно. Несколько лет назад я мигрировал с ru_RU.koi8-r на ru_RU.utf-8. Комментарии в коде, где были на русском, там и остались в koi8-r. Кодировку в начале сорца я никогда не указывал, перекодировать всё за раз скриптом не решился. И до сих пор случаются казусы, когда я лезу в какой-нибудь давно забытый сорец, чтобы посмотреть как я там что-то делал, или чтобы скопипастить оттуда кусок кода, и натыкаюсь на то, что файл надо открывать указывая кодировку явно. Это очень неудобно.
А если все сорцы в левой кодировке? Я запускаю `grep убей *', чтобы найти сорец откуда я вызываю kill, а поиск не происходит, потому что системная кодировка utf8, и grep ничего не знает про то, что сорцы в utf8. Да, я понимаю, можно изменить поведение "по-умолчанию", но что, я создавая какой-нибудь тестовый проект, чтобы просто проверить, что я правильно понимаю документацию, должен изменять это поведение по "умолчанию"? Каждый раз? Но это же не здорово. Значит мне надо общесистемно менять предпочтения компилятора. А раз так, то встаёт вопрос: почему это должен делать я, и почему это не сделано "по-умолчанию"?
А как компилятор переживёт то, что имена файлов, предположим, кодированы в cp866, а в сорцах они указываются в utf8? Это конечно же не такая уж и непреодолимая проблема. Да плевать на проблемы компилятора, а если я скрипт написал, который анализирует проект, ползает по include'ам, открывает файлы и какие-то там статистики считает. Ведь в этом скрипте будет больше вызовов iconv, для преобразования кодировки, чем собственно логики работы. Либо, в качестве варианта, все имена файлов проекта я должен буду указывать в не-системной кодировке, отказываясь от возможности изучать дерево файлов проекта привычным файлбраузером. Но если использовать системную кодировку, то спотыкаться о такие проблемы будут исключительно извращенцы, которые пишут сорцы в не-системной кодировке.

 

r90

Это относится к редактору, у компилятора задача простая:
1.Загрузить исходные файлы.
2.Процесировать.
3.Сохранить результат.
Так или иначе, чтоб корректно распознавать исходные файлы, компилятору необходимо знать их кодировку.

Согласен no good, но брать значение кодировки из локали тоже не верно, потому что например системная utf8,
но вы предпочитаете исходники в utf-8, лучше добыть параметр кодировки по умолчанию в настройки самого
компилятора, чтоб пользователь мог выбрать её при установке компилятора.

Вот здесь как раз компилятору при запуске стоит узнать текущую системную кодировку и передавать имена файлов системе в ней.

Что поделать, либо так, либо привести все к одной(системной) кодировке.

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

Не думаю что не правильно завязываться на сис. кодировку, а если например две машины (на работе и дома) Win и Lin?

 

Вы постоянно путаете общий случай, с частными проявлениями. Установки "по-умолчанию", должны быть заточены на какой-то частный случай, который чаще всего бывает. Сделать так, чтобы "по-умолчанию" работало везде не удастся, поэтому надо сделать так, чтобы "по-умолчанию" работало бы как можно чаще. А чаще всего бывает так, что пользователь хочет хранить файлы в системной кодировке.

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

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

Поведение "по-умолчанию" должно быть заточено на локальную кодировку. А всё остальное -- это уже для тех, кто на рабочем месте не справляется с работой, и поэтому носит работу домой и работает ещё и дома. Это для тех, кто работает в разношёрстной команде, и вынужден оглядываться на остальных при выборе кодировки. И затачивать поведение "по-умолчанию" на таких людей -- неправильно, поскольку они всё равно придут к выводу, что всё сделано неудобно, и надо делать иначе. Они всё равно начнут вписывать в каждый файл строку типа "/* -*-coding: utf8-dos;-*- */". И в каждой директории оставлять файлик с именем .fname-coding:utf-8 (или .fname-coding:utf8, или ещё что-нибудь в этом роде). Они настроят свои IDE, чтобы те делали это автоматически. И будут гнобить каждого, кто не настроил IDE, и при этом забывает указывать кодировки. Очевидно же, что таких людей не будет волновать поведение компилятора "по-умолчанию". Они сделают свои умолчания. А вот тот, кто работает один и работает для себя, будет в первую очередь затачиваться на поведение компилятора "по-умолчанию". И если оно не совпадает с поведением "по-умолчанию" текстового редактора, файлового браузера, всех прочих программ, то это просто издевательство над ним.

 

r90

Абсолютно верно.

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

Ни в коем случае не по своей прихоти, он проверяет задана ли кодировка явно, если нет использует заданное по умолчанию.

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

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

Код (Text):

1. А всё остальное -- это уже для тех, кто на рабочем месте не справляется с работой, и поэтому носит работу домой и работает ещё и дома...

Не стоит их осуждать.

Код (Text):

1. А вот тот, кто работает один и работает для себя, будет в первую очередь затачиваться на поведение компилятора "по-умолчанию".
2. И если оно не совпадает с поведением "по-умолчанию" текстового редактора, файлового браузера, всех прочих программ, то это просто издевательство над ним.

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

 

Угу. Десять лет назад я был достаточно умён, чтобы поставив линупс, два часа настраивать его на кириллицу, консультируясь с Cyrillic-HOWTO. Но и тем не менее, я всеми руками за сегодняшнее положение дел, когда всё работает из коробки. Ум и сообразительность человека -- это ещё не повод писать для него неудобный софт. Я бы сказал, что ровно наоборот: умный и сообразительный человек, более способен к миграции на более удобный софт. Поэтому для него надо писать хорошо.

Но я кажется понял. Думал-думал, откуда такое упорство, и нежелание принимать общепринятые практики выбора внешней кодировки, которые уже доказали свою работоспособность. И никак не мог понять. А дело ведь в заголовочных файлах, которые ставятся вместе с компилятором и стандартными библиотеками, так? Их ведь нельзя поставить в системной кодировке, поскольку разные пользователи системы могут использовать разные кодировки. Кроме того компилятор ставится администратором системы, который вообще, быть может, работает в локали LANG=C, и поддержка кириллицы у него лишь эпизодическая. И в общем случае можно угодить с кодировкой большинству пользователей, но никак не всем. Либо уговаривать пользователей к переходу на какую-нибудь единую для всех кодировку. Либо каждому пользователю ставить копию всех заголовков, перекодируя их согласно предпочтениям пользователя. И конечно же, проще всего нацеливать компилятор на какую-то одну кодировку, оставив поддержку остальных в виде опции для "умных и сообразительных".
Ну что ж. Успехов вам, в вашем нелёгком деле.

 

r90
Спасибо.

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