[Fluxus] Turtle builder

[Kassen]

On 1 August 2010 17:29, gabor papp <gabor.lists at mndl.hu> wrote:

> hi Kassen,
>
> Hey, Gabor!


>
>>  i think you are right, but since turtle is not a primitive, but a
> primitive builder, it would require much more changes than a couple of lines
> of code like the (get-turtle-transform) was. it would also infer other stuff
> like (build-turtle-builder), maybe using (rotate) and (translate) instead of
> (turtle-turn) and (turtle-move) like we discussed about the lights.
>
>
Clearly, yes..... but we can dream :-).

It's not even clear to me why it would be bad if primitive builders would
themselves be primitives too. Maybe this would be bad, maybe the universe
would implode. Maybe it'd be great fun. I do think that right now the turtle
is so different from the rest that it can get a bit confusing.

Perhaps the most important thing is wondering what the turtle is meant for
and going from there. Is it supposed to be a easy entrance into computer
graphics (because of it's ancestry)? In that case it might make sense to
have it work in a different way to the rest and perhaps even have a cute
turtle icon as Luis suggested. Perhaps it's meant to be a good introduction
to using Fluxus, in which case more consistency could be a good idea.
Perhaps it's meant for unusual, advanced and experimental techniques, in
which case building our own turtle army could make sense.... I don't know,
maybe nobody does. Maybe it's best to leave it be until we know?


>
> additionaly, i think there are a couple of choices in fluxus that could be
> a bit more logical, like
> - (turtle-prim) requires numbers to specify polygon face type instead of
> symbols as opposed to (build-polygons)
>

That's weird, yes.


> - you can either switch on or off a (hint-...), but not both.
>

Sorry, lost me. Why would I want to turn a hint both on and off?


> - naming inconsistencies like (hint-wire), (wire-color), but (line-width),
> (line-pattern)
>
>
Yes! Those are easy to fix though;

(define (wire-width foo)
    (line-width foo))

Compatibility is the only reason I didn't add that to my own fluxus.scm file

so it would need a lot of effort and discussion to find out how we could
> make fluxus more logical. on the other hand, we all got used to these things
> and probably prefer quickly adding new features than perfecting old ones.
> although it would be nice to collect and sort out these issues, and make
> fluxus more logical and easier to use.
>
>
I agree. There is only a real issue if the stuff that we have starts
interfering with building new things on top of it. I think it all works
quite well, really. It'd be good to keep a eye on consistency but aside from
the minor issue of "line" and "wire" I don't think I see any real problems
right now. I do find it useful to ask questions whenever I find things
confusing though; either I learn something or we get something on the list
of stuff that might need clarification or change; it's win/win.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20100803/ae34b7b0/attachment.html>