Enhanced type guard syntax]

[Joe Armstrong]

On Thu, 18 Sep 2003, Eric Newhuis wrote:

> This is a wonderful suggestion.  I would welcome it.  Furthermore I 
> would also welcome compile-time checking in cases where it is 
> practical.  Such a small thing could be a stepping stone to some 
> ultimate type system.
> 
> > foo(A/integer, B/integer) ->
> >      A * B.
> 
> What is the runtime expense of performing such checks?

  It  depends upon  the  set of  patterns.  If we  have a  polymorphic
function like this:

foo(A/integer, B/...) ->
foo(A/integer, B/...)
foo(true, ...) ->
foo(bar, ...) ->

  Then  any  half  decent  pattern matching  compiler  could  generate
pattern matching code like this....

	switchOnTag Arg0 {
        	case integer: ...
	        case atom:   ...
	}

  But with no type information  the pattern matching code might be far
worse.

  My general feeling is that "the more you tell the compiler about the
program the better"
	
  As a programmer you shouldn't  think about how to write patterns, or
guards for efficiency - let the pattern matching compiler do that.

  If you  *do* make assumptions  about this your assumptions  may well
turn  out  wrong   in  the  next  version  of   the  system,  and  you
optimisations might turn into pessimisations


  /Joe


> 
> The technique I employ is liberal use of unit tests so I can avoid type 
> checking at runtime and gain a slight performance advantage.  But 
> perhaps this is an illusion?  What is the real expense?
> 



> Would this lead the way to a user-defined type system some day, one that 
> even supports recursive type definitions?
> 
> -type (blammo, [atom() | blammo()]).
> foo (A/blammo, B/blammo) ->
>     blammize (A, B).
> 
> Maybe I've been hanging around ObjectiveCAML too much.  M. Logan 
> probably thinks I'm crazy.  ;-)
> 
> -e
> 
>