[erlang-questions] erlang improvement - objective c (or smalltalk) syntax
Richard O'Keefe
ok@REDACTED
Fri Jun 5 08:21:27 CEST 2009
On 5 Jun 2009, at 2:18 am, David Mercer wrote:
>>> Didn't you (or was it someone else? I can't find that message in the
>>> archives) suggest for some time ago a different but similar way to
>>> represent function calls, something like
>>> string:substring(String)from(Start)length(Length)
>>> ?
>> That was suggested by Richard A. O'Keefe.
>
> And if I recall correctly, a compromise could be done using tuples.
> E.g.:
>
> string:substring({S, from, I, length, J})
I have seen Prolog code written in this style:
substring(string(S), offset(O), length(L)) :-
...
?- substring(string("foobar'), offset(2), length(3)).
where the point was to ensure that incorrectly named parameters
would cause a match failure. It was a real performance killer.
Whenever a question of 'compromise' arises, one has to ask
what benefits are being traded for what costs.
- Paul Lyons-style split procedure names:
A compiler extension only, and not a large one.
The code that is generated is EXACTLY the code that
would have been generated had you written a normal
call in the first place.
There is NO change to the run time system.
Compile-time detection of incorrect calls within the
current module, load-time detection of incorrect
cross-module calls.
- Joe's proposal:
I can't tell, but I suspect that he's looking
for a compile-time approach.
- This proposal:
Extra data is constructed on the heap just for checking.
This takes extra time.
Even the arity cannot be checked until run time.
- This proposal amended to use records:
Some compile-time checking
About half as much extra data.
So what are the goals of a proposal along these lines?
- Code should be clearer to read.
- There should be zero performance cost for using it.
- The implementation cost should be low.
- For old code to be able to call new code (callbacks, &c)
it should just involve name mangling
- The earlier errors can be detected the better.
More information about the erlang-questions
mailing list