[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sections
Original-Via: uk.ac.ukc; Thu, 25 Oct 90 12:17:54 BST
From: Kent Karlsson <kent>
Date: Thu, 25 Oct 90 11:05:30 +0100
To: haskell@cs.glasgow.ac.uk
Subject: Re: sections
Original-Sender: kent%se.chalmers.cs@sunic.sunet.se
Sender: haskell-request@cs.glasgow.ac.uk
> Kent Karlsson proposes:
> I think the "placeholder" in a s.c. section should be explicitly
> marked, either by a '?', or, if you don't want to reserve a new
> symbol, by an '_'. E.g.:
...
> At first glance, I like your idea! It generalises nicely to e.g.
> (if _ then e1 else e2),
> etc. But, hm, presumably you would have to restrict the number
> of placeholders to one in an expression? Or would you want to allow
> (_ + _), (if _ then e1 else _), etc?
No, I don't. Restrict this notation to s.c. sections ((*) or (_ * _) are not
sections) and maybe generalized to 'sectioning' out *one* argument in an
*application* (which would exclude the if-then-else examples).
Note that map (f _ 1 2) is eq. to map (\x -> f x 1 2) rather than
(\x -> map (f x 1 2)), otherwise you get an unexpectedly large 'scope'
for the '_'. So h (g _ 4) (f _ 1 2) is eq. to h (\x -> g x 4) (\y -> f y 1 2).
In other (informal) words, '_' cannot "escape" from a pair of parentheses.
> In writing increasingly complicated "sections", there comes a point where
> a lambda expression becomes more readable.
For readability, 'sectioning' should only be used for *very small* expressions.
But the same goes for lambda-expressions. Giving a name to a function
(in a where-clause) increases readability if the lambda-expression is large.
/kn