Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>И получается, что то, что в Хаскеле делается системой типов и регулярными средствами, в Схеме с Лиспом делается макросами MC>В некоторых случаях — да (канонический случай с myif). Но в обратную сторону неверно.
Я не понял, что означает здесь "в обратную сторону".
T>>(Software Transactional Memory, например). MC>А зачем для stm макросы?
Для контроля.
Чтобы ты не потребовал transaction-peek вне atomic block.
Как в Схеме сделать так, чтобы транзакционные примитивы не могли быть вызваны вне атомарного блока?
T>>Покажи, пожалуйста, жизненный пример, в котором потребуется вводить связывающие конструкции, не выражаемые через сравнение с образцом, лямбды, ФВП и let/where. MC>Я уже предлагал — дополнить паттерн-матчинг новой конструкцией. Пример с (list (pattern) ...) тебе не нравится почему-то, хотя штука удобная. Можно придумать другой — например, сделать матчинг по типу того, как в эрланге сделан для binary. Или чтобы можно было матчить строчку по регулярному выражению и биндить именованные группы к переменным.
Ну, вот binary уже туда-сюда.
Строка по регулярным выражениям — это комбинаторы в сочетании с rewrite rules.
T>>Да только я всего один раз ощутил нужду в Template Haskell. Недавно. MC>Ну вот видишь, и ты не безнадежен
И это, я считаю, самый большой недостаток Хаскеля — то, что мне TH все-таки понадобился.
Это очень, очень неудобно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали: T>Чтобы ты не потребовал transaction-peek вне atomic block. T>Как в Схеме сделать так, чтобы транзакционные примитивы не могли быть вызваны вне атомарного блока?
Ты про монаду STM? Да, мне тоже нравится идея контролировать все, что можно, в компайл-тайм на уровне типов, но scheme — динамически типизированный язык со всеми вытекающими.
T>rewrite rules.
Которые, судя по описанию (сам не юзал), близки к syntax-rules.
Вот увидишь, пройдет немного времени (лет 5?) — и хаскелисты будут знакомиться с макросами чуть ли не раньше, чем с монадой ЙО.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>Чтобы ты не потребовал transaction-peek вне atomic block. T>>Как в Схеме сделать так, чтобы транзакционные примитивы не могли быть вызваны вне атомарного блока? MC>Ты про монаду STM? Да, мне тоже нравится идея контролировать все, что можно, в компайл-тайм на уровне типов, но scheme — динамически типизированный язык со всеми вытекающими.
То-то и оно.
Схема никак не помогает не совершать ошибок.
T>>rewrite rules. MC>Которые, судя по описанию (сам не юзал), близки к syntax-rules.
Нет, не близки.
MC>Вот увидишь, пройдет немного времени (лет 5?) — и хаскелисты будут знакомиться с макросами чуть ли не раньше, чем с монадой ЙО.
Нет, не будут.
rewrite rules нужны для оптимизации чего-то там. Оптимизация возникает тогда, когда сама программа уже написана.
Ты как-то всё не поймёшь, что макросы и метапрограммирование нужно тогда, когда язык сам по себе низкоуровневый. См. того же Брукса, "Мифический человеко-месяц".
Здравствуйте, thesz, Вы писали: T>Схема никак не помогает не совершать ошибок.
По сравнению с хаскелем — да. По сравнению с другими динамическими языками — иногда помогает.
MC>>Вот увидишь, пройдет немного времени (лет 5?) — и хаскелисты будут знакомиться с макросами чуть ли не раньше, чем с монадой ЙО. T>Нет, не будут.
Ну по крайней мере я буду на это надеяться
T>rewrite rules нужны для оптимизации чего-то там.
Подожди. Ты только что собирался их применять совсем не для оптимизации.
T>Ты как-то всё не поймёшь, что макросы и метапрограммирование нужно тогда, когда язык сам по себе низкоуровневый.
Ну в целом да. Это преподносится как достоинство схемы: небольшое ядро плюс всемогущие макросы. Ты зачем-то разделяешь понятия, для разделения не предназначенные: тебе видится убогий язык и макросы, исправляющие его убогость. А scheme — это на самом деле красивый язык с макросами.
T>См. того же Брукса, "Мифический человеко-месяц".
Там и про это есть? Возможно, и правда полистать стоит.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>rewrite rules нужны для оптимизации чего-то там. MC>Подожди. Ты только что собирался их применять совсем не для оптимизации.
Макрос сделает статический код, выполняющийся эффективно. Rewrite rules нужны для того же.
То есть, для оптимизации.
T>>Ты как-то всё не поймёшь, что макросы и метапрограммирование нужно тогда, когда язык сам по себе низкоуровневый. MC>Ну в целом да. Это преподносится как достоинство схемы: небольшое ядро плюс всемогущие макросы.
Какие же они всемогущие, если даже не могут проверить обращение к транзакции вне блока работы с транзакцией?
MC>Ты зачем-то разделяешь понятия, для разделения не предназначенные: тебе видится убогий язык и макросы, исправляющие его убогость. А scheme — это на самом деле красивый язык с макросами.
Да я как-то красоты в языке не вижу.
Как только показывают что-то красивое, так оказывается, что это макросы. Посмотришь внимательней внутрь, так и красоты нет — один синтаксис.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали: T>>>rewrite rules нужны для оптимизации чего-то там. MC>>Подожди. Ты только что собирался их применять совсем не для оптимизации. T>Макрос сделает статический код, выполняющийся эффективно. Rewrite rules нужны для того же. T>То есть, для оптимизации.
Стоп. Ты говорил собрался сделать, что rr позволят позволить писать вот вот такое (я это имел в виду под паттерн-матчингом к регекспу):
f "^\\d+$" = doSomething1
f "^\\w+$" = doSomething2
Все-таки это можно и без rr сделать?
T>Как только показывают что-то красивое, так оказывается, что это макросы.
Таки ты макроненавистник
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>>>rewrite rules нужны для оптимизации чего-то там. MC>>>Подожди. Ты только что собирался их применять совсем не для оптимизации. T>>Макрос сделает статический код, выполняющийся эффективно. Rewrite rules нужны для того же. T>>То есть, для оптимизации. MC>Стоп. Ты говорил собрался сделать, что rr позволят позволить писать вот вот такое (я это имел в виду под паттерн-матчингом к регекспу): MC>
{-# LANGUAGE ViewPatterns, PatternGuards #-}data Match = M [String] | F -- match or failure.type REString = String
re :: REString -> String -> Match
re re string = M [re,string] -- должно быть что-то из regexp, что в ghc
f (re "something" -> M []) = "do something"-- try f "really nothing".
f (re "nothing" -> M ["nothing","really nothing"]) = "do nothing"
f _ = "huh?"-- Второй вариант:
g string
| M [] <- re "something" = "do something"
| m ["nothing","really nothing"] <- re "nothing" = "do nothing"
| _ = "huh?"
Вот кусок реального кода:
getPart (ValueArr arr) ((Right index):path)
| Just value <- lookup index arr = getPart value path
| otherwise = dummyValue
При сравнении можно получать значения переменных.
T>>Как только показывают что-то красивое, так оказывается, что это макросы. MC>Таки ты макроненавистник
Мне они не нравятся с практической точки зрения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали: T>{-# LANGUAGE ViewPatterns, PatternGuards #-}
Вот-вот. Нет бы развивать макросы в хаскеле — вместо этого плодят расширения.
Здравствуйте, Mr.Cat, Вы писали:
MC>Стоп. Ты говорил собрался сделать, что rr позволят позволить писать вот вот такое (я это имел в виду под паттерн-матчингом к регекспу): MC>
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>{-# LANGUAGE ViewPatterns, PatternGuards #-} MC>Вот-вот. Нет бы развивать макросы в хаскеле — вместо этого плодят расширения.
И как ты себе это представляешь, расширение Хаскеля макросами?
Попробуй спроектировать макросистему, чтобы на ней можно было сделать (хотя бы) PatternGuards/ViewPatterns. С учётом строгой типизации и сообщений об ошибках.
Так что вот так-то вот так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали: T>Попробуй спроектировать макросистему, чтобы на ней можно было сделать (хотя бы) PatternGuards/ViewPatterns. С учётом строгой типизации и сообщений об ошибках.
В ближайшее время и пробовать не буду. Но у plt есть typed scheme — надо будет посмотреть, как там дела с макросами.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>Попробуй спроектировать макросистему, чтобы на ней можно было сделать (хотя бы) PatternGuards/ViewPatterns. С учётом строгой типизации и сообщений об ошибках. MC>В ближайшее время и пробовать не буду. Но у plt есть typed scheme — надо будет посмотреть, как там дела с макросами.
* type errors in SML are difficult
* type errors in Soft Scheme are pure torture
* explaining type errors in Soft Scheme remains for PhD-level experts
Вот так-то.
Ещё добавь вывод типов, а не просто проверку, и тебе станет совсем хорошо.
А в Typed Scheme-то, как раз, от вывода типов ушли. И про макросы ни слова. Так что ничем тебе typed scheme не поможет.
PS
Smith's Law: Any sufficiently large test suite for a program written in a dynamic language will contain an ad-hoc, informally-specified, bug-ridden, slow, patchy implementation of half of the Haskell type system
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
