nums in a reflective system

[Fare Rideau]

>>>>: Henry G. Baker
>>>: Kalman Reti
>>: Fare
>: Kalman Reti

> My point is that there are numeric values
> that you plausibly might need to store
> or manipulate as part of the operating system
> which exceed the size of typical lisp implementation fixnums,
Sure!

> hence the basic system might want to contain them.
Not *at all*!
Why the heck should all parts of the OS be written in the *basic* Lisp???
The very principle of a reflective system is that you write
every function in just the language and modules you need,
neither too low-level, nor too high-level.

It's the contrary of a bloated language where every single feature is defined,
and you find out that interactions between parts
are always overspecified or underspecified to you,
and you can't get what you want or extend the system efficiently.

So that your primitives that do file-sizes will either use
ADA-style number types or bignums, or whatever, but certainly not fixnums!
The compiler will choose the right optimization into fixnums.

Hence, software components using bignums will use a "bignum" package;
software components using quaternions will use a "quaternion" package;
software components using regexp will use a "regexp" package;
software components using odors will use a "odor" package;
software components using stereo voice recognition
will use a "stereo voice recognition" package.
software components using frobnitz will use a "frobnitz" package.
Every package will define enough syntax for domain-specific idioms
to be easy to read and write.
You can also selectively import syntax or not,
and pretty-print with this syntax or not,
so people not familiar with the domain-specific language don't have to use it,
but see stubborn constructs instead, like:
	(make-complex :real-part 3.4e-2 :imaginary-part 123.5)
instead of
	3.4e-2+1.235e2i
or
	(make-regexp "\\(\\.")
instead of
	m/\(\./


> Another example is a universal time.
> If you are going down to the bare hardware,
> you have to decide
> how to store and manipulate things like file-size, creation-date
> etc.
>
This is not a problem in a reflective system.
Basic lisp is meant for the really low-level layers of the system,
like implementing GC, bignums, I/O, etc.

System time et al will be accessed through high-level interfaces,
and the code generator will optimize in an implementation-dependent way,
from its knowledge of the way things will have been done by the basic lisp
on this particular architecture (e.g. on Pentiums, use the 64bit RDTSC).

Why overspecify such things as layout and datatypes,
when we can have high-level interfaces, and an optimizing compiler?
Just define an arch-dep function from basic primitives,
and let generic algorithms manage marshalling!
The result will be a system that's much faster than any
non-reflective implementation, where you spend most of your time
gratuitously complying to stubborn static low-level calling conventions.

>> The trap: basic != standard.
>> There can very well be a non-so-standard basic system
>> used to build standard non-basic system on top...


Chris Vogt also replied to hbaker:
> I couldn't disagree more strongly.  IMHO Bignums is one of the top 10
> reasons why Lisp is a superior language.
>
Sure. And we're not preventing anyone from using bignums as seamlessly
as one ever could with lisp.
That's just the matter of a (use-package 'bignum),
or (use-package 'cltl2), or (use-package 'r4rs).
The whole point is that we can now access things at a lower-level,
when we need do lower level things
(like implement and optimize bignums, GC, etc).

> It is all too easy to see integers overflow 32 bits, and wreak havoc.
>
Access to Basic Lisp should sure be restricted to superusers,
or run inside protected unixish isolation boxes.

> I'm not against the concept of
> having a "core" Lisp, but I think it would be a big mistake to leave out
> bignum support.
>
We're NOT leaving out bignum support.
We're moving it outside of the core lisp language,
into a lisp-implemented, lisp-optimizable, package.
Bignum syntax will be included by default with the bignum package, etc.
   Unless you mean that C and ASM shall be kept forever as implementation
languages in which huge bloated lisp systems shall be written.

#f