neonumeric - C++ arbitrary precision arithmetic library

[Avi Gross]

The precedence example used below made a strange assumption that the
imaginary program would not be told up-front what computer language it was
being asked to convert from. That is not the scenario being discussed as we
have described. In any particular language, there usually is a well-known
precedence order such as "*" coming before "+" unless you use something like
parentheses to make your intent clear and over-ride it.

But it makes me think of a related question. Assume you are writing code in
a language like Python and the language has been analyzed and all kinds of
info stored that describes it and that includes things like precedence rules
for operators. Suppose it works fine and YOU want to break it. Could you?

If your language supports constructs like creating what looks like new infix
operators as an example, or overloading existing ones, could you write
expressions this mystical product would interpret differently than the
original compiler or interpreter?

As an example, what does this simple statement mean:

A + B

I mean A can be an integer or floating point number or character string but
can also be a complex number or a data.frame  or just about any arbitrary
object. So can B. And in many cases, the operation is not at all Abelian and
B+A is something else. In many cases, the logic is to look at the right-hand
or left-hand variable and see if it has a method defined to be called such
as __ADD__ or __RADD__  or maybe  inherited such a method from another class
perhaps using some specific method with complicated multiple inheritance
scenarios. Or the language may choose to convert either A or B or both to
some other format and perform some kind of addition and maybe convert the
result to something. Lots of work is in the Python interpreter to deal with
this and some of it has to be flexible enough to deal with times when a
class or object is changed as the program runs. Might it be possible to
create edge cases that break a static set of description files? If not, how
much more complex must the imaginary program get to handle these challenges
and what might that do to the purported gains in efficiency claimed?

I am currently studying a language called Kotlin. They, like some other
languages, allow the creation of new infix operators and once I have defined
"myplus" I can write code like:

A myplus B

What if it would also allow me to specify dynamically what the priority of
"myplus" is? Clearly it cannot be a reserved keyword in some table loaded in
the language in advance. R lets me do something similar like create
"%myplus%" as an operator and even weirder things like rebinding "+" to mean
something else that no longer has a particular priority that was
pre-ordained.

So if we had a contest on finding ways to break a sort of general purpose
customizable any-language mangler, I wonder if it might be easy to mangle it
at first. To get around that, you might have to not handle languages you
declare as misbehaving, or make a more complex system that handles all known
cases. But even then, can we design a new language for the express purpose
of exposing some hidden flaw and make them deal with that?

New languages keep popping up, some with no prior intent on breaking
anything, but I think a universal translator may not be imminent.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net at python.org> On
Behalf Of Peter J. Holzer
Sent: Sunday, March 7, 2021 2:43 PM
To: python-list at python.org
Subject: Re: neonumeric - C++ arbitrary precision arithmetic library

On 2021-03-06 23:41:10 +0100, Mirko via Python-list wrote:
> I even wonder why they have tried. Writing a universal 
> compiler/interpreter sounds logically impossible to me, Here's a 
> simple Python expression:
> 
> >>> 3+3*5
> 18
> 
> And here's the same expression in (GNU) Smalltalk:
> 
> st> 3+3*5
> 30
> 
> 
> How would such a universal compiler know which evaluation strategy to 
> follow, if not by writing a parser end evaluator for every supported 
> language?

That depends on what you mean by "writing". If we stick to your example, you
would need to specify in some way that in Python * has higher precedence
than +, while in Smalltalk it doesn't. You could write some code in Python
or Smalltalk or C or Assembler or even for a Turing machine to do that. Or
you can write the grammar in some formal language (e.g. BNF) and let the
compiler interpret that (or generate native code from it and run that). The
latter is what a "universal compiler" would do and parser generators have
been around for a long time (they were nothing new when I studied CS in the
1980's). While there is still progress here (I've come across a few
interesting papers over the last year or so), I'd say that part of the
problem is solved.

The second part is converting a parse tree into code. I am quite sure that
it is possible to devise a formal language to specify the semantics of any
programming language and then to use this to generate the code.
However, I strongly suspect that such a language would be comparable in
expressiveness and ease of use to other programming languages - or in other
worlds it would be just another programming language. Certainly better
suited to compiler construction (otherwise why would you use it?), but
probably not massively so (unlike writing a Yacc grammar is a lot
easier/quicker than writing a top-down parser), So there wouldn't be a huge
incentive to use it unless you plan to write compilers for lots of
languages. On the other hand there are downsides: Such a generic system
might be slow and/or memory-hungry, it might not run on every platform, it
might have a steep learning curve, and it's probably not so well-suited for
non-compiler programs.

> And if it's hard for this simple problem, how about more complex 
> cases.

For this simple problem it's easy :-)

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"