[erlang-questions] Erlang elseif
Wed Nov 26 09:07:27 CET 2008
To make it short; I don't want Erlang to be like C, it seems you got so
tangled up in your own agenda so I don't think you care anymore what I am
talking about. What I would like is Erlang to be able to do what it does
with nested cases in a better and non-nested syntax, like the proposed
"cond" that Jay is talking about. Then the programmer could decide for them
selfs if they want to use it or not.
2008/11/25 Richard O'Keefe <ok@REDACTED>
> On 25 Nov 2008, at 9:56 pm, Daniel Rönnqvist wrote:
>> Richard, I understand and to a great extent agree with your will to stay
>> in the functional language domain and don't adapt to much other paradigms.
> That's not exactly what my attitude/will is.
> I've forgotten who said "A language that doesn't change the way you
> think isn't worth learning", but there's a lot of wisdom in it.
> Can you hear the sound of panting? That's me trying (and failing)
> to keep up with how the typeful FP crowd think. Clean and Haskell 98
> I can get my head around, but dependent types are starting to enter
> what passes for the mainstream in FP, and while I know perfectly well
> what they are, I don't yet know how to use them effectively. The only
> way will be to find some time and *try*.
> Constraint logic programming: I know *what* it is and to a moderate
> extent how it works, what I don't know yet is how to use it effectively.
> The only way to really get my head around it will be to spend some time
> trying on realistic problems *without* all the time trying to pretend
> CLP is something else.
> I'm an enthusiastic Smalltalker. My own Smalltalk compiler has
> finally reached the point where I can run tests (finding bug of course)
> and benchmarks (which look pretty good actually, despite doing no
> optimisation at all). The way to master Smalltalk was to try very
> hard to do things in a Smalltalk style, and not try to pretend it's C.
> When I was in the happy position of being able to get a free copy
> of GNAT for my el cheapo and long off the market but still working
> just fine thank you SunBlade 1000, I used Ada, and the way to do
> that effectively is to stop trying to think like a C or Pascal or
> Fortran programmer and try to think like an Ada programmer and make
> really effective use of its type system.
> I would love to spend some time playing with APL again, but Haskell
> gives me a surprisingly similar programming style if I want it. But
> it was APL that taught me about *calculating* programs.
> In short, it's *always* a good idea to try to work a language for
> all it's worth *on its own terms* before trying to make it like some
> other language. (As witness the serious mess that exceptions have
> made of Haskell's semantics. Many obvious natural and useful
> equalities aren't, thanks to exceptions.)
> All I'm saying is that theoretically it can be inefficient to have to run
>> _all_ tests (expressions), tag the results and then pattern match on this
>> tag, especially when the tests take a long time.
> So what? I for one have never proposed anything even remotely like
> that and am not proposing it now.
> The point at issue is this:
> The *precise* equivalent (linear source code expansion ratio,
> linear object code expansion ratio, linear run time expansion
> ratio, same semantics up to when types are checked) of
> if E1 then E2 else E3
> in say SML is
> case E1 of true -> E2 ; false -> E3 end
> in Erlang.
> That is, Erlang *HAS* if-expressions, they are just *spelled* 'case'.
> The only significant difference is thussyntactic style.
> Three magic tokens are replaced by eight.
> This is admittedly clumsy.
> However, in well written Erlang code it should also be rare,
> so it should not matter that much.
> This seem to me to be one of the two general thoughts on how to do it the
>> Erlang-way. The other one with pattern matching but that's sometimes not an
>> option, or at least it takes a lot more code (I.E your example in a previous
> But "if-is-case" is done with pattern matching, so anything that
> can be done with "if _ then _ else _" in Algol 60 or SML or "_ ? _ : _"
> in C can be done with pattern matching in Erlang and so pattern
> matching is *always* an option.
> I have provided several examples. I cannot tell which you are
> referring to.
>> One last thing; how am I refusing to discuss "a key reason why the present
>> (or rather, the pre-Great Blunder) state of affairs is a Good Thing." by not
>> wanting to use full blown application as an example?
> Because the question at issue is whether the (more apparent than real)
> lack of an analogue of if _ then _ else _ in Erlang is a good thing or
> a bad thing. If it stops people writing good code, it is a bad thing.
> If it encourages them to write better code, it is a good thing. The
> only way to tell is to try real examples where someone *thinks* that
> if _ then _ else would be appropriate. If we can readily find better
> code without it, then Erlang does not have a problem.
> By the way, nobody has asked for a "full blown application",
> only for *some* real code. In the absence of real code, all the
> debate amounts to is
> X. I think Erlang needs to be like C.
> Y. I don't.
> Stalemate. With a real example, we can make progress.
> Maybe you misunderstood me, what I wanted to know with my question was if
>> there's a way to do this (elseif) in Erlang in a syntactically short and
>> easy way without getting nested expressions.
> You have two issues here: brevity and nesting.
> Brevity matters for frequent things, and in Erlang, this should
> not be a frequent problem.
> There's an important reason why it shouldn't be a frequent problem.
> Since not very long after Pascal came out, books and articles about
> how to be a good programmer started saying "DO NOT OVERUSE Boolean".
> Classic examples go something like this:
> function switch(S: SwitchNumber): Boolean;
> If switch(17) is true, does that mean switch 17 is on, or that it is off?
> Better to do
> type SwitchStatus = (Off, On);
> function switch(S: SwitchNumber): SwitchStatus;
> and then instead of
> if switch(17) then begin
> end else begin
> case switch(17) of
> On: ...;
> Off: ...;
> The character classification example was a textbook instance of this
> design antipattern. Instead of a bunch of Boolean tests
> is_restricted_upper(C) -> true | false
> is_restricted_lower(C) -> true | false
> is_restricted_digit(C) -> true | false
> there should be a single classification function
> restricted_character_class(C) -> upper | lower | digit | other
> I repeat, this is a classic antipattern going back over 30 years.
> So much for the brevity of what should be rare.
> Now to nesting.
> Algol 60 (but not Algol 68), C, C++, Java, Haskell, Clean, and SML
> all require nested expressions if you want more than one 'if' in
> an expression. Let's just take determining the sign of an integer.
> Algol 60 if x < 0 then -1 else (if x > 0 then 1 else 0)
> Algol 68 if x < 0 then -1 elif x > 0 then 1 else 0 fi
> or (x < 0 | -1 |: x > 0 | 1 | 0)
> BCPL x < 0 -> -1, (x > 0 -> 1, 0)
> C x < 0 ? -1 : (x > 0 ? 1 : 0)
> Clean if (x < 0) -1 (if (x > 0) 1 0)
> Haskell if x < 0 then -1 else (if x > 0 then 1 else 0)
> Erlang case x < 0 of true -> -1 ; false ->
> case x > 0 of true -> 1 ; false -> 0 end end
> Lisp (if (< x 0) -1 (if (> x 0) 1 0))
> or (cond ((< x 0) -1) ((> x 0) 1) (T 0))
> The parentheses in the Algol 60, BCPL, C, and Haskell examples
> are there to point out that the expressions are in fact nested,
> you don't really need them. All other parentheses are required.
> Does it really matter that much that only Algol 68 and Lisp in
> this list off non-nested multi-armed if (cond)? Why?
> Again, how-to-be-a-good-programmer textbooks have been warning
> for decades that complex ifs are probably wrong.
>> I ran some benchmarks on the examples I provided with lists of 30 elements
>> and there was no consistent efficiency winner in any of my examples but it
>> seemed that elseif1 (andalso & orelse) and the elseif5 (using exceptions)
>> was the slowest. I know micro-benchmarks is close to completely useless but
>> I just couldn't help myself.
> No, micro-benchmarks can tell you useful things.
> I'm not surprised by the exception handling approach coming last.
> I will say that on today's machines lists of 30 elements are probably
> far too short to get useful timings from, unless you are using hardware
> performance counters.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions