Language change proposal

[Robert Virding]

----- Original Message ----- 
From: "Chris Pressey" <cpressey@REDACTED>
To: "Richard A. O'Keefe" <ok@REDACTED>
Cc: "Erlang-Questions" <erlang-questions@REDACTED>
Sent: Friday, October 24, 2003 5:53 PM
Subject: Re: Language change proposal


> Ah, but the rivers of the Erlang support list are choked with the bodies
> of keyboard-pounding language designers, are they not?   Guardians of
> Truth and Beauty, each and every one of us, who do not seem to realize
> that Erlang is not a project in pursuit of perfect language purity.  It
> is, in fact, an exercise in return-on-investment (right, Mr. Ericsson?)
> 
> And defining a new predefined macro is just about as small an investment
> there is.
> 
> Take it one small step further and add -assert() to -ifdef() and
> friends, and I for one have a hard time explaining the difference
> between
> 
>   -requires_erlang('5.3').
> 
> and
> 
>   -assert(?ERLANG_VERSION, '5.3').
> 
> in terms that the average non-language-designing Erlang programmer would
> appreciate or care about.  So it would seem to me that this small
> investment gets a comparable return.  Perhaps even a greater one, when
> you consider the same -assert() mechanism can be used for any other
> macro already in use, predefined (like ?MACHINE) or otherwise.
> 
> So there you have a plausible case for using macros.

Being the original "Guardian of Truth and Beauty" I think you have missed the point, at least how I see it. If you want Erlang to be a good return-on-investment over a long term then you have to be very strict about what you allow in the language. Otherwise it will become full of little "features" that, separately, are all innocent but put together result in a complete mess, which is difficult to understand and maintain. And macros are definitely in this this category.

Mind you this coming from the person who actually added macros to the language! :-) To my defence I must say that I didn't want them myself and never really saw the benefit. They made me do it. Being in a playful mood I gave them much more than they originally asked for, for example arguments, and there is only one thing I really missed and that is allowing macros of the same name with different number of arguments. If you are going down you might as well do it properly.

But I still say the preprocessor should never have been added. Richard where is the Ada reasoning about a preprocessor described? If I had been able to come up with Richard O'Keefe's Abstract Data Types this would have been a much better solution.

In contrast to Joe though I don't see size in itself to be the main problem. The main things to worry about are to be extremely clear about the basic concepts in your language and keeping to them, and in being consistent. If two different things look similar then they should behave similarily, and vice a versa. That was one of my main critisms about the type checking in patterns, it broke the model of being able to put terms together and pull them apart by the same construct. I think that if you ARE clear and consistent then there is no basic problem in adding new features. Of course it is another question whether you NEED the new features. Implementing the union of everyones requests is a bad idea.

This is one of the problems I see with ETS tables. They don't fit into the basic Erlang model of how data is organised. Data is local to processes while ETS tables are outside. It is my view (and here I do agree with Joe :-) that everything should look like a process, i.e. you communicate with messages and you can link to it.

This is why you need guardians so that it will be clear and consistent. As I have said before one of our, the original implementors, main faults was not actually explaining and writing down our basic concepts. To us they were so clear they need no explanantion. Of course sometimes we weren't in agreement as to the concepts. :-)

Robert

P.S. I also implemented records. :-) Not my idea either. A struct like term would have been much better but there were reasons for not doing that, which I again think were wrong.