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

Куда? На balancer@balancer.ru и balancer73 на гмыле не получал.

На balancer@balancer.ru со своего гмыла.

Не просто оскорбления, а оскорбления невежественных дебилов, которые этого заслуживают.
Кстати, в отличие от тебя, на скор не дрочу, утрись.

Ясно. Оно в спам упало. Ответил.

>> Короче, как ты будешь сохранять объекты в БД?

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

эээ... я не ожидал такого

это ж не масштабируемо — придется иметь всего один сервер

а если бы объекты сохранялись в БД сразу же, можно было бы подключить несколько серверов

хотя в принципе тоже вариант...

>это ж не масштабируемо — придется иметь всего один сервер

Угу, L2Fortress не был масштабируемым.

а если бы объекты сохранялись в БД сразу же, можно было бы подключить несколько серверов

Так можно и сразу. Просто в ряде случаев при очень частой модификации это убивает SQL-сервер. А при хранении объектов в памяти их сбрасывать можно в сотни, если не тысячи раз реже.

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

Scala это недоязычок, в котором нет абсолютно НИЧЕГО нового и интересного, по сравнению с существующими языками, кроме небольшого синтаксического сахара над байткодом jvm(кстати, гыгы, для этого недоязычка среди всех его любителей не нашлось даже способных написать компилятор в нейтив).

И если бы ты знал больше 2(условно) языков программирования, ты бы со мной согласился.

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

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

> среди всех его любителей не нашлось даже способных написать компилятор в нейтив

Excelsior JET

Эх, если бы компиляторы и правду были библиотеками... Что-то я замечтался :) (разве что LLVM).

Эх, если бы компиляторы и правду были библиотеками

Ты тоже не видишь плюсов от реализации скалы поверх jvm?

Excelsior JET

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

> в котором нет абсолютно НИЧЕГО нового и интересного, по сравнению с существующими языками, кроме небольшого синтаксического сахара над байткодом jvm

система_типов_времени_компиляции != синтаксический_сахар

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

Ты тоже не видишь плюсов от реализации скалы поверх jvm?

(С)++-сов я тут определённо не вижу :)

система_типов_времени_компиляции != синтаксический_сахар

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

Не, не будет проблем.

«Нет ничего нового». Потрясающая аргументация. Грувисты в начале топика и то убедительнее ругались.

> Не, не будет проблем.

Ну раскажи, как это сделать в лиспе (только без простынок кода).

С учетом того, что библиотеки писались без типизации.

Для начала расскажи как сделать целую глобальную переменную БЕЗ тайптега. (да, это относится к типизации)

Потом расскажи, как реализовать в лиспе вариант CLOS, аналогичный С++ — т.е. чтобы там невозможно было поменять на ходу слоты-методы объекта, и при этом он работал быстро, не теряя времени на wrapper, обычный в таких случаях.

При этом, новый CLOS должен быть интероперабельным со старым.

Ну раскажи, как это сделать в лиспе (только без простынок кода).

Если ты хочешь начать, то давай сначала условимся - изначально Lisp-семейство это семейство динамических языков. Поэтому если там что-то возможно, то это не значит, что оно повсеместно используется.

Common Lisp идёт немного далее, это строго типизированный динамически по умолчанию язык. В стандарте определена статическая по выбору типизация, но определена не полно. Никаких гарантий со стороны стандарта.

Ладно, далее берём реализации (CMUCL, SBCL, ClozureCL, LispWorks, думаю достаточный список) - они гарантируют то что не доделано в стандарте - статическая типизация по выбору железная.

Теперь возьмём конкретно CMUCL/SBCL: там имеется свой type inference.

Ну и последнее - ничего вроде HM нигде нет. Это конечно проблема, но никто не мешает ещё раз «пойти дальше». Если это кому-то будет очень нужно - это сделают.

С учетом того, что библиотеки писались без типизации.

Это смотря какие.

Для начала расскажи как сделать целую глобальную переменную БЕЗ тайптега.

(variable 5)

Ок?

блин,

(variable *var* 5) 

Потом расскажи, как реализовать в лиспе вариант CLOS, аналогичный С++ — т.е. чтобы там невозможно было поменять на ходу слоты-методы объекта, и при этом он работал быстро, не теряя времени на wrapper, обычный в таких случаях.

Если ты начнёшь называть «лисп» CL-ем? Подробнее пожалуйста условие:

чтобы там невозможно было поменять на ходу слоты-методы

Что такое «слоты-методы», класс содержит «поля» (они называются слоты), т.е. данные. Методы пишутся отдельно - есть общие generic методы и конкретные для класса (диспетчеризирующие) методы. Что нужно, чтобы слоты были read-only или чтобы метод нельзя было переопределить?

> Ну и последнее - ничего вроде HM нигде нет. Это конечно проблема, но никто не мешает ещё раз «пойти дальше». Если это кому-то будет очень нужно - это сделают.

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

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

Зависит от людей.

> Никаких гарантий со стороны стандарта.

Тогда вопрос, а на кой такой стандарт, который ничего не гарантирует? Вернее, что он даёт, газификацию луж?

P.S.: понятно было, если это было бы рекомендация, тогда, никакой гарантии нет, что она будет соблюдаться, а раз стандарт, то надо придерживаться стандарта.

целую глобальную переменную БЕЗ тайптега

Хотя нет, я бы даже сказал, что также как и обычную, но указав в начале что мы юзаем уыод типоу:

(in-package #:cl-typed)

(defvar *a* 5)

(setf *a* 'a)
;; Эй, чувак, оппортунисты негодуэ!

Тезис ананимуса о костыльности отклоняется - всё зависит от того как будет сделано - сделают как костыль... Ну тогда будет костыль :)

Если ты спросишь - могу я это сделать, то «да», но ты просил без портянок.

> Ну и последнее - ничего вроде HM нигде нет. Это конечно проблема, но никто не мешает ещё раз «пойти дальше». Если это кому-то будет очень нужно - это сделают.

И я должен *этому* верить?

Я просил детали предполагаемой реализации системы типов без abstraction penalty, которые, с моей точки зрения, законфликтуют со стандартом и практикой использования лиспа.

Хрен с с++. Раз тут речь идет о JVM, то система типов должна позволять делать JVM-овские классы с JVM-оскими же накладными расходами.

(variable 5) Ок?

И оно будет небоксованное и 32 битное? не верю. сходи глянь дискуссию

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

Ананимус обобщает и рубит с плеча?

Стандарт определяет протокол (declaim, declare, proclaim) по которому можно информировать компилятор (т.е. серьёзную реализацию :)) о куче вещей - типах, времени жизни объектов, inline для функций и т.д. Всё это есть не предусмотрены лишь детали поведения реализации - т.е. реация реализации на эти «советы». Почему? Ну ведь есть ещё интерпретаторы - им эти совету что об стенку горохам. Но все уважаемые компиляторы очень хорошо обрабатывают эти декларации:

Python brings strong typing to Common Lisp (Python это так называется компилятор CMUCL/SBCL).

> Что нужно, чтобы слоты были read-only или чтобы метод нельзя было переопределить?

нужно, чтобы номенклатура слотов была фиксированная или расширяемая как в яве, но не изменяемая — то есть запретить redefinition of an existing class и в результате поиметь профит — убрать одну лишнуюю (или даже 2 лишние) индирекцию на http://cl-cookbook.sourceforge.net/clos-tutorial/images/fig-4.gif

> Python brings strong typing to Common Lisp (Python это так называется компилятор CMUCL/SBCL).

Нам бы не strong, а static :)

Я просил детали предполагаемой реализации системы типов без abstraction penalty, которые, с моей точки зрения, законфликтуют со стандартом и практикой использования лиспа.

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

Хрен с с++. Раз тут речь идет о JVM, то система типов должна позволять делать JVM-овские классы с JVM-оскими же накладными расходами.

Да, кстати. Лиспер опять зашёл не в тот трэд :)

И оно будет небоксованное и 32 битное?

Значит:

(variable *a* 5)

Оно будет боксированное 29 битное на SBCL. А что?

Нам бы не strong, а static :)

И этого тоже есть у нас вам :)

> Если ты спросишь - могу я это сделать, то «да», но ты просил без портянок.

я спросил «как» ты это сделаешь; для описания пути/способа/идеи реализации простыни кода не нужны и даже вредны

> Оно будет боксированное 29 битное на SBCL. А что?

я просил НЕбоксированное ( == БЕЗ тайптега )

> Какие именно детали конкретно?

Какие именно детали законфликтуют — выяснится после того, как ты предложишь свой вариант с этими самыми деталями :-)

У тебя неограниченное множество попыток.

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

нужно, чтобы номенклатура слотов была фиксированная или расширяемая как в яве, но не изменяемая — то есть запретить redefinition of an existing class и в результате поиметь профит — убрать одну лишнуюю (или даже 2 лишние) индирекцию на http://cl-cookbook.sourceforge.net/clos-tutorial/images/fig-4.gif

Я ничего не могу сказать про, например, ABCL (CL на JVM), и я не знаю зачем это нужно. Профита не получится получить, потому что есть ещё много вещей (вроде MOP), чтобы получить простенькую ОО систему вроде JVM-овской (sic!) нужно кастрировать CLOS :) ну и может будет какой профит, да.

Насчёт реализации сабжа - ну так легко :) Есть такая штука - любые горячие переопределения вообще (не только классов но и чего угодно) обрабатываются в SBCL с помощью style-warning, т.е. нужно:

1) определить опцию :sb-horrible которую можно установит при сборке SBCL.

2) грепать все style-warning обработки и писать туда

(#!+sb-horrible horroble-error #!-sb-horrible style-warning ...)

вот и всё. Но не нужно.

> Какие именно детали конкретно [законфликтуют] ?

в то же время, реализация динамических фенечек типа боксованных значений, классов с возможностью redefinition of an existing class и т.д. в системе с хорошей типизацией очень просто — т.к. это ОСЛАБЛЕНИЕ типовой диспилины (а в CL это будет усиление и трудно)

что реально мешает это *бесшовно* интегрировать в языки — так это отсутствие... ну назовем это синтаксическим сахаром, хотя оно немного шире

я просил НЕбоксированное ( == БЕЗ тайптега )

Ясно, я думал тайптег это:

(defvar *a* 5 :type fixnum)

Тоже называется «тэгирование типами». Ну а то что в SBCL числа боксированные - это его проблемы, как open source изделия. Так и будет, пока кто-нибудь не придёт и не починит, о чём тут спорить.

> нужно кастрировать CLOS :)

Да, система типов предполагает именно это :-)

определить опцию :sb-horrible которую можно установит при сборке SBCL.

не-не-не

я просил интероперабольность со старой CLOS, т.е. как минимум она не должна быть умершей при сборке SBCL

> вот и всё. Но не нужно.

нужно или нет — это не относится к теме разговора

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

Какие именно детали законфликтуют — выяснится после того, как ты предложишь свой вариант с этими самыми деталями :-)

[супер-крутой-язык-с-типами] -> [супер-крутая-система-выводов-типов] -> [plain-CL]

Знаешь, вся верхушка SBCL это функции (ну просто «программирование», определение стандартных функций для разных АТД), и макросы (и их вспомогательные функции) котрые код транслируют. Ниже source-transformators и ir1/ir2 трансляторы завязанные на Python и VM-$ARCH. Это к тому что -> [супер-крутая-система-выводов-типов] -> делается «на макросах». Люди разную ленивость и бесконечные последовательности в виде библиотек делали, тут тоже нет никаких проблем (ага :)).

* несмотря на все лисповские возможности сделать синтаксически сладко

> [супер-крутой-язык-с-типами] -> [супер-крутая-система-выводов-типов] -> [plain-CL]

Последняя стрелка — это выхлоп лисповского кода и скармливание его допустим SBCL?

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

Люди разную ленивость и бесконечные последовательности в виде библиотек делали, тут тоже нет никаких проблем (ага :)).

меня (в этой ветке) не интересуют проблемы, решаемые синтаксическим сахаром

я просил интероперабольность со старой CLOS, т.е. как минимум она не должна быть умершей при сборке SBCL

Ну так что нужно? Делаем «ай-ай-ай» действие - какая реакция CLOS? Сейчасв SBCL делает ворнинг, можно собрать чтобы была ошибка без рестарта. Можно сделать параметр, чтобы не нужно было пересобирать SBCL - ставим параметр в False будут реакции в виде «опасностэ», ставим в True - будут сыпаться «ошибки». Если сейчас пойти и посмотрет, то возможно, что есть способ хакнуть это прямо в живую.

Последняя стрелка — это выхлоп лисповского кода и скармливание его допустим SBCL?

Если на макросах, то это будет очередной выхлоп очередного (подмножества) CL-кода, на очередной стадии macroexpand.

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

Я уже написал, что это к теме не относится и должно решаться sbcl hackers.

К слову о подмножествах - CL это около 25 примитивных форм, всё остальное - это макросы, макросы-макросов, ... И определения функций.

> Ну а то что в SBCL числа боксированные - это его проблемы, как open source изделия. Так и будет, пока кто-нибудь не придёт и не починит, о чём тут спорить.

А в каком CL они не боксированные? Годятся платные.

Да и вообще — глобальную переменную может читать/писать лисповый модуль, который не знает о нашей типизации. Как он узнает, какого она типа? Есть ли в CL *старндартные* способы сказать «не пытайся тут найти тайптег из 3 бит, здесь целое число» для *глобальной* переменной?

> Я уже написал, что это к теме не относится

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

и должно решаться sbcl hackers.

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

> Можно сделать параметр, чтобы не нужно было пересобирать SBCL - ставим параметр в False будут реакции в виде «опасностэ», ставим в True - будут сыпаться «ошибки».

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

Я же говорю - статическая типизация «рекомендуется» (для компиляторов) стандартом - есть fixnum, что-то вроде сишного int. То что у SBCL заморочки с fixnum, это его проблемы (решаемые) и к реализации типизации аля ML это не относится.

Вот чисто стандартный код:

(deftype int32 () '(signed-byte 32)) ;; library? `alexandria'.

(declaim (type int32 *my-int*))
(defvar *my-int* 256)

(type-of *my-int*)

(setf *my-int* -1)

(setf *my-int* -6534645675475676575475757745)
;; The value 6534645675475676575475757745
;; is not of type
;;  (SIGNED-BYTE 32).
;;   [Condition of type TYPE-ERROR]