Re: [Haskell-cafe] On finding the right exposition...
GHC's use of a State-like monad to represent I/O is semantically bogus, .... I wouldn't take it as a good mental model.
Indeed. I fondly remember that in my intro text (the 'Gentle Introduction'), there was a warning this section is not so gentle. But I was already well through the book so it didn't seem such a drama. I'd already figured that 'mentally evaluating' code wasn't about contents of memory locations. For Monads esp I/O, 'programmable semicolon' or 'workflow' might be a better model. Ref the current discussion, I'm expecting a learner would spend a long time writing expressions at the ghci prompt; investigating their type; chucking in a few in-line decls with `let { }`. Dropping those decls into a source file -- which would contain only decls, not even a `module { }` header. A few simple `do{ ; }` blocks at the prompt. I was advocating lambda-calculus for the pure function evaluation parts of an intro. Higher-order functions, partial evaluation, operator sections, (un)currying. The o.p. was having trouble with a signature like `(a -> b -> c) -> a -> b -> d`. Later remarks expressed surprise why function application wasn't written `add(x, y)`. The (very old) paper mentioned was nearly all pure code. Without a firm basis grokking type signatures, the Monad operators are going to seem deeply weird. If you're used to 'higher-order function' meaning something that passes round an entry point for a block of code, partial application will take some head-scratching. And I can see if you're used to `x ++` meaning something and `x+=1` meaning something similar and `* y` meaning something completely different and `(x +)` being a syntax error, Haskell is going to feel strange. (Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be publicly flogged on a regular basis. Why couldn't they just follow the model of BCPL, which is far more elegant and consistent in its syntax. They stole nearly everything else from BCPL.) Which reminds me ... My all-time favourite language intro text is still http://rabbit.eng.miami.edu/info/bcpl_reference_manual.pdf This serves also as a language definition.This was thrown at undergrads, and they were left to get on with it. (There was also a 'User Guide' that talked about the operating environment, debugging, IO and file handling -- essentially equiv to Haskell's Appendixes on the base modules.) I note again, the language is small and elegant (expressible in A5 minimanual format). Similarly, you can get enough of lambda-calculus on a few sheets of A4. I contrast that 'Category Theory for Programmers' (mentioned in this thread) is 500 pages, and not even a language primer, although it contains snippets of code. How many hundred pages must I read before I'm allowed to write a Foldable instance? I'm up to 100, and we seem to be still preparing the ground for what is an endomorph.
Am 19.09.21 um 05:00 schrieb Anthony Clayden:
Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be publicly flogged on a regular basis.
And for so many other reasons, too, like mandating a preprocessor (with a complex, operationally defined semantics) simply because they couldn't be bothered to design a (simple, 1st order) module system. And lots of inconsistencies and special cases. Like functions can be declared to return void but trying to actually do so (return void) is an error. Or that void is indeed a keyword and not a typedef for "struct {}". Talking of inconsistencies, Haskell is not without some of those. For instance, I never understood why (->) is right associative in types, but (=>) is not and you are instead supposed to pack constraints in a tuple. (It works in some simple cases but not consistently.) Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman
On Mon, 4 Oct 2021, Ben Franksen wrote:
Talking of inconsistencies, Haskell is not without some of those. For instance, I never understood why (->) is right associative in types, but (=>) is not and you are instead supposed to pack constraints in a tuple. (It works in some simple cases but not consistently.)
I use nested (=>) frequently. GHC allows it in type signatures but not in super-class constraints. Would be cool to be allowed everywhere, as it supports the "terminator syntax style".
On Mon, Oct 04, 2021 at 06:12:13PM +0200, Henning Thielemann wrote:
On Mon, 4 Oct 2021, Ben Franksen wrote:
Talking of inconsistencies, Haskell is not without some of those. For instance, I never understood why (->) is right associative in types, but (=>) is not and you are instead supposed to pack constraints in a tuple. (It works in some simple cases but not consistently.)
I use nested (=>) frequently. GHC allows it in type signatures but not in super-class constraints. Would be cool to be allowed everywhere, as it supports the "terminator syntax style".
Could you say what "terminator syntax style" is? I'm not finding any hits on popular search engines.
On Mon, 4 Oct 2021, Tom Ellis wrote:
On Mon, Oct 04, 2021 at 06:12:13PM +0200, Henning Thielemann wrote:
I use nested (=>) frequently. GHC allows it in type signatures but not in super-class constraints. Would be cool to be allowed everywhere, as it supports the "terminator syntax style".
Could you say what "terminator syntax style" is? I'm not finding any hits on popular search engines.
Am 04.10.21 um 18:12 schrieb Henning Thielemann:
On Mon, 4 Oct 2021, Ben Franksen wrote:
Talking of inconsistencies, Haskell is not without some of those. For instance, I never understood why (->) is right associative in types, but (=>) is not and you are instead supposed to pack constraints in a tuple. (It works in some simple cases but not consistently.)
I use nested (=>) frequently. GHC allows it in type signatures but not in super-class constraints. Would be cool to be allowed everywhere, as it supports the "terminator syntax style".
I am having second thoughts. The analogy of => with -> breaks down when you consider that the order of constraints never matters. Despite the tuple-like notation, I guess the better intuition is that constraints are always sets, "," is union, and simple constraints are singleton sets. This also works better when using constraint synonyms such as type OrderedNum a = (Num a, Ordered a) I can write f :: (OrderedNum a, Floating a) => a -> a which would otherwise be a nested tuple? Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman
participants (4)
-
Anthony Clayden -
Ben Franksen -
Henning Thielemann -
Tom Ellis