JVM-based языки. Кто умеет такой синтаксис?

а точнее, использование хакнутого SBCL означат использование ИНОГО языка программирования, чем CL

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

> То что у SBCL заморочки с fixnum, это его проблемы (решаемые)

я уже 3-й раз спрашиваю название реализации, где они решены

Относится. Напрямую. Никому не нужна говносистема типов, имеющая abstraction penalty динамического (говно)языка.

Не, система типов это тру-матан. Фишка из wish-list SBCL это совсем другое.

В таком случае предъяви пункт стандарта CL, который sbcl hackers нарушили или не реализовали в своей реализации.

Стандарт делали в конце 80-ых, ну и не учли, блин, не наняли провидца - какие в 90-ых intel наклепает прцессоры :)

Меня не интересуют хаки SBCL, меня интересует путь по стандарту CL.

Я не знаток стандарта - я не знаю есть там что-то про horrible поведение. Там нет даже сокетов, так что врядли. То что в рамках SBCL такое расширение проделывается легко - это правда. К примеру, ничго что у GHC столько своих расширений, и ничего ведь.

> (declaim (type int32 *my-int*))

(defvar *my-int* 256)

по-прежнему не верю, что это 1. лежит в 4-х байтах

2. нет *никаких* байтов в памяти, обозначающих тип этих 4-х байт и проверяемых при каждом чтении-записи этой переменной

не 100% но можно это проверить, прогнав мой тест (см. ссылку, что я раньше постил)

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

Э... Я же сейчас привёл пример кода и написал - он стандартный. Что ещё надо? CL-с-выводом-типов-это по прежнему CL, так как в стандарте достаточно возможностей по статической типизации.

я уже 3-й раз спрашиваю название реализации, где они решены

Clozure CL.

не 100% но можно это проверить, прогнав мой тест (см. ссылку, что я раньше постил)

какой именно? этот - http://www.linux.org.ru/forum/development/3856841

или http://www.linux.org.ru/jump-message.jsp?msgid=4254952&cid=4256013 при чём тут try/catch?

Ты хочешь чтобы CL компилировался в лапшу навроде C? Это никак не получится.

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

Тем не менее - давай тест который проверяет лежит/не лежит переменная в 4 байтах?

> Не, система типов это тру-матан.

теоретически «CLOS с дополнительным верификатором кода в момент Х» можно назвать лиспом с типизацией, но практически никому он не нужет, если он будет тормозить как обычный CLOS, в то время как ява бегает

ну даже пусть тебе нужен

тогда встает вопрос о моменте Х

в яве, с++ и т.д. я бы сказал Х=«компиляции»

а что будет у CL?

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

это весьма распостраненное заблуждение неосиляторов с++

> Тем не менее - давай тест который проверяет лежит/не лежит переменная в 4 байтах?

Кстати да.

Это должен быть некий тест, где в цикле целая глобальная переменная довольно просто модифицируется (типа i*=5 или i=i+i<<2), пока не дойдет до 1 снова; но надо чтобы она была глобальной.

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

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

> Тем не менее - давай тест который проверяет лежит/не лежит переменная в 4 байтах?

и важны не столько байты, сколько скорость — т.е. п.2:

2. нет *никаких* байтов в памяти, обозначающих тип этих 4-х байт и проверяемых при каждом чтении-записи этой переменной

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

теоретически «CLOS с дополнительным верификатором кода в момент Х» можно назвать лиспом с типизацией, но практически никому он не нужет, если он будет тормозить как обычный CLOS, в то время как ява бегает

А, ты не понял - вывод типов, статическая типизация - не имеют отношения к CLOS. Вопрос про hardened CLOS это отдельный вопрос (я думаю мы его решили - но только для SBCL).

тогда встает вопрос о моменте Х
в яве, с++ и т.д. я бы сказал Х=«компиляции»
а что будет у CL?

Ранняя стадия в compile-time известная как macro-expansion.

это весьма распостраненное заблуждение неосиляторов с++

Да вроде осиливал как-то :) Ну это хорошо когда всё в шоколаде - и крутая система типов и компиляция в лапшу. Но исходя из текущих реалий рантайм SBCL это рантайм чуть получше чем у OCaml (не считая способности OCaml компилить компактный код), получше чем Erlang (не считая киллер-фич последней в параллельности) и хуже чем у Java, GHC, C, C++.

чтобы с++ не вышел вперед лиспа из-за лучшего оптимизатора

Он уже десять раз вышел вперёд на шутауте, если ты об этом. Хотя код на CL там и написан с типами.

Хотя, иногда получается написать код на CL который работает just like in C :)

Вот тест со всеми гарантиями, но только для кишков SBCL:

(in-package #:sb-vm)

(deftype uint32 () '(unsigned-byte 32))

(defknown my-test-for-reg (uint32 uint32) uint32)

(define-vop (my-test-for-reg)
  (:translate my-test-for-reg)
  (:policy :fast-safe)
  (:args (x :scs (unsigned-reg) :target res)
         (y :scs (unsigned-reg) :target res))
  (:results (res :scs (unsigned-reg)))
  (:arg-types unsigned-num unsigned-num)
  (:result-types unsigned-num)
  (:generator 1
    (move res x)
    (inst add res y)))

(declaim (ftype (function (uint32 uint32) uint32) my-test-for-reg))
(defun my-test-for-reg (x y)
  (declare (type uint32 x y))
  (my-test-for-reg x y))

(my-test-for-reg (- (expt 2 32) 1) 256)
=> 255

(disassemble #'my-test-for-reg)
;...
;      3FE:       01D9             ADD ECX, EBX
;      400:       F7C1000000E0     TEST ECX, 3758096384
;...

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

Хотя это конечно ерунда, выстрелили себе в ногу путём

  mov %ecx, 2 ^ 32 - 1
  add %ecx, 256

  => 255

Но если я, скажем, по стандарту типизируются a :: uint8, то если в цикле начну инкрементировать a, то при a > 2 ^ 8 - 1 будет ошибка типизации а не сброс на 0. А вот регистры - как в примере выше - отличаются таким поведением. Т.е. я ещё скажу, что можно сделать DSL для «переменных» которые ведут себя как числа по модулю 2 ^ (n * 8), как регистры короче.

Т.е. я ещё скажу, что можно сделать DSL для «переменных» которые ведут себя как числа по модулю 2 ^ (n * 8), как регистры короче.

Т.е потому что они и есть регистры.

hash = ['item1', 'item2' => 'subst1', 1234];

А Ruby такой синтаксис понимает? Может тогда это http://www.linux.org.ru/news/java/5359488