LINUX.ORG.RU

[haskell] есть ли что-то типа reflection? (недемократизм языка?)

 


0

0

Обычная фраза: deriving (Read, Show, Eq, Ord)

Компилятор умеет выводить инстансы этих typeclass-ов. А что делать, если хочется их выводить чуть-чуть по-другому или добавить еще один, который автоматически бы выводился? (Для этого, возможно, подошло что-то похожее на reflection, патчить компилятор не предлагайте)

__________________________________________________

Недемократизм языка в моем понимании -- это

1. Частичная реализация некой фичи и одновременно отстутствие инструмента для расширения реализации этой фичи. Например в яве оператор + для сложения целых, вещественных, строк и все: комплексные, кватернионы, вектора, матрицы... складывай уже через add.

2. Невозможность смены конкретной реализации фичи (зачастую связано с п.1). Например, невозможность создать в рамках с++ свой virtual dispatch (для того, что сделать множественный virtual dispatch, т.е. п.1). В принципе, п.2 до некоторой степени неизбежен, так как иногда намного проще сделать фичу, чем API для написания фич).

__________________________________________________

Более глобальный вопрос -- а насколько хаскель демократичен? (для обеспечения демократизма разрешается использовать ключи компилятора, template haskell, ...)

Ответ на: комментарий от anonymous

значение при компиляции.
 
А в рантайме, у большинства статических языков - что флоат, что инт - одна херня, сраные 32 бита :)

anonymous
()
Ответ на: комментарий от Macil

>Но какой смысл в списках, элементы которых могут быть _любым_ типом?
Вон оно оказывается, смысла то и нет! Надо пойти на c.l.l. рассказать :))

anonymous
()
Ответ на: комментарий от anonymous

> значение при компиляции.

Значение чего? можешь полностью сформулировать? :)

> А в рантайме, у большинства статических языков - что флоат, что инт - одна херня, сраные 32 бита :)

anonymous
()
Ответ на: комментарий от www_linux_org_ru

>И вообще, язык высокого уровня абстрагируется от деталей поиска.

Замечательное занятие - сидеть и искать сработавшую перегрузку. Я вообще люблю попить кофе и почитать распечатки кода на досуге. Если там find будет чем угодно, то какой смысл в этом занятии? Тут как бы сановский fortress с конверсией в pdf это лучшая идея - программа как документ. Только непонятно как с библиотеками наподобие gmp работать. Перегрузка операторов это явно вредная идея, т.к с одной стороны непонятно чего можно ожидать от a*b, а с другой при операциях с бесконечной мантиссой есть опции округления которые не впердолишь в правый операнд. Но изображать выражения в естественном виде как-то надо. Плагины в компилятор какие-то наверно нужны всетаки.

Absurd ★★★
()
Ответ на: комментарий от Macil

> Если так, то тут языки со статической типизацией не рулят.

(устало) иди прочти исходник, всего 50 строк

> Но какой смысл в списках, элементы которых могут быть _любым_ типом? Да и всегда ли есть требование, чтобы тип был _любой_?

Да. Запись в файл например и чтение из него.

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от Absurd

> Замечательное занятие - сидеть и искать сработавшую перегрузку. Я вообще люблю попить кофе и почитать распечатки кода на досуге. ... Тут как бы сановский fortress с конверсией в pdf это лучшая идея - программа как документ.

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

Ну и вообще, есть легенькие нетбуки с приемлемым экраном.

> Если там find будет чем угодно, то какой смысл в этом занятии?

файнд должен искать и искать за определенное О(чего-то). Я вообще предполагал, что недалеко имеется SortedVector vv=..., но вполне может случиться int i=find(12, some_function(x)) и тогда действительно получается обфускация. По идее IDE для печати тут должно вставлять коммент

int i=find(12, /*SortedVector<int>*/ some_function(x))

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

int i=find(12, 'SortedVector<int>' some_function(x))

в добавок, такое нужно видеть отнюдь не всем.

и твой вариант назвать find по-другому мне уже кажется намного лучше, только не binary_search, а типа ln_n_search или quick_search

> Перегрузка операторов это явно вредная идея, т.к с одной стороны непонятно чего можно ожидать от a*b,

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

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

не понял

> Но изображать выражения в естественном виде как-то надо.

юникод, верхние-нижние индексы, ну и т.д по мат. нотации

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

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

>не понял

В жабовском BigDecimal.divide() не один а два параметра - делитель и как округлять, например. В контракт operator/ это не влезет.

Absurd ★★★
()
Ответ на: комментарий от anonymous

> Наверное, это потому, что pattern matching и list comprehension в лиспопрограммах ДЕЙСТВИТЕЛЬНО никому нафиг не нужен.

Вполне допускаю. Паттерн-матчинг - он и в хаскелопрограммах, скажем так, фича не первой надобности.

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

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

А какая разница?

> 1) типизирование совершенно опционально

Всё понял. Значит, урод за соседним столом напишет без типизации, а я потом мучайся.

> он определяет _класс значений_, а не тип.

Не понял разницы. Вопрос в том, будет ли он проверен при компиляции - или в рантайме?

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

> The value 6227020800 is not of type FIXNUM.

Это не динамическая типизация, это проверка в рантайме на переполнение. Неудивительно, что лисп такой тормозной.

Никто не мешает сделать

newtype MyInt = MyInt Int deriving (Eq, Show, Ord, Read, ...)

instance Num MyInt where ...

и впендюрить те же самые проверки.

Miguel ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

При чём тут?

Miguel ★★★★★
()
Ответ на: комментарий от aninamous

> Какой будет тип у функции с переменным количеством аргументов

У каждой функции есть только один аргумент. См. математику.

> у функции возвращающей переменное количество значений?

Каждая функция возвращает одно значение. См. математику.

> И конечно же тут логические ошибки невозможны.

Затруднены. Хотя, конечно, возможны.

Miguel ★★★★★
()
Ответ на: комментарий от aninamous

> опенсорс.орг.ру намекает, что нужно ссылку на проект, который дохнет от ошибок динамики.

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

Miguel ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

Анонимус прав. В плюсах есть статическая типизация, но в ней такое количество дырок и обходных путей, что, по сути, типизации почти и нет вообще.

Haskell, ML - да, там обходные пути тоже, конечно, есть (unsafeCoerce, например), но они чётко изолированы и вся идеология языка строится так, чтобы избегать их всегда, кроме как когда уж совсем никуда.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

>Это не динамическая типизация, это проверка в рантайме на переполнение. Неудивительно, что лисп такой тормозной.
Да нет, там все быстро. fixnum это size-t минус несколько битоа на тайптег.
В этом фишка, в лиспе у значений в рантайме есть типы, в отличии от.

Ну и вообще, про приизводительность кто бы мычал. SBCL рвет GHC по скорости на всех задачах посложнее "факториал посчитать". Особенно если принимать во внимание т.н. "функциональный" стиль, которым хаскелоиды грешат(в смысле тот факт, что оптимизации на хаскеле не попрактикуешь особо, в силу урезанной, до невозможности, мутабельности).

anonymous
()
Ответ на: комментарий от Miguel

>У каждой функции есть только один аргумент. См. математику.
Это в какой такой математике такой стало вдруг?
Ну, в том подмножестве анализа, которое в провинциальных вузах в первый семестр читают, возможно. А так...
>Затруднены.

Да с какой это стати?
Логические ошибки типизации ортогональны. Ошибки типов это о_пе_чат_ки.

anonymous
()
Ответ на: комментарий от Miguel

>Каждая функция возвращает одно значение. См. математику.
"Функция" это довольно узкое и убогое понятие в контексте программирования, это да.
Правильнее будет назвать "отображение".

anonymous
()
Ответ на: комментарий от anonymous

>У каждой функции есть только один аргумент. См. математику.

>Это в какой такой математике такой стало вдруг? Ну, в том подмножестве анализа, которое в провинциальных вузах в первый семестр читают, возможно. А так...

Хехехе... Функция - лишь отображение одного множества на другое. И соотвественно да, имеет лишь один аргумент и в качестве результата тоже только один (многозначные обобщения не рассматриваем).

ЗЫ неужели ЛОРовский анонимус обмельчал так, что даже матан не учит?

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

Функции нескольких аргументов из математики куда-то исчезли? Я, видимо, старый стал слишком, раз такое пропустил.

anonymous
()
Ответ на: комментарий от anonymous

>Функции нескольких аргументов из математики куда-то исчезли? Я, видимо, старый стал слишком, раз такое пропустил.

Функции нескольких аргументов - это такое лукавство, ты ж понимаешь...

Якобы функция от трёх аргументов f(x, y, z) = x*y*z

На деле то f: R*R*R -> R функция одного аргумента из множества R*R*R

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

Это сути не меняет.
Если множество не R*R*R, а R*N*C*..(до, в теории, бесконечности), Хиндли-Милнер ломается, а хаскелоиды, поджав хвост, начинают скулить о ненужности таких функций.

anonymous
()
Ответ на: комментарий от anonymous

>Это сути не меняет. Если множество не R*R*R, а R*N*C*..(до, в теории, бесконечности), Хиндли-Милнер ломается, а хаскелоиды, поджав хвост, начинают скулить о ненужности таких функций.

1) такое и вправду редко надо, а если надо, то вот живой пример =)

http://cvs.haskell.org/Hugs/pages/libraries/base/Text-Printf.html

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

Убогий пример.

show/hide Instances
PrintfArg Char
PrintfArg Double
PrintfArg Float
PrintfArg Int
PrintfArg Integer
IsChar c => PrintfArg [c]

Что касается «не нужно», то хорошо, конечно, говорить, что не нужно, когда невозможно :))

anonymous
()
Ответ на: комментарий от anonymous

>Убогий пример.

И в чем же он убогий?

>Что касается "не нужно", то хорошо, конечно, говорить, что не нужно, когда невозможно :))

Я показал, что возможно и без особых напрягов. В чем проблема?

Waterlaz ★★★★★
()
Ответ на: комментарий от anonymous

>Не убогим примером была бы функция funcall :) ну или apply

Карринг же.

Waterlaz ★★★★★
()
Ответ на: комментарий от anonymous

> Ну и вообще, про приизводительность кто бы мычал.

Я шучу, вообще-то.

> SBCL рвет GHC по скорости на всех задачах посложнее "факториал посчитать".

Несколько сомнительное утверждение. Есть пруф?

> оптимизации на хаскеле не попрактикуешь особо, в силу урезанной, до невозможности, мутабельности

??? Именно иммутабельность даёт возможность для таких оптимизаций, которые лиспу и не снились.

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

> Это в какой такой математике такой стало вдруг?

Определение функции вспомни, да? Функция есть синоним слова отображение. Отображение работает из одного множества в другое. Элементы первого множества - аргументы, второго - значения.

> Логические ошибки типизации ортогональны. Ошибки типов это о_пе_чат_ки.

Ой, зря ты так думаешь. Погугли, например, free theorems. И узнаешь, что информация о типе порой говорит очень многое. Вплоть до того, что может вообще сделать реализацию, по сути, единственной.

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

> Если множество не R*R*R, а R*N*C*..(до, в теории, бесконечности)

Ну, вот тебе функция из бесконечного произведения экземпляров R:

(Integer -> Float) -> Float

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Затруднены. Хотя, конечно, возможны.

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

У каждой функции есть только один аргумент. См. математику.

Каждая функция возвращает одно значение. См. математику.

Если так, то всё упирается в форму записи - в качестве аргумента упорядоченное входное множество, в качестве результата тоже упорядоченное множество. При статической типизации нужно опять писать обёртки-костыли. В динамической же сразу:

(defun f ( &rest x )
	   (values-list x)

CL-USER> (f 1 2 3 4)
1
2
3
4

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

aninamous
()
Ответ на: комментарий от www_linux_org_ru

> непоняяяяял... а как гетерогенные списки в лиспе делаются? тоже без боксинга и без "void* (и аналоги) и разнообразные костыли, типо Boxed с тайптегом и/или табличкой типов, фактически убирающие статику и эмулирующие динамику"?

А это как в реализации будет. Обычно там те же самые ссылки (например в списках), для векторов и массивов (наверное, по-другому устроено). Другой вопрос в том, что это 1) не нужно боксировать - т.е. нет никаких ненужных посредников 2) при оптимизации от списков может ничего не остаться, и там уже будут не списки, а что-то совсем другое.

> Если твои инференс даст что-то слабее F_{2<:}, то я сомневаюсь в его практической пользе.

Он в динамических языках не может быть F-образным - потому что основан на НЕТИПИЗИРОВАННОМ лямбда исчислении и там есть присваивание. Там совсем _друой_ inference - там идет процесс уточнения, а не нахождения, поэтому проблема разрешимости там так остро не стоит.

Про мощность. Ну вот смотри.

Такой простой пример. Берем хаскелл и определяем функцию без деклараций и аннотаций.

[code] f x | 1 = "hello" | 2 = 3 [code]

Пытаемся скомпилировать [code] No instance for (Num [Char]) arising from the literal `3' at test.hs:91:10 Possible fix: add an instance declaration for (Num [Char]) In the expression: 3 In the definition of `f': f x | 1 = "hello" | 2 = 3

[/code]

Ладно уточним ему Num

[code] f x | 1 = "hello" | 2 = 3 :: Int [/code]

Компилим .

[code] Couldn't match expected type `[Char]' against inferred type `Int' In the expression: 3 :: Int In the definition of `f': f x | 1 = "hello" | 2 = 3 :: Int [/code]

Т.е. крутой Хиндли-Милнер без аннотаций с этим примером так и не смог управиться.

Тоже самое делаем в лиспе.

[code] (defun f (x) (cond ((= x 1) "hello") ((= x 2) 1)))

[/code]

Смотрим выведенный "тип".

[code] (VALUES (OR (SIMPLE-ARRAY CHARACTER (5)) (INTEGER 1 1)) &OPTIONAL) [/code]

Круто - т.е. он не просто вывел тип, он вывел "оптимальный" тип. Например, (integer 1 1) в компутере сильно оптимальнее Int'a или Integer в хаскелле.

> И если с аннотациями, то почему ты будешь считать свое изделие с динамической типизацией, а не с soft typing хотя бы?

Что подразумеваешь под soft typing, потому что мы похоже говорим про разные вещи.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

Сраный лор-код.

непоняяяяял... а как гетерогенные списки в лиспе делаются? тоже без боксинга и без «void* (и аналоги) и разнообразные костыли, типо Boxed с тайптегом и/или табличкой типов, фактически убирающие статику и эмулирующие динамику»?

А это как в реализации будет. Обычно там те же самые ссылки (например в списках), для векторов и массивов (наверное, по-другому устроено). Другой вопрос в том, что это 1) не нужно боксировать - т.е. нет никаких ненужных посредников 2) при оптимизации от списков может ничего не остаться, и там уже будут не списки, а что-то совсем другое.

Если твои инференс даст что-то слабее F_{2<:}, то я сомневаюсь в его практической пользе.

Он в динамических языках не может быть F-образным - потому что основан на НЕТИПИЗИРОВАННОМ лямбда исчислении и там есть присваивание. Там совсем _друой_ inference - там идет процесс уточнения, а не нахождения, поэтому проблема разрешимости там так остро не стоит.

Про мощность. Ну вот смотри.

Такой простой пример. Берем хаскелл и определяем функцию без деклараций и аннотаций.

f x                                                                                                                                                                               
    | 1 = "hello"                                                                                                                                                                 
    | 2 = 3

Пытаемся скомпилировать

    No instance for (Num [Char])
      arising from the literal `3' at test.hs:91:10
    Possible fix: add an instance declaration for (Num [Char])
    In the expression: 3
    In the definition of `f':
        f x | 1 = "hello"
            | 2 = 3

Ладно уточним ему Num

f x                                                                                                                                                                               
    | 1 = "hello"                                                                                                                                                                 
    | 2 = 3 :: Int 

Компилим .

    Couldn't match expected type `[Char]' against inferred type `Int'
    In the expression: 3 :: Int
    In the definition of `f':
        f x | 1 = "hello"
            | 2 = 3 :: Int

Т.е. крутой Хиндли-Милнер без аннотаций с этим примером так и не смог управиться.

Тоже самое делаем в лиспе.

(defun f (x)  (cond ((= x 1) "hello")                                                                                                                                             
                    ((= x 2) 1)))                                                                                                                                                 
                                   

Смотрим выведенный «тип».

(VALUES (OR (SIMPLE-ARRAY CHARACTER (5)) (INTEGER 1 1)) &OPTIONAL)

Круто - т.е. он не просто вывел тип, он вывел «оптимальный» тип. Например, (integer 1 1) в компутере сильно оптимальнее Int'a или Integer в хаскелле.

И если с аннотациями, то почему ты будешь считать свое изделие с динамической типизацией, а не с soft typing хотя бы?

Что подразумеваешь под soft typing, потому что мы похоже говорим про разные вещи.

anonymous
()
Ответ на: комментарий от Miguel

> Вполне допускаю. Паттерн-матчинг - он и в хаскелопрограммах, скажем так, фича не первой надобности.

Я наверное не сильно ошибусь, если предположу, что паттерн-матчинг (cl-unification) в своих программах использует дай бог 4 калеки и автор, в то время как найти программу без pattern-matching в хаскелле - тяжело.

anonymous
()
Ответ на: комментарий от Miguel

> А какая разница?

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

> Всё понял. Значит, урод за соседним столом напишет без типизации, а я потом мучайся.

Ну только не говори, что у вас нет coding style в конторе, и за его несоблюдение не бьют по голове.

> Не понял разницы. Вопрос в том, будет ли он проверен при компиляции - или в рантайме?

Нет, вопрос в другом :) А будут ли проверятся при компиляции или в рантайме зависит от оптимизации компилятора, от safety и speed параметров, а также от реализации.

anonymous
()
Ответ на: комментарий от Miguel

> Это не динамическая типизация, это проверка в рантайме на переполнение. Неудивительно, что лисп такой тормозной.

:) Так я же написал, что safety 3 - т.е. все проверки типов делаются в ран-тайме (это общее правило - тестировать при safety 3, а рабочий код делать при safety 0 1). Но даже при safety 0 (самый небезопасный - без проверок типа и прочего) - он дает правильный ответ.

> newtype MyInt = MyInt Int deriving (Eq, Show, Ord, Read, ...)

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

anonymous
()
Ответ на: комментарий от Miguel

> У каждой функции есть только один аргумент. См. математику.

А в математике функции тоже могут напечатать строку на мониторе? Там можно сделать присваивание?

Мы про языки программирования, а не про математику.

> Затруднены. Хотя, конечно, возможны.

К сожалению, нет, совсем нет. Язык программирования автоматом не дает +10 к интеллекту. Наговнокодить и на хаскелле легко.

anonymous
()
Ответ на: комментарий от Miguel

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

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

anonymous
()
Ответ на: комментарий от anonymous

> Ну и вообще, про приизводительность кто бы мычал. SBCL рвет GHC по скорости на всех задачах посложнее "факториал посчитать".

Ну говорил же Никодимус Сиивола - не надо никогда говорить, что SBCL рвет кого-то или что-то, тем более что на многих задачах ghc его рвет.

На самом деле ghc такой тормозной по большей части из-за ленивости и полной иммутабельности (хотя там можно реализовать соответствующие мутабельные данные в чисто функциональном стиле с такими же О-характериситками - хотя задача, надо сказать, нетривиальная - посмотри книжку Окасаки и статьи Олега). Те же *ML - хотя они и очень функциональные - делают лисп практически всегда и везде.

anonymous
()
Ответ на: комментарий от Miguel

> ??? Именно иммутабельность даёт возможность для таких оптимизаций, которые лиспу и не снились.

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

anonymous
()
Ответ на: комментарий от aninamous

> И как это поможет обезопасить программу от ошибок, учитывая то, что ошибки типов составляют незначительный процент?

Ты просто не осознаёшь, что многие твои ошибки - это ошибки типов.

> в качестве аргумента упорядоченное входное множество, в качестве результата тоже упорядоченное множество.

Не понял. При чём тут упорядоченные множества?

[code] > (defun f ( &rest x ) (values-list x)

> CL-USER> (f 1 2 3 4) 1 2 3 4 [/code]

Ну да, ну да...

f x = x

*> f [1,2,3,4] [1,2,3,4]

Охрененная разница.

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

>А в математике функции тоже могут напечатать строку на мониторе?

элементарно. правда, мир после применения такой функции чуть-чуть изменится...ровно на строчку на мониторе!

>Там можно сделать присваивание?

можно связать значение с именем

>Мы про языки программирования, а не про математику.

а по-моему это иллюстрированный журнал обо всём на свете. разве нет?

>Язык программирования автоматом не дает +10 к интеллекту

факт. даже если это лисп. зато может дать +9000 к ЧСВ. особенно если это лисп

jtootf ★★★★★
()
Ответ на: комментарий от Miguel

> Ты просто не осознаёшь, что многие твои ошибки - это ошибки типов.

Можно пример такой ошибки?

> Не понял. При чём тут упорядоченные множества?

тот анонимус, наверное, про то, что чтобы вернуть значение не нужно заворачивать его в списки или какой другой контейнер, и, поэтому, например, связка values и multiple-values-bind работает быстрее, чем list и destructuring-bind.

anonymous
()
Ответ на: комментарий от anonymous

> найти программу без pattern-matching в хаскелле - тяжело.

Мэй би. Только всё равно - не первой надобности. Если бы хаскель автоматически генерил деструкторы типа

data Something = First Int | Second [String] | Third (Float -> IO Char)

destructSomething :: Something -> (Int -> a) -> ([String] -> a) -> ((Float -> IO Char) -> a) -> a

destructSomething (First n) f _ _ = f n

destructSomething (Second ss) _ f _ = f ss

destructSomething (Third h) _ _ f = f h

То было бы вообще шоколадно.

Miguel ★★★★★
()
Ответ на: комментарий от jtootf

> элементарно. правда, мир после применения такой функции чуть-чуть изменится...ровно на строчку на мониторе!

А, ну да мы же в аргументы передавали еще и universe :) ты часто в математике передаешь universe в качестве аргумента, только честно.

> факт. даже если это лисп. зато может дать +9000 к ЧСВ. особенно если это лисп

Кто-то утверждал, что лисп дает +10 к интеллекту? А ЧСВ меня мало интересует.

anonymous
()
Ответ на: комментарий от anonymous
> (defun f (x)  (cond ((= x 1) "hello")             
> ((= x 2) 1)))  

Ну да, о чём и речь. Нефиг делать произвольные ошибки типизации.

f 1 = Left "hello"
f 2 = Right 1

И всё пинцетно.

Miguel ★★★★★
()
Ответ на: комментарий от jtootf

> можно связать значение с именем

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

anonymous
()
Ответ на: комментарий от anonymous

> Ну меньше телодвижений - оно же лучше, не правда ли? когда результат будет таким же.

Я спрашивал, какая разница между твоими типами и не твоими?

> Ну только не говори, что у вас нет coding style в конторе, и за его несоблюдение не бьют по голове.

Есть. Бьют. Но лучше, когда критерии несоблюдения - проще. Например: "не импортируй System.IO.Unsafe".

> Нет, вопрос в другом

Именно в этом. Проверится при компиляции - значит, статика; в рантайме - динамика.

> А будут ли проверятся при компиляции или в рантайме зависит от оптимизации компилятора, от safety и speed параметров, а также от реализации.

Значит, в рантайме. В смысле, что полагаться на проверку при компиляции нельзя.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

> И всё пинцетно.

Ну т.е. без аннотаций или оберток не получится? :) И почему же он не выводил-то тип?

anonymous
()
Ответ на: комментарий от Miguel

> Именно в этом. Проверится при компиляции - значит, статика; в рантайме - динамика.

Так блин, он может проверять _вообще все_ в рантайме - ты только скажи, а может и не проверять.

> Значит, в рантайме.

Нет, т.е. не будет в коде у тебя явных проверок типа - если бы они были - как ты думаешь, мог ли лисп быть таким быстрым и на счетных задачах типа ray tracerа быть наравне со статическими языками?

> В смысле, что полагаться на проверку при компиляции нельзя.

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

anonymous
()
Ответ на: комментарий от anonymous

> А в математике функции тоже могут напечатать строку на мониторе?

Функция никогда не печатает строку на мониторе. Печатает компьютер, выполняя функцию.

> Мы про языки программирования, а не про математику.

Программирование - это такой раздел математики.

> К сожалению, нет, совсем нет.

К счастью, да, совсем да.

> Наговнокодить и на хаскелле легко.

Да, если у тебя уже есть +10 к интеллекту.

Miguel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.