Ищутся статически типизированные контейнеры для Common Lisp

Лол :-) Зачем тебе нужен Лисп? :-) Сама природа Лиспа предполагает динамическую типизацию :-) А против природы не попрёшь :-) Если тебе нужен map<T, U>, учи цепепе-17 :-)

Если тебе нужен map<T, U>, учи цепепе-17

А если мне нужен map<K, V> что учить?

А если мне нужен map<K, V> что учить?

Знаки препинания учи :-) Лол :-)

Давно ":-)" стало знаком препинания?

Вообще, это напоминает классику жанра «хочу программировать на Foo как на Bar» :-) Уже был один такой :-) Хотел программировать на Си как на Симуле :-) В итоге, появился цепепе :-) И понеслось :-) Лол :-)

Уже был один такой

Он ещё жив.

Анонимусы захватили эту тему :(

По-моему, только прикручивать что-то вроде https://github.com/mmontone/cl-gradual

Map<T1,T2> в терминах лиспа — это hashtable. Как ты себе представляешь тип аксессора gethash при существовании типизированного хэша?

Для Racket имеем

> hash-ref
- : (All (a b c)
      (case->
       (-> (HashTable a b) a b)
       (-> (HashTable a b) a False (U False b))
       (-> (HashTable a b) a (-> c) (U b c)))
> hash-set!
- : (All (a b) (-> (HashTable a b) a b Void))

P.S. Можно на базе CL сделать некий Typed CL, но объём работы очень солидный.

https://github.com/mmontone/cl-gradual

Status: THIS IS VAPORWARE AND I DON'T KNOW WHAT I'M DOING.

Отличное признание автора :-) Лол :-)

Не typed CL, а typed Яр :) Солидный, да. Я пока пытаюсь его осознать и спроектировать, как должно быть в итоге. А сделать можно и потом. Типизированный хеш будет обёрткой над обычным, просто, если переменная H имеет тип hash<К,V> для некотоых типов К и V, то компилятор сможет убрать проверку из рантайма в форме (the V (gethash Мy-key H))

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

Над написанным тобой примером сигнатур попробую потом помедитировать.

Сейчас я со смайликом согласен. Прелесть лиспа в его динамической природе, которую довели до совершенства. Но недостатки - это продолжение достоинств. Там, где нужна статика, лисп не подходит.

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

Возьми вон rust или haskell. У них, можно сказать, IDE нет совсем (хотя у rust может появиться), но все равно у них есть очень стойкие поклонники. Думаю, это связано с тем, что авторам этих языков было что сказать новое миру. И это зацепило людей.

Кстати, c++, java и c# тоже взлетели не из-за IDE. Для своего времени они были очень привлекательны именно как языки и платформы. А потом уже подоспели IDE, хотя я когда-то использовал совсем немного симантевскую IDE для jdk 1.0.1, предпочитая, правда, простой обычный Far, но поверь, дело было не только в IDE. Сначала деньги, а потом стулья. Сначала должен быть посыл, должно что-то цеплять, а потом и IDE, и все остальное

Не typed CL, а typed Яр :) Солидный, да.

Тогда не мучай SBCL, а делай типизация на уровне Яра.

компилятор сможет убрать проверку из рантайма в форме (the V (gethash Мy-key H))

Вот именно. Для этого у gethash должен быть тип, который показывает, что для любого типа вида Map<K, V> вернётся тип V. Полиморфных типов в CL нет. Максимум, параметрические.

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

В 1С нету :-)

У них, можно сказать, IDE нет совсем

leksah очень симпатичен.

Кстати, c++, java и c# тоже взлетели не из-за IDE.

С++ — да. А java без IDE пользоваться практически невозможно. Всё равно, что писать HTML в текстовом редакторе.

Каждый язык заточен под какой-то тип использования. Lisp, PERL и Python не требуют IDE. Java и 1С без IDE жутко неудобны.

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

С этим согласен полностью. Идею Яра я тоже не понимаю. Изначально вроде был CL с паскалевским синтаксисом. Хорошо: аналог honu для CL.

Затем добавилась строгая типизация и убрались макросы. Это уже понятно меньше. Для CL макросы основной плюс. Если в Яре ещё и не будет динамических (в смысле, special) переменных, то получим паскаль со сборщиком мусора.

Не заметил, чтобы leksah сильно использовали. К примеру, связка haskell-mode в emacs + браузер для справки + cabal / stack покрывают самое необходимое для меня

С++ — да. А java без IDE пользоваться практически невозможно. Всё равно, что писать HTML в текстовом редакторе.

Это сейчас превратили в макаронного энтерпрайзного монстра, а когда-то я проекты собирал через javac. Не помню уже, там был make или нет. То же справедливо и для ранних версий c#, только csc и nmake, соответственно

Это сейчас превратили в макаронного энтерпрайзного монстра, а когда-то я проекты собирал через javac.

Да собирать-то можно было. Я тоже утилиту для выдёргивания данных на Linux из MSSQL в Vim'е писал. Но изначальные рекомендации правильного использования с классами на каждый чих без IDE практически неуправляемы. То есть вопрос стиля. Конечно, настоящий программист напишет программу на fortran на любом языке программирования, но тогда зачем вообще java? А с IDE java и с# позволяют планировать сроки разработки с точностью в 30%, а не в 1000% как на C++.

Не заметил, чтобы leksah сильно использовали. К примеру, связка haskell-mode в emacs...

leksah — 697 звёзд на github, haskell-mode — 839. Сравнимо. К слову, а чем haskell-mode не IDE? По мне, так не хуже, чем CEDET, например.

IDE - это IntelliJ IDEA. Поиск использования, просто поиск, отладчик, все такое.

Но как я уже писал выше (да, уважаю диалектику) достоинства - это продолжение недостатков. Это просто здорово, что haskell-mode не IDE. Пусть таким оно и остается. Не нужны эти раздражающие индексирования, долбанные автокомплиты и тому подобное. Не надо этого!

Но как я уже писал выше (да, уважаю диалектику) достоинства - это продолжение недостатков.

Это не диалектика. То что ты пытаешься сказать — всего лишь то, что недостаток оборачивается достоинством и наоборот, в зависимости от применения(как, например, легкий вес в боксе компенсирует отсутствие хорошего удара подвижностью). Диалектика — это развитие из противоречия: тезис-антитезис-синтез

Не нужны эти раздражающие индексирования, долбанные автокомплиты и тому подобное. Не надо этого!

Так оно там есть: http://haskell.github.io/haskell-mode/manual/latest/Completion-support.html#C...

IDE - это IntelliJ IDEA.

Turbo C — тоже IDE

А с IDE java и с# позволяют планировать сроки разработки с точностью в 30%, а не в 1000% как на C++.

Для цепепе это 10000% :-) Лол :-)

Офигенное заявление «Gradual typing is a type system I developed with Walid Taha in 2006 that allows parts of a program to be dynamically typed and other parts to be statically typed.»

SBCL/CMU тоже это умеет, с какого года? С 1990-го или раньше?

Как ты себе представляешь тип аксессора gethash при существовании типизированного хэша?

Для ридера как-то так:

(deftype type-of-gethash-reader (key-type value-type)
  `(function (,key-type 
               (typed-hash ,key-type ,value-type) 
               &optional ,key-type)
      (values (or null ,value-type) boolean &optional)))

Возьми вон rust или haskell. У них, можно сказать, IDE нет совсем (хотя у rust может появиться), но все равно у них есть очень стойкие поклонники.

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

У меня анонимусы в игноре, поэтому я не обязательно знаю, о чём вещает смайлик :-) Лол

Там, где нужна статика, лисп не подходит.

Я считаю, что это неправда и это офф :-)

Идею Яра я тоже не понимаю

Опциональная статическая типизация предполагалась изначально, потому что она уже есть в CL. Просто я остановился на С++ той поры, когда в нём только появились шаблоны и на Delphi 7, а с тех пор много воды утекло. Оказывается, что система типов CL несколько отстала от жизни. Например, отсутствие типизированных контейнеров выглядит для меня неприемлемым, а отсюда возникают параметрические типы. Это вызвало процесс раздувания ТЗ, который мне не нравится, но остановить его я не могу.

убрались макросы

Макросы ортогональны остальному языку. Пока что я не настолько хорошо понимаю прогресс в макросах, достигнутый со времён CL, чтобы написать хорошее ТЗ. А раз так - то можно ограничиться возможностью импорта макросов из лиспа.

Lisp, PERL и Python не требуют IDE.

Мне страшно это читать от тебя. А как же без IDE переходить к определению?

Если в Яре ещё и не будет динамических (в смысле, special) переменных,

Будут, конечно, разве можно такую гениальную вещь выбрасывать?

Я считаю, что это неправда и это офф :-)

Ты можешь считать как угодно :-) Однако же сделать Common Lisp статически типизированным никакими библиотечками не получится :-) Особенно такими, где авторы «не знают, что они делают» :-) Лол :-)

С такими требованиями тебе надо придумать свой Лисп :-) Потом на нём реализовать Яр :-)

В aref всегда возвращается тип t, даже если массив известного типа.

Думаю, ты не совсем прав. В SBCL, если ты делаешь

(let ((a (aref (the (simple-array fixnum (*)) foo) 3))) 
  а)

В SBCL, если ты делаешь

Потому что на низком уровне aref превращается в некий aref-fixnum с правильной сигнатурой. А если сделать

(defun bar (x) (aref x 3))

(let ((a (bar (the (simple-array fixnum (*)) foo)))) 
  а)

то a уже имеет тип t.

Для ридера как-то так:

(declare (ftype ... gethash)) напиши. Или предлагаешь на каждую параметризацию отдельный gethash определять? Типа gethash-fixnum-string, gethash-number-number, ...?

Это не диалектика. То что ты пытаешься сказать — всего лишь то, что недостаток оборачивается достоинством и наоборот, в зависимости от применения(как, например, легкий вес в боксе компенсирует отсутствие хорошего удара подвижностью). Диалектика — это развитие из противоречия: тезис-антитезис-синтез

Представь себе, что еще есть «борьба и единство противоположностей». Доучиваться

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

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

Новый код или свой код мне проще писать без IDE, где IDE начинает только мешать

В случае же haskell несколько особая ситуация. Из-за того, что он обязывает контролировать побочные эффекты, код получается значительно более модульным.

Поэтому и необходимость в IDE должна быть значительно ниже, чем в тех же java или c#, но только в случае haskell у меня такого опыта работы с чужой большой кодовой базой нет, чтобы утверждать на 100%, что IDE особо не нужна

Новый код или свой код мне проще писать без IDE, где IDE начинает только мешать

Boilerplate без IDE писать муторно.

В случае же haskell несколько особая ситуация. Из-за того, что он обязывает контролировать побочные эффекты, код получается значительно более модульным.

Там IDE выполняет две функции:
- Boilerplate для шаблона модуля, пакета и автотипа функции по её телу
- Показывает тип переменной при наведении (избавляет от 90% ошибок при опечатках).

Автодополнение и показывание документации тоже помогают

В случае же haskell несколько особая ситуация. Из-за того, что он обязывает контролировать побочные эффекты, код получается значительно более модульным.

Там IDE выполняет две функции:
- Boilerplate для шаблона модуля, пакета и автотипа функции по её телу
- Показывает тип переменной при наведении (избавляет от 90% ошибок при опечатках).

Это ты про Lehsah? Или есть еще IDE для Хаскеля?

Кек, зачем тебе такая проверка "(the V (gethash Мy-key H))" на гете? У тебя ж статически типизированный язык(я про твой яр). Т.е. ты не сможешь запушить в таблицу не тот тип. Значит проверка на гете не имеет смысла.

Погоди, ты пользователь leksah? Удобная штука?

Это ты про Lehsah? Или есть еще IDE для Хаскеля?

Про leksah. Но вроде и docstring и шаблоны в haskell-mode тоже есть.

Погоди, ты пользователь leksah? Удобная штука?

Неторопливая чуть, а в остальном совмещает плюсы REPL и редактора. Дописал функцию, он сразу проверяет её на соответствие типу и если что не так, подчёркивает спорные места. Шаблоны для cabal, тестов. Автодополнение.

Значит проверка на гете не имеет смысла.

Он ровно это и написал. Если тип элементов таблицы указан, то при чтении проверка типа не нужна. Точнее нужна на стадии компиляции.

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

А ты не пробовал настроить окружение для haskell на Atom?

А ты не пробовал настроить окружение для haskell на Atom?

Нет. У меня только Emacs и Vim из универсальных редакторов.

leksah

У меня это гомно даже не собралось, но я видел его на чужом компе, поэтому даже и не расстроился и разбираться не стал. Щетаю не нужно оно.

Я как-то года три назад пробовал leksah, но мне не понравилось, как она выглядела.

На линуксе примерно в то же время у него были косяки в UI — «морда» расползалась за пределы экрана.

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

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

«яйцо еще у курицы в заднице, а он уже со сковородкой по двору бегает...»

Ты это к чему?

Ну и, кстати, некоторые языки (например, Swift или Kotlin) «родились» вполне с поддержкой IDE. И что-то мне подсказывает, что это обеспечивает дополнительный приток интересующихся.

Можно поспорить, но лень.

Ага.