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 Wed, Mar 19, 2014 at 10:54:26AM +0100, Panicz Maciej Godek wrote: > 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. Especially if you don't use it often, a cryptic name will mean the reader of your code will have to look up its meaning. Not an advantage. > 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. I agree. And more importantly, when writing code in a language, it's good practice to try and write _idiomatic_ code (when in Rome, do as the Romans do). That means using the conventions established by existing codebases and the language's standard library. This will make your code easier to pick up by someone fluent in that language. In Scheme, names are generally very verbose (think "call-with-current-continuation"), so using really short names breaks the flow. I tend to reserve short names for procedure arguments and local LET-bound variables, but only when it's obvious what they do or when the names would get in the way too much. > > 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). In CHICKEN, this is called "constantly", because it's a procedure which constantly returns the same thing. I don't know if this was taken from another implementation, or a local invention :) http://api.call-cc.org/doc/data-structures/constantly > 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. Yeah, I had to read that code twice before I grokked what it did. > > 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 CHICKEN also ships with "compose" in its "data-structures" unit (which is misleadingly named, IMO): http://api.call-cc.org/doc/data-structures/compose > > 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) The generalisation makes sense to me, but I don't know if it really is the best one, because it's inconsistent with how multi-argument "map" works, as you described. Cheers, Peter -- http://www.more-magic.net _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports