LINUX.ORG.RU

[Лиспофлейм]Реализации common lisp и пакеты


0

0

Вот не пойму.

Вы хотите написать программу, использующую сторонние библиотеки в C, вы пишите

#include <foo.h> // препроцессор вставляет сдесь содержимое foo.h

В пистоне: import foo // Создается неймспейс foo, читается код из foo.py, все переменные/функции запихиваются в этот неймспейс.

В лиспе же вообще нет единой системы. Когда я сидел под дебианом в clisp'е там было что-то типа:

(require 'common-lisp-controller)
(common-lisp-controller:clc-require 'foo)

В sbcl для установки(!!) пакетов (вернее «систем», которые определяются с помощью defsystem) используется asdf-install:

(asdf-install 'foo)
(require 'foo)

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

Почему везде нельзя как в emacs (идеальный вариант):

(setq load-path (append load-path '(#p"/foo/bar" #p"/foo/buz")))
(require 'bar)
(require 'buz)

Или тупо (load «/foo/bar/buz»)?

Вопрос не совсем технический, поэтому в talks

Ответ на: комментарий от naryl

> Нелинейная сложность же достигается C/C++ благодаря хедерам.

и как же тогда tcc умудряется компилировать быстро? :)

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

патамучта гладиолус ^W это си, а не плюсы. Go вон тоже быстро конпелирует, особенно 6g, а не gcc go

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

> патамучта гладиолус ^W это си, а не плюсы

он писал и про С

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

> и как же тогда tcc умудряется компилировать быстро? :)

Сравнение с dmd на аналогичных проектах с парой десятков (можно больше) файлов в студию. На одном файле с двумя строчками tcc быстрее. :)

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

Сравнение с dmd на аналогичных проектах с парой десятков (можно больше) файлов в студию. На одном файле с двумя строчками tcc быстрее. :)

ты ж доказываешь, что компиляция в С медленная - ты и приводи сравнение, а насчет «На одном файле с двумя строчками tcc быстрее» - я еще раз тебе скопипастю:

Compiler   Time(s)   lines/second   MBytes/second 
TinyCC 0.9.22    2.27    859000    29.6 
 
Measures were done on a 2.4 GHz Pentium 4. Real time is measured. Compilation time includes compilation, assembly and linking.  

это компиляция links - не один файл, и не две строчки

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

> В случае с C++ тормозят и g++ и ld.

тоже мне новость. ld не gold? пачиму? ld просто по определению тормозит на плюсах, почитай блог автора gold

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

п%ц - можно подумать это я к нему пристал и доказываю, что компиляторы на С тормозные :)

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

«xfBuild has been tested on projects with 300+ modules and achieves build times of around 2–3 seconds when just a few modules need to be recompiled therein (on a 1.7GHz Intel Centrino CPU with DMD-Win).»

Сейчас проверю на DWT.

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

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

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

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

Сейчас проверю на DWT.

naryl ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.