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
1R9
http://www.ai.sri.com/~leei/ (604) 222-9312 (05)