Enhanced type guard syntax]

[Peter-Henry Mander]

Hi Vlad,

You're right, there is the issue of optimisation, which may bear on some 
languages. But can you give an example of what optimisations would 
vastly improve Erlang performance? If straight-line dragster performance 
is an issue, maybe Erlang is the wrong tool? It's strengths are 
elsewhere. I'm using Erlang as a Megaco signalling stress tester, and 
Jove! It beats the pants off commercial testing tools because it's power 
is in concurrency, not so much in single-threaded speed.

Maybe some elaborate and sophisticated data analysis on ordinary Erlang 
code would reveal optimisations that a simple human could not envisage? 
I would prefer a tool to do the grunt work and avoid me making mistaken 
"optimisation" judgements. Besides, if the algorithm is wrong anyway, 
then the programmer is the problem, not the language.

So we have (as a first draft) type strictness for:-

1) code correctness and proof at compile time

2) trapping errors at runtime,

3) compiler code optimisation pass.



Vlad Dumitrescu wrote:
> Just a short comment (for now :)
> 
> From: "Peter-Henry Mander"
> 
>>I think that if the prototype demonstrates the need for stricter types,
>>an experienced programmer/designer will introduce them as required, and
>>avoid the pain later, unless of course the design decision was wrong.
> 
> 
> What if the compiler will be able to optimize a lot more if supplied with type
> information? This has nothing to do with design, but depends on the specific
> compiler implementation.
> 
> I feel there are several issues at stake and that I can't separate them
> properly, so I'll take my time to think over properly.
> 
> /Vlad
> 
>