Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> This is what happens when you have support for dozens of versions of a 
>> program in your file format. Not unlike C++.  "How about defining a 
>> source input format that can't be checked for syntactic correctness 
>> without a potentially infinite storage space?"  ;-)
> 
>   It's incredible how you find ways to bash C++ in every possible context.

Oh come on. I'm poking at you. :-)  C++ is just generally easy to poke 
at.  Any sufficiently crufty specification is going to have 
under-specified parts to it.

Making something too simple can be just as annoying. My latest annoyance 
at Erlang:

To receive a message, you write
   receive guard1 -> value1; guard2 -> value2; ... end.
That means when you get a message, it matches against each guard in turn 
until it finds one that matches. If it finds it, it calculates the 
associated value and consumes the message. If there's no match, it 
leaves it in the queue and idles until another message comes along.

Because of this, each [guard] has to not have any side-effects. In 
practice, this means you can only call certain built-in functions the 
compiler knows have no side effects (is_integer(), list_length(), test 
for equality, etc).

Sadly, the "if" statement (and "case" statement, slightly different) 
also use guards.
    if guard -> value; guard -> value; ... ; true -> value end
(the last if you want to guarantee a match, like "else").

The sad part is that it's the same guard, hence no side-effects, hence 
no user-defined functions. If you have three methods that might match, 
increasingly more expensive to calculate, and you want to know which it 
was, you can't write

   if my_cheapmatch(X) -> cheap;
      my_medium(X) -> medium;
      my_expensive(X)->expensive;
      true -> nope
   end

You have to write
   C = my_cheapmatch(X),
   if X -> cheap;
      true -> M = my_medium(X),
              if M -> medium;
                 true -> E = my_expensive(X),
                 if E -> expensive;
                    true -> nope
                 end
              end
    end

Kind of deeply nested for such a simple concept, and afaict there's no 
real reason to prohibit side-effects in the if statement since (unlike 
receive) it doesn't get retried in any sense.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message