LINUX.ORG.RU
Форум — Development  

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


0

0

Доброго времени суток!

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

1. Вычленяем в С то, что заставляет его медленно компилировать.
2. Делаем частичный компилятор С в язык, подобный Паскалю (который можно быстро компилировать).
По моим понятиям, что мешает С быстро компилироваться (могу ошибаться):
- система типов
Значит, нужен промежуточный язык, в котором неявное становится явным.
- идеология сборки с многократным чтением инклюдников
Значит, нужно поменять идеологию сборки. Я думаю, нужно уметь создавать некий «модуль», подобный «прекомпилированному хедеру», но более гибкий. С gcc я почти не работал, в MSVS прекомпилированный хидер - один на проект и этого мало. Нужно несколько. Они должны инкапсулировать состояние препроцессора и перекомпилироваться только по необходимости.

Тем самым мы получаем в наследство всё, что есть в С, только с быстрой сборкой.
Далее добавляем:
- нормальные макросы (включая обратимые макросы, возможность подменить лексеры и включая средства отслеживания сорсов)
- возможность делать код динамическим, т.е. динамически перекомпилировать отдельные функции и менять типы данных. Не все, но большинство.
- специальные переменные, локальные функции, замыкания
- встроенный тип «вариант» и полноценный полиморфизм
- декларативное управление памятью. Работая в лиспе, я чётко понимаю, что он мало подходит для задач реального времени. Я не думаю, что языки со сборкой мусора когда-нибудь смогут использоваться для этого. Да, можно извратиться и иногда накрутить много циклов без сборки мусора, но программирование становится очень сложным. Кроме того, ничего не декларируется о неожиданном порождении мусора в библиотеках или даже в самой рантайм-среде (например, если вдруг запустится JIT-компилятор). Поэтому, предлагается поддерживать на уровне компилятора всякие «умные указатели», чтобы можно было в статике проверить правильность работы с памятью.Конечно, вообще говоря эта задача не разрешима. Но представьте себе, например, сигнатуру функции:

fresh treeNode makeTreeNod(alien referenced treeNode parent);

Здесь говорится о том, что функция возвращает treeNode, выделенный в куче. Значит, кто-то в будущем должен будет позаботиться о его уничтожении (если мы не находимся в режиме компиляции с автоматической сборкой мусора, что может быть нужно для отладки или гарантии динамизма). При этом параметр parent также является ссылкой. alien говорит о том, что этот параметр не будет уничтожен нашей функцией. referenced говорит о том, что мы, возможно, создадим на него новую ссылку. Как минимум, это - автодокументация. Как максимум - подсказка компилятору. Я для своего пользования разработал несколько таких деклараций и пользуюсь ими на работе (пишу на Дельфи). Мой набор неполон, но вот он:

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

fresh - для возвращаемого значения или локальной переменной. Создали в области видимости и куда-то передаём (или возвращаем), после чего мы уже не отвечаем за удаление
my - для локальной переменной. Функция создаёт объект и удаляет его
alien - для параметра. Функция не берёт ответственности за удаление объекта.
eat - для параметра. Принимающая функция теперь отвечает за удаление
kill - для параметра функции. Не я создал, но я убъю до возврата из функции.
нет декларации - ничего не известно и нельзя судить о поведении функции в отношении удаления этого объекта.

Вот, видимо, этот набор не полон. Он, как минимум, не учитывает возможности включения объекта в подсчёт ссылок или сборку мусора, не рассматривает возможность существования объекта на стеке. Видимо, можно развить некую «алгебру» и получить полный набор таких деклараций. Он будет довольно сложным и не всегда однозначным, но он позволит, анализируя возможные пути исполнения, во многих случаях найти ошибки работы с памятью. Подобно тому, как сейчас компиляторы находят неинициализированные переменные, или неиспользованные присваивания значений.

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

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

/*М fresh*/treeNode makeTreeNod(/*M alien referenced*/ treeNode parent);
по сути означает то же самое, но не проверяется компилятором. Или же

typedef treeNode fresh_treeNode;

или же
#define FRESH(x) x
#define ALIEN(x) x

FRESH(treeNode) makeTreeNode(FRESH(ALIEN(treeNode)) parent);

Я пользуюсь, мне нравится.

А, вот ещё одну фишку вспомнил, только не могу её сформулировать в виде С.
declare procedure foo returns (x int, y varchar(100)) as
begin
end
соответственно, foo.return_type должно быть именем записи с двумя полями x и y. Чтобы не придумывать ей имя. Маленькая фишка, но ИМХО полезная.

★★★★★
← [QT] QThread
GCC inline assembler →

  1 2 3 4 5 6 7 8 9 10 11
Ответ на: комментарий от anonymous

Лисперы никак не могут успокоится и усвоить уроки истории.

вы никак не можете осилить лисп чтобы писать аргументированные посты? тогда лучше не пишите

pseudo-cat ★★★
()
Ответ на: комментарий от anonymous

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

Жабка конечно хороший язык в культурных руках, но неплохо бы уточнить что конкретно на ней предполагается делать в 90% из этих 10153 вакансий и нужно ли для этих вещей вообще чего-то учить.

Absurd ★★★
()
Ответ на: комментарий от pseudo-cat

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Работу по специальности «наркоман» тоже никто не предлагает. Но из этого не следует, что работа «наркоман» очень хорошая работа.

anonymous
()
Ответ на: комментарий от anonymous

>Но из этого не следует, что работа «наркоман» очень хорошая работа.

Точно также не следует и того, что работа нейрохирурга (программиста на Лиспе, Коболе, Форте) - очень плохая.

Вообще, чуть выше уже было: http://www.linux.org.ru/jump-message.jsp?msgid=4335258&cid=4336379

:)

KRoN73 ★★★★★
()

> Видимо, можно развить некую «алгебру» и получить полный набор таких деклараций.

да, это интересно и полезно, и именно этим надо заниматься

и я бы предложил этим заниматься в любой ущерб реализации (вопреки jtootf)

теперь насчет реализации и идей по синтаксису.

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

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

ну это прямо позарез хочется на этом писать... но самое главное ведь не парсер, а

правила разрешения имен/видимости

правила перегрузки функций

система типов (ее кусочек ты описал)

вывод типов

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от KRoN73

> Точно также не следует и того, что работа нейрохирурга (программиста на Лиспе, Коболе, Форте) - очень плохая.

Немного другая ситуация:

нейрохирургов, владеющим скальпелем таким-то требуется...

нейрохирургов, владеющим скальпелем другим требуется...

www_linux_org_ru ★★★★★
()

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

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

в общем, это тем для дискуссии

www_linux_org_ru ★★★★★
()

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

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

www_linux_org_ru ★★★★★
()

> специальные переменные,

это про что?

локальные функции, замыкания

тут вроде ничего сложного нет

встроенный тип «вариант»

тут тоже

и полноценный полиморфизм

какие из полиморфизмов?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

Не все, но большинство.

хм. а почему бы не все вообще?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от KRoN73

Создание программы на языке Java можно заменить на создание такой же программы на языке C# или С++. Но работу нейрохирурга не заменить работой менеджера или лётчика-испытателя.
Правильно выше замечено, что надо сравнивать инструменты, применяемые в профессии, а не разные профессии. Лисп является очень редко используемым инструментом, знание которого не даст работу.

anonymous
()

>fresh treeNode makeTreeNod(alien referenced treeNode parent);

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

Absurd ★★★
()
Ответ на: комментарий от anonymous

Когда аналогии начинают развивать - это диагноз :)

Впрочем, можно в эту игру поиграть.

Создание программы на языке Java можно заменить на создание такой же программы на языке C# или С++. Но работу нейрохирурга не заменить работой менеджера или лётчика-испытателя.


Замена программы на Java на программу на C# - это примерно как замена работы газовика на водопроводчика.

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


Остаётся только удивиться, откуда берутся программисты да хоть на том же AutoLisp'е :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Аналогии это да.
Можно спорить не только про Лисп vs Java.
Можно ещё спорить что лучше из напитков: кофе растворимый, кофе из зёрен, кофе с молоком охлаждённый, чай чёрный, чай зелёный, чай чёрный в пакетиках, чай зелёный в пакетиках с жасмином. И так далее. Использовать в споре статистику популярности, объёмы продаж, исследования врачей, мнение знаменитостей, запросы Гугла с количеством ссылок и так далее.
Но всё равно в итоге все останутся при своём собственном мнении про эти жидкости.
:)))

anonymous
()
Ответ на: комментарий от KRoN73

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

eugine_kosenko ★★★
()
Ответ на: комментарий от tailgunner

>Их несколько. Ты, я подозреваю, имеешь в виду поколения данных.
Говорить о том, что GC вообще как-то значительно тормозит это показывать свое не то что даже незнание устройств оных, а вообще, отсутствие опыта работы с рантаймами с нормальными GC. Это C++ головного мозга.

Первые компиляторы в машкод - это середина 70-х, читай Стила.

Что-то у меня складывается впечатление, что ты даже не тролль, а просто тупой.
http://lisp.org/alu/res-lisp-history

Love5an
()
Ответ на: комментарий от mono

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

В мире вообще много несправедливого и просто идиотского - религии, табакокурение и т.п. Но это не значит, что на это надо ориентироваться.

Love5an
()
Ответ на: комментарий от eugine_kosenko

Кстати, похоже, по той же причине не компилируют в Лисп.

eugine_kosenko ★★★
()
Ответ на: комментарий от anonymous

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

В мире вообще много несправедливого и просто идиотского - религии, табакокурение и т.п. Но это не значит, что на это надо ориентироваться.

Ну и не ориентируйся.

ах да, зачем же пеной исходить так, вас же никто не называет идиотом

pseudo-cat ★★★
()

Мне кажется, что скорость компиляции для Си не является важным фактором. Многим по барабану как долго собирается программа. Более того, есть гентушники, которые ловят кайф от самого процесса ;)

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

dave ★★★★★
()
Ответ на: комментарий от eugine_kosenko

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

Да. Хотя Форт тут совершенно не при чём :)

Возможно, в связи с лучшей стандартизированностью и переносимостью.


В первую очередь в связи с кроссплатформенностью GCC. Со стандартами у _Си_ (в целом, а не у GCC конкретно) всё ещё хуже, чем у Форта :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Love5an

> Говорить о том, что GC вообще как-то значительно тормозит

Это ты сам с собой разговариваешь? %)

отсутствие опыта работы с рантаймами с нормальными GC

Названия «нормальных» почему-то не приведены %)

Что-то у меня складывается впечатление, что ты даже не тролль, а просто тупой.

Просто тебе удобно считать, что все тупые и идиоты, а ты один умный...

http://lisp.org/alu/res-lisp-history

...правда, при этом ты способн давать только битые линки и линки на закрытые статьи :D Ссылка на Lisp 1.5 manual - мертвая.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Названия «нормальных» почему-то не приведены %)
Нормальные это не тупой mark-and-sweep и уж тем более не подсчет ссылок.

Love5an
()
Ответ на: комментарий от Love5an

У Вас есть обзоры GC, в которых объясняется «ненормальность» mark-and-sweep и подсчётов ссылок и объясняются принципы работы «нормального» GC на конкретной реализации, используемой на практике? Или у Вас принцип «лисп это круто, а вы все тупые идиоты»?

anonymous
()
Ответ на: комментарий от Love5an

>> Названия «нормальных» почему-то не приведены %)

Нормальные это не тупой mark-and-sweep и уж тем более не подсчет ссылок.

Плюсофаги обычно бравируют тем что последний раз написали delete пару лет назад. Но на вопрос «почему автоуказательные сопли должны быть принципиально быстрее GC?» ответить не могут.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> на вопрос «почему автоуказательные сопли должны быть принципиально быстрее GC?» ответить не могут.

Ты тоже сам с собой разговариваешь?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> на вопрос «почему автоуказательные сопли должны быть принципиально быстрее GC?» ответить не могут.

Ты тоже сам с собой разговариваешь?

Это примечание к чужой мысли. А ты тупой, да.

Absurd ★★★
()
Ответ на: комментарий от Love5an

Где описание «нормальной» работающей реализации GC для Лиспа? Там по ссылке Лисп только 2 раза упомянут. Сливаете что ли? Про «нормальные» и «ненормальные» заявили, а примеры реализации GC для Лиспа отсутcтвуют.

anonymous
()
Ответ на: комментарий от Love5an

По любезно предоставленной Вами ссылке перечислены 2 вида GC
Tracing GC
Reference counting

Ни один из них под Ваше описание «нормального» GC не попадает.

anonymous
()
Ответ на: комментарий от Absurd

>>> на вопрос «почему автоуказательные сопли должны быть принципиально быстрее GC?» ответить не могут.

Ты тоже сам с собой разговариваешь?

Это примечание к чужой мысли.

Впроде в этом топике никто не говорил про «скорость автоуказательных соплей» по сравнению с GC. Наверное, это у тебя в голове прозвучало? %)

А ты тупой, да.

Ну так не мучай себя общением со мной.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> Это примечание к чужой мысли.

Впроде в этом топике никто не говорил про «скорость автоуказательных соплей» по сравнению с GC. Наверное, это у тебя в голове прозвучало?

Ну можно же методом исключения вывести - если у нас нет GC, то мы обкладывается разными «стратегиями владения». К этой идее все автоуказатели собственно и сводятся.

Ну так не мучай себя общением со мной.

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

Absurd ★★★
()
Ответ на: комментарий от Absurd

>>Впроде в этом топике никто не говорил про «скорость автоуказательных соплей» по сравнению с GC. Наверное, это у тебя в голове прозвучало?

Ну можно же методом исключения вывести - если у нас нет GC, то мы обкладывается разными «стратегиями владения»

А сравнительную скорость ты тоже методом исключения выводишь, да? :D

Ну так не мучай себя общением со мной.

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

Ага, и этот постинг тоже не мне %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>А сравнительную скорость ты тоже методом исключения выводишь, да? :D

Если отказаться от указателей и ручной аллокации/деаллокации памяти, то нет причины ожидать a priori лучшего перформанса по сравнению с другими языками где тоже нет указателей и ручной аллокации/деаллокации памяти. Какбе чудес не бывает в этом мире. Вот я и повторил изначальную мысль еще раз, для очень острых людей.

Absurd ★★★
()
Ответ на: комментарий от balodja

> Ну, транслированный в html вариант легко находится в кеше гугла: http://209.85.135.132/search?q=cache:nyN_M5x5FHMJ:www.softwarepreservation.or...

Ну, мне интересна история, но не настолько :)

Хотя признаю - компиляция в машкод появилась в Лиспе на 10 лет раньше, чем я думал. Правда, непонятно, что это меняет в применимости языков с GC для реалтайма.

tailgunner ★★★★★
()
Ответ на: комментарий от Love5an

Очень хочется всё-таки узнать про «нормальные» GC, которые используются в Лиспе. «Ненормальные» уже извесны: Tracing GC и Reference counting. Надеюсь информация про «нормальные» GC не засекречена?

anonymous
()

Какая разница, джава, лисп. За что платят - на том и пишут.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

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

О! Еще один «острый» оппонент. Придется разжевать мысль в третий раз: без GC можно обойтись только в том случае если у Вас все структуры данных фиксированного размера размещать их в стеке или преаллоцированном пуле. В противном случае нужно либо иметь GC либо эмулировать GC. Чем качественно отличается «эмулирование GC» от «имения GC» что-то никто не знает.

BTW, никто не мешает в том том же CL применять исключительно деструктивные операции и массивы фиксированного размера. Или в жабе создать пул реюзаемых объектов в static-секции класса и пользоваться только им.

Absurd ★★★
()
Ответ на: комментарий от tailgunner

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

imhotep
()
Ответ на: комментарий от KRoN73

> Остаётся только удивиться, откуда берутся программисты да хоть на том же AutoLisp'е :)

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

LamerOk ★★★★★
()
Ответ на: комментарий от Absurd

> О! Еще один «острый» оппонент.

Следи за тредом. )) Это не твой оппонент, и вопрос относится к посту:

http://www.linux.org.ru/jump-message.jsp?msgid=4335258&cid=4337686

Названия «нормальных» почему-то не приведены %)

Нормальные это не тупой mark-and-sweep и уж тем более не подсчет ссылок.

LamerOk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8 9 10 11
← [QT] QThread
Development
GCC inline assembler →