[pg]

Numbers are represented using pairs. Specifically

  (lit num (sign n d) (sign n d))

where the first (sign n d) is the real component and the second the imaginary component. A sign is either + or -, and n and d are unary integers (i.e. lists of t) representing a numerator and denominator.

[sillysaurusx]

Is an implementation compliant if it ignores this definition for the sake of performance?

One nit with this definition is that it implies the car of a number would be a well-defined operation. For complex numbers, it would be natural for car to return the real component.

I admit, it was surprising you are defining numbers at all. It’s tricky to pin down a good definition that isn’t limiting (either formally or for implementations).

I once got most of Arc running in JavaScript, almost identical to your original 3.1 code, and FWIW it was very fast. Even car and cdr, which were implemented in terms of plain JavaScript object literals, didn’t slow down the algorithms much.

But I suspect that requiring that (car x) always be valid for all numbers might be much more tricky, in terms of performance.

I apologize if you have already explained that implementation isn’t a concern at all. I was just wondering if you had any thoughts for someone who is anxious to actually implement it.

EDIT: Is pi written as 31415926 over 1000000?

[pg]

I don't expect implementations to be compliant. Starting with an initial phase where you care just about the concepts and not at all about efficient implementation almost guarantees you're going to have to discard some things from that phase when you make a version to run on the computers of your time. But I think it's still a good exercise to start out by asking "what would I do if I didn't count the cost?" before switching to counting the cost, instead of doing everything in one phase and having your thinking constrained by worries about efficiency.

So cleverness in implementation won't translate into compliance, but rather into inventing declarations that programmers can use that will make their programs dramatically faster. E.g. if programmers are willing to declare that they're not going to look inside or modify literals, you don't have to actually represent functions as lists. And maybe into making really good programming tools.

As I said elsewhere, half jokingly but also seriously, this language is going to give implementors lots of opportunities for discovering new optimization techniques.

[julian37]

Something like 5419351 / 1725033 requires fewer digits (or bits) and gives a much better approximation, off by e-14 instead of e-8.

http://mathworld.wolfram.com/PiContinuedFraction.html

[foldr]

Doesn't this allow four distinct representations of zero?

[pg]

An infinite number, in theory. Even (sign n d) does, since you can have anything in d.