[cells-devel] Cells & Clozure CL

[Kenneth Tilton]

[I have taken the liberty of CCing cells-devel because it might be 
useful in the archive.]

Neil Baylis wrote:
> This cells.. is a good thing. Do you want to incorporate the changes I
> made to make it work under Clozure CL?

Nah, I am not really doing o/s any more. Thx, tho.

> 
>>From what I've seen so far, it looks as though it fits with my
> project, which is some kind of geometry/art tool for exploring
> tilings, tessellations, symmetries, etc.
> 
> The graphic objects will mainly be triangles and squares, and I'm
> still figuring out how I want to model them.
> 
> Take triangles: At first glance, it looks as though I would model a
> triangle with a cell. I would have some way to initialize it, and then
> slots to return attributes. E.g. if I specifed 3 sides, there would be
> slots that returned the angles (lazily). Another slot might return the
> area. That much I understand.
> 
> But there are more ways to create a triangle. I could specify 3 sides,
> or 2 sides and an angle, etc. I could also say "make it similar to
> that triangle over there, but the same size as that square over there,
> etc. So, it seems to me that each of those cases would require a
> different defmodel, because they would have different initforms. Is
> that right?

No. One of the most powerful features of Cells is an accident: OO works 
now, because two instances of the same class can have different rules 
(or a non-rule literal or an input cell allowing conventional procedural 
code to alter a slot) for the same slot. This means more reuse for a 
class, because normally the variation you describe requires one to 
forever be creating new classes. The only question is whether you go 
crazy and have just one class (say, polygon) or strike a middle ground 
and have classes for triangle, quadrangle, etc. I guess it comes down to 
how much you want to get out of method specialization, which obviously 
calls for a different instance type.

That said, I often create a class (a defmodel) just as a way of bundling 
up a bunch of rules. ie, They can as well be functions or macros with a 
make-instance 'polygon inside. I guess for debugging and inspecting 
specifically a different class can be of use.

You prolly do want a defmodel triangle, but going for isosceles might be 
a point of dimishing return.

> 
> Anyway, assume I have that sorted out. Then, I'll create a bunch of
> instances of these classes. I'd start by putting one of them in the
> middle of the canvas. Then attach others to it, as dependents.So, if I
> then change a dimension on the original object, that change would have
> to propagate to all the dependent objects so they resize themselves.
> That part sounds like cells to me.
> 
> The relationships will all be about geometry: coincident points, equal
> angles, similar figures, parallel lines, intersections, etc. "This
> triangle is rotated 45 degrees further than that one over there". And
> so on. Maybe circles as well, tangents, secants, etc. That's a lot of
> stuff right there.
> 
> I've attached an image of the kind of thing I want to do. This one I
> created in Inkscape, but the UI there is somewhat horrid and it's easy
> for cumulative errors to creep in. But that was built up entirely from
> small squares and triangles. It's a reproduction of a tile pattern I
> saw in Sydney Australia when I went there earlier this year.

Nice.

> 
> I was thinking I wanted a full blown geometric constraint solver, but
> I'm hoping that I don't need that. It's a lot of math  and other
> theory I want to avoid learning at the moment. Cells looks like it
> might do the trick. I need to get more familiar with it though.

Not sure where you need a solver, unless the idea is that you hope to 
specify just a few parameters and let a solver figure out a pattern that 
"works". Cells is not about that -- we specify all the rules and the 
Cells engine just sees to it that the rules run.

If you need something non-deterministic I would use Screamer+ to work 
out the hard stuff and have cell rules mine the screamer results.

> 
> 
> I also had a probably dumbass newbie question: Whenever I eval a
> (defmodel..) I get compiler errors, such as:
> 
> CELLS> (defmodel hello-cells ()
>   ((num :accessor num :initarg :num :initform (c-in 0))
>    (square-num :accessor square-num
> 	       :initform (c? (* (num self) (num self))))))
> ;Compiler warnings :
> ;   In an anonymous lambda form inside an anonymous lambda form inside
> an anonymous lambda form: Undefined function NUM
> ;   In an anonymous lambda form inside an anonymous lambda form inside
> an anonymous lambda form: Undefined function NUM
> NIL
> CELLS>
> 
> I imagine there's some delcaration I need to invoke to make that not
> happen. Any ideas?

I actually see that from time to time, but rarely. There must be 
something wrong with my eval-whens internal to defmodel. You won't see 
those on subsequent iterations, so ignore them (or go crazy and debug 
defmodel).

cheers, ken