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 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 Panicz Maciej Godek 19 Mar 2014 09:54 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