 uCLisp
|
12 июл, 2015 @ 20:29 
|
|---|
|
В общем, если вам нужны списки переменной длины, содержащие данные заранее неопределённого типа (скажем, могут быть вперемешку строки и интегеры), то старый добрый Си скажем вам - "фиг тебе, это невозможно". А Лисп скажет - "да легко ваще".
Хочу тут автоматизировать одну процидурку инициализации некоего устройства, и пришёл к выводу, что лучше уж я допишу "Лисп внутри Си" и переложу самую занудную часть задачи на могучие плечи самодельного процессора списков :) Думаю, он мне ещё не раз пригодится.
ECL не подходит из-за того, что его ещё портировать надо - а тут всё компилируется как обычная Си-программа, вместе со всем остальным. И можно использовать даже на STM32, никаких ОС-зависимых вещей нет.
Два дня разбегаться, чтоб потом за 5 минут долететь! |
если все равно надо дописывать, то с таким же успехом можно дописать в си++ какой-нибудь свой список или наполовину свой - без подражания лиспу во-первых, это не ++ во-вторых, подражание не от хорошей жизни, а потому, что лисповый подход мне реально нравится. А вот STL - как-то "не пошло" ну если не ++ то stl отпадает автоматом а что из лиспового подхода ценно например? "плоский" синтаксис, например. Один и тот же подход для всего, за очень редкими неизбежными исключениями когда кто-то говорит, что в лиспе слишком много скобок, я открываю какие-нибудь исходники от Qt и вижу миллионы всяких РАЗНЫХ скобок... Edited at 2015-07-12 19:03 (UTC)кстати, сам факт того, что в С/С++ надо ДОПИСЫВАТЬ СВОЮ РЕАЛИЗАЦИЮ списков, когда в Лиспе она была изначально (потому что сам язык такой), уже кое-что интересное говорит :) А списки - это такая банальщина реализацию списков как раз не надо, поскольку есть std::list. затык в том, что тебе понадобился специфический тип, который станет элементом списка: то-ли-целый-то-ли-строка - но такой тип можно реализовать миллионом способов, соответственно как может кто-то заранее знать, какой вариант нужен тебе? учитывая, что даже свой список пишется средствами чистого C часа за два и средствами С++ - за час - тащить туда целую идеологию (LISP или чего еще) - это как из пушки по воробьям лупить :) соответственно как может кто-то заранее знать, какой вариант нужен тебе?а что если есть такой вариант, где вообще не надо заморачиваться "специфическими типами" и их поддержкой, потому что в языке это уже реализовано - не в библиотеке, а в самом языке, нативно? Лиспу пофиг, какой типа у элементов списка. И не надо тратить два часа на миллион разных способов. Да, это целая идеология. И не только про списки. Сборка мусора, динамическая типизация и т.п., и т.д. Да, ни Си тоже можно всё это сделать (внутри Лисп-машин ведь именно Си и работает, в большинстве случаев). Но всё это требует отдельных (причём зачастую нетривиальных) телодвижений и изобретательности. Вместо того, чтобы взять инструмент и решать с его помощью прикладную задачу, надо сначала "доработать напильником", чтобы обойти встроенные ограничения - то есть, не воспользоваться встроенными возможностями, а обойти ограничения! Это ли не странно? Но у всего есть своя ниша, я не спорю. На Лиспе, например, неудобно работать с бинарными данными - битовые поля и т.п. реализовать можно, но через изврат (особенно если хочется аппаратно-независимой переносимости -- но и на Си в таких условиях могут быть проблемы, просто не такие). Поэтому я и сочиняю гибрид. Чтобы не терять возможность выстрелить себе точно в ногу из динамически определённого пистолета. > если вам нужны списки переменной длины, содержащие данные заранее неопределённого типа То у вас в дизайне, скорее всего, дыра. Вовсе нет. Обычная ситуация из реального мира. Что-то не придумывается. Причём это ведь мало запихать, с этим потом ещё и работать придётся. при разборе данных, например, с консоли. На этапе компиляции мало что известно про то, что там напечатают очумелые ручки пользователя. Пользователь херачит руками по телетайпу. От этого получаются беспорядочные символы. Можно потом это, конечно, разбирать и нарезать на лексемы (возможно, неявные). Но это один хрен будет типом "лексема". |
|
