some questions (was Re: illegal guard)

[Pekka.Hedqvist@REDACTED]

Bob Smart writes:
 > 1.
 >  > One of the reasons for this is that guards
 >  > should be easy to implement and very fast to check
 > 
 > I can understand this in receive, but do all guards have to be so restricted?
 > For example it makes "if" prety useless. Mind you I worked out that you
 > should use "case <boolean-expression> of ..." instead of "if". However
 > that brings up another problem:
 > 
 > Why do some things, like atom(X), only work inside guards and don't
 > give boolean results elsewhere. This is a minor irritation when writing
 > filter functions.
I agree, for me its not obvious why all type check guards doesn't simply
return true or false outside guards and why do this work:
[X || X <- [1,2,3,a,f,[]], atom(X)].
[a,f]

and not:
4> lists:filter(fun(X) -> atom(X) end, [1,2,a,b,d,[]]).
** exited: {undef,{shell_default,atom,[1]}} **

but this works of course:
lists:filter(fun(X) when atom(X) -> true; (_) -> false end, [1,2,a,b,d,[]]).
[a,b,d]

 > 3. JVM?
 > 
 > I saw a claim that the JVM doesn't handle tail recursion well so
 > would be problematic for functional languages. Not sure where I saw 
 > this but on reflection I don't understand it. All you have to do
 > (in Java rather than JVM terminology) is wrap the function body in
 > "while(true) { ... }". When you want to do a tail recursion you just
 > do (as you would at machine level): change the parameter and "continue".
 > Obviously you have to exit such a routine with an explict "return val".
 > Am I missing something?

Kawa - the Scheme solves the recursion problem nicely. The major thing I see
is howto represent tagged data efficently, thats necessery in a dynamically
typed language like Erlang. Give each and every Erlang object and JVM 
object representation is neither fast or cost efficient.