On Mon, Apr 28, 2014 at 11:30 AM, John M. Dlugosz wrote:

On 4/27/2014 11:24 PM, Magnus Therning wrote:

...

It most likely sees it as the binary minus rather than the unary minus.

That's what I thought.

Couldn't match expected type `Picture' with actual type `Float -> Picture -> Picture' In the expression: translate - 50 0 $ color green (Circle 50) In the first argument of `Pictures', namely `[Circle 100, translate - 50 0 $ color green (Circle 50), scale 200 200 $ color red $ (Pictures $ take 20 chain1), testcirc]' In the expression: Pictures [Circle 100, translate - 50 0 $ color green (Circle 50), scale 200 200 $ color red $ (Pictures $ take 20 chain1), testcirc]

But what is the error message telling me? Given that infix is done after adjacency application, it should parse as: ((translate - (50 0) ) $ (color (green (Circle 50))))

Left of the $, that is the parse tree

subtract+ | + translate | + apply+ | + 50 | + 0

I think it would complain that 50 isn't a function, or the first argument of subtract is not a Num but a function translate :: Float -> Float -> Picture -> Picture, or that the argument of translate isn't a Float but something it can't make sense of. Why is it looking for a Picture? Where is it getting Float->Picture->Picture (seems to be a curried translate? But the next token is not something it would like so how can it find a first argument?)

Understanding the compiler's errors is a skill I want to learn, as well as shake out my understanding of what's really going on.

It's not easy to answer that without knowing the types of the involved values/functions. You can always play around a bit in ghci with the ':type' command to see if you can work it out for yourself :) It can be confusing though, functions are values too, and precedence rules come into play too. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On 4/28/2014 2:08 AM, Kim-Ee Yeoh wrote:

On Mon, Apr 28, 2014 at 10:59 AM, John M. Dlugosz mailto:ngnr63q02@sneakemail.com> wrote:

Also, is the comma in a list different from the operator comma which is noted as right-associative precedence 5? I had thought that the item separator in the list was special syntax that had very low precedence.

The _colon_ is a non-rebindable special-syntax operator with infixr 5.

Otoh, the _comma_ in a list is _not_ an operator but merely an item separator.

Comma-separated list notation e.g. [1,2,3] is special syntax that desugars to e.g. 1:2:3:[].

Other than that, the colon and comma don't have anything else in common.

-- Kim-Ee

I misread the chart: the “:,++” meant to use the comma to separate two operators, not be one of three operators listed.