T>Иными словами, схемеры не могут только преподавать программирование через сравнение с образцом. T>Заметная часть прогресса в программировании с 1971 года, AFAIR, недоступна. T>ЧТД.
Ваш разговор полная бредуха, но тем не менее
* Аргументы Вадлера произвели на американские университеры не особенно сильное впечатление.
* У Фридмана — опыт преподавания скорее даже поболее, чем у Вадлера. Ну и вообше, HTDP, PLAI, EOPL, SICP, The Reasoned Schemer, The Seasoned Schemer
* Все курсы indiana.edu издревле использовали паттерн-матчинг(и дататипы тоже) — раньше хитрый, со встроенным катаморфизмом, последние годы простой, его написал Киселев, вот реализация (портабельная) целиком:
;;; Code written by Oleg Kiselyov
;;; (http://pobox.com/~oleg/ftp/)
;;;
;;; Taken from leanTAP.scm
;;; http://kanren.cvs.sourceforge.net/kanren/kanren/mini/leanTAP.scm?view=log
; A simple linear pattern matcher
; It is efficient (generates code at macro-expansion time) and simple:
; it should work on any R5RS Scheme system.
; (pmatch exp <clause> ...[<else-clause>])
; <clause> ::= (<pattern> <guard> exp ...)
; <else-clause> ::= (else exp ...)
; <guard> ::= boolean exp | ()
; <pattern> :: =
; ,var -- matches always and binds the var
; pattern must be linear! No check is done
; _ -- matches always
; 'exp -- comparison with exp (using equal?)
; exp -- comparison with exp (using equal?)
; (<pattern1> <pattern2> ...) -- matches the list of patterns
; (<pattern1> . <pattern2>) -- ditto
; () -- matches the empty list
(define-syntax pmatch
(syntax-rules ()
((_ exp clause ...)
(let ((val-to-match exp))
(pmatch* val-to-match clause ...)))))
(define match-failure
(lambda (val)
(error 'match-failure "failed match ~s\n" val)))
(define-syntax pmatch*
(syntax-rules (else)
((_ val (else exp ...))
(let () exp ...))
((_ val)
(match-failure val))
((_ val (pattern () exp0 exp ...) . clauses)
(let ((fail (lambda () (pmatch* val . clauses))))
; note that match-pattern may do binding. Here,
; other clauses are outside of these binding
(match-pattern val pattern (let () exp0 exp ...) (fail))))
((_ val (pattern guard exp0 exp ...) . clauses)
(let ((fail (lambda () (pmatch* val . clauses))))
(match-pattern val pattern
(if guard (let () exp0 exp ...) (fail))
(fail))))))
; (match-pattern val pattern kt kf)
(define-syntax match-pattern
(syntax-rules (_ quote unquote)
((_ val _ kt kf) kt)
((_ val () kt kf)
(if (null? val) kt kf))
((_ val (quote lit) kt kf)
(if (equal? val (quote lit)) kt kf))
((_ val (unquote var) kt kf)
(let ((var val)) kt))
((_ val (x . y) kt kf)
(if (pair? val)
(let ((valx (car val))
(valy (cdr val)))
(match-pattern valx x
(match-pattern valy y kt kf)
kf))
kf))
((_ val lit kt kf)
(if (equal? val (quote lit)) kt kf))))
Здравствуйте, thesz, Вы писали: MC>>Это unzip, встроенный в матчинг. Удобная штука. T>Так что он означает, этот отрывок? Чем не удовлетворяет сравнение с головой-парой?
Демонстрирует, как матч биндит первый компонент от unzip-а к "a", а второй — к "b".
MC>>Самая интересный раздел по твоей ссылке — это macros. Какой аналог для explicit renaming в хаскеле? T>Это покрывается функциями высших порядков (подстановка аргументов), ленивыми вычислениями (создание замыканий для условий) и областями видимости в виде let/where.
Не, не покрывается. Например, на syntax-rules, менее мощных, чем er, сделан паттерн матчинг. Ленивость и фвп позволят в хаскеле дополнить матчинг какой-нибудь новой конструкцией?
В принципе, Вадлер тогда был в некотором роде прав. В r3rs не было даже syntax-rules, в sicp макросы вроде тоже не упоминались, так что myif в рамках r3rs написать было нельзя. Хотя, возможно, в реальных имплементациях scheme макросистемы уже были.
Здравствуйте, thesz, Вы писали: T>Да плюс на страничке самого EoPL содержание выложено в ps. Это ж вообще, в начале 21-го века, и такой анахронизм.
Реализация интерпретаторов уже неактуальна?
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, thesz, Вы писали:
T>>Иными словами, схемеры не могут только преподавать программирование через сравнение с образцом. T>>Заметная часть прогресса в программировании с 1971 года, AFAIR, недоступна. T>>ЧТД. Z>Ваш разговор полная бредуха, но тем не менее Z>* Аргументы Вадлера произвели на американские университеры не особенно сильное впечатление.
Просто тогда нормальной Миранды не было.
Z>* У Фридмана — опыт преподавания скорее даже поболее, чем у Вадлера. Ну и вообше, HTDP, PLAI, EOPL, SICP, The Reasoned Schemer, The Seasoned Schemer
И всё вокруг Схемы. Неинтересно.
Тот же Appel хотя бы для нескольких языков свой Modern Compiler Implementation сделал.
Z>* Все курсы indiana.edu издревле использовали паттерн-матчинг(и дататипы тоже) — раньше хитрый, со встроенным катаморфизмом, последние годы простой, его написал Киселев, вот реализация (портабельная) целиком:
Издревле — это как давно?
Z>Ну и так далее, лень писать.
А зря. Это очень интересно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: MC>>>Это unzip, встроенный в матчинг. Удобная штука. T>>Так что он означает, этот отрывок? Чем не удовлетворяет сравнение с головой-парой? MC>Демонстрирует, как матч биндит первый компонент от unzip-а к "a", а второй — к "b".
Что такое первый компонент от unzip-а?
Почему ты не можешь нормально объяснить? Приведи раскрытый код этого сравнения с образцом.
MC>>>Самая интересный раздел по твоей ссылке — это macros. Какой аналог для explicit renaming в хаскеле? T>>Это покрывается функциями высших порядков (подстановка аргументов), ленивыми вычислениями (создание замыканий для условий) и областями видимости в виде let/where. MC>Не, не покрывается. Например, на syntax-rules, менее мощных, чем er, сделан паттерн матчинг. Ленивость и фвп позволят в хаскеле дополнить матчинг какой-нибудь новой конструкцией?
Да зачем?
MC>В принципе, Вадлер тогда был в некотором роде прав. В r3rs не было даже syntax-rules, в sicp макросы вроде тоже не упоминались, так что myif в рамках r3rs написать было нельзя. Хотя, возможно, в реальных имплементациях scheme макросистемы уже были.
Ещё раз. То, что в Схеме требует макросов, в языке типа Хаскеля работает без них.
Так что Вадлер и сейчас прав. Для использования Хаскеля надо меньше изучать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>Да плюс на страничке самого EoPL содержание выложено в ps. Это ж вообще, в начале 21-го века, и такой анахронизм. MC>Реализация интерпретаторов уже неактуальна?
Здравствуйте, thesz, Вы писали: MC>>Демонстрирует, как матч биндит первый компонент от unzip-а к "a", а второй — к "b". T>Что такое первый компонент от unzip-а? T>Почему ты не можешь нормально объяснить? Приведи раскрытый код этого сравнения с образцом.
Раскрытый код смотреть неинтересно.
#lang scheme
(match '((1 2) (3 4) (5 6))
((list (list a b) ...) и т.п.
Забиндит '(1 3 5) к "a" и '(2 4 6) к "b". Все, подробнее не буду — слишком много постов на один пример. Если после этого разговора ты заинтересуешься схемой — сам доки почитаешь. Если нет — ну и бог с ним, значит — тебе это не нужно.
T>Да зачем?
Чтобы разговор поддержать. Ну не хочешь — не надо, есть пример нагляднее — см. ниже.
T>Ещё раз. То, что в Схеме требует макросов, в языке типа Хаскеля работает без них.
По данному пункту критики схемы приводят в пример то, что для реализации cond через if нужны макросы. Т.е. задача такова:
Есть полновесная имплементация scheme, но в ней нет cond (другой вариант — if или short-circuit-логические операции). Сделай cond, неотличимый от того, что прописан в стандарте.
Ок. Предлагаю тебе такую задачу:
Есть полновесная имплементация хаскеля но в ней нет let (или where — на твой выбор). Сделай let (ну или where), неотличимый от того, что прописан в репорте.
Instructors who would prefer that their students use a strongly-typed language such as ML or OCAML will find that the algorithms in the book are easy to rewrite in such a language. We have added to Scheme a new special form, define-datatype, that is very similar to ML's datatype or OCAML's type. With the use of our matching form, cases, the programs are structured much as they would be in ML or OCAML.
We rely on a Scheme-based parser generator, SLLGEN. It should be straightforward to port our lexical and grammatical specifications to an ML-based parser generator such as mllex/mlyacc or to ocamllex/ocamlyacc, or to write the parsers by hand
Z>>* Все курсы indiana.edu издревле использовали паттерн-матчинг(и дататипы тоже) — раньше хитрый, со встроенным катаморфизмом, последние годы простой, его написал Киселев, вот реализация (портабельная) целиком:
T>Издревле — это как давно?
Мои раскопки показали, что по крайней мере с 1992 года (первое издание EOPL). Там это называлось "variant-case".
Здравствуйте, thesz, Вы писали: T>Безопасных — актуальна.
Все это, конечно, интересно, но пока не для моего ума.
Я тут-таки намылился (благо начало семестра — есть свободное время) подучить, теорию (в плане ЛИ, типов и т.п.) — хочу начать с "Type Theory & Functional Programming" за авторством Simon Thompson — это хороший вариант?
T>На Схеме — нет.
В EoPL обсуждаются основы. Например, это одно из немногих мест, где доступно объясняется cps-преобразование.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: MC>>>Демонстрирует, как матч биндит первый компонент от unzip-а к "a", а второй — к "b". T>>Что такое первый компонент от unzip-а? T>>Почему ты не можешь нормально объяснить? Приведи раскрытый код этого сравнения с образцом. MC>Раскрытый код смотреть неинтересно. MC>
MC>;#lang scheme
MC>;(match '((1 2) (3 4) (5 6))
MC>; ((list (list a b) ...) и т.п.
MC>;
MC>Забиндит '(1 3 5) к "a" и '(2 4 6) к "b". Все, подробнее не буду — слишком много постов на один пример. Если после этого разговора ты заинтересуешься схемой — сам доки почитаешь. Если нет — ну и бог с ним, значит — тебе это не нужно.
Именно.
Я не вижу, зачем делать unzip через сравнение с образцом, если есть unzip.
T>>Да зачем? MC>Чтобы разговор поддержать. Ну не хочешь — не надо, есть пример нагляднее — см. ниже.
Лично я стараюсь приводить жизненные примеры.
Потому, что так проще пронять.
Что, тяжело привести пример, когда действительно нужно дополнять сравнение с образцом дополнительной конструкцией?
T>>Ещё раз. То, что в Схеме требует макросов, в языке типа Хаскеля работает без них. MC> По данному пункту критики схемы приводят в пример то, что для реализации cond через if нужны макросы. Т.е. задача такова: MC>
MC>Есть полновесная имплементация scheme, но в ней нет cond (другой вариант — if или short-circuit-логические операции). Сделай cond, неотличимый от того, что прописан в стандарте.
MC>Ок. Предлагаю тебе такую задачу: MC>
MC>Есть полновесная имплементация хаскеля но в ней нет let (или where — на твой выбор). Сделай let (ну или where), неотличимый от того, что прописан в репорте.
let x = e in f x это (\x -> f x) e (опустив подробности с взаимно-рекурсивными определениями)
Неотличимо по синтаксису не получится, но по семантике соответствует.
См. lambda lifting в обе стороны.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, thesz, Вы писали:
Z>>>* Все курсы indiana.edu издревле использовали паттерн-матчинг(и дататипы тоже) — раньше хитрый, со встроенным катаморфизмом, последние годы простой, его написал Киселев, вот реализация (портабельная) целиком:
T>>Издревле — это как давно?
Z>Мои раскопки показали, что по крайней мере с 1992 года (первое издание EOPL). Там это называлось "variant-case".
То есть, критика Вадлера всё-таки подействовала.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>Безопасных — актуальна. MC>Все это, конечно, интересно, но пока не для моего ума. MC>Я тут-таки намылился (благо начало семестра — есть свободное время) подучить, теорию (в плане ЛИ, типов и т.п.) — хочу начать с "Type Theory & Functional Programming" за авторством Simon Thompson — это хороший вариант?
Выглядит хорошо. Вроде, покрыты все интересные вещи, и даже с запасом.
Надо будет потом почитать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали: T>Я не вижу, зачем делать unzip через сравнение с образцом, если есть unzip.
Это удобно. Собственно, одно из применение макросов — "сделать себе удобно".
T>Что, тяжело привести пример, когда действительно нужно дополнять сравнение с образцом дополнительной конструкцией?
Да, тяжело. Как правило, я макросы использую "по месту" — т.е. вижу, что некоторая конструкция начинает копипаститься — и начинаю думать, как этого избежать. В некоторых случаях в итоге конструкция заменяется макросом. Аналогично — с паттерн-матчингом. Поэтому сформулировать какой-то отдельно стоящий и наглядный случай использования макросов мне сложно.
T>Неотличимо по синтаксису не получится, но по семантике соответствует.
Ну вот. А говоришь: T>То, что в Схеме требует макросов, в языке типа Хаскеля работает без них.
Получается, что в хаскеле без какого-то подобия макросов нельзя вводить новые конструкции, осуществляющие биндинг.
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, Mr.Cat, Вы писали:
MC>>Я тут-таки намылился (благо начало семестра — есть свободное время) подучить, теорию (в плане ЛИ, типов и т.п.) — хочу начать с "Type Theory & Functional Programming" за авторством Simon Thompson — это хороший вариант?
T>Выглядит хорошо. Вроде, покрыты все интересные вещи, и даже с запасом.
T>Надо будет потом почитать.
Здравствуйте, thesz, Вы писали:
MC>>Т.е. с ленивыми списками на самом деле проблем нет.
T>На момент написания Вадлером статьи потоки не были спроектированы правильно. А значит, проблемы были.
Здравствуйте, thesz, Вы писали:
T>>>Издревле — это как давно?
Z>>Мои раскопки показали, что по крайней мере с 1992 года (первое издание EOPL). Там это называлось "variant-case".
T>То есть, критика Вадлера всё-таки подействовала.
В двух словах: они разделили мудрость на две книги: HTDP для первокурсников, посвященную основам и структурированию программ, и PLAI которая больше похожа на SICP: интерпретаторы разных языков, континюейшны etc.
Схема из статьи:
SICP: HTDP:
primality moving circles
interval arithmetic hangman
symbolic differentiation moving shapes
representing sets moving pictures
huffman encoding trees rearranging words
symbolic algebra binary search trees
digital circuits evaluating scheme
more on web pages
evaluating scheme again
moving pictures, again
mathematical examples
Gaussian elimination
normal/applicative order checking (on) queens
strictness/laziness accumulators on trees
non-determinism missionaries and cannibals
logic programming board solitaire
register machines exploring places
compilers moving pictures, a last time
Fig.1. SICP and HTDP exercises
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, thesz, Вы писали:
T>>Здравствуйте, Mr.Cat, Вы писали:
MC>>>Я тут-таки намылился (благо начало семестра — есть свободное время) подучить, теорию (в плане ЛИ, типов и т.п.) — хочу начать с "Type Theory & Functional Programming" за авторством Simon Thompson — это хороший вариант? T>>Выглядит хорошо. Вроде, покрыты все интересные вещи, и даже с запасом. T>>Надо будет потом почитать. К>Сергей, тебе для размышлений — последняя книжка того же автора
Деньги дерёт.
Кстати, последнюю книгу я читать не буду — ничего интересного нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, thesz, Вы писали: T>>Я не вижу, зачем делать unzip через сравнение с образцом, если есть unzip. MC>Это удобно. Собственно, одно из применение макросов — "сделать себе удобно".
Это тогда, когда регулярные средства неудобны, ведь так?
И получается, что то, что в Хаскеле делается системой типов и регулярными средствами, в Схеме с Лиспом делается макросами (Software Transactional Memory, например).
T>>Что, тяжело привести пример, когда действительно нужно дополнять сравнение с образцом дополнительной конструкцией? MC>Да, тяжело. Как правило, я макросы использую "по месту" — т.е. вижу, что некоторая конструкция начинает копипаститься — и начинаю думать, как этого избежать. В некоторых случаях в итоге конструкция заменяется макросом.
ФВП. В Хаскеле они очень дёшевы.
MC>Аналогично — с паттерн-матчингом. Поэтому сформулировать какой-то отдельно стоящий и наглядный случай использования макросов мне сложно.
T>>Неотличимо по синтаксису не получится, но по семантике соответствует. MC>Ну вот. А говоришь:
Я, опять же, не вижу здесь серьёзных трудностей.
Покажи, пожалуйста, жизненный пример, в котором потребуется вводить связывающие конструкции, не выражаемые через сравнение с образцом, лямбды, ФВП и let/where.
T>>То, что в Схеме требует макросов, в языке типа Хаскеля работает без них. MC>Получается, что в хаскеле без какого-то подобия макросов нельзя вводить новые конструкции, осуществляющие биндинг.
Да.
Да только я всего один раз ощутил нужду в Template Haskell. Недавно.
За почти 11 лет использования Хаскеля.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Уважаемые коллеги, предлагаю по возможности не пренебрегать таким замечательным средством художественной выразительности, как заголовки сообщений. Это существенно упростило бы навигацию и поиск нужных сообщений в дереве комментариев.
Здравствуйте, thesz, Вы писали: T>И получается, что то, что в Хаскеле делается системой типов и регулярными средствами, в Схеме с Лиспом делается макросами
В некоторых случаях — да (канонический случай с myif). Но в обратную сторону неверно.
T>(Software Transactional Memory, например).
А зачем для stm макросы?
T>Покажи, пожалуйста, жизненный пример, в котором потребуется вводить связывающие конструкции, не выражаемые через сравнение с образцом, лямбды, ФВП и let/where.
Я уже предлагал — дополнить паттерн-матчинг новой конструкцией. Пример с (list (pattern) ...) тебе не нравится почему-то, хотя штука удобная. Можно придумать другой — например, сделать матчинг по типу того, как в эрланге сделан для binary. Или чтобы можно было матчить строчку по регулярному выражению и биндить именованные группы к переменным.
T>Да только я всего один раз ощутил нужду в Template Haskell. Недавно.
Ну вот видишь, и ты не безнадежен
Ну не хочешь — не надо, есть пример нагляднее — см. ниже.
