Jim Blandy wrote:
>> Is the ENTRY the same in both cases? And in DIR, if I'm
>> right, ENTRIES can be empty -- but "skel.h" doesn't allow an
>> empty list.
>
>
> No, ENTRY isn't the same in both cases. In a CLONE, the entry is just
> the name of the directory entry.
>
> Yes, ENTRIES can be empty. skel.h should allow an empty list; if it
> doesn't, that's a bug. An empty list is a skel_t whose `is_atom' and
> `children' members are both zero.
If you don't mind, I'll fix "structure" and "skel.h" to reflect that.
Tomorrow, that is.
>> Sorry for being so pedantic, but I'm trying to wrap my head
>> around this, and the questions just popped up. And don't
>> worry, I'll be asking more questions soon, no doubt. :-)
>
>
> No problem! If you can think of a simpler way to track cloning, do
> let me know. Keep in mind that the base revision can do arbitrary
> structure sharing, and in fact, will do so in everyday cases.
Hmm, yes, I was thinking about that. My very first thought was that
storing the entry name in the directory instead of in the node revision
could be less than a good thing, especially as any change in the tables
may have to touch more records than strictly necessary. But I haven't
thought my way throught that yet.
And anyway, it might be a good idea to just implement the spec as it is
now, and worry about design optimisations later. "Prematire optimisation
...", etc. ad nauseam.
> One thing to note about the syntax: I'm imitating the list structure
> notation used in Scheme. The `...' syntax is actually well-defined
> for describing list (or skel) structure --- it means zero or more
> repetitions of the preceding object. So (FOO ...) is a list of zero
> or more FOO's. ((FOO BAR) ...) is a list of zero or more lists, each
> of which contains a FOO, and a BAR. It's less general than writing
> out the recursion in BNF, but it's still very handy.
I guessed as much. I was just trying to make sure I understand what
we're talking about.
Tell you what, I'll fix this along with the "structure" and "skel.h"
changes I proposed, then I'll paste the whole thing as an appendix into
"structure", O.K.? I'm sure it'll help other readers understand what's
going on.
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:15 2006