for -- else: what was the motivation?

[Avi Gross]

Interesting idea, Anton.

I would be interested in hearing more detail on how it would work.

Although much of programming has been centered on the Latin alphabet and
especially English, that may change. I can imagine a customized compiler or
interpreter that uses key words in the local language instead of for or
while or if or else or even import.

If a region of UNICODE was set aside, would it have to be as a sort of
additional ALT or shift key for anything, or just English characters or
would it be for abstract symbols that would be mapped to and from a long
list of reserved key words that may vary by locale?

A serious problem I have been noting is the interactions between
typographical paradigms never expected to interact. I mean special
characters allowed or expected that clash. An example in Python and many
other languages is regular expressions. When using a string of characters,
you may have to deal with the rules for evaluating a string of that type
and double up backslash characters or be carefully as a dollar sign or
curly brace might invoke a side effect and interpolate something into it.
But for languages that allow RE to be entered without a string as in /.../
you have to write it differently.

I noted other ways in which naming conventions and even sort of keywords
need special care. Consider a Javascript program in a browser that can read
and manipulate HTML and CSS. The rules for names in JS do not allow hyphens
while others often do. So the programmers making the structures in the DOM
had to twist things. To access something like font-type you ask for font
Type as an example by changing the identifier to camel case.

I sometimes have programs that combine R and Python somewhat
interchangeably and it highlights places the naming does not match. R
allows periods as parts of names as in my.data and almost anything
including spaces if you use grave accent quotes such as `one [identifier`
so it is perfectly valid to have a function call like `[`(x, 5) to mean
x[5] albeit explaining why that is useful is beyond the scope. Similarly
you can make all kinds of in-line functions between percent signs as in %*%
or %specialized computation% and you sort of make your own keywords albeit
Chris and others may rightly suggest they are something else rather than
the first level of syntax.

My point is that your idea may need to support keywords for disparate ideas
and languages.

On Sun, Oct 16, 2022, 6:20 AM Antoon Pardon <antoon.pardon at vub.be> wrote:

> Op 16/10/2022 om 00:50 schreef avi.e.gross at gmail.com:
> > This has been discussed so often precisely because I swear NO CHOICE of
> keyword would satisfy everybody! Most languages start with designated
> keywords and some reserve a few for later use. But then things can get
> frozen in place to avoid breaking existing programs or break older
> compilers/interpreters.
> >
> > Some languages use techniques to extend themselves more harmlessly such
> as creating a singleton object that has content that can be regular data as
> in math.pi, or functions/methods or new ides like "Symbols" that allow all
> kinds of extensions to the language in a fairly harmless way as no older
> program would likely have used features that did not exist.
> >
> > That might not easily solve this problem. But I wonder if reserving some
> kind of prefix might help, so anything like extension.0nNoBreak could be
> added to a loop as a final clause and be treated as a non-key keyword of
> sorts.
>
> My idea would be to reserve different unicode blocks for the keywords
> and the identifiers. e.g. We could reserve the mathematical alphanumeric
> block for keywords and all other letters and numbers for identifiers.
> Doing so would allow extenting the keywords without breaking programs
> that already use that combination as an identifier.
>
> Python could slowly transition in this direction by first allowing the
> current keywords to be in this block. Every new keyword would only be in
> that unicode block. If would then be possible to write python code with
> this convention but it wouldn't be obligatory. After some time the
> python developers could decide to make it obligatory.
>
> I doubt this will idea will get from the ground, but I think it would
> allow for a smoother transition into new concepts, as it is no longer a
> strugle searching for a keyword that will break as little programs as
> possible.
>
> --
> Antoon Pardon.
> --
> https://mail.python.org/mailman/listinfo/python-list
>