[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Pattern matching and list comprehensions
- To: Panicz Maciej Godek <godek.maciek@x>
- Subject: Re: [Scheme-reports] Pattern matching and list comprehensions
- From: Peter Bex <Peter.Bex@x>
- Date: Wed, 19 Mar 2014 11:20:21 +0100
- Cc: Scheme-reports@x, Denis Trapeznikoff <denin@x>
- In-reply-to: <CAMFYt2Yn3g2JiFwCfNceDyfQ3hh8CuY0HsMDazf=_uApkJ7NMg@mail.gmail.com>
- Mail-followup-to: Panicz Maciej Godek <godek.maciek@x>, Denis Trapeznikoff <denin@x>, Scheme-reports@x
- References: <firstname.lastname@example.org> <CAMFYt2bNYj91=xjPJA3qmeeHu1LGwoXe-pDL-rXyM9Cq+yRjOQ@mail.gmail.com> <email@example.com> <CAMFYt2Yn3g2JiFwCfNceDyfQ3hh8CuY0HsMDazf=_uApkJ7NMg@mail.gmail.com>
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 :)
> 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:
CHICKEN also ships with "compose" in its "data-structures" unit (which
is misleadingly named, IMO):
> > 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.
Scheme-reports mailing list