[erlang-questions] EEP 40 - A proposal for Unicode variable and atom names in Erlang.

[Richard O'Keefe]

On 2/11/2012, at 10:37 AM, Dmitry Belyaev wrote:

> Comments inside the quoted text below.
> 
> -- 
> Dmitry Belyaev
> 
> On 02.11.2012, at 1:15, Richard O'Keefe wrote:
> 
>> 
>> On 2/11/2012, at 1:36 AM, Dmitry Belyaev wrote:
>> 
>>> I've looked through the proposal and don't understand why there are no proposal to add localized keywords?
>> 
>> Because that's actually an orthogonal concern.
>> ...
>> There is no point in allowing people to plug Serbian keywords
>> into a table if they will never be recognised as identifiers to
>> start with.  We have to get that part right first.
> 
> It is like to allow to type only variable names localized and do not allow atoms. No use if I cannot write all the text in the language I've chosen.

I did not say "no, never do it".
I said "We have to handle Unicode variables and atoms FIRST".

Step 1: recognise and distinguish between variables and atoms-or-keywords.

THAT is what EEP 40 is about.

Step 2: decide which atoms-or-keywords are atoms and which are what keywords.

If you want keywords in Hebrew or Malayalam or whatever, you have to do
step 1 first.

For that matter, if you are willing to begin keywords with a special
character (as Algol and IMP programmers had to), you can just

	-include('keywords/fr').
	... ?essayez
		...
	    ?attrapez
		...
	    ?fin

right now.  (%external %integer %fn %spec ring any bells with my readers?)

To repeat: I am NOT saying NO.
I am saying, let's get EEP 40 through *FIRST*.
Then you will be able to use ?slučaj (Croatian for 'case') or
whatever takes your fancy with _no_ extra support from the
Erlang/OTP maintainers right away.  You get _that_ much ability
to use localised keywords *sooner* than if you put that into EEP 40.

> What about your Māori students? Will you tell them they may write some parts of the program in their language and some other words they have to write in English?

No, I'll tell them about the macro trick.

>> (3) Ada and Python have not done this.
> 
> I don't think that pointing to other bad choices is good.

Considering the huge amount of design work that has gone into
Ada revision -- I once printed out a whole bunch of revision
documents and stopped when I had a pile 60 cm high and still
had a long way to go -- it's not clear that how bad a choice
it is.  As with EEP 40, it's not "no never" to localised
keywords, but "this _first_".

There are, after all, such things as preprocessors,
and at least keywords are not something you have to name in
a debugger in order to trace them or put breakpoints on them,
so unlike other identifier mapping, keyword localisation via
preprocessor actually works.
> 
> Yes, I'd choose "All or Nothing" option for all this proposal.

EEP 40 is *ORTHOGONAL* to localised keywords.
You could have localised (in Latin-1 only) keywords without EEP 40.
You could have EEP 40 without localised keywords.
You can have both.
You can, as I have already said, have EEP 40 AS A STEP TOWARDS
localised keywords.

Here's how it goes:

	- first one supports alternative encodings,
	  but still accepts only Latin-1 characters.

	- next one supports non-Latin-1 characters in comments.

	- next one supports non-Latin-1 characters in strings.

	- next one supports non-Latin-1 characters in identifiers.

	- next one supports non-Latin-1 characters in numbers.

	- and at any point along the route one can consider
	  localised keywords.