some questions (was Re: illegal guard)

[Robert Virding]

Pekka.Hedqvist@REDACTED writes:
>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]

This is coming.  The latest suugestion is to create a number of type test 
functions "is_XXX(Term)" which will also be able to be used in guards as 
guard tests.  The reason for adding the "is_" prefix is to be more explicit 
that these are boolean tests and to get around the problem with float/1 
(think about it).

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

The problem is that with the JVM you can only "call" another function, even 
if it is the last thing you do in a function.  Wrapping it in a "while" 
does not help, this is how you transfer control.  This means that you 
always come back to the caller, but this is precisely what you DON'T want 
to do for the last call.  A "common" solution is to use a continuation 
passing style and explicitly carrying around a pointer of where you want to 
go after you are done.  This works in the JVM but apparently significantly 
slows it down.

	Robert