Tue, 30 Jan 1996 18:29:57 +0000 (GMT)
> Don't bother explaining the diversions to me. I just did my homework
> and now I understand. I've been translating biosapi.S. It's amazing
> everything you had to go through to sort the code fragments by segment
> etc... Wow!
Well, actually, I did not invent anything,
but just did my best to implement
the usual TASM segmentation using usual m4 macro style.
> I think I'll replace the sorting system by a function like
> (define (add-code! mode seg loc code) ...)
While there sure should be such kind of procedure,
I think we should be better off with a more
"object-oriented" (yuck), well, encapsulated, approach:
let's have code "segments" be represented as
"output ports" for type "sequence of instruction";
there would be defining words for
segments, groups of segments,
reverse segments (what I called revidsions in the m4 macros,
where code gets accumulated in the other way round).
Surely, we should first implement (or use some implementation of)
an encapsulation mechanism.
Scheme scoping just ain't any replacement for that,
least reflectivity be used in quite a dirty way.
Does anyone know any good encapsulation ("object") system for Scheme ?
BTW, as far as terminology is concerned,
I'd prefer we use "constructor/destructor"
instead of "constructor/detector", because of symmetry.
See the article in the latest Tunes glossary that I just published.
-- , , _ v ~ ^ --
-- Fare -- firstname.lastname@example.org -- Francois-Rene Rideau -- +)ang-Vu Ban --
-- ' / . --
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"