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)
|
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. `call-with-values' is also a long name, but introducing a new cryptic operator for it wouldn't contribute positively to the program's readability -- you'd only have more things to remember. If your argument was that using a long word such as "compose" makes your programs impractically long, then I'd agree that it's better to have a shorthand. However, I only used it twice in around 12000 lines of my Scheme code and I doubt that if it was named with some fancy characters it would improve readability. The fact that there are languages that allow to express some notions in a shorter way doesn't mean that some longer ways are too long. > So I've decided to name procedure constructors in a > unified manner: > 1) their names should start in the same distinguishing character; > 2) and they should be short, and, probably, operator-like. > `$' is not popular in the Report, so it was chosen to not clash with > standard procedures. > Now, `*' seemed good for the compositions, because composition is a monoid > operation for functions. > Likewise `$0' is a procedure that returns constant-returning function (that > is, ($0 1 2 3) always returns (values 1 2 3), whenever called with any set > of arguments), it is not something that costs zero dollars. :) I'd rather use the name "constant" here (although I don't know if it's a common tradition). 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)))) (the underscore was meant to stand for the unbound argument, and the dollar -- for the bound one) but I eventually preferred to just use lambdas (or λ), because in the end those inventions of mine didn't add anything but confusion. > Once again: it was all for brevity. APL programs are good examples of brevity. But they are also extremely non-self-descriptive. > Btw, how is "compose" defined traditionally? I think that traditionally every Scheme programmer defines one's own version :) But I have incorporated this definition to my personal library: http://stackoverflow.com/a/1698417/1110499 > > As to the behaviour of "filter", it is not clear whether it should > > behave as you described when more than one list is provided. Perhaps > > it should rather iterate over their cartesian product? Or concatenate > > the lists? That's one more thing to remember, and eventually one more > > thing to forget. If you're doing something complex, don't let your > > code pretend that it's something simple. > > So that's a rule: when (filter) is fed with one list, it returns one list. > When it's fed with several lists, it returns as many lists. > This is just another feature of Scheme utilized to make a procedure more > general case. 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) Pozdrawiam M. _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports