[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