neonumeric - C++ arbitrary precision arithmetic library

[Peter J. Holzer]

On 2021-03-08 09:29:31 +0100, Mirko via Python-list wrote:
> Am 07.03.2021 um 21:52 schrieb Avi Gross via Python-list:
> > 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.
> 
> Well, no I did not assume some kind of magical universal translator
> ala Star Trek. ;-)
> 
> The OP seems to claim, that he could compile any language by just
> providing a JSON schema file which describes the language.

Right. Using JSON is probably not the best choice (20 years ago
everybody was using XML for everything, now everybody uses JSON for
everything), but that's merely a question of readability. The
functionality doesn't depend on the (meta-)syntax.

> I assumed that those who tried this before did something similar. And
> that is what sounds logically impossible (or at least unfeasible) to
> me. How can one write a comparatively small descriptive schema that
> covers all of a language's subtleties in syntax, grammar, semantics
> and behavior?

How does one design a programming language which covers all the
subtleties in algorithms?

I think these are quite similar problems. Except that it has already
been proven that a very primitive programming language (the Turing
machine) is sufficient to describe all algorithms, and I'm not sure that
a similar prove exists for formal languages. Still, I think that the
latter can be reduced to the former (I compiler is essentially such a
description, so you could just use any programming language).

(Such formal languages exist, for example, for formal verification of
programs. I don't think any of these is truely universal, but I suspect
that the restrictions are more caused by having to be "provable" in the
mathematical sense and less with the variety in possible semantics.)

Where the OP is wrong, IMHO, is the "comparatively small" aspect. A
formal description of C will not fit into a few lines. The C standard is
670 pages, about 150 pages of which are the language proper (the rest is
library, concepts, etc.) All that information has to be expressed in
that formal language. Depending on the expressiveness of the language
such a formal description might be quite a bit shorter (or much longer)
than English prose, but it won't be dramatically shorter. And C is a
relatively small language ...

> I agree that my example wasn't good, since it would be just a matter
> of specifying operator precedence. But there are numerous little and
> large aspects to cover for any language. In the end, one would have
> to write a more or less full blown parser.

Yes, but writing a parser is (comparatively) easy. Parser generators
have existed for decades. It's the semantics that are difficult.

I'm not saying that you are wrong. I am saying that you haven't even
looked at the real problems yet.

        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/20210309/9be74d9e/attachment.sig>