[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