[erlang-questions] I think I wish I could write case Any of whatever -> _ end.

[Bengt Kleberg]

I think this is the short paper by Schmidt and Lampson:
http://research.microsoft.com/en-us/um/people/blampson/32-organizingsoftware/32-organizingsoftwareocr.doc

Unfortunately it is unavailable there, but there is a cache:
http://webcache.googleusercontent.com/search?q=cache:YMjF4RmG6BEJ:http://research.microsoft.com/en-us/um/people/blampson/32-organizingsoftware/32-organizingsoftwareocr.doc+cedar+Eric+Schmidt+system+model&hl=&ct=clnk


bengt

On Wed, 2010-05-19 at 04:41 +0200, Richard O'Keefe wrote:
> On May 18, 2010, at 3:05 PM, Henning Diedrich wrote:
> 
> > Richard, righteous,
> >
> > I was just curious about the defense you'd mount to keep ~ for the  
> > frame syntax.
> >
> > Where the first thing that hit my uneducated I was how the use of ~  
> > in it was so completely special --- as some other symbol uses in  
> > Erlang are --- that it, well, may be an excellent fit. Why starting  
> > to get conventional. A language proudly flying =< could also have ~  
> > to mean 'something like' while really, yes, significantly different  
> > from =.
> 
> I am baffled by this "so completely special" claim.
> The frames report goes to some trouble to point out that this use of
> ~ for maplets is *NOT* innovative.  It was a straight steal from
> Xerox PARC.  The Mesa programming language had an equivalent of
> 'make' called C/Mesa.  For Mesa's successor Cedar, this was replaced
> by Eric Schimdt's "System Modeller", which took care of
>   - versions
>   - building
>   - distribution
> using a "system model" (think "Makefile on steroids") which was nothing
> other than a pure lazy functional program for building systems.  (This
> is the same Eric Schmidt who became CEO of Google.)  A lovely idea,
> and anyone thinking about configuring, building, distributing, and
> installing Erlang systems really ought to spend some time reading
> Schmidt's thesis.  (Or at least the short paper about it by him and
> Butler Lampson, which is a little easier to find.)
> 
> Which is where I got "~" from.  Pebble and SML (System Modelling
> Language) come from the same stable.  Pebble was mainly used as a
> formal notation for specifying Cedar, but it _was_ implemented.
> So "~" has been used in at least two functional languages.
> 
> And it *does* standardly mean "sort of like =".  I grant you that in
> Haskell it means "match this pattern lazily", and in ML it means
> "negative sign" as part of a numeric literal, and in C, bizarrely,
> it means "bitwise complement", but all of those are *unary* uses.
> See for example http://mathworld.wolfram.com/Tilde.html.
> 
> The other thing that might make sense would be ":=" (is defined as),
> although that would tend to confuse people used to sane programming
> languages that don't use = for assignment.  (Fortran has much to
> answer for.  FORmula TRANslator, yet they used .EQ. for equality?)
> 
> As for =<, that wasn't really a matter of choice.  Prolog was used
> to manipulate logical expressions, and desperately needed <= and =>
> for free use as arrows, forcing equals-or-less than to be written
> =<.  Parlog, FCP, GHC, and Strand 88 all followed it.  The first
> implementation of Erlang was in Prolog.  Hence much of Erlang
> syntax.  But not all of it by any means.  Erlang *has* innovated.
> Just not *there*.
> 
> 
> >
> > I think I already got used to the proposed frame syntax, followed  
> > your arguments and support it.
> >
> > But I think ~ would be great to also roughly mean 'what I just  
> > said'. Also ./. might do, or -"-, or *.
> 
> It is extremely difficult to believe that this is not an elaborate
> practical joke.
> 
> As it happens, I _have_ used a programming language in which * could be
> used in much that way:  Burroughs Extended Algol.  From the 1977 manual,
> page 5-6:
> 	Pragmatics
> 	An "update assignment" can be specified with an asterisk (*)
> 	after the colon equal (:=) by an assignment to an
> 	<arithmetic variable> whose <partial word part> is empty.
> 	For example, "A := *+1" produces the same results as
> 	"A := A+1".  Updating a <subscripted variable> via this
> 	method is more efficient."
> 
> It _should_ have been in the syntax, not the pragmatics.
> It was more efficient because it only evaluated the subscripts once.
> 
> I was always rather annoyed because this wasn't consistently carried
> out:
> 	BA[I] := NOT *		not allowed
> 	RA[I] := * - 1		allowed
> 	RA[I] := 1 - *		not allowed
> Note that
> 	RA[I] := * * Y + Z
> is _not_ like C's ra[i] *= y+z, but like ra[i] = (ra[i]*y)+z.
> 
> That taught me to beware of "what I just said".
> 
> I mentioned Common Lisp's REPL.  SML has something similar:
> 	% sml
> 	- 6*7;
> 	val it = 42 : int
> 	- it div 3;
> 	val it = 14 : int
> Now we have two definitions of "it", the later one hiding the
> earlier.  Want to refer to the earlier?  You're stuffed.
> 
> A SINGLE "WHAT-I-JUST-SAID" IS A BAD IDEA NO MATTER HOW YOU SPELL IT.
> 
> If you are sharp-witted and realise that you need to save a value,
> you can quickly name it:
> 
> 	- val planets = it;
> 	val planets = 14 : int
> 	- 72;
> 	val it = 72 : int
> 	- planets;
> 	val it = 14 : int
> 
> In the same way, the S programming language allows assignment to
> be written right-to-left
> 	var <- expr
> or left-to-right
> 	expr -> var
> so that if you've just typed a hairy long expression and realise
> that you'll need to refer to the value again, you can tack an
> assignment on the end without retyping the whole thing.
> 
> The problem is that we need to *think* about our programs, to take
> bits of them, manipulate them, put them back, turn them inside out
> and run them backwards, in a very fluid way.
> 
> But a "what I just said" is tightly bound to its context.
> It's not just in a particular place, it's coated with thick
> layers of superglue, nailed fast, and anchored with a thick
> chain.  Sure, if an expression in an arm of a case refers to
> a variable bound in the pattern of that arm, it still needs
> that variable, but it *SAYS* what variable it needs.
> 
> > The argument about being hard to pronounce sounds a bit convenient  
> > in this context. Pronouncing code is a rarified art and runs into  
> > this problem time again.
> 
> "Rarefied" (note spelling) means "thin", as in the opposite of
> "condensed".  As for pronouncing code, it SHOULDN'T be an esoteric
> art.  We do, after all, TALK about our programs with each other.
> What do we do?  Point and grunt?  I have a tongue and I'm not scared
> to use it in the service of my profession.  "The telephone test" is
> not of my invention.
> 
> Here's an example of an error due to the pronunciation of
> characters:
> 	~1
> is the ML way to write what you get by subtracting 1 from 0.
> If you *pronounce* it "negative one", well and good.  Any ML
> programmer who has got past the tyro stage will get it right.
> But if you *pronounce* it "minus one", you will far too often
> write
> 	-1
> which is a syntax error, if you are lucky.  For
> 	f x ~1
> means (f (x))(~1), while
> 	f x -1
> means (op -)(f x, 1).  The only way I ever found to cure myself
> of this was to religiously say "negative one".  (The same applies
> in APL, where the "high minus" character is used for "negative".)
> 
> > But just as '=' can mean many things to different people, maybe '~'  
> > can be used for both things.
> 
> = has three principal uses in programming languages:
>     query: is this equal to that?
>     definition: this is equal to that, now and always!
>     command: change this to be equal to that (at the moment).
> "Equal" is in all of them.
> 
> Maybe ~ *could* be used to mean "what I just said" or "the price
> of fish in Port Stanley last Thursday" or "this CPU's current clock
> frequency".  Heck, we could even use it to replace self(), which
> would benefit from not being a function call.  That doesn't make
> any of these a good idea.
> 
> > I thought it was a tad illogical, however, to argue that because  
> > there is no obviousness to the meaning of <<< in Lisp might indicate  
> > that the 'some as above/before' connotation of ~ should likewise and  
> > somehow guilty by association be irrelevant or even  
> > counterproductive when deciding about. It's use.
> 
> What I was arguing was perfectly logical: a hack can be turned into a
> principle if you repeat it *consistently*, but the Lisp * ** ***
> convention is not repeated *consistently*.  (The key one was not the
> missing <<< but the missing -- and --- .)
> 
> To put it another way: you *can* demand that people learn some weird
> new convention, BUT you have to make it pay off for them.  Isolated
> hacks don't pay off for your readers.
> 
> > Not that I believe that anyone cares, but eye have a hobby horse  
> > that had me thinking about hacking the pre-compiler already: the  
> > doubling of function signatures where the variation that is called  
> > in the former is, plus one default argument as literal, exactly the  
> > head of the next. I might be doing something wrong there but I keep  
> > copying heads and it makes the code hard to read. I regularily go,  
> > copy a head, paste it three times (one over the old ) and alter two  
> > of them marginally. A nice remedy could be:
> >
> > Fun(A) -> Fun(A, b).
> >
> > Fun(A,B) ...
> 
> Believe it or not, but this is covered by an old proposal of mine.
> My adaptation of Paul Lyons' "split procedure heads" covers both
> keywords and optional arguments.
> 
> Lisp has	(defun f (a (&optional b 'B)) ...)
> S (R) has	f <- function (a, b = "B") { ... }
> Ada has		function F(A : T1; B: T2 => "B") is ...
> C++ has		T0 f(T1 a, T2 b = 'b') { ... }
> 
> Notice a pattern about where the default value goes?
> \
> >
> > This could become
> >
> > Fun(A) -> ~~ b.
> 
> That puts the default value where the body belongs,
> and means that you only get ONE default argument.
> Two strikes against it to start with.
> 
> If I wanted this often, I might use M4, and define
> 
> optional(HEAD, E1, ..., En)
> 
> to expand to
> 
> 	HEAD') -> HEAD'(E1).
> 	HEAD' _V_1) -> HEAD' _V_1, E2).
> 	...
> 	HEAD' _V_1, ..., V_n_minus_1) -> HEAD' (_V_1, ..., _V_n_minus_1, En).
> 
> where HEAD' is HEAD without its trailing ),
> which would be a pretty trivial piece of M4 code, but would
> let you write
> 
> optional(foobar(A,B), A+2, 42).
> foobar(A, B, C, D) -> ...
> 
> and have it expand to
> 
> 	foobar(A,B) -> foobar(A,B, A+2).
> 	foobar(A,B, _V_1) -> foobar(A,B, _V_1, 42).
> 	foobar(A, B, C, D) -> ...
> 
> Hmm.  I don't quite like that interface.  Maybe
> 
> optional(F(A1, ..., An))
> 
> where Ai is either Var or Var=>Expr
> 
> optional(foobar(A, B=>A+2, C, D=>A*B+C))
> 
> That looks like it might work.  I did use a special symbol here,
> but (note again the absence of innovation) it's the same one Ada
> uses.  Come to think of it, since Ada uses => for records as well
> as optional parameters, it would make sense to use the same
> symbol in Erlang, and use Var ~ Expr for defaults.
> 
> Last draft today:
> 
> optional(foobar(A, B ~ A+2, C, D ~ A*B+C))
> 
> In any case, no actual change to Erlang is involved.
> It would also be possible to hack on the Erlang parser
> to recognise
> -optional foobar(A, B ~ A+2, C, D ~ A*B+C).
> but I'd want to prototype it with M4.
> 
> >
> > Sorry there is no relation to the negation connotation that ~  
> > somehow brings along. But that seemed to be alright for its use in  
> > io:format in the first place, didn't it? Also, somehow, it negates  
> > writing code doubly.
> 
> If you're a C programmer, sure, ~ says bitwise negation.
> In Lisp, it doesn't.  Not even close.  And that's where 'format'
> comes from.  (Possibly via Prolog.)  In _Erlang_, the only use
> of "~" is in formats, and there isn't the slightest whiff of
> negation about it anywhere.
> 
> 
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>