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

[Henning Diedrich]

True pleasure as always Sir,

so it's a done deal and we'll make a proposal for

foobar(A, B ~ A+2, C, D ~ A*B+C) -> ...

?

Or are you insisting on M4 for this?

For the record, the negation connotation was raised by you earlier.

 > I am baffled by this "so completely special" claim.

With that disclaimer, "to my uneducated eyes" - yes, certainly. I had no 
exposure to Prolog. It's premise had been suspect to me since high 
school and I successfully avoided it.

I like the idea of being consistent about hacks to make them 
justifiable. But for now, why not find characters, or even reserveable 
atoms, for these desired uses. Let's not forget `_ -> ok.' either.

I will look out for samples in my sources where I would benefit from:

foobar(A, B ~ A+2, C, D ~ A*B+C) -> ...
:=
foobar(A, D) -> foobar(A, A+2, C,A*B+C).
foobar(A, B, D) -> foobar(A, B, C,A*B+C).
foobar(A, B, C, D) -> ...

- - - - - - - - - -

    case foo()
      of {ping,_} -> ~~
       ; {_,pong} -> pang(~~)
    end

    :=
   
    case X=foo()
      of {ping,_} -> X
       ; {_,pong} -> pang(X)
    end


- - - - - - - - - -

    case foo() of
       { something, And } -> bar(And);
       ~~~
    end

    :=

    case X = foo() of
       { something, And } -> bar(And);
       _ -> X
    end


Or any other sign. Although sorta-kinda makes sense to me. The third 
even looks nicely formatted.

Not that I couldn't live without. But I dare participating in the 
conversation for this reason: after a while you are getting used to the 
funniest things. When you're fresh it's easier to note what could be 
different, while at the same time unable to judge the deeper consequences.

 > 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.

I don't think that makes a difference, you still need to the context to 
make sense of it. Named or not.

 > A SINGLE "WHAT-I-JUST-SAID" IS A BAD IDEA NO MATTER HOW YOU SPELL IT.

For my taste, constructions can make sense even if you can't really 
stretch their use. I even found macro implemented templates somewhat 
better than none, or compiler constructs with their usual limitations 
(if you don't happen to have you M4 at hand, of course).

 > "Rarefied" (note spelling)

We can absolutely switch to German if you feel its essential that I 
insert no human language related mistakes.

 >  As for pronouncing code, it SHOULDN'T be an esoteric art. 

Maybe, but it most certainly is. I would not enjoy reading an source 
over the phone and I also don't think that's the point of PLs. I mean, 
Erlang??? Open curly brace, Open square brace, Open curly brace, one, 
close curly brace ... wow.

I maintain that a tilde by convention named 'sorta-kina-operator' would 
be less of a nuisance to pronounce than all the brackets the syntax of 
Erlang loves so much. And fun.

 > =< and >=

I didn't doubt there was a reason but thanks for the education. I was 
pretty sure it was to reserve  <= and => just wondered that there 
weren't any of these before binary matching.

Thanks!
Henning







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.
>
>
>