новый язык. Еще один подход.

Прошивка для робота - достаточно hard rt?
http://www.flownet.com/gat/jpl-lisp.html (см. про robby и tooth)

Вообще, в hard rt тогда уж сосет и C++, с динамической памятью в нем все еще хреновее, чем в системах с GC(а не с динамической - лиспы тоже умеют структуры на стек класть, числа в регистрах складывать и т.п.).

> есть какие-то потуги в области применимости lisp в rt, хотя если говорить о hard real time то тут они все сосут.

Ну я насчет именно лиспа не знаю, просто неитересно. А сборшики мусора для RT пилятся. Думаю, скоро появятся реально применимые :)

> http://www.flownet.com/gat/jpl-lisp.html

Этот баян будет вечным %)

>Что, правда глаза колет? )))

Мне-то каким боком? Я Лиспом никогда не пользовался и не собираюсь. Просто колет глаза, когда люди чушь несут с умным видом. Правда, с твоим ником-то... Но на него не сразу внимание обращаешь.

Очень хочется всё-таки узнать про «нормальные» GC, которые используются в Лиспе.

Придется разжевать мысль в третий раз: без GC можно обойтись только в том случае если...

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

Прошивка для робота - достаточно hard rt?

у hard-rt есть определение, которое избавляет от необходимости оперировать словами «достаточно» и «недостаточно». нужно ли это самое rt роботу - зависит исключительно от робота

Вообще, в hard rt тогда уж сосет и C++

сосёт-не сосёт, но используется. причём с самописными GC

Ну вот видишь. «Другой подход» работает. )))

когда люди чушь несут с умным видом.

Цитаты и прувы в студию.

Правда, с твоим ником-то...

Ммммм. Сразу вспомнается детский сад, манная каша, тётя Валя и «обзывалки» - «антошка-картошка», «машка-какашка» и т.д. )))

Крон, ты просто мастер балансирования в дискуссии между «программистами на автолиспе» и совсем законченным детским садом. )))

>> рошивка для робота - достаточно hard rt?

у hard-rt есть определение, которое избавляет от необходимости оперировать словами «достаточно» и «недостаточно»

Не избавляет :) Если директивные сроки порядка секунд, то даже паузы на stop-the-world-GC не повлияют ни на что. Прикол в том, что на одном из упомянутых роботов Лиспа не было вообще, а на втором была смесь Лиспа и Си :)

>Боюсь, что парсера быстрее Фортовского не придумать.

Но можно ли транслятор Лиспа запихнуть в 512 байт ПЗУ? ;)

Когда «дедушка Вирт и К» допилят «Оберон-На-Чипе»
http://www.embeddedcomputingconference.ch/pdf_sec_2009/4A3-Goldener.pdf ,
тогда и настанет Фортокапец :)

Кстати о GC в hrt - там часто память выделяется статически один раз и динамическая память вообще не используется, так что в таком контексте говорить о GC вообще смысла нет.

Ну так что с нормальными GC из Лиспа, которые «Нормальные это не тупой mark-and-sweep и уж тем более не подсчет ссылок». А что же это? Можете назвать?

Да в любой современной реализации. И не то, что лиспа, а вон и жабы той же - ни naive mark-sweep, ни reference counting не используется, ибо несолидно.

то есть не можешь

Что, полное название GC?
generational copying gc [Sun JVM, SBCL/CMUCL на не-x86]
generational mostly-copying gc [SBCL/CMUCL на x86]

и почему было не написать этого семь часов назад?

>Когда «дедушка Вирт и К» допилят «Оберон-На-Чипе»

Не... Это не интересно. Вот когда Оберон можно будет сделать на любом универсальном чипе... :D

...

И, по-любому, промышленные форт-процессоры были уже лет 25 тому назад :D

> теперь насчет реализации и идей по синтаксису.
Насчёт синтаксиса у меня следующие идеи:
1. Комментарии.
2. Строки. Скорее всего, строки должны быть многострочными «Вот это -
правильная строка». 'И это - тоже';
3. Пробелы (просто разделяют токены). Точки, двоеточия - примерно такой же смысл, как в С. Что делать с запятой - я не знаю. Однозначно, списки лучше, когда они разделены пробелами, а не запятыми. В clojure запятую приравняли к whitespace, это имхо тоже неправильно. Может быть, её тоже нужно использовать для указания структуры? Я не знаю.
4. Скобки. {}, [], (), <>, и попарные сочетания, такие, как (*, *), [: :] и т.п. В таких сочетаниях содержимое должно выделяться пробелами. Смысл скобок может зависеть от контекста. Но, в основном, квадратные скобки отвечают за применение функций, круглые - за группировку, фигурные - за блоки. Операции «больше и меньше» записываются по-фортрановски, чтобы не было неоднозначности в толковании. Унарный минус должен быть приписан к числовой константе, или он считается символом "-" (вру, наверное).
5. Всё, что не входит в вышеперечисленные категории, является токеном. Токен, не являющийся строкой и числом, является идентификатором. По-моему, позитивной идеей являются префиксы. Например, @foo могло бы читаться как «foo с префиксом @». В лиспе @foo - это просто идентификатор. В MS SQL и в перле смысл префикса @ фиксирован. В Pascal @ является оператором. Всё это недостаточно круто. Мы могли бы задавать контекстно-зависимый смысл префикса @. Простейший вариант - читать @foo как [@ foo], и тогда, назначая разные макросы символу с именем @, можно менять смысл выражения @foo. Хотя, того же можно добиться и перегрузкой операции @. В общем, не знаю.
6. Макрочиталки. Макрочиталка может быть назначена идентификатору и запускает функцию, читающую что-то из входного потока и пытающуюся построить какой-то объект. Например, можно сделать парсер даты, привязнный к символу date и срабатывающий в таком например, виде:
[extractYear date.2009-10-01]
7. Такие вещи, как =, +, -, * - это тоже символы. Поэтому, не a=b, а только a = b. Что оставляет возможность иметь имена идентификаторов типа integer->string или doit!
8. Имеется приоритет операций. Можно сказать, что данный идентификатор (например, +) является бинарной операцией и задать его приоритет (эта идея была реализована ещё в Прологе). Лучше бы задать приоритеты основных операторов сразу.
В остальном, синтаксис - лисповый, потому что он самый простой. Хотя
9. Можно попытаться сделать и операторы, только они должны быть простые, чтобы можно было парсить методом рекурсивного спуска. Т.е., по первому слову оператора должно быть понятно, что это за оператор. И так далее, чтобы текст всегда парсился без возвратов назад. Тогда легко будет расширять грамматику без наступания на грабли. Тут, кстати, мы находим, куда воткнуть ";" и ",". Операторы должны первым делом преобразовываться к функциональной форме, чтобы получился низкоуровневый S-exp - образный синтаксис, который легко переколбашивать. А pretty-printer должен печатать их обратно в виде операторов (вот и парсер-линза). Так сделано в Mathematica и это - правильно.

Также должно быть квазицитирование, под него можно задействовать какие-то из видов скобок. Например, так:
<:тело-шаблона {:подставляемое-выражение:}:>

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

Кстати, получающиеся смайлики должны быть скорее такими :), чем такими :( , задолбало уже это инферно. Сделаем мир позитивнее!

Этот синтаксис почти хорошо продуман и, в общем-то, он подитоживает весь мой опыт изучения программирования. Я ничего не написал про пространства имён, но тут я пока что в непонятках. Крайности - это SQL и Mathematica, и я пока не знаю, что правильнее. В динамических языках имеются некоторые фундаментальные проблемы с пространствами имён и я пока не вижу, как их преодолеть...

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

> макросы вероятно не нужны,
Макросы, безусловно, нужны. Система типов их не заменяет. Макросы ортогональны ко всему остальному. Может быть, именно из-за них всё написано на С, а не на Паскале... Типизации они не мешают - их можно пустить отдельным слоем до собственно компиляции. Как это сделано в С (достаточно общо, но по-уродски), в Лиспе (гениально). И только шаблоны в С++ хорошо согласованы с типизацией, но это - слишком узкий частный случай, поэтому они и не спасли C++.

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

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

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

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

Аду изобретаешь?

А что, в Аде есть декларации, связанные с памятью?

без GC можно обойтись только в том случае если у Вас все структуры данных > фиксированного размера размещать их в стеке или преаллоцированном пуле. В > противном случае нужно либо иметь GC либо эмулировать GC

Чем GC помогает, если структура меняет размер? Всё равно нужно её перевыделить на новом месте. Кроме того, вообще неправильное утверждение. Я видел работающие программы без GC, с, например, векторами переменного размера. А вообще, есть и другие способы обезопасивания памяти. Например, отношения собственности, при которых все объекты выстраиваются в иерархию от некоего единственного корня, а объекты одной «должности» глобально упорядочены по какому-то номеру. В этом случае, получаем, что все объекты линейно упорядочены и можно пользоваться подсчётом ссылок (если я не ошибаюсь). Кроме того, в некоторых случаях можно статически проверить правильность ручного выделения памяти. Частный случай: созданный в процедуре объект удаляется на любом пути исполнения. Именно на подобные частные случаи я и предлагаю обратить внимание, говоря про декларации alien, fresh и т.п.

Прошу прощения за многословие...

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

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

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

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

Остальное вообще какой-то дикий бред, даже комментировать лень.

>Лисп вряд-ли будет подмножеством Форта. Хотя бы потому, что в заявленные 512 байт вряд-ли входит полноценная динамическая память со сборкой мусора.

Ну, ты не путай тёплое с мягким. 512 байт ПЗУ - это минимальные размеры известных мне embedded-систем. Но я нигде не говорил, что в этих 512 байтах вмещается LISP :) Если встаёт вопрос динамической памяти, сборки мусора и LISP'а - то тут размер, безусловно, пойдёт на десятки килобайт. Может быть даже сотни, если с большими библиотеками :) 32-х битный Forthius со всеми либами, IDE (DOS ещё, понятное дело) и DOS-экстендером у нас больше 100кБ занимал :)

>Выведение типов я не очень понимаю, я как-то без него обходился всю жизнь.

Я думаю достаточно «локального выведения» - когда определяющим является тип «выражения», а не «место применения». Правда, это может сказаться негативно на читаемости «в твоём понимании». И ещё в таком случае приведение типов должно быть либо явно декларируемым, либо нужны «задаваемые правила».

> Хотите зарабатывать - забудьте слово Лисп.

1) Работы на работных сайтах ищут только лохи.

2) Средний доход среднего лиспера на порядок выше доходов жабоводов.

Можешь плакать.

> А вот программеры Java, C#, C+ нужны на рынке труда в больших количествах.

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

>И только шаблоны в С++ хорошо согласованы с типизацией, но это - слишком узкий частный случай, поэтому они и не спасли C++.

Но именно «типизированных макр» мне в лиспе и не хватало. Т.е. по хорошему их должно быть 2 вида: «синтаксические» - просто «вставка сгенерированного программного кода» (как в лиспе сейчас), и AST-преобразования - т.е. «макры как дженерики»: могут анализировать полученные АСТ-ноды и должны выдавать сгенерированный АСТ (знаю только один аналог - в немерле, хотя вроде там и макры первого типа тоже есть - хз).

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

И ещё я опираюсь на тот факт, что CLOS - слишком медленный и лисперы обычно не рекомендуют им пользоваться

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

Может надо несколько типов дженериков?

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

Оптимизация по «простым типам» - да, возможна. Но обойтись совсем без классов невозможно - на них весь ввод/вывод (как минимум).

>Средний доход среднего лиспера на порядок выше доходов жабоводов.

Еще один элитный сказочник?

> Еще один элитный сказочник?

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

есть структуры, вобщем-то

> Средний доход среднего лиспера на порядок выше доходов жабоводов.

На двоичный порядок, десятичный, шестнадцатиричный?

>есть структуры, вобщем-то

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

«На порядок выше» == «В два раза и более» :)

>В два раза и более

чем у кого? у дворника, джава- джуниора, опытного, тимлида, pm'a? и где территориально?

Какое это имеет отношение к значению фразы «на порядок выше»?

> чем у кого? у дворника, джава- джуниора, опытного, тимлида, pm'a?

Сказано же - у «среднего».

и где территориально?

Хороший вопрос.

>у «среднего».

у «среднего» дворника, джава- джуниора, опытного, тимлида, pm'a?

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

> у «среднего» дворника, джава- джуниора, опытного, тимлида, pm'a?

Да что ты привязался к «дворнику»? «Средний доход среднего лиспера на порядок выше доходов жабоводов» - что тут непонятного?

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

Ыыы... «Часто даже не от лиспа - просто знание лиспа делает программиста намного лучшим специалистом вообще» - у тебя с другим анонимным братом вообще консенсус.

Хотя фразу про «XXX делает намного лучшим специалистом вообще» любят вообще все евангелисты^Wпропагандисты.

>«Средний доход среднего лиспера на порядок выше доходов жабоводов» - что тут непонятного?

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

Часто даже не от лиспа - просто знание лиспа делает программиста намного лучшим специалистом вообще

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

>Часто даже не от лиспа - просто знание лиспа делает программиста намного лучшим специалистом вообще.

Думаю, это характерно для любого идеологически продуманного подхода. Классические ЯВУ пишутся обычно ради сиюминутных задач с игнорированием идеологического момента, поэтому те, кто осваивает только их - ремесленники, со всеми плюсами и минусами этого подхода. Те же, кто берётся за освоение отдельной идеологии (не важно, LISP это, Forth или Haskell) - имеет потом опыт взгляда со стороны и способен программировать уже и на мейнстриме намного эффективнее.

>> Часто даже не от лиспа - просто знание лиспа делает программиста намного лучшим специалистом вообще

Речь не про это.

Твоя - не про это.

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

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

По крайней мере, я так понял анонимного брата.

Идиотам объясняют, что языки программирования это инструменты ВНУТРИ одной профессии «программист». А они продолжают сравнивать разные профессии типа программисты, продавцы и дворники.

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

> От изучения другого языка программирования появляются новые способности???

Нет, растет квалификация.

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

Прогер - не писатель, а переводчик. И таки да, я думаю, что переводчику как минимум полезно знать несколько языков.

Ну у лисперов песец самомнение.

А так же хаскеляторов, эрлангеров, фортеров :)

> От изучения другого языка программирования появляются новые способности???

Да. Конкретно - растет способность сконструировать код для одной и той же задачи разными способами. Правда, не всегда это плюс. )))

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

Разумеется.

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

Вы книги читаете? Ну так, для общего развития? Или может быть чем то еще интересуетесь?

Других аргументов нет кроме перехода на личности?

> На факультетах иностранных языков готовят писателей?

На них готовят лингвистов. Всегда ваш, К.О.

ВСЕ

ВСЕ

Тебе 10 лет, и других кванторов, кроме всеобщности, ты не знаешь?