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?
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?
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)+4The 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.
On 26/11/2021 01: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
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?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.
On 26/11/2021 01: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
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?
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.
On Friday, November 26, 2021 at 1:33:12 AM UTC-6, Dmitry A. Kazakov wrote:
On 2021-11-26 02:39, luserdroog wrote:
Digging back into the source code of my olmec language, I rediscoveredThe parser I use can add missing parenthesis and also infer infix
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
operators, e.g.
A B + C ---> A * B + C
It's conceivable that right parens might become pretty scare, since allNo, because the place of the missing parenthesis cannot be inferred:
precedence the same and all associativity is right-to-left (like APL).
Awesome?
A + B + C)
A + (B + C + D))
etc.
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.
On Friday, November 26, 2021 at 11:34:33 AM UTC-6, James Harris wrote:
On 26/11/2021 01: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
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?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.
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.
no ambiguity
On Fri, 26 Nov 2021 17:34:32 +0000
James Harris <james.harris.1@gmail.com> wrote:
On 26/11/2021 01: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
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?
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.
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]".
On 27/11/2021 09:37, Rod Pemberton wrote:
On Fri, 26 Nov 2021 17:34:32 +0000
James Harris <james.h...@gmail.com> wrote:
On 26/11/2021 01: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
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?
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.
I believe your response was serious and genuine, but I can't help thinkI wasn't messing with him at all and I wasn't thinking about C. It's
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]".
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.
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.
Again again, parens are only inferred at the edges. Hard edges that
already exist.
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 toAnd again, parens are only implicitly added at the outside edges of expression. The programmer has to add any important ones that
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.
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.Is that allowed in code golf, that you can just make up your own
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.
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 thatMy 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.
already exist.
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?
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, [...]
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 21:18:19 |
| Calls: | 6,646 |
| Calls today: | 1 |
| Files: | 12,190 |
| Messages: | 5,327,493 |