Недостатки Racket

А сам racket со всеми своими либами - на typed racket? Весь-весь? Хера толку от проверок в МОЁМ коде, если все «системные» либы - динамические?

Typed Racket при экспанде заменяет safe-функции на unsafe. В динамических либах они, скорее всего, и так unsafe везде, где это важно.

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

И, да, читабельность и понятность решения для меня важнее его производительности.

недостаток сахара в коде^W организме? :)

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

Но вот втирать, что ваша пуля - серебряная, не стоит... ;)

недостаток сахара

При чем тут недостаток сахара? Ты где там сахар нашел в решении для racket? Вон привели же код для SBCL который то же что и racket делает - примерно то же самое по размеру. Только ПАДАЕТ.

Но вот втирать, что ваша пуля - серебряная

Я не втираю никому про серебрянную пуля, я отвечаю по конкретным тезисам. Тут сказали ложь что-де SBCL быстре Racket я и ответил, что, во-первых, часть решений делает просто разные вещи, а потому их сравнивать нельзя, и, во-вторых, сравнивается неидеоматический код.

Вот взять обычный код и racket и sbcl, без анальных оптимизаций, генераций вопов, обкладывания декларациями типов/unsafe операций что там что там. И это сравниваем. Вот в этом я вижу смысл.

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

Какой именно части? Я понимаю, что времени прошло ещё совсем мало, но только после того, как всю библиотеку переведут на typed racket, а untyped её верся будет лишь «враппером» typed версии - соглашусь, что в racket появилась типизация :Ь

Вот в этом я вижу смысл.

тогда ещё выкинуть нафиг загрузку и инициализацию рантайма и оперировать исключительно производительностью конкретного кода. При этом код sbcl «оптимизировать» по скорости в ущерб отладке и безопасности :)

Какой именно части?

Ну я так полагаю все что в (require racket) входит переведено.

Так это как раз то что делает шутаут.

а untyped её верся будет лишь «враппером» typed версии

Не будет, там на данный момент принципиальные трудности с трансформацией type->untyped.

Ну я так полагаю все что в (require racket) входит переведено.

А я вот не уверен :)

Так это как раз то что делает шутаут.

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

Не будет, там на данный момент принципиальные трудности с трансформацией type->untyped.

Да фиг с ними - пусть хоть пишут по две версии каждой либы. Но все либы (и core!) должны быть в typed версии.

При нативной же реализации код остается как был

(define f1 (lambda (f2 x y z)
  (f2 x)))

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

Вообще-то там только ASCII

Это не значит, что строки автоматически становятся base-string.

Мне это неинтересно, мне интересна производительность РЕАЛЬНОГО кода.

Кроме воплей, ты вообще не утруждаешь ся доказательствами. Рэкет медленнее - это ОЧЕВИДНО ЖЕ.

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

Нет не передаем. Передаем только в случае cps (ну как в sbcl) а при нативной реализации ничего никуда не передается.

Он делает то, о чем ты говорил в предыдущем посте. А ту фигню что ты описал сейчас - конечно не делает.

core вообще на сишке, о чем ты?

Так можно увидеть решение на CL для ANSI которое не будет падать?

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

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

Рэкет медленнее - это ОЧЕВИДНО ЖЕ.

Мне очевидно обратное. В raket делается (и можно делать) множество оптимизаций, которые принципиально невозможны в семантике CL. По-этому потенциально racket быстрее на порядок. Сейчас racket быстрее SBCL лишь немного, т.к. никто особо не занимается оптимизацией.

Он делает то, о чем ты говорил в предыдущем посте.

КАК шутаут сейчас _не_ учитывает загрузку рантайма? Я не вижу

вымогательство медленнее SBCL. Точка.

core вообще на сишке, о чем ты?

Сишка мешает ядру быть типизированным или нет? Так ядро typed или untyped?

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

Так с твоих слов

В raket делается (и можно делать) множество оптимизаций, которые принципиально невозможны в семантике CL. По-этому потенциально racket быстрее на порядок.

Перепиши тесты racket на шутауте так, чтобы racket обогнал sbcl на порядок используя множество оптимизаций - утри нам нос!

А до тех пор уткнись, а то скулёж и отрицание доступной информации наводит на печальные мысли по поводу твоего душевного состояния.

Передаем только в случае cps (ну как в sbcl) а при нативной реализации ничего никуда не передается.

(define (test f)
   (let ((i 0))
     (f)
     (set! i (+ i 1))
     i))

По твоему утверждению в функцию f ничего не передаётся. Теперь делаем так:

(define the-continuation #f)
(define (fun) (call/cc (lambda (k) (set! the-continuation k))))
(test fun)
(the-continuation) -> 2
(the-continuation) -> 3

Обрати внимание, в функции call/cc внутри fun внезапно оказался доступ к переменной i из test и к куску кода после вызова f. Откуда?

Более того, в лиспе при компиляции скорее всего переменная i была бы вообще удалена и test соптимизирован в что-то вроде

(define (test f)
  (f)
  1)

Перепиши тесты racket на шутауте так, чтобы racket обогнал sbcl на порядок используя множество оптимизаций - утри нам нос!

Слово «потенциально» ты не увидел, да?

Перепиши тесты racket на шутауте так, чтобы racket обогнал sbcl на порядок используя множество оптимизаций - утри нам нос!

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

Racket - НЕ схемка. Как следствие, весь остаток поста становится бессмысленными.

http://ru.wikipedia.org/wiki/Причастие_(лингвистика)

Это ты к чему, бедняша?

И Аллах пророк его. Аминь.

И Аллах пророк его. Аминь.

По твоему утверждению в функцию f ничего не передаётся.

Именно.

Обрати внимание, в функции call/cc внутри fun внезапно оказался доступ к переменной i

Где?

Откуда?

call/cc захватывает стектрейс в точке вызова.

К тому, что ты тупой мудила.

А ты - безграмотное быдло.

Где?

(the-continuation) возвращает текущее значение переменной i и увеличивает её на единицу. (define the-continuation ..) производится в функции fun, куда i не передавалась.

call/cc захватывает стектрейс

Значит этот стектрейс приходится передавать в функцию f (а в лиспе в f можно передавать только параметры функции + захваченные лексические переменные). И нельзя оптимизировать вычисления вокруг вызова любой функции (а вдруг она захочет захватить продолжение?). Всё равно, что в C-шной программе все переменные объявлять с volatile.

(the-continuation) возвращает текущее значение переменной i и увеличивает её на единицу.

Да. Но доступа к i там нет.

Значит этот стектрейс приходится передавать в функцию f

Нам нужно ровно две вещи - значение регистра SP и IP. По-этому передавать ничего никуда не надо, все что нам нужно и так всегда лежит в регистрах.

При вызове call/cc условно происходит следующее - берется куда-то копируется стек начиная с текущего значения SP, туда добавляется значение IP и эта структура является продолжением. При вызове продолжения восстанавливается стек и смещается IP. Что здесь по-твоему надо передавать?

И нельзя оптимизировать вычисления вокруг вызова любой функции

Какие именно вычисления и как именно нельзя оптимизировать? Если на переменную не делается set! в текущем скопе, то эта переменная константа, а значит все оптимизации можно делать.

Если на переменную не делается set! в текущем скопе, то эта переменная константа, а значит все оптимизации можно делать.

Ну вот. А в лиспе можно выполнять заранее всё, что не зависит от внешних функций. Ну и порядок вычислений более произвольно менять можно. Хотя, согласен, практически на производительности это сказываться не должно.

Тут надо отметить, что в схемоподобных диалектах set! использовать избегают и реально _очень_ редко применяют. Так что и проблем таких нет.

Тут надо отметить, что в схемоподобных диалектах set! использовать избегают и реально _очень_ редко применяют. Так что и проблем таких нет.

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

Те, кому «тяжело привыкнуть» к чему бы то ни было, программировать вообще противопоказано. Слабые интеллектом должны улицы подметать, а не программировать.

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