Superparens ... awesome?

[luserdroog]

Digging back into the source code of my olmec language, I rediscovered
that it allows "superparens". That is, it can infer any missing parentheses
on the outside edges of expressions. So you only need to add whatever
inner parens might be needed to disambiguate. eg.

2*3)+4

It's conceivable that right parens might become pretty scare, since all
precedence the same and all associativity is right-to-left (like APL).

Awesome?

[Dmitry A. Kazakov]

On 2021-11-26 02:39, luserdroog wrote:
> Digging back into the source code of my olmec language, I rediscovered
> that it allows "superparens". That is, it can infer any missing parentheses
> on the outside edges of expressions. So you only need to add whatever
> inner parens might be needed to disambiguate. eg.
>
> 2*3)+4

The parser I use can add missing parenthesis and also infer infix
operators, e.g.

A B + C ---> A * B + C

> It's conceivable that right parens might become pretty scare, since all
> precedence the same and all associativity is right-to-left (like APL).
>
> Awesome?

No, because the place of the missing parenthesis cannot be inferred:

A + B + C)

A + (B + C + D))

etc.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[James Harris]

Not awesome!

One advantage of syntax and semantic checks is to prompt a programmer to
make code unambiguous. If a compiler started to guess at how a piece of
code should be corrected then it might make different guesses from what
a programmer would expect.


--
James Harris

[luserdroog]

Well, it may not actually be useful. But by my definitions, it isn't ambiguous.
Parens are only inferred at the edges. So for your two examples, it wouldn't
change anything really: an extra open paren '(' would be added to the left
edge.

[luserdroog]

That's true and all. But with the superparens, they're only added in cases
where there's no ambiguity. If it were Lisp, it would save you from counting
and closing all your stuff at the end. You just stop. Hit enter. done.

[Rod Pemberton]

I believe your response was serious and genuine, but I can't help think
you were messing with this guy just a bit, especially given how the C
language handles this issue. C programmers routinely add parenthesis
to make sure the C compiler parses expressions the way the programmer
intended, and not the way C's precedence rules dictate. I.e., from the
programmer's perspective, the C compiler is "guessing", due to the
precedence rules, "at how a piece of code should be [understood]".


--
"If Britain were to join the United States, it would be the
second-poorest state, behind Alabama and ahead of Mississippi,"
Hunter Schwarz, Washington Post

[Rod Pemberton]

...

> no ambiguity

When does that exist? ...

Do you understand how a C expression is parsed without the parentheses?
I don't. I've been programming C for three decades. Without the
parentheses, I have to look up the precedence rules in a table in a
book, largely because they're not what I would expect and there are too
many of them to easily remember. In general, C programmers add extra
parens, because no one knows what those rules are, especially since
most C programmers don't have the correct book, or any book for that
matter, nor the C standard available.

Also, the other guys posting here haven't decided to do things the same
way even for simple math operators, which are well defined by an
entirely different field, i.e., mathematics versus computer science.
So, why would you expect someone else reading your code to come to the
same conclusion as you as to how to properly interpret the placement of
parenthesis or how precedence rules should be applied? E.g., about 2
billion people read right-to-left. That's alot of people. Do the
other 5 billion people who read left-to-right get to say that they're
wrong?

[Dmitry A. Kazakov]

No, the rightmost "stub" which in presence of mixed parenthesis and
commas it could be different, e.g.

A + C [ D + F ) ]
^
| stub

In my parser it could be even further to the right, but that would
require inspection of the operators stack before rolling it up.

[James Harris]

I wasn't messing with him at all and I wasn't thinking about C. It's
just a general principle that autocorrections may guess wrong.

If you think C's precedence rules are hard to remember just imagine
having to remember what autocorrections a compiler might apply. It would
be a complete nightmare!

Where autocorrections can be useful is in allowing a compiler to try to
compile more code and report more errors from a single run but it
shouldn't produce an object module from code with any errors in it, IMO.


--
James Harris

[luserdroog]

I think you're right that precedence and superparens wouldn't work well
together. But they don't have to! Olmec is a variant of APL: no precedence.
Ok, there's a slight bit of precedence between adverbs and verbs
(or operators and functions, or higher level functions and primitive functions).

And again, parens are only implicitly added at the outside edges of
expression. The programmer has to add any important ones that
govern how the expression executes. You're just allowed to omit
extra opening or closing parens at the start or end of the expression.
Expressions are already delimited by line breaks. There are no provisions
for "line continuation" or similar.

I maybe forgot to explain the weird set of goals for this language.
It's intended to be a compromise between a nice general purpose
language and a golfing language. And for the golfing side, being able
to just rip out extra bytes seems like a big win.

Again again, parens are only inferred at the edges. Hard edges that
already exist.

[Bart]

On 27/11/2021 13:42, luserdroog wrote:
> On Saturday, November 27, 2021 at 4:16:55 AM UTC-6, James Harris wrote:

>> Where autocorrections can be useful is in allowing a compiler to try to
>> compile more code and report more errors from a single run but it
>> shouldn't produce an object module from code with any errors in it, IMO.

> And again, parens are only implicitly added at the outside edges of
> expression. The programmer has to add any important ones that
> govern how the expression executes. You're just allowed to omit
> extra opening or closing parens at the start or end of the expression.
> Expressions are already delimited by line breaks. There are no provisions
> for "line continuation" or similar.
>
> I maybe forgot to explain the weird set of goals for this language.
> It's intended to be a compromise between a nice general purpose
> language and a golfing language. And for the golfing side, being able
> to just rip out extra bytes seems like a big win.

Is that allowed in code golf, that you can just make up your own
language to gain an advantage?

Because what stops someone creating a language with a single,
1-character keyword that will perform some specific task?

Or maybe the implementation (on top of some common language or platform)
is included... (I've never tried it).

> Again again, parens are only inferred at the edges. Hard edges that
> already exist.

My Casio calculator does that, but only at the right edge. I find it
convenient, but in that context, the right edge is also the end of the
'program'. Nothing else follows that might cause ambiguity.

[luserdroog]

On Saturday, November 27, 2021 at 8:06:33 AM UTC-6, Bart wrote:
> On 27/11/2021 13:42, luserdroog wrote:
> > On Saturday, November 27, 2021 at 4:16:55 AM UTC-6, James Harris wrote:
>
> >> Where autocorrections can be useful is in allowing a compiler to try to
> >> compile more code and report more errors from a single run but it
> >> shouldn't produce an object module from code with any errors in it, IMO.
> > And again, parens are only implicitly added at the outside edges of
> > expression. The programmer has to add any important ones that
> > govern how the expression executes. You're just allowed to omit
> > extra opening or closing parens at the start or end of the expression.
> > Expressions are already delimited by line breaks. There are no provisions
> > for "line continuation" or similar.
> >
> > I maybe forgot to explain the weird set of goals for this language.
> > It's intended to be a compromise between a nice general purpose
> > language and a golfing language. And for the golfing side, being able
> > to just rip out extra bytes seems like a big win.
> Is that allowed in code golf, that you can just make up your own
> language to gain an advantage?
>
> Because what stops someone creating a language with a single,
> 1-character keyword that will perform some specific task?

Yes, with restrictions. At codegolf.stackexchange.com (last I checked)
The language has to already exist at the time the challenge is posted.
So you can learn from previous challenges and improve your language,
but you can only use those improvements in future challenges (specifying
the version or release of the language that's required).

And a lot of special trickery has been specifically ruled out like
that program hc9++?? something something. It can work like cat or
cow or several other things. They really want it to be a real language
rather than just a swiss army knife.

[luserdroog]

Did I win? They're awesome, right?

I do quite like Dmitry's idea of inferring juxtaposition as an operator,
but I don't think I can use it for Olmec. The APL parentage already
interprets juxtaposition as (con)catenation. If you do happen to
end up with 2 distinct array objects juxtaposed in an expression,
then that could lead to a parsing or execution error. Or maybe one
or the other will get scooped up by a higher order function and yield
a function that operates on the other array. So, yeah. Can't use it.

[Tim Rentsch]

Rod Pemberton <noe...@basdxcqvbe.com> writes:

[...]

> Do you understand how a C expression is parsed without the
> parentheses? I don't. I've been programming C for three decades.
> Without the parentheses, I have to look up the precedence rules in a

> table in a book, [...]

Then shame on you. I have no sympathy.

[David Brown]

On 27/11/2021 10:50, Rod Pemberton wrote:

> Do you understand how a C expression is parsed without the parentheses?
> I don't. I've been programming C for three decades. Without the
> parentheses, I have to look up the precedence rules in a table in a
> book, largely because they're not what I would expect and there are too
> many of them to easily remember. In general, C programmers add extra
> parens, because no one knows what those rules are, especially since
> most C programmers don't have the correct book, or any book for that
> matter, nor the C standard available.
>

Most people have the internet available these days. It is not hard to
google for C operator precedence rules.

(It's not hard to find the free draft versions of the C standards
either, but that does not make them easy to read!)

A good reference for C is :

<https://en.cppreference.com/w/c>

The same site also has C++, and it is recommended and supported by the C
and C++ groups at ISO. It is a reference, not a tutorial, but worth
bookmarking for any C or C++ programmer.

And a good online compiler is a great resource for learning or testing
code. <https://godbolt.org> has a wide selection of compilers and
programming languages - I use it regularly in my work.

In the particular case of parenthesis and operator precedence, I think
the common operators are easy to remember, and are reasonably logical.
It gets harder with the rarer ones - primarily because you don't
remember things you don't use much.

I'm a fan of adding extra parenthesis, as long as they serve a purpose -
I write:

(x >= 10) && (x < 20)

To me, the only reason to write that without parenthesis would be to
brag about how the writer knows all the precedence rules. It is simply
clearer to group logical parts of an expression, and parentheses help
there - it's all clearer to the reader.

Local variables are free. Large expressions can be broken up in
separate lines with separate parts. This gives you more room, lets you
use names, lets you be clear about types, gives you place to add
comments explaining the purpose of the expressions, and makes it all
easier to maintain and friendlier for source code management, change
management and code reviews.


(This applies to all languages, of course, not just C.)