[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] More about dimensions (lists)
- To: zzdev@xxxxxxxxxx
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] More about dimensions (lists)
- From: Antti-Juhani Kaijanaho <gaia@xxxxxx>
- Date: Wed, 9 Aug 2000 19:30:24 +0300
- In-reply-to: <Pine.HPP.3.96.1000809104542.3933A-100000@xxxxxxxxxxxxxxxx>; from lukka@xxxxxxxxxxx on Wed, Aug 09, 2000 at 11:04:39AM +0300
- Mail-followup-to: zzdev@xxxxxxxxxx
- References: <20000809084048.F25335@xxxxxxxxxxx> <Pine.HPP.3.96.1000809104542.3933A-100000@xxxxxxxxxxxxxxxx>
- Sender: Antti-Juhani Kaijanaho <ajk@xxxxxxxxxxx>
On Wed, Aug 09, 2000 at 11:04:39AM +0300, Tuomas Lukka wrote:
> Would you draw the Z_7 modulus field as a circle or as a list?
As a circle. But one can look at it as an infinite list: it's a
representation of the result of map (\x -> x mod 7) [1,2,3,...] in
Haskell notation. (Of course, the Haskell version is unidirectional,
but a bidirectional one would not be too hard to come up with.)
> > A looping list can *also* be understood as a finite representation of
> > a repeating infinite list.
> Usually it's not intended to do that, I'd expect.
It's surprisingly common in nonstrict functional programming. But I'm
not so sure how relevant that is wrt ZZ.
Hm, are there any plans to introduce (generic) lazy structures in ZZ?
As in, assign to the current cell a procedure that produces a ZZ structure
starting from current cell poswards on d.foo; then move your cursor
poswards on d.foo, and the procedure is run until it produces a cell
there (with the new cell possibly containing a procedure to generate more
cells as needed); and as you traverse the structure, more of it will be
generated on demand? (just a crazy thought, but it could be useful in
modeling countably infinite structures)
> In a sense, then, wouldn't the proposal of explicificating many-to-one
> relations go agains this sense, too: the ZZ structure is a simple and
> powerful foundation; does it really *need* the standardized many-to-one
Then again, *if* it needs a many-to-one thing, a standardized one would
probably be a good thing.
> > How do d.1, d.2 and d.3 have any meaning at all? Why not call them d.foo,
> > d.bar and d.baz? They'd be about as descriptive.
> But longer and harder to remember for non-CSers. 1-2-3 is pretty easy
> to live with.
I was trying to make a point. I have difficulty understanding why we
need d.1, d.2 and d.3. Why not use some dimensions with names that *say*
something about the purpose of the dimensions? Such as d.list etc.
> Oops, I was unclear. By "free" I was referring to the three visible
> dimensions: the more of them somehing uses, the less easy navigation becomes,
> like Benjamin was saying.
Hm, BTW, couldn't we have a fourth dimension going from UR corner to
%%% Antti-Juhani Kaijanaho % gaia@xxxxxx % http://www.iki.fi/gaia/ %%%