The type signature for `...' lacks an accompanying binding about ihaskell

[aavogt]

I think that input should be accepted. You could work-around it for now and write:

let doubleIt :: Int -> Int
    doubleIt x = x*2

I think the issue is that doubleIt :: Int -> Int can parse as a statement (think helloWorld :: IO ()), or as a declaration. IHaskell.Eval.Evaluate.parseCommands classifies doubleIt :: Int -> Int as a statement.

[gibiansky]

This is something I would consider a bug, and should be fixed. The
workaround is okay for now, but I think this I will make this fixed when I
switch to ghc api for parsing.

[aavogt]

I don't think ghc's parser knows how to tell the difference: ghci doesn't accept Carreau's input without the let. To expand on how things are ambiguous:

helloWorld = putStrLn "hello world"
helloWorld :: IO ()

If you put that into a file, the helloWorld :: IO () specifies the type. In IHaskell that's currently rejected, but it could be asking to evaluate the IO, or it could be a type signature just like in a file.

Maybe it is better to classify the whole chunk as having only declarations or only statements.

[Carreau]

I can't judge as I have probably not written more than 50 lines of Haskell in my life. But it is confusing when following a tutorial and just copy-pasting example.

But I guess that how python newbies feel when they spawn class declaration across multiple cell in notebook and it does not work.

So I'll let you guy decide ,let is fine for me for the time beeing :-)

[gibiansky]

Another option: allow declarations immediately before the definitions?
On Oct 29, 2013 1:12 PM, "Adam Vogt" [email protected] wrote:

I don't think ghc's parser knows how to tell the difference: ghci doesn't
accept Carreau's input without the let. To expand on how things are
ambiguous:

helloWorld = putStrLn "hello world"
helloWorld :: IO ()

If you put that into a file, the helloWorld :: IO () specifies the type.
In IHaskell that's currently rejected, but it could be asking to evaluate
the IO, or it could be a type signature just like in a file.

Maybe it is better to classify the whole chunk as having only declarations
or only statements.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-27338924
.

[Carreau]

Do you mean, asking Haskell spec to change or actually trying to hack something for it to work ?

[aavogt]

@Carreau the haskell spec doesn't describe what ghci is supposed to do.

@gibiansky yeah we could resolve the ambiguity in favor of sigD if you have a valD or funD (to use template-haskell's names) that defines the same Name right above/below.

[Carreau]

@Carreau the haskell spec doesn't describe what ghci is supposed to do.

What I ment is that maybe the Haskell spec suppose a "file" is compiled in one block
and does not accomodate for REPL. So maybe this is and ambiguity should not even
try to resolve or at least try to have this case beeing a standard in spec ?

When Julia Guys came to bind to the notebook, we were missunderstanding some stuff, because
they were both wondering if they should change thing in Julia or in julia (lower case being the
reference implementation of the interpreter, and Uppercase being the spec) They ended up changing both
and actually buiding feature into the language itself.

[gibiansky]

@Carreau

This should be fixed in commit a6dd856

The way this currently works is that a type declaration of that form is always parsed as a declaration, not an expression. Although this is a bit ambiguous, it can be resolved by putting it in parentheses if necesary:

doubleIt :: Int -> Int -- Declaration
(doubleIt :: Int -> Int) -- Expression

Declarations after that must be followed by the appropriate definition.