Library Preview: Turtle drawing!

[Max Goldstein]

About a week ago, Patrick brought up Logo / turtle graphics in Elm and I got nerd-sniped. Hard.

The result: A turtle library that supports many commands, animated and immediate drawing, and a few examples. It is not yet on the package server, but it's good enough to get feedback on.

I wound up creating a non-empty list library in support of the turtles, read this paper, and got to work on a non-trivial DSL. Technically, my library is a deeply embedded DSL, since the AST is represented with lists and a union type.

About a year ago, someone made a shallow embedding (representation is implicit in functions) in Elm 0.12.3 (thread, sprout, repo). The code is very brief and I'd have to examine it closely to figure out what it's doing. I stuck to the approach used in Mindstorms of issuing simple word commands with a number after them.

A few pieces of feedback I'm looking for:

• I think I want to parameterize a few things about animate and draw with an Options record. It would have be different for each. I want client code to be able to set the view window, random seed, animation stepper (e.g. Mouse.clicks instead of an fps ticker). Hopefully that won't make it too complicated for beginners.
• Are the names of the tags sensible? What were Papert's original names?
• Should I remove RotateTo and Teleport, since they position the turtle in absolute (not relative) terms and are ripe for abuse?
• Abuse by whom? Should I try to make this useful beyond new programmers?
• More examples are welcome.

Enjoy!

[Jeff Smits]

I really like the idea of turtle graphics, also as an intuitive way of teaching the basics of programming. So this is really cool! :D

That said, whenever you start working with angles in your examples, I cannot compute it in my head any more. Maybe some more intuitive way than trigonometic functions would help? 

On Mon, May 18, 2015 at 8:53 PM, Max Goldstein <maxgol...@gmail.com> wrote:

About a week ago, Patrick brought up Logo / turtle graphics in Elm and I got nerd-sniped. Hard.

The result: A turtle library that supports many commands, animated and immediate drawing, and a few examples. It is not yet on the package server, but it's good enough to get feedback on.

I wound up creating a non-empty list library in support of the turtles, read this paper, and got to work on a non-trivial DSL. Technically, my library is a deeply embedded DSL, since the AST is represented with lists and a union type.

About a year ago, someone made a shallow embedding (representation is implicit in functions) in Elm 0.12.3 (thread, sprout, repo). The code is very brief and I'd have to examine it closely to figure out what it's doing. I stuck to the approach used in Mindstorms of issuing simple word commands with a number after them.

A few pieces of feedback I'm looking for:

• I think I want to parameterize a few things about animate and draw with an Options record. It would have be different for each. I want client code to be able to set the view window, random seed, animation stepper (e.g. Mouse.clicks instead of an fps ticker). Hopefully that won't make it too complicated for beginners.

Go for it. As long as you provide a `defaultConf : Options` or some `animate'` that does the default thing, beginners can just use that and ignore config.

• Are the names of the tags sensible? What were Papert's original names?

I find `Make`  unclear. I also think the `Movement` type alias is making things more confusing, `List Step` is clearer. 

• Should I remove RotateTo and Teleport, since they position the turtle in absolute (not relative) terms and are ripe for abuse?

It makes sense for initialisation... I guess it's abuse because they're absolute, but I'm not sure you need to remove them. 

• Abuse by whom? Should I try to make this useful beyond new programmers?

I always liked the recursive drawings you can easily make with this. I think that's an advantage for non-newbies.  

[Patrick Ester]

Max, do you know when this will be available in Packages? I have a few students who may find this interesting.

[Max Goldstein]

I'm glad there's interest!

Part of what's been holding me up is the discovery of the other (old and non-working) library. I want to make sure my library can do everything it can do. In particular, I can't add more instructions to the union type without a major version bump, so I want to make sure I get it right. (Client code shouldn't be doing case statements on the tags, but if it did patterns matches could become incomplete.) The other idea is to keep the tags hidden and wrap them with normal functions. I might try that. OTOH, I might try to implement those fractals (I've already added the Branch instruction). Pedagogically, is it helpful to have those Capitals to break up the text?

Ahh, analysis paralysis!

[Evan Czaplicki]

Hide the tags!

Generally speaking, a strong abstraction boundary will not expose the constructors for union types. This way you can add to it without a major bump. I'm trying to think of exceptions to this rule, but I'm not really thinking of any :)

In the case of a library for beginners, having everything be lower case seems like it'll be nicer anyway.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Max Goldstein]

Then the tags shall be hidden!

This actually lets me document each one individually, and split up the advanced usage. Probably won't get to it tonight though.

[Max Goldstein]

Sorry it's been a few weeks but I've released the library!

Taking cues from Evan, the library is split into two modules. The Turtle module has the building blocks that children can start playing with. Turtle.Advanced has a lot of extra goodies for more experienced users. The cool thing is that most of the implementation is in Turtle.Core, which is not exported. Therefore, I can make tweaks to union types and such without a major release.

It's kind of odd if you think about it-- turtles are inherently stateful, and there's a lot of state that is tracked behind the scenes, but Elm is a functional language. I found myself writing wrapper functions in Advanced but they're leaky abstractions. If I wanted to add, say, more state to the evaluator to be able to fully undo these operations, I could. I probably won't in the near future though.

In the process, the nonempty-list library has matured quite a bit and hopefully someone will find it useful. It is used extensively in Core.

[Mike Clark]

Very cool, Max!

[Hassan Hayat]

Cool. I'm for promoting this library in elm-lang.org/try 

I know that there's already Graphics.Collage (which could use a good re-vamp btw), but this looks like a good library to teach kids how to code and it would be a shame to have it gated behind a command line.

[Max Goldstein]

Thanks Mike and Hassan! It would be great to have it on the website.

Off topic 1: In the discussion about animation, we mentioned elm-svg, elm-html, Graphics.Collage, and Graphics.Element as rendering backends, which we would want to be independent of. Maybe this library can be considered another such backend?

Off topic 2: I'd be interested in hearing ideas for improving Graphics.Collage in another thread. It hasn't changed much in the time I've been here.