Re: [ba-ohs-talk] GUI Ideas and NODAL
Lee Iverson wrote:
> 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... (01)
Yes. I think I am looking at it from an access perspective, which is
possibly not the view you are taking.
So, I might well be missing something crucial. (02)
>From an accessing perspective: (03)
Take Perl for instance.
A hash (map/dictionary in other languages) in perl is accessed by
$value = $hashname{$keystr}; #in perl (04)
No difference between that and a struct in perl really. In fact, perl
basically deals with objects as hashes.
So map and struct are definitely very similar, if you ignore the fearsome
datatyping of certain other languages.
Now, in NODAL, datatypes are a property set on the Node, but otherwise
everything is treated as a Node object. Is that correct? (05)
So in a strongly typed language like C++ I might declare a map as
map<Node, Node>; //in C++
And if we escape from the specifics of the C++ language, me might well be
talking
Node <= {[Node <link> Node] && [Node <link> Node], ...} (06)
And to approach the sequence...
float f = arrayname[index]; // in C/C++
The difference between an array and the hash above is in the index for
addressing. It's restricted to an integer value. Again in NODAL do we have
to worry about datatyping in that structure?
Node <= {[Node <link> Node] && [Node <link> Node], ...}
So the only difference between a map and a sequence in terms of accessing
the contents is the restriction on the key type.
(And it wouldn't surprise me if that was what perl was doing under the hood
in reality when you use arrays.) (07)
Now, isn't it the case that in order to perform operations on Nodes, you
have to check their datatype property after accessing them? (08)
So then, I think I'm really asking, if NODAL is above the particulars of
datatyping in a specific programming language (is it?), then does it make
sense to specify a uniform approach to the data storage that is independent
of the particulars of structs, maps, and sequences? (09)
Cheers,
Peter (010)
----- Original Message -----
From: "Lee Iverson" <leei@telus.net>
To: <ba-ohs-talk@bootstrap.org>
Sent: Monday, November 12, 2001 9:21 PM
Subject: Re: [ba-ohs-talk] GUI Ideas and NODAL (011)
> 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.
>
> 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...
>
> > > 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?
>
> 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.
>
> --
> --------------------------------------------------------------------------
-----
> Lee Iverson
> leei@telus.net #105-2700 Acadia Rd., Vancouver B.C. V6T
> 1R9
> http://www.ai.sri.com/~leei/ (604) 222-9312
>
> (012)