Re: [Scheme-reports] Pattern matching and list comprehensions
Panicz Maciej Godek
(17 Mar 2014 22:06 UTC)
|
Re: [Scheme-reports] Pattern matching and list comprehensions
Denis Trapeznikoff
(19 Mar 2014 06:16 UTC)
|
Re: [Scheme-reports] Pattern matching and list comprehensions
Panicz Maciej Godek
(19 Mar 2014 09:58 UTC)
|
Re: [Scheme-reports] Pattern matching and list comprehensions
Peter Bex
(19 Mar 2014 10:24 UTC)
|
Re: [Scheme-reports] Pattern matching and list comprehensions
Denis Trapeznikoff
(21 Mar 2014 19:48 UTC)
|
Re: [Scheme-reports] Pattern matching and list comprehensions Alan Manuel Gloria (21 Mar 2014 23:53 UTC)
|
Re: [Scheme-reports] Pattern matching and list comprehensions
Denis Trapeznikoff
(24 Mar 2014 18:51 UTC)
|
Re: [Scheme-reports] Pattern matching and list comprehensions
Panicz Maciej Godek
(22 Mar 2014 12:58 UTC)
|
Re: [Scheme-reports] Pattern matching and list comprehensions
Aaron W. Hsu
(19 Mar 2014 18:19 UTC)
|
On Sat, Mar 22, 2014 at 3:38 AM, Denis Trapeznikoff <denin@mail.ru> wrote: > Hello. > > > Wed, 19 Mar 2014 10:54:26 +0100 от Panicz Maciej Godek > <godek.maciek@gmail.com>: > > Hi! > > 2014-03-19 7:06 GMT+01:00 Denis Trapeznikoff <denin@mail.ru>: >> Mon, 17 Mar 2014 23:02:52 +0100 от Panicz Maciej Godek >> <godek.maciek@gmail.com>: >> >> > I think that there's a nice tradition among the Scheme programmers to >> > use the name "compose" to refer to a composition function. It is much >> > more descriptive than "dollar-asterisk" ("multiply dollars"? "a >> > millionare marries a star"? "jackpot"?), and hence more >> > reader-friendly, and unless you are doing some domain-specific >> > research, your programs usually won't get much longer because of that. >> >> Yes (and I did so, too, at start), but `compose' is too long a word >> (compare >> it to Haskell's `.'). > > Haskell is a very nice language, but -- compared to Scheme -- it > conveys a lot of information in its complex syntax. Correct me if I'm > wrong, but I don't think that it would allow you to define the "." > operator if it wasn't already in the language. > > Actually, there is no problem in that: > > import Prelude hiding ((.)) > > main = (putStrLn . concat) ["Hell", "o!"] > > (.) :: (b -> c) -> (a -> b) -> (a -> c) > f . g = (\x -> f (g x)) > > Haskell is a functional language after all! :) Haskell is also a lot more unified than the Scheme world - there's only one "real" library repository, hackage.haskell.org, and only one implementation of any significant community size, GHC (any other implementation of Haskell has to target GHC-compatibility just to get traction). This tends to make Haskell definitions also more centralized. Each and every relatively recent syntax operator, like <$> and <*> (i.e. one that is not the old stable Haskell 98 definition), is introduced in some paper that is published which source code, whose source code makes its way into hackage.haskell.org, and most of the community gets exposed to it. In Scheme, any implementation of Scheme will get traction once it has a minimum of RnRS-compatibility (and RnRS is a very short standard, except for n=6) plus a module system plus a library repository, and each Scheme implementation becomes its own little island, Any short, succinct operator that arises on one island will not be understood on another island. Hence the need in Scheme for fully specifying what you mean in each name. > > Interestingly, when I was exploring Scheme for the first time, I have > also been introducing such operators as > > (define ($_ f . x) > (lambda y (apply f (append x y)))) > > (define (_$ f . y) > (lambda x (apply f (append x y)))) > > ((append) is not needed here.) Actually, it is: (let ((x (list 1 2 3)) (y (list 4 5 6))) (apply f (append x y))) == (f 1 2 3 4 5 6) but: (let ((x (list 1 2 3)) (y (list 4 5 6))) (apply f x y)) == (f (list 1 2 3) 4 5 6) > > It's not only that -- it is also relevant how arguments are applied to > the predicate. To be honest, I have no intuition of whether such > generalization is good. Can you come up with any real-world usage > example? (Like: multiple argument map allows you to easily define the > code that computes the dot product) > > Sorry, I don't have production examples right before my eyes now, so > anything I come up with would be somewhat artificial. > Let's say you have two function graphs in two buffers and want to compute > their relation at all points where the denominator is not zero: > > (define nom-list) > (define denom-list) > (define ratio-list (call-with-values (lambda () (filter (lambda (a b) (not > (zero? b))) nom-list denom-list)) (lambda (l1 l2) (map / l1 l2)))) > > (I intentionally have not used any more procedures of prelude.scm in this > example.) > > > Pozdrawiam > M. > > > > С уважением, > > denin@mail.ru > > _______________________________________________ > Scheme-reports mailing list > Scheme-reports@scheme-reports.org > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports > _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports