<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Most important thing when learning Haskell is that everything is function no constants<div class="">and variables like in imperative language.</div><div class="">So</div><div class=""><br class=""></div><div class="">a = 5</div><div class=""><br class=""></div><div class="">is function a</div><div class="">lambas are just syntactic sugar you can do same with local functions.</div><div class="">Don’t make fog and build simple things complicated.</div><div class="">Also learn to teach that when you need variable in functional language</div><div class="">you have to use handle to access it.</div><div class=""><br class=""></div><div class="">Greetings, Branimir.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 19.09.2021., at 01:20, Chris Smith <<a href="mailto:cdsmith@gmail.com" class="">cdsmith@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I don't think it quite makes sense to say that Haskell shares the evaluation model with lambda calculus, because I don't think it's fair to say that lambda calculus has any specific evaluation model at all. Do you mean substitution, for example? But that's only one way to implement lambda calculus, and not one that is shared by any widely used Haskell implementation.<div class=""><br class=""></div><div class="">But I do agree there's a point here. There's a simplicity that the purely functional fragment of Haskell shares with the lambda calculus, which I wish were easier to get across to new Haskell programmers. That simplicity is precisely what allows the lambda calculus, as well as the purely functional fragment of Haskell, to have a meaning <i class="">without</i> answering the question of how it is evaluated. (Even in more complex programming languages, the notion of evaluation that is used to define the language is often not the same one that's used by implementations, of course. But nevertheless these languages must be defined in terms of some model of evaluation, where the purely functional fragment of Haskell doesn't.)</div><div class=""><br class=""></div><div class="">I struggle with this. In some very real ways, I consider it the most important point of learning Haskell for many programmers. But it's also not a prerequisite to using Haskell for practical purposes. For me, since I learned Haskell in order to just experience the cool ideas that it contains (and only 15 years later got my first job programming in Haskell), that's reason enough. But, within reason at least, it's the learner's goals that matter most when learning. Someone who isn't looking to understand the fundamental simplicity of a portion of Haskell isn't likely to be motivated to work through the effort it takes to understand it. So there must be some ways, at least, to learn Haskell without focusing on that particular aspect of the language. A Haskell programmer won't be as good of a Haskell programmer as they could be without understanding it, and will struggle to write idiomatic pure code. But one must start somewhere. New Python programmers don't write idiomatic or perfect Python, either!</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 18, 2021 at 7:11 PM Olaf Klinke <<a href="mailto:olf@aatal-apotheke.de" class="">olf@aatal-apotheke.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Perhaps one thing that speaks in favour of Anthony Clayden's suggestion<br class="">
to learn lambda calculus before/along Haskell is this: <br class="">
Haskell shares the evaluation model with the lambda calculus. One of<br class="">
Michael Turner's points of criticism was, as I understand it,<br class="">
insufficient documentation about the inner workings of Haskell [1].<br class="">
Haskell needs constructs like the ST monad because of the evaluation<br class="">
model. Once the learner knows, perhaps by experimenting with it on<br class="">
paper or on [2,3], that a lambda term can be reduced in several ways,<br class="">
and confluence guarantees that all ways result in the same normal form,<br class="">
then some things might be much clearer: <br class="">
* Which freedoms the compiler can exercise in evaluating your program.<br class="">
* Why one needs the State monad for ordering sequences of effects (the<br class="">
programmable semicolon) [4]. <br class="">
* How the various tricks and pitfalls around lazy and strict functions<br class="">
work, e.g. Viktor's new Foldable documentation.<br class="">
<br class="">
I looked at the first chapter of my K&R. It presents small example C<br class="">
programs and explains what they do. Taking small Haskell programs and<br class="">
explaining how these lambda terms are reduced to normal form would be a<br class="">
comparable (and desirable, in Michael's view) approach? The Haskell<br class="">
language report does not say anything in this respect, as far as I can<br class="">
see. Only translation of syntactic constructs to core Haskell is given.<br class="">
<br class="">
Olaf<br class="">
<br class="">
[1] Of course the documentation is out there somewhere, but not written<br class="">
in a style which pleases learners like Michael. <br class="">
[2] <a href="https://lambdacalc.io/" rel="noreferrer" target="_blank" class="">https://lambdacalc.io/</a><br class="">
[3] <a href="https://capra.cs.cornell.edu/lambdalab/" rel="noreferrer" target="_blank" class="">https://capra.cs.cornell.edu/lambdalab/</a> <br class="">
[4] I tried to convince myself that the state monad indeed sequences<br class="">
effects. In a pure lambda world I think this should mean that a certain<br class="">
lambda term has only one way of being reduced. Is the following valid<br class="">
reasoning?<br class="">
type State s a = s -> (a,s)<br class="">
When Church-encoding the tuple (a,s) one finds that <br class="">
(m :: State s a) >>= (k :: a -> State s b)<br class="">
= \s -> m s k<br class="">
so the only applicable rule is beta-reducing m when applying to some s.<br class="">
<br class="">
_______________________________________________<br class="">
Haskell-Cafe mailing list<br class="">
To (un)subscribe, modify options or view archives go to:<br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">
Only members subscribed via the mailman list are allowed to post.</blockquote></div>
_______________________________________________<br class="">Haskell-Cafe mailing list<br class="">To (un)subscribe, modify options or view archives go to:<br class=""><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">Only members subscribed via the mailman list are allowed to post.</div></blockquote></div><br class=""></div></body></html>