freenode/#clim - IRC Chatlog
Search
11:55:28
scymtym
beach: hi. i didn't push yet. i wanted to ask how you would like to proceed. e.g. would you like to review changes first?
13:14:18
scymtym
i have one immediate question, though: is making the project independent of SICL a goal and if so, should a/SICL's readtable implementation be a part of the project?
13:25:01
beach
I think the readtable must be part of it. And, yes, I would like it to be independent of SICL.
13:26:14
beach
Maybe later we can adapt it to the native readtables, but I think that is non-trivial.
13:35:11
scymtym
i thought about copying the simple readtable code in SICL, but you may be referring to https://github.com/robert-strandh/Claire ?
13:35:48
beach
No. Hold on. I thought I copied the readtable. Let me make sure I am not going crazy...
13:40:42
scymtym
assuming that, the starting point for extracting readtable stuff is Code/Readtable in SICL, right?
15:21:55
beach
nyef``: I think I made significant progress today with respect to the SICL bootstrapping procedure. Not in terms of code, but in terms of convincing myself that I can produce a viable image without an evaluator (no compiler, no interpreter) in it.
15:24:59
nyef``
I haven't gotten that far yet, but given the existance of Cleavir, I figured that things might have changed to the point that it might be out-of-date.
15:26:15
beach
I did extract the Cleavir-related stuff to a separate document in the Clevir subdirectory.
15:26:49
nyef``
Right, the Cleavir document is also on my read-queue (in fact, is already loaded in a pdf viewer).
15:29:48
nyef``
As ever, most of the work in programming involves the written word rather than code, right?
15:30:43
beach
I write way more comments than I used to, for that very reason. And they turn out to be extremely helpful when I return to the code after some time.
15:39:27
nyef``
Anyway, I did manage to read through the description of object representation, and I'm thinking that I might be able to put together an initial implementation of that in some form.
15:48:39
nyef``
Not exactly. More... the definitions and code fragments required to operate in terms of these data structures in the context of a Linux executable.
15:50:44
nyef``
The fragments themselves would have to be written in terms of CPU instructions. But I'd probably represent them as Common Lisp functions for producing the fragments as a stream or vector of octets.
15:52:25
nyef``
Does any of this copious documentation cover FFI or otherwise interacting with a host environment (even if it's "just" bare Linux syscalls)?
15:56:59
beach
Actually, that's not *quite* true. I did start sketching on a 2-level library for Linux syscalls. The lower level close to the native stuff with return codes and such, and a higher level that is closer to Common Lisp tradition.
16:01:41
beach
It got complicated when I had to decide on the definition of all those little structures that are necessary to communicate with the kernel.
16:02:48
nyef``
Mmm. Especially since there's a surprising amount of variability between implementations of the POSIX API, even at the level of the C APIs.
16:39:16
nyef``
... I am, once again, reminded that Common Lisp, as specified, is unimplementable: MOST-POSITIVE-BIGNUM exists. /-:
16:42:44
nyef``
Essentially, a BIGNUM has, in practice, some upper limit. This limit is either constrained by the representation of the number of "digits" that it can have or by the total memory available for storing those digits.
16:43:25
jackdaniel
I've skimmed linked document and it talks about one particular implementation - that it had such limitation
16:43:48
jackdaniel
bignums in ECL are implemented with libgmp and they may be arbitrary big (given enough memory)
16:44:07
jackdaniel
because *there is* a pointer to "another" chunk if the first one is insufficient to store it
16:44:49
nyef``
Hell, the other angle is to run out of address space, even if you have sufficient backing store.
16:46:04
jackdaniel
in linked article it is only said, that an array of limited size is allocated for bignums
16:46:33
jackdaniel
I don't think that limitations of the hardware (or operating system) count in such disputes
16:48:48
nyef``
Except that this is an argument of implementability, and thus the limitations are PRECISELY what matters, even if they don't count without using Peano arithmetic.
16:52:30
jackdaniel
one could argue, that "unimplementable" is a very strong assertion for something what is simply limited by a medium
16:53:37
jackdaniel
you may provide correct implementation for bignums of arbitrary size so it is only limited on how much medium permits
16:56:37
nyef``
Essentially, the specification explicitly requires that there be no upper bound for a BIGNUM. Any implementation that has an upper bound, for whatever reason, is non-conforming.
16:57:10
jackdaniel
it is not a limit of the implementation but a limit of the environment. It is a big difference (which imo is crucial here). Algorithm is correct if it returns correct result after a finite number of steps. Fact that it may run longer than universe (as a medium) exists doesn't make it any less correct.
16:57:12
nyef``
And this is a deficiency in the specification more than it is a deficiency in implementations.