Вышел в свет GHC 6.10.1 новым параллельным сборщиком мусора, data parallel arrays, а главное — теперь доступны давно обещанные семейства типов (type families).
Prelude> :s -XTransformListComp
Prelude> :m GHC.Exts
Prelude GHC.Exts> let employees = [ ("Simon", "MS", 80) , ("Erik", "MS", 100) ,
("Phil", "Ed", 40) , ("Gordon", "Ed", 45) , ("Paul", "Yale", 60)]
Prelude GHC.Exts> let output = [ (the dept, sum salary) | (name, dept, salary) <
- employees , then group by dept , then sortWith by (sum salary) , then take 5 ]
Prelude GHC.Exts> output
[("Yale",60),("Ed",85),("MS",180)]
Мы можем увидеть, что Эрик получает в MS больше Саймона, и это, соратники, самое удивительное! Отмечу также, что в Эдинбургском университете зарплаты ниже, чем в Йельском.
Отдельный привет немерлистам — в Template Haskell добавлено квазицитирование.
D>Prelude GHC.Exts> let output = [ (the dept, sum salary) | (name, dept, salary) <
D>- employees , thengroupby dept , then sortWith by (sum salary) , then take 5 ]
D>>Prelude GHC.Exts> let output = [ (the dept, sum salary) | (name, dept, salary) <
D>>- employees , thengroupby dept , then sortWith by (sum salary) , then take 5 ]
LCR>
Спасибо за линк, только начал читать (головоломка в начале отличная).
Но совершенно очевидно, что именно такого синтаксиса не добиться — как ты себе представляешь then в виде функции? В этом случае выражение "then sortWith by (sum salary)" играло бы роль guard'а (в стандартных list comprehensions такое выражение больше ничем быть не может синтаксически), а это совсем не то, что нужно.
palm mute,
PM>Спасибо за линк, только начал читать (головоломка в начале отличная). PM>Но совершенно очевидно, что именно такого синтаксиса не добиться — как ты себе представляешь then в виде функции? В этом случае выражение "then sortWith by (sum salary)" играло бы роль guard'а (в стандартных list comprehensions такое выражение больше ничем быть не может синтаксически), а это совсем не то, что нужно.
Да, головоломка мне тоже понравилась Согласен, именно такого синтаксиса не добиться, однако этот экстенсивный путь накидывания фичек "шоб було" мне тоже очень не нравится. Хаскель и так сложный, даже можно сказать бездонный, чтобы засирать (прости мой французский) синтаксис. Раньше компрехеншн был просто лист-монадой, а сейчас — самостоятельная синтаксическая конструкция (или нет?).
Здравствуйте, Lazy Cjow Rhrr, Вы писали: LCR>экстенсивный путь накидывания фичек "шоб було" мне тоже очень не нравится.
Угу. Лучше б с багами боролись. Наверняка ghci до сих пор ld-скрипты не поддерживает. Поубивал бы за такое.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Да, головоломка мне тоже понравилась Согласен, именно такого синтаксиса не добиться, однако этот экстенсивный путь накидывания фичек "шоб було" мне тоже очень не нравится. Хаскель и так сложный, даже можно сказать бездонный, чтобы засирать (прости мой французский) синтаксис. Раньше компрехеншн был просто лист-монадой, а сейчас — самостоятельная синтаксическая конструкция (или нет?).
Хм, list-comprehensions всегда были самостоятельной синтаксической конструкцией, это же просто синтаксический сахар для операций над списками — они не предлагают ничего нового по сравнению с fold'ами семантически. И вполне логично при наличии явных параллелей между LC и запросами SQL расширить набор подсахаренных операций — если раньше поддерживались только filter и concatMap, то теперь еще поддерживаются sort и group, криминала я в этом не вижу; причем я думаю, что именно эта фича будет востребованной, писать лямбды вида "\(_,_,x,_)->x" радости мало.
Если говорить о раздутости Хаскелла, то скорее проблемой является одновременное наличие fundeps, associated types и type families, когда одних type families хватило бы.
palm mute,
PM>Хм, list-comprehensions всегда были самостоятельной синтаксической конструкцией, это же просто синтаксический сахар для операций над списками — они не предлагают ничего нового по сравнению с fold'ами семантически.
PM> И вполне логично при наличии явных параллелей между LC и запросами SQL расширить набор подсахаренных операций — если раньше поддерживались только filter и concatMap, то теперь еще поддерживаются sort и group, криминала я в этом не вижу; причем я думаю, что именно эта фича будет востребованной, писать лямбды вида "\(_,_,x,_)->x" радости мало.
Я имею ввиду, что выражение
[ a+b | a <- [1,2,3], b <- [3,4,5] ]
дословно эквивалентно
do {a <- [1,2,3]; b <- [3,4,5]; return (a+b)}
А вот
[ a+b | a <- [1,2,3], b <- [3,4,5], then group by b]
непонятно чему эквивалентно. Во всяком случае мне.
То, что стандартные L.C. легко определялись с помощью do-нотации, а расширенные — нет, по-моему, лишь показывает границы применимости монад и do-нотации для построения EDSL с хитрыми областями видимости переменных.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Согласен, именно такого синтаксиса не добиться, однако этот экстенсивный путь накидывания фичек "шоб було" мне тоже очень не нравится. Хаскель и так сложный, даже можно сказать бездонный, чтобы засирать (прости мой французский) синтаксис. Раньше компрехеншн был просто лист-монадой, а сейчас — самостоятельная синтаксическая конструкция (или нет?).
