a
их получается много, и никогда не знаешь, всё ли ты учёл
Size: a a a
2020 June 22
LL
А контекст как поможет?
LL
Пока звучит так, что лучше просто переписать
a
ну может я не так выразился, допустим, мы знаем, что на выходе нужен bool, выдаем #f, а если на выходе нужна пара, выдаем какую-нибудь пару, и т.п.
LL
А это уже звучит как статическая типизация
a
да, но у нас же нет статической типизации...
LL
Только в крякете
AK
anton
ну может я не так выразился, допустим, мы знаем, что на выходе нужен bool, выдаем #f, а если на выходе нужна пара, выдаем какую-нибудь пару, и т.п.
Можно извернуться и, используя какой-нибудь из портов CLOS, переопределить
car, null? и проч. как дженерики, чтобы для твоего спец. типа nil они возвращали то, что тебе нужно, а для остальных типов - то, что вернула бы библиотечная функция. Но, опять-таки, это не решит проблему с if и другими контекстами, в которых участвуют особые формыa
если я хочу переопределить or мне же нужно переопределять его для переменного числа аргументов?
A
or не функция, а специальный символ для short-circuit
a
но я же могу перепределить его
ХЛ
А REPL Julia написан на Scheme?
ХЛ
Если да, то прикольно
b⛅
Все работает, бросает ошибку
inc: contract violation
expected: number?
inc: contract violation
expected: number?
кстати, обожаю эти контракты. Гораздо круче статической типизации для многих задач.
LL
Говорят их сложно в оптимизированый код компилять
b⛅
Говорят их сложно в оптимизированый код компилять
почти невозможно. Функции могут динамично генерироваться и меняться, всё такое
b⛅
хотя можно на шаге компиляции хотя бы часть ошибок ловить
b⛅
допустим, условная sum, которая ждёт два нумбера.
и строчкой ниже (sum "1" 2)
достаточно просто отловить
и строчкой ниже (sum "1" 2)
достаточно просто отловить
b⛅
но это по сути никому не нужно, потому что в рантайме тоже словится
b⛅
а если нужно, чтобы все ошибки с типами ловились в компайлтайме, то лисп не очень подходит