[m-dev.] Re: zero-arity higher-order function terms and apply/1

[Thomas Charles CONWAY]

> However, on second thoughts, it would be useful to allow zero-arity
> higher-order function types.  To create one, you would have to use
> a lambda expression.  E.g. given
> 
> 	:- func foo((func) = T) = T.
> 	foo(X) = apply(X).
> 
> then you would have to write
> 
> 	foo(func = math__pi)
> 
> rather than
> 
> 	foo(math__pi).
> 
> This is in contrast to other higher-order function types, where
> you can always just use the function name.  So it is a little
> bit non-orthogonal.  However, as far as orthogonality goes, I
> suppose it is no worse than disallowing zero-arity higher-order
> function terms altogether.
> 
> So, this suggests the following alternative change:
> 
>  | Allow zero-arity higher-order function terms.
>  | 
>  | compiler/typecheck.m:
>  | 	Allow apply/1.
>  | 
>  | doc/reference_manual.texi:
>  | 	Document that zero-arity higher-order function types, 
>  | 	insts, modes, lambda expressions, and applications
>  | 	are allowed.
> 
> Comments?  Anyone want to review this change?
> 

This looks good. I think it adds a useful amount of expressiveness
that well trades off any loss of orthogonality (though the previous
behaviour was, as you say, not exactly orthogonal).

BTW,
In the OpenGL developers list (or was it rec.games.programmer?) there
has been a nasty little flame war in which clueless bubblesort-in-asm
type programmers have described as 'meaningless jargon' this use of
the word 'orthogonality', as in "OpenGL is good because it is orthogonal,
but D3D is bad because it is not".
-- 
ZZ:wq!
^X^C
Thomas Conway               				      conway at cs.mu.oz.au
AD DEUM ET VINUM	  			      Every sword has two edges.