[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] GUI Ideas and NODAL

On Mon, 2001-11-12 at 12:58, Peter Jones wrote:
> >
> > Well, there are really a number of reasons to separate these out.  The
> > most obvious one in my mind is simply that manipulating these three
> > kinds of collections (from an object-oriented point of view) is very
> > different.  The operations performed on a Struct, Sequence and Map are
> > just completely separate.  A Struct has a fixed set of fields and one
> > may only assign new values to them.  A Sequence has a set of items of
> > uniform type and we can insert or delete subsequences or set individual
> > items.  A Map indexes its values via keys of a defined type and we can
> > either assign values to keys or remove keys.  It is certainly true that
> > we could emulate these behaviours with simpler constructs, but then we
> > would lose a great deal of the expressive power of our data modelling
> > language.
> [ppj] Or you might gain a powerful generalisation, depending on what you
> actually end up doing with the data.
> I see your point, but I'm just wondering whether it's possible to step
> beyond it by fixing aspects of the general (super)graph instead. Perhaps it
> becomes too complicated.    (01)

Convince me then.  I've used systems (LISP for example) with very
simple, general building blocks and seen them evolve toward richer,
more targeted ones.  It's a balancing act...    (02)

> > Well, you are ignoring the fact that various systems define line endings
> > very differently (e.g. line ending semantics on MS vs. Unix vs. Mac
> > systems).  The text encoding for exactly the same file is different on
> > these systems but the data model is identical.  (Properly then, the
> > "line" strings in such a file should exclude these line-ending
> > characters ("\r\n" in C parlance).  That is not to say that you can't
> > define a file type that is simply an undistinguished sequence of
> > characters for your own purposes.  It's not what I have in mind though.
> [ppj] OK. Neat. I like the approach you're going for. But if that's the
> case, why have you kept 'characters' as a primitive, and not just made the
> string type the primitive, leaving char[]'s up to the implementation
> concerned?    (03)

I also want a general addressing mechanism and using the Node types as
the primitives for this allows one to address *inside* of strings just
as one would address inside of any other collection.  The atomic types
are just that -- indivisible.  We gain from having strings as a
Sequence, and don't really lose anything.    (04)

Lee Iverson                    
leei@telus.net                 #105-2700 Acadia Rd., Vancouver B.C. V6T
http://www.ai.sri.com/~leei/   (604) 222-9312    (05)