Turtle Graphics!

[Piotr Cyrankiewicz]

inspired by the other topic about recursive structures in Elm I hacked a small module to easily create simple turtle graphics

http://share-elm.com/sprout/5386626de4b07afa6f9814a9

please share your suggestions for API/code improvements

also, please share demos if you make anything cool with it :D

[Evan Czaplicki]

These look great! :D

Speaking of Turtle Graphics, this reminds me of an idea. Processing gives you access to a render loop so it's super easy for beginners to start doing stuff with mouse, dimensions, keyboard, state, etc. With the goal of letting people play around without knowing anything, I was thinking it could be possible to provide someone an API like:

playground : Stepper state -> Renderer state -> Signal Element

type Input =

  { mouse : { x:Float, y:Float }

  , dimensions : { x:Float, y:Float }

  , click : Bool

  }

type Stepper state = Input -> state -> state

  

type Renderer state = state -> Element

The idea is that playground would wire everything up, so you don't have to think about Signals to get started. I think this is not super related actually, but it's too late, it's written down! :)

--
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.

[Jeff Smits]

This looks quite nice :) You should create a library out of it. A naming discussion is easier on GitHub IMHO.

I accidentally found this when I fiddled with some values of one of your demos: http://share-elm.com/sprout/5387339de4b07afa6f981516/stable/view

As for API suggestions, I have some general comments: I prefer operators to be aliases of a normal (named) functions (though I don't mind names that work best when the function is used infix). For the naming itself, I usually prefer declarative names over imperative names.

[Piotr Cyrankiewicz]

This looks quite nice :) You should create a library out of it. A naming discussion is easier on GitHub IMHO.

I'm planning to :) 

I accidentally found this when I fiddled with some values of one of your demos: http://share-elm.com/sprout/5387339de4b07afa6f981516/stable/view

this was HARD for my browser, but the effect is quite disturbing (call it whatever you want I see a demonic face there :P ) 

As for API suggestions, I have some general comments: I prefer operators to be aliases of a normal (named) functions (though I don't mind names that work best when the function is used infix). For the naming itself, I usually prefer declarative names over imperative names.

yes, names would be helpful I guess, along with some docs, I'm not sure which names you find imperative though, could you elaborate? :)

 

These look great! :D

Speaking of Turtle Graphics, this reminds me of an idea. Processing gives you access to a render loop so it's super easy for beginners to start doing stuff with mouse, dimensions, keyboard, state, etc. With the goal of letting people play around without knowing anything, I was thinking it could be possible to provide someone an API like:

playground : Stepper state -> Renderer state -> Signal Element

type Input =

  { mouse : { x:Float, y:Float }

  , dimensions : { x:Float, y:Float }

  , click : Bool

  }

type Stepper state = Input -> state -> state

  

type Renderer state = state -> Element

The idea is that playground would wire everything up, so you don't have to think about Signals to get started. I think this is not super related actually, but it's too late, it's written down! :)

thats something I feel should have it's own thread once someone wants to implement it, (I might get to it one day, playgrounds are fun :) ) still, seems a lot of work just to take over someones lifting and foldping (pardon my elmglish)

[Evan Czaplicki]

On the naming topic, check out the library design guidelines: http://library.elm-lang.org/DesignGuidelines.html

I think relying on infix operators that do not have helpful, pronounceable names is very bad for comprehension. I think Haskell is hurt by the prevalence of "infix only" functions, and we should not copy that culture.

--

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.

--
Sent from Gmail Mobile

[Piotr Cyrankiewicz]

I reworked the API (I think it's much better and cleaner also it simplified the examples)

and here it is! https://github.com/piotrcyr/elm-turtlegraphics

issues are welcome :)

[Max Goldstein]

"and its trace". No apostrophe.

I would suggest renaming "bend" to "turn". The current name wrongly implies you're acting on a line segment and not the turtle.

Beyond that, a lot depends on who the target audience is. If you want to work towards Logo's original purpose of being accessible to small children, then the API will be a little cumbersome to adults. Alternatively, you could want to teach functional concepts by way of the turtle to teens. And if you use traditional programming or Elm idioms, it might be weird to the kids. But here goes.

Elm convention gently suggests that applying a function to a list should be named by adding an s to the end (e.g. merge and merges). This will likely confuse the little kids.

Consider leaving the turtle type undocumented and opaque. It doesn't matter anywhere else in the interface. It feels weird to introduce a turtle at a specific point, especially since it can't be reset later. A turtle isn't used anywhere except in trace. So: create a turtle in the center of the canvas within trace, and then follow the trace passed in. Or, say that all traces happen in a 100x100 box, and then rescale accordingly.

If the turtle leaves the type system entirely, maybe the name Trace deserves reconsideration. Instruction? I'd say Command but that's going to mean something else.

Hope that helps!

[Volker]

Hi Piotr,

I am new to Elm and tried to compile the library with

elm -m TurtleGraphics.elm

However, I got the following error:

Overlapping definitions for infix operators: >>

Any ideas?

[Joseph Collard]

In the latest version of elm, >> has been added as an infix function for function composition. It looks like he had defined an infix operator which is now overlapping. To get this working, you'll need to redefine >> to something else or use `join` in its place.

--

[Alex Shroyer]

Looks like a heavy metal album cover :)

 http://upload.wikimedia.org/wikipedia/en/e/ed/Meshuggah-Nothing.jpg