OT: Programmers whos first language is not English

[Stephen Horne]

On 15 Mar 2003 14:08:28 -0800, anamax at earthlink.net (Andy Freeman)
wrote:

>Stephen Horne <intentionally at blank.co.uk> wrote in message news:<2mg47vg08fs23nd4fh8eh9trp3hbkq1jad at 4ax.com>...
>> On 14 Mar 2003 12:43:42 -0800, anamax at earthlink.net (Andy Freeman)
>> wrote:
>> >I've found that the time/energy/etc saved by folks who omit "unnecessary"
>> >grouping elements (parentheses, curly brackets, etc.) is dwarfed by the
>> >time spent fixing problems due to omitting said "unnecessary" elements.
>...
>> >It would be okay to omit "unnecessary" parens in a hidden representation,
>> >but the display and authored representation should have them.
>> 
>> We're not discussing something that programmers are meant to read and
>> write. We're discussing a marked-up-text format that will be read by
>> compilers and programmers editors, but not by people.
>> 
>> And NO-ONE MENTIONED OMITTING "UNNECESSARY" PARENS.
>
>Really?  If a human sees or writes expressions like
>"a + b * c << d | e & 37", we are talking about omitting "unnecessary"
>parens.
>
>Yes, such expressions can be well defined and parsed.  The problem is
>that the parser's capabilities exceed what humans can reasonably do
>in this area.  That expression is almost certain to be "wrong", and
>there's nothing that the parser can do to detect the error.  Moreover,
>the parser's abilities made the error possible.
>
>Operator precedence has basically been a disaster.

It seems I missed your intention in your original post - seeing it as
criticising something where you'd missed the point rather than as
introducing a new topic.

Sorry.

I'm not looking at one problem - I'm looking at many problems but only
one or two have been topics for this thread. Intentions for the
visible syntax of this new language have not been a topic for
discussion so far, except in the sense of whether keywords should
automatically reflect the local language.

Another idea I have, for instance, is to use multiple dispatch as an
alternative to dynamic typing with easily-defined closure-based
'templates' to avoid any resulting duplication and type-inference to
avoid every local variable needing a declared type. An advantage would
be that, being statically typed, it would allow qualifiers to be
defined for function parameters when they are defined. For instance...

  def add (var list x, (int | float) y) :
    x = map (x, lambda (int | float) a : a * y)


As it happens, my view about infix operators is somewhat different to
the conventional view. Conventionally (for languages which support
infix operators) every operator has a precedence relationship with
every other operator. I will probably have small groups of operators
with precedence relationships within the groups - such as multiply
having higher precedence than add - but with parentheses _required_ to
mix groups in the same expression.

Using presentation rather than semantic spellings, one group would
be...
  +, - : left-to-right
  *, / : left-to-right

Another group would be...
  <<, >> : left-to-right

Assignment would be special - either considered the lowest priority
operator in all groups, or perhaps separate from the precedence groups
- so that you could write...

  x := a*b + c*d - 1;

...or...

  x := a << b;

...but you could not write...

  x := a * b << c * d;

... you'd have to rewrite it explicitly as either...

  x := (a * b) << (c * d);

...or...

  x := a * (b << c) * d;

The basic logic is that in mathematics, precedence is actually quite
limited - I remember the old 'BIMDAS' for example. Precedence between
boolean logic operators is largely based on 'and' being considered a
'product' and 'or' being considered a 'sum'. AFAIK there is no
precedence relationship defined between 'and' and '*' in mathematics -
though of course I could be wrong.

I should emphasise that this *is* an experiment. Normally, I'd say
that the judgement of which parentheses are necessary is the
programmers responsibility, but that if the programmer does not use
parentheses when needed for readability that is clearly bad style.

If there are some clear enough readability rules that the compiler
and/or editor can spot at least some confusing cases and complain -
all the better. The worry is that it is also likely to nag in cases
which are actually perfectly clear. The distinction between helpful
suggestions and pointless nagging will no doubt be a subjective one.


>And this is a real problem in what universe?  (On the rare occasions
>that I've run into the 30 keyword version, it was easy enough to solve
>with a simpler mechanism that scales to an arbitrary number of new
>keywords.)

Seemingly every new Python syntax proposal throws up
is-the-new-keyword-good-or-bad debates. Many throw up ridiculously
bizarre syntax suggestions to avoid creating a new keyword.

There are other ways around this, such as an enforced naming
convention (eg a case convention) or using a prefix symbol to say
'this is a keyword' or 'this is an identifier'. But this is only *one*
of the reasons for using an XML notation.

My reasons for wanting to mark up the basic plain text of source code
go from wanting to store case/builder-like settings in a sensible way
(storing pure semantics) right down to wanting to highlight the key
parts of an algorithm in bold or with a different colour to
distinguish it from validation and other necessary-but-distracting
housekeeping code and thus improve readability (pure presentation).

If I have one solution to all of these problems, the existencee of
alternate solutions to a few of them is irrelevant.