_Loader_

Hi Lev,

Tue Oct 21 2003 10:54, Lev Serebryakov wrote to Alex Kouznetsov:

LS> Добавлю -- там где ты выбросишь IF в любой его форме.

Мне кажется, ты будешь смеяться... Анекдот состоит в том, что в PDF есть операторы if и ifelse ;-)) Смотри таблицу 3.38 адобевского документа PDF Reference fourth edition

Пока, Алексей

Tue Oct 21 2003 09:38, Roman Khvatov wrote to Ilia Tarasov:

RK>>> Опять же, это ассемблер. IT>> ЯВУ или промежуточный код?

RK> Промежуточный код.

(*)

IT>> И gcc, на который тут так активно показывали, уже не сможет IT>> сгенерировать код для стековой машины?

RK> Может, как и для любого другого ассемблера :)

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

RK>>> Только для неоптимизирующего компилятора, для оптимизируещего RK>>> придется писать оптимизирующий кодогенератор с этого 'ассемблера' IT>> См. TIGRE, например.

RK> Это система преобразования графов, оптимизировать код под конкретные RK> особенности конкретного стекового процессора она не сможет, она сможет RK> сделать некоторые алгоритмические оптимизации для обобщенного стекового RK> процессора.

Угу. В итоге на базе этого обобщенного представления окажется возможным сгенерировать систему команд для конкретной реализации стекового процессора. Иначе говоря, ввести аппаратную поддержку для _конкретного_ решения. Для регистровой модели я пока не вижу столь же эффективного и оперативного подхода. Правда, про MicroBlaze пишут, что методики построения компиляторов для его архитектуры "хорошо известны", но _систему_ (имея в виду System-On-Chip) на основе MicroBlaze я бы не стал делать вот так сразу...

IT>> Fixed. А теперь объясни этому же человеку, почему он должен писать IT>> _только_ на ассемблере с довольно низкой производительностью своего IT>> труда? Hикаких промежуточных инструментов уже не допускается?

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

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

IT>> Вот я применяю тулз, основанный на парсере, встроенном в IT>> Форт-транслятор, который генерирует коды для конечного автомата.

RK> Это хорошо, только тогда это уже не Форт, а именно 'тулз, основанный на RK> парсере, встроенном в Форт-транслятор'.

Ну и как прикажешь тогда его назвать? :) У меня фантазия на названия исчерпалась.... да и длинновато как-то.

IT>> Я все равно тебя не понимаю. Почему для использования разработки нужны IT>> миллионы ее пользователей вокруг?

RK> А кто ее будет использовать, если она никому не известна? С другой RK> стороны, если ею никто не пользуется, то и развиваться она не будет, так RK> мы и имеем Форт, практически не изменившийся за 30 лет с момента RK> возникновения.

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

IT>> говорю о рекламе, я не хочу, чтобы люди выбирали себе смоляное IT>> чучелко для битья... а то распространен Форт мало, но ругать его IT>> сбегаются целые толпы... :))))

RK> Так ругают за дело - у Форта есть _огромный_ недостаток в виде совершенно RK> нечитаемого синтаксиса (только не надо криков 'кому как, я отлично его RK> читаю' - можно и медведя научить ездить на велосипеде, но это не значит, RK> что медведи в лесу должны устраивать велогонки) и отсуствие каких либо RK> _реальных_ преимуществ по сравнению с _современными_ системами RK> програмирования (30 лет назад эти преимущества были, но прогресс не стоит RK> на месте, а Форт - стоит, и сегодня этих преимуществ _уже нет_)

Ты думаешь, мне он _нравится_? :) Я к нему _привык_, и научился быстро переходить к гораздо более читаемому представлению программ, которые пишу. Вот поговорить о практических методах синтаксических преобразований - дело. А преимущества действительно играли роль, пока памяти было мало и развернуться с оптимизирующими компиляторами было особо негде. Сейчас для PC есть более эффективные средства в качестве mainstream. И Форт язык далеко не первоочередной для изучения, хотя если программист собирается писать компиляторы (вообще), то написать транслятор Форта было бы ОЧЕНЬ полезно.

IT>> Знаешь, я бы не рискнул рекомендовать паяльник для производства IT>> печатных плат в промышленных масштабах.

RK> Паяльник массово применяется в исследовательских лабораториях, причем RK> тоже в промышленных масштабах (_промышленные масштабы_ != _на заводе_)

Ну я написал "производства в промышленных масштабах"... т.е. имея в виду серийный выпуск изделий на одном предприятии. Что до исследовательских лабораторий, то я знаю подобные места, где именно Форт и используют, адаптировав его под свои потребности. Чтобы со вкусом развернуться в программировании на чем-то "красивом, правильном и современном", частенько времени не хватает, да и не оценят красоту текста, написанного для _лабораторной_ установки.

IT>> Именно что грамматика не изменится. После препроцессора полученный IT>> текст (в котором опять begin end) можно будет пропустить через IT>> компилятор Паскаля...

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

Исходный - не будет. После препроцессора - будет.

IT>> Какие дальше будут соображения? Как поделить орехи на кучки?

RK> Еще раз напомню, что мы пытались определить: отличие между _разными_ RK> языками и _диалектом_ одного и того же языка. RK> Заметь - _существующими_ языками, а не теми, которые можно придумать :) RK> Я знаю один диалект паскаля, где были введены лексемы _( и _) как RK> _аналоги_ соотвественно begin и end, заметь, не _заменили_ begin и end, а RK> ввели синонимы.

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

RK> То есть это не помешало компилировать обычные Паскалевские программы, но RK> позволило сократить запись для разрабатываемых на этом диалекте программ. RK> То есть на лицо явный _диалект_. Если бы _( и _) были введены _вместо_ RK> begin и end, то _все_ Паскалевские программы перестали бы RK> компилироваться, то есть налицо новый язык (нафиг никому не нужный :)

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

RK> Правильно, для определения разницы между диалектами языка и разными RK> языками компиляторы и _должны_ рассматриваться как черный ящик. Причем RK> нас совершенно не интересует, что они генерируют на выходе, нас RK> интересует только смог ли данный компилятор (рассматриваемый как черный RK> ящик) откомпилировать исходный текст программы или не смог. Под смог/не RK> смог понимается получили мы в результате выходные данные от компилятора RK> (независимо от того, что это за данные - код, промежуточное RK> представление, текст на другом языке, и т.д. - это зависит только от RK> самого компилятора и входит в определение черного ящика как RK> успешная/неуспешная компиляция) или нет.

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

RK> Здесь я под граматикой исходной программы имел в виду совокупность ее RK> лексики, грамматики и семантики, то есть все вместе.

Точнее, лексики, синтаксиса и семантики. Грамматика - более объемлющее понятие.

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

RK> Схожим, но не одинаковым!

Ммм... в пределах понимаемости человеком?

IT>> Hаучился писать на одном - очень легко перейти к другому IT>> (Си -> Паскаль).

RK> Писать - можно, компилировать программу одного другим - нет, то есть это RK> все же _разные языки_ (хотя и очень похожи, так как они _производные_ RK> Алгола)

Компилировать - уровень _реализации_ инструментов. Писать - уровень разработки программы человеком. Здесь всегда можно пустить другой .exe, это-то как раз не проблема. Проблема с ходу перейти от Си к Прологу, например...

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

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

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

С учетом предыдущей твоей фразы требуется очень существенное уточнение терминологии. Не проще ли компилятором называть "классический компилятор"?

IT>> VHDL - это _совершенно_ не код,

RK> Какая разница - это продукт деятельности первого компилятора.

"Неклассического"...

IT>> то есть не продукт деятельности компилятора. А если я его буду не IT>> руками набирать, а с микрофона надиктовывать, то программа IT>> распознавания речи будет компилятором?

RK> Для данной дискусси - да.

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

Hi Lev,

Tue Oct 21 2003 23:42, Lev Serebryakov wrote to Alexey Boyko:

LS>>> Кстати, Language != Programming Language. LS>>> HTML == HyperText MARKUP LANGUAGE AB>> PCL == Printer Control Language (Язык управления принтером)

Все же не совсем понятно. Скажем, функциональные языки - это языки программирования или нет? Классичекий пример

Quicksort in Haskell qsort [] = [] qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x where elts_lt_x = [y | y <- xs, y < x] elts_greq_x = [y | y <- xs, y >= x]

Никаких if нет - значит, это не программа? А то же самое, написанное на С - это программа, потому что там будет использоваться if?

Или, например, в промышленности применяют язык релейно-контактных схем - это язык программирования, или просто язык? В нем, в отличие от PDF, вовсе нет никаких if. Получается, что PDF-файл - это программа (про что я и говорил с самого начала), а то, что исполняет какой-нибудь PLC, управляя станком, - не программа? С последним трудно согласиться...

Пока, Алексей