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

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

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

Я вижу светлое будущее примерно так:

есть какая-нибудь операционная система, есть выверенное, отлаженное, стабильное api к ней. Есть какой-нибудь фреймворк, типа .NET, в котором есть JIT, сборщик мусора и мощное API на все случаи жизни. И вот на этом фреймворке и создавать пользовательские приложения. Ошибки памяти можно свести к минимуму.

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

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

Но это все мечты-мечты-мечты.

mono ★★★★★
()

Язык С пытаются «улучшить» уже десятки лет. Немного удалось только у С++.

anonymous
()

а ты пробовал реализовать хоть что-нибудь из того, что напридумывал?

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

>есть выверенное, отлаженное, стабильное api к ней

POSIX

в котором есть JIT, сборщик мусора и мощное API на все случаи жизни.

Java

Для видеокарт и прочей внутренней гадости тоже можно придумать универсальный API.

OpenGL

пользователю совершенно не нужно будет знать какая ось унутре, линукс, винда или любая другая ось

Java, SDL, ......

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

>POSIX

Да.

Java

Для прикладных приложений не подходит Java.

OpenGL

читай внимательнее, я про драйвера говорил..

Java, SDL, ......

да тоже не то.

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

>Язык С пытаются «улучшить» уже десятки лет. Немного удалось только у С++.

ей богу, смешно. А как же ObjC или Vala?

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

>Когда Линус переведёт своё ядро на Objective C? Ведь он лучше, чем С.

завтра в 2 часа дня по Московскому времени. Жди.

mono ★★★★★
()

>Известно, что паскаль компилируется в несколько раз быстрее, чем С.

Извини - дальше этих слов не читал. Будет время, загляни на
http://bellard.org/tcc/

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

>В итоге ОС должна стать просто прокладкой и пользователю совершенно не нужно будет знать какая ось унутре, линукс, винда или любая другая ось.

Хрень какая. Окружающий Environment и его, конечно не устройств, но свойства и интерфейсы, это в любом случае значимая вещь.
То, как ты написал это то, как уже и сейчас существует на винде. Но вот только там все равно не все идеально, в итоге.

Идеальная ОС это лисп- или смоллтолк- система - с достаточной абстракцией железа и внутренностей, и динамичным, состоящим из объектов, рантаймом.

Позиксы и винды это все worse-is-better и говно сорокалетней давности.

Love5an
()

>Работая в лиспе, я чётко понимаю, что он мало подходит для задач реального времени.
Бредятина.

«GC мешает реалтайму» это выдумки школьников и скубентов с gamedev.ru и подобных ресурсов.
Но даже если при упоминании GC у кого-то начинается приступ панических атак, то во-первых, все современные компиляторы лиспа, и, особенно, компилирующие в нейтив, умеют класть разнообразные лисповские объекты на стек, во-вторых, данные можно хранить в каких-то преаллоцированных заранее структурах, которые до завершения программы особо не меняются в размерах, и не страдать функциональщиной головного мозга и использовать с ними заодно операции с побочными эффектами(т.е. модифицирующие эти структуры), и, в третьих, если уж совсем плохо[с головой], можно использовать FFI к сишке и хранить данные в сырой памяти - и объема меньше занимается, и быстро, и контролируемо.

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

>Идеальная ОС это лисп- или смоллтолк- система - с достаточной >абстракцией железа и внутренностей, и динамичным, состоящим из >объектов, рантаймом.

Позиксы и винды это все worse-is-better и говно сорокалетней давности.


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

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

> «GC мешает реалтайму» это выдумки школьников и скубентов с gamedev.ru

Ооо, матерые разработчики рилтайма ITT %)

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

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

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

> А ты, поди, уже проектов пять в области реалтайма завалил из-за GC, сволочи такой.

Нет, у нас языки с GC для реалтайма не используются. А если посмотреть, скажем, на спецификацию RTSJ, мы увидим, что там GC фактически отключается в критичных по времени участках.

Анонимусы говорили мне, что RT GC уже существует, но ссылок не давали, а я сам не нашел. Вроде да, уже almost there. Но еще не совсем, и только для JVM. Для Лиспа - нету :)

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

>Нет, у нас языки с GC для реалтайма не используются.
Ага, значит «Пастернака не читал»

Вообще, принцип действия современных GC известен?

Различные лиспы же за время своего существования работали на самых диких встраиваемых системах.
А эффективные компиляторы и рантаймы для них существуют с начала-середины 60х. И RT тоже были; разработанные Symbolics, например.

Love5an
()
Ответ на: Лжешь от anonymous

Нет ты

> Toward this end, Harlequin created a special variant of its LispWorks® system which offers the realtime response necessary to meet AT&T's rigorous needs, even in spite of being a garbage collected system!

Хаченная для одного клиента (неизвестно каким образом) версия не в счет.

Customers whose applications can't even tolerate the speed of a generational GC should talk to LispWorks Ltd about its realtime implementation of Lisp. So far, this has not been packaged as a shrink-wrapped product but we might be able to provide it to you under some sort of consulting arrangement

tailgunner ★★★★★
()

Чего только не придумают люди, чтобы Форт не учить :)

...

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

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

>Различные лиспы же за время своего существования работали на самых диких встраиваемых системах.

Вот именно что работали. Где они сейчас, вместе с Symbolics?

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

> Вообще, принцип действия современных GC известен?

Да, но это не имеет отношения к теме.

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

И что?

А эффективные компиляторы и рантаймы для них существуют с начала-середины 60х.

70-х

И RT тоже были; разработанные Symbolics, например.

Ага, я тоже много легенд слышал.

tailgunner ★★★★★
()

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

Условный переход он везде условный переход. Вызов функции он везде вызов функции. И так далее.

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

Есть такой сайт поиска работы http://www.dice.com/

Java 10153
C# 4965
C++ 4316
Ruby 703
Lisp 16

При этом работы с упоминанием Лиспа идут под заголовком Java. Типа знание Лиспа будет плюсом.
Такое вот гуамно Ваш Лисп.

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

Там же

perl 3310
python 1293
tcl 212
fortran 79

Лисп самый редкий с 16 результатами. Даже Фортран в разы популярнее.

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

>Да, но это не имеет отношения к теме.
И какой же это принцип?

Ага, я тоже много легенд слышал.

70-х

Нет, 60х. Такие были уже для LISP 1.5 и его вариаций.

Ага, я тоже много легенд слышал.

http://en.wikipedia.org/wiki/Symbolics#Contributions_to_computer_science

Более того, вообще:
http://portal.acm.org/citation.cfm?id=802146 1982
http://portal.acm.org/citation.cfm?id=114669.114679 1991, но уже CL
Легенды? Ну, вообще, после того, как рынок около-AI технологий схлопнулся в ходе последней AI Winter, действительно.
Оную, кстати, хочется прямо таки с ядерной войной сравнить - до - были лисп-машины, а после - переизобретают реалтайм на Жабе.

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

> Ну, вообще, после того, как рынок около-АI технологий схлопнулся в ходе последней AI Winter, действительно.

это был заговор плюсофилов и прочих-будущих-жаба-нето-быдлокодеров.

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

Итого с http://www.dice.com/ : 

Java       10153
C#         4965
javascript 4401
C++        4316
perl       3310
pl/sql     2202
VB         2050
python     1293
Ruby       703
cobol      526
tcl        212
fortran    79
delphi     64
Lisp       16
smalltalk  14

Вывод:
Хотите зарабатывать - забудьте слово Лисп. Хотите сидеть на ЛОРе и троллить - изучайте Lisp и Smalltalk.

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

>Известно, что паскаль компилируется в несколько раз быстрее, чем С.

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

http://bellard.org/tcc/

Ух ты! А почему так? Дело в оптимизациях? Интересно было бы глянуть на бенчмарки.

или Vala?

Я так понял, не было ещё релиза 1.0, значит, языка как такового ещё не существует.

Есть какой-нибудь фреймворк, типа .NET, в котором есть JIT, сборщик мусора и мощное API на все случаи жизни

С моей точки зрения, обе технологии - Java и .NET - это удачные лохотроны, точнее - один удачный лохотрон. Цель - выжать побольше денег, заставив клиентов купить более мощное железо. В лиспе всё то же самое было ещё 30 (ну, ладно, 20) лет назад. Плюс к тому - гораздо более высокая способность программы меняться на лету. Т.е., по сравнению с лиспом, если рассматривать его как платформу, а не как язык, Java и .NET - это огромный шаг назад. С теми кто не имеет опыта программирования на лиспе, я этот вопрос обсуждать не стану, а те, кто имеет такой опыт, со мной согласятся.

«GC мешает реалтайму» это выдумки школьников и скубентов с gamedev.ru и подобных ресурсов.

GC мешает не только реалтайму, но и вообще производительности. Подумай, как реализовать eq хеш-таблицы в условиях подвижности любого объекта и ты всё поймёшь. Если не поймёшь - исходники SBCL можешь почитать. Что самое обидное, чем больше у тебя хеш-таблиц, в которые регулярно производится запись, тем медленнее будет работать программа. Т.е., масштабируемость лиспа далеко не идеальна. Кроме того, динамическая типизация тоже мешает производительности. И не надо мне басен, я сам пытался улучшить результаты лиспа на шутауте и понимаю, что на самом деле, быстрота, легко достигаемая на С, на лиспе может быть получена только с большим трудом и большой потерей выразительности. Можешь почитать исходники тамошних задач, сделанные для SBCL. Хотя, если сравнивать лисп с каким-нибудь питоном, то, конечно, лисп быстр.

умеют класть разнообразные лисповские объекты на стек

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

а ты пробовал реализовать хоть что-нибудь из того, что напридумывал?

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

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

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

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

вот написал бы proof-of-concept - было бы на что смотреть и о чём говорить; а так - просто очередная порция еды троллям, ничего более

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

>http://en.wikipedia.org/wiki/Symbolics#Contributions_to_computer_science

Сплошная предвзятость в статье. Разогнанный на нафталине z80 с микрокодом способным обрабатывть только базовые примитивы lisp. Особенно порадовала способность обработки hdtv на ч/б аналоговых мониторах :)

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

Получить пожелание написать proof-of-concept - это уже нормальная цель для прихода сюда :) Кроме того, я уже сразу уточнил задачу, выяснив, что есть, оказывается быстрый tcc. В принципе, С меня устраивает в качестве back-end, тошноту вызывает только его скорость компиляции. Если тут всё на самом деле не так плохо, то я рад.

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

Я на Форте не писал, но книжку по нему в своё время прочитал и понял. А ты лисп знаешь?

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

>Ух ты! А почему так? Дело в оптимизациях? Интересно было бы глянуть на бенчмарки.

А то. Думаешь он генерирует оптимальный код ? Нет. Но генерирует :) И даже нативный компилятор под процессоры отличные от х86 собирается как кросс-компилятор работающий на целевой архитектуре.

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

> Думаешь он генерирует оптимальный код ? Нет. Но генерирует
Наверное, при сравнении производительности этого кода с питоном или байт-кодом java-машины его можно считать оптимальным с большим запасом :) Тогда следующий вопрос, нет ли в gcc каких-нибудь флажков, после которых он начинает работать так же быстро, как tcc?

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

>нет ли в gcc каких-нибудь флажков, после которых он начинает работать так же быстро, как tcc?

Сомневаюсь. Ибо человек являющийся отцом-основателем qemu и ушедший из проекта uclibc не стал бы до сих пор поддерживать свое детище tcc.

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

>> Да, но это не имеет отношения к теме.

И какой же это принцип?

Их несколько. Ты, я подозреваю, имеешь в виду поколения данных.

70-х

Нет, 60х. Такие были уже для LISP 1.5 и его вариаций.

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

http://portal.acm.org/citation.cfm?id=802146 1982

http://portal.acm.org/citation.cfm?id=114669.114679 1991, но уже CL

Это такой способ эпически слить - дать ссылки на закрытые статьи? И, судя по тому, что там упоминается алгоритм Бейкера - это не катит за отмазку.

Замнем. У меня нет желания флеймить на эту тему здесь.

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

>В лиспе всё то же самое было ещё 30 (ну, ладно, 20) лет назад.

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

Скажите, подходит ли лисп для написания прикладного софта?

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

>Я на Форте не писал, но книжку по нему в своё время прочитал и понял. А ты лисп знаешь?

Я на Лиспе не писал, но несколько книжек по нему в своё время прочитал и понял :)

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

> Скажите, подходит ли лисп для написания прикладного софта?
Примеры тому есть. Например, http://www.cormtech.com/ или http://www.ystok.ru/ (в последнем случае можно скачать демо-программы под офтопик).

жабу и дотнет превозосят и даже пишут прикладной софт.

Кока-колу тоже привозносят и даже пьют. И что теперь?

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

>Я думаю, что Форт можно считать строгим подмножеством лиспа.

Равно, как и Лисп - подмножеством Форта. Можно и синтаксис Форта сделать на Лиспе. И синтаксис Лиспа на Форте. Но можно ли транслятор Лиспа запихнуть в 512 байт ПЗУ? ;)

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

Пля, очередной тред в дев. скатывается в лисп vs c++ vs all

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

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

>жабу и дотнет превозосят и даже пишут прикладной софт.

Кока-колу тоже привозносят и даже пьют. И что теперь?


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

Пример:
Мне нравится нечто по имени А.

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

Если А не популярно у других, то я привожу в пример кока-колу и макдональдс и говорю что вот они популярны и что? Это же отрава, хоть и популярна.


Так можно спорить до бесконечности.

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

>традиция, хранимая с...2003, что ли, года. вобщем, ничего удивительного - меняются только ники некоторых участников

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

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