neonumeric - C++ arbitrary precision arithmetic library

[Peter J. Holzer]

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!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/python-list/attachments/20210307/de02a2b6/attachment.sig>