mapping without map

[Gergely Mészáros]

Hi code.worder users and creators,

I'm Gergely Mészáros from Hungary and I like to express my gratitude to the author. It seems to be a project just I was looking for.

However, tinkering with code.word I was wondering why I can not map things. To my limited understanding (f)mapping is very basic operation in functional languages and I miss it very much.

I understand that the language tries to be simple. However excluding mapping actually makes the language more difficult to understand (imho).
For example I'd like to show to my kids how to transform a bunch of numbers to bunch of circles:

main = drawingOf (pictures circles)
numbers = [ 1..10 ]
circles = map circle numbers

Ooo.. so map is something what makes a bunch of this from bunch of that! Clean and simple. Or I can say we're applying the transformation of "circle" to my numbers. In line with the other functions I could use the uncurried version like map(circle, numbers).

Without map, I'm lost. Of course I could use list comprehensions or define my map as map f xs = [ f x | x<-xs ] but I see this much-much less trivial. I see [ circle number |  number <- numbers ] is quite cryptic for a newcomer (not to mention it's less generic). 

What is the official solution to get my maps? Can I import some module?
I'd rather stick with the kid's version without the full prelude (code.world/haskell).

[Chris Smith]

Right, you don't get map or filter in the standard library, without using the full prelude.  The replacement (as you suggest) is list comprehensions.  So instead of `map circle numbers`, you'd say `[ circle(n) | n <- numbers ]`.

I use this because it's similar to set comprehensions in mathematics, and it can be generalized to multiple parameters without writing lambdas (which are just as cryptic as list comprehensions!).  The second point is more significant than you might think as a Haskell programmer: without partial application (due to uncurried functions), map becomes a lot harder to use.

That all being said, I'd be okay with an optional exposed module in codeworld-base to re-introduce maps, filters, and folds.  (The existing "combined" function is a fold, but it's a limited one.)  Feel free to send a pull request for that.

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to codeworld-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/de0556a9-d19a-4283-a63d-ae4cb3c6104b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gergely Mészáros]

I see. Supposedly you have much more experience of teaching kids for coding, so I believe you. Maybe this is the good way. The main question was whether fmap is missing intentionally or whether I did something wrong.

However, I still consider that pull-request, despite my Haskell skill is very rusty, because:
1. In functional languages maps and folds are the loops. It's essential (and fun) even without the partial application.
2. map exists in almost every language from C++ to javascript. It is much more common than list comprehensions.
3. maps are very easy to understand. (might be the reason behind 2.)

I'm not sure about your lamdas argument. For maps (or folds) why do we need lamdas? Can't we just use named functions?
And in case of uncurried parameters we could map on zips (or not?)

Of course without partial application we wont be able to use funny things like transformerQueue = [ scale 1 2, rotate 10, translate 2 4, rotate 15 ] but because of the tuple parameters it would be hard to do with comprehensions either (or is there a way?)

---

On Monday, February 27, 2017 at 5:58:39 PM UTC+1, Chris Smith wrote:

Right, you don't get map or filter in the standard library, without using the full prelude.  The replacement (as you suggest) is list comprehensions.  So instead of `map circle numbers`, you'd say `[ circle(n) | n <- numbers ]`.

I use this because it's similar to set comprehensions in mathematics, and it can be generalized to multiple parameters without writing lambdas (which are just as cryptic as list comprehensions!).  The second point is more significant than you might think as a Haskell programmer: without partial application (due to uncurried functions), map becomes a lot harder to use.

That all being said, I'd be okay with an optional exposed module in codeworld-base to re-introduce maps, filters, and folds.  (The existing "combined" function is a fold, but it's a limited one.)  Feel free to send a pull request for that.

On Mon, Feb 27, 2017 at 7:53 AM, Gergely Mészáros <meszaros...@gmail.com> wrote:

Hi code.worder users and creators,

I'm Gergely Mészáros from Hungary and I like to express my gratitude to the author. It seems to be a project just I was looking for.

However, tinkering with code.word I was wondering why I can not map things. To my limited understanding (f)mapping is very basic operation in functional languages and I miss it very much.

I understand that the language tries to be simple. However excluding mapping actually makes the language more difficult to understand (imho).
For example I'd like to show to my kids how to transform a bunch of numbers to bunch of circles:

main = drawingOf (pictures circles)
numbers = [ 1..10 ]
circles = map circle numbers

Ooo.. so map is something what makes a bunch of this from bunch of that! Clean and simple. Or I can say we're applying the transformation of "circle" to my numbers. In line with the other functions I could use the uncurried version like map(circle, numbers).

Without map, I'm lost. Of course I could use list comprehensions or define my map as map f xs = [ f x | x<-xs ] but I see this much-much less trivial. I see [ circle number |  number <- numbers ] is quite cryptic for a newcomer (not to mention it's less generic). 

What is the official solution to get my maps? Can I import some module?
I'd rather stick with the kid's version without the full prelude (code.world/haskell).

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-disc...@googlegroups.com.
To post to this group, send email to codeworl...@googlegroups.com.

[Chris Smith]

Of course, fmap and map are different things!  Definitely fmap is missing on purpose, because there are no type classes and therefore no abstraction over functors.  I think if you're looking for type classes, you may as well swap to https://code.world/haskell and use the whole language.  List combinators are fine, though; I'd just like to keep them out of the prelude at first.

To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to codeworld-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/d65eb597-5eff-4b3c-acaf-22a94d3d211d%40googlegroups.com.