Enhanced type guard syntax]
Fri Sep 19 13:34:45 CEST 2003
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.
More information about the erlang-questions