Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: clarification on IO (Will Ness)
2. Re: let indenting problems (7stud)
3. Re: Re: let indenting problems (Daniel Fischer)
4. Re: let indenting problems (7stud)
5. Re: Re: Finite State Machine .. (Tom Poliquin)
6. Re: Re: let indenting problems (Miguel Pignatelli)
7. Re: let indenting problems (Francesco Bochicchio)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Mar 2009 19:28:41 +0000 (UTC)
From: Will Ness <will_...@yahoo.com>
Subject: [Haskell-beginners] Re: clarification on IO
To: beginners@haskell.org
Message-ID: <loom.20090302t172825-...@post.gmane.org>
Content-Type: text/plain; charset=utf-8
Gregg Reynolds <dev <at> mobileink.com> writes:
>
>
> Hi Will,I can tell I'm talking to a kindred spirit - we oughta be able to
describe all this stuff in plain, simple, clear English. It's a great
challenge for a prose writer.
>
> On Mon, Mar 2, 2009 at 9:21 AM, Will Ness <will_n48 <at> yahoo.com> wrote:
>
> Monad semantics in general is to chain together its action-
> functions (:: a -> M b). IO monad's semantics is that it promises to perform
> the recorded requests, if called upon. Not only is it directly implicated by
> its semantics, it IS its semantics. It is what IO-bind is. Other monad's binds
> will mean something else.Â
>
> Right, but this is //Haskell// monad semantics. It's an artifact of lazy
evaluation.Â
I don't think so, no. This value can be forced just like any other:
Prelude> let x = do { c <- getChar; putChar c; return c }
Prelude> const 1 $! x
1
Prelude> :t x
x :: IO Char
> Referring back to the mathematical definition of monad, there's no evaluation
process or promise, only denotation.
Right, it denotes lists of requests that come from chained action-functions, in
case of my metaphoric "IO".
>
> ________________________________
> data IO a = IORec -> (a,IORec)
> -- building the record of I/O activities to be performed
>
> instance Monad IO where
> Â return a rec = (a,rec) Â Â Â Â Â Â -- return :: a -> IO a
>  (m »= g) rec = uncurry g $ m rec  -- g    :: a -> IO b
> putStrLn :: a -> IO ()
> putStrLn a rec = ((),rec ++ [("putStrLn", a)])
> ================================
>
> _______________________________________
> IO value describes the computation that
> WILL BE performed OUTSIDE of Haskell.
> =======================================
>
>
> But also logically inconsistent:Â how can an expression "inside" of Haskell
refer to something outside of Haskell? More specifically, Haskell expressions
can only denote values in the Haskell semantic universe. IO processes (not
computations) lie outside of that universe, so Haskell cannot say anything
about them. But the //result// of an IO process is a value within the
semantic
universe, so it can be referenced.
No, it is just described, symbolically, to be interpreted by some external
interpreter, outside of Haskell realm (in our example). The actual I/O hasn't
got a chance to be performed yet. The "holes" in the computation structure,
ready to receive their values, stay empty. IOW the function is built but not
applied yet, its argument(s) not yet bound, computation not yet performed.
But the definition that defines this computation is already there. It can stay
lazy, it can be forced too.
> The whole future/promise thing comes from lazy evaluation.Â
No, not at all. We could force the value totally that is produced by the above
monad. All it does is it produces a symbolic description of things to do (in my
metaphor). It has nothing to do with Haskell being lazy or strict. The whole
thing could be strictly computed, and still be describing - symbolically -
requests to perform I/O (and pure Haskell calculations that go with them,
working with thus received values).
> With strict evaluation, there would be no such promise; expressions would be
evaluated (reduced) on the spot, so there would be no log of promised
execution.Â
No, this can only be done with impure language. Strict or not, doesn't matter.
Since Haskell is pure, it records these requests to be performed later by the
impure run-time system. It's got nothing to do with delay/promise of lazy
evaluation. There is no evaluation in Haskell. Eval is an imperative. :)
That's the whole central point about it. The computation gets defined (as a
function) - but not yet performed (function not called).
___________________________________________
It is all about separating pure and impure,
===========================================
not about doing it strictly or non-strictly.
It'll be performed when the run-time system will call that function. It may do
this twice, or never. The functions is defined just as well. Its definition can
be forced to be more strict, to be fleshed out more fully. It's still a
function wating to be called, so that the computation process it describes will
get performed.
See?
what is promised, is actual I/O operations to be performed - **by the impure
run-time system**. That's the promises I'm talking about, and that's the reason
it's all put aside into a function.
It's to separate the pure and the impure, not to delay some //calculations//.
We're not talking about no delayed evaluation. :)
> Language semantics (denotational) and evaluation strategy (operational?) are
orthogonal. Evaluation strategy doesn't change the meaning (denotation) of
the
program, but it does affect its execution profile - memory consumption, etc. -
so programmers have to think about it. Except of course it does change the
behavior of the program where IO is concerned.  In a lazy language you can
write IO expressions that will never get evaluate/performed, but not so in a
strict language.Â
No, not so. You can have function in a strict language, calling the I/O
primitives. This function might never get called. So yes, you can do that in a
strict language.
Never once in this whole discussion was I talking about "evaluation strategy".
____________________________________________
It's not about strictness, it's about purity.
============================================
>
>>>Denotationally, all a monad does is ensure sequencing, which is necessary to
>>>properly order the (non-deterministic) IO values.
>>No it does more than that. It ascribes actual meaning to what its M-action-
>>functions mean, and it defines what it means for them to be combined in a
>>chain. They are of course kept in sequence, in that chain.
>
> Ok, then for the IO monad all it does is ensure sequencing. The behavior of
getChar comes from its implementation, not from the monad it is wrapped in.Â
Yes. But the fact that the primitive _io_get_char (or whatever) actually gets
_called_ later, *does* come from the monad it is wrapped in. Or else the I/O
would get performed by the following (and it doesn't):
Prelude> const 1 $! getChar
1
>
> >With lazy eval this gets translated into the building of a "future log" etc.
> Right, only better not to use "eval" - ever. Haskell has expressions which get
> reduced; values belong to its runtime system. They are OUTSIDE of Haskell
> world.
> We do not "evaluate" anything. It would be an imperative. :)
>
>
> We're probably stuck with it, practically speaking, but where extra clarity
is needed I suggest "reduction" instead of "evaluation", from the lambda
calculus.
"Reduction" is always better. Not every rewrite simplifies the code though.
Cheers,
------------------------------
Message: 2
Date: Mon, 2 Mar 2009 19:42:42 +0000 (UTC)
From: 7stud <bbxx789_0...@yahoo.com>
Subject: [Haskell-beginners] Re: let indenting problems
To: beginners@haskell.org
Message-ID: <loom.20090302t193854-...@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
Miguel Pignatelli <miguel.pignatelli <at> uv.es> writes:
>
> What about...
>
> mySort xs = let myCompare x y
> | lx < ly = LT
> | lx == ly = EQ
> | lx > ly = GT
> where
> lx = length x
> ly = length y
> in sortBy myCompare xs
>
That doesn't work for me:
-- bhask.hs
mySort xs = let myCompare x y
| lx < ly = LT
| lx == ly = EQ
| lx > ly = GT
where
lx = length x
ly = length y
in sortBy myCompare xs
Prelude> :load bhask.hs
[1 of 1] Compiling Main ( bhask.hs, interpreted )
bhask.hs:4:16: parse error (possibly incorrect indentation)
Failed, modules loaded: none.
Prelude>
Line 4 is the first guard.
------------------------------
Message: 3
Date: Mon, 2 Mar 2009 21:07:27 +0100
From: Daniel Fischer <daniel.is.fisc...@web.de>
Subject: Re: [Haskell-beginners] Re: let indenting problems
To: 7stud <bbxx789_0...@yahoo.com>, beginners@haskell.org
Message-ID: <200903022107.27308.daniel.is.fisc...@web.de>
Content-Type: text/plain; charset="iso-8859-1"
Am Montag, 2. März 2009 20:42 schrieb 7stud:
>
> mySort xs = let myCompare x y
>
> | lx < ly = LT
> | lx == ly = EQ
> | lx > ly = GT
>
> where
> lx = length x
> ly = length y
> in sortBy myCompare xs
>
>
>
>
> Prelude> :load bhask.hs
> [1 of 1] Compiling Main ( bhask.hs, interpreted )
>
> bhask.hs:4:16: parse error (possibly incorrect indentation)
> Failed, modules loaded: none.
> Prelude>
>
>
> Line 4 is the first guard.
>
That line must be indented further than the first letter of myCompare in the
line above.
After the keyword 'let', the position of the start of the next significant
token (not whitespace or comments), sets a new indentation level. The
definiton begun there extends until
- a line indented less or equally far is encountered
- the keyword 'in' appears
- an explicit semicolon ends the definition
If a line indented less appears before the keyword 'in', a parse error
results. Details can be found in
http://haskell.org/onlinereport/syntax-iso.html#sect9.3
------------------------------
Message: 4
Date: Mon, 2 Mar 2009 20:08:19 +0000 (UTC)
From: 7stud <bbxx789_0...@yahoo.com>
Subject: [Haskell-beginners] Re: let indenting problems
To: beginners@haskell.org
Message-ID: <loom.20090302t195746...@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
Heinrich Apfelmus <apfelmus <at> quantentunnel.de> writes:
> How about
>
> import Data.Ord (comparing)
>
> mySort = sortBy (comparing length)
>
I just finished chap. 3 of Real World Haskell, which doesn't
even imports. It took me hours to figure out how to
access sortBy. The book hasn't introduced "comparing", yet.
> or at least
>
> mySort = sortBy myCompare
> where
> myCompare x y = compare (length x) (length y)
>
Very nice. The book mentioned the compare function in
chap. 2.
I have a question about that code: how come you
don't have to specify a parameter for mySort, for example:
mySort xs = ...
And doesn't sortBy require two arguments?
sortBy :: (a -> a -> Ordering) -> [a] -> [a]
(1) (2)
How come you can write it with only one argument?
Finally, l'm wondering if anyone can explain why my
let examples failed?
------------------------------
Message: 5
Date: Mon, 2 Mar 2009 23:51:03 -0800
From: Tom Poliquin <poliq...@softcomp.com>
Subject: Re: [Haskell-beginners] Re: Finite State Machine ..
To: beginners@haskell.org
Message-ID: <200903022351.03540.poliq...@softcomp.com>
Content-Type: text/plain; charset="iso-8859-1"
Heinrich Apfelmus wrote:
> Tom Poliquin wrote:
> > Heinrich Apfelmus wrote:
> >> You probably want guards, like this
> >>
> >> fib n
> >>
> >> | n == 0 = 0
> >> | n == 1 = 1
> >> | otherwise = fib (n-1) + fib (n-2)
> >
> > Is this what you had in mind?
> >
> > module Main where
> >
> > foo a b c
> >
> > | p1 && p2 || not p3 = 42
> > | p1 || not p2 && p3 = 13
> > | otherwise = 0
> >
> > where
> > -- setup if predicates
> > p1 = a > b
> > p2 = a + b > 2
> > p3 = a - b < 1
> >
> > main = do
> > x <- return $ foo 9 2 3
> > print x
> >
> > -- 42
>
> Yes.
>
> Of course, it will become clunky very quickly; only abstraction and
> insights into the problem domain can help in these cases.
ay, there's the rub! (Hamlet Act III, Scene I)
Those pesky insights into the problem !
If I have time I'll try all three approaches; guards,FSM, and insights.
Thanks everyone for the help!
Tom
------------------------------
Message: 6
Date: Tue, 03 Mar 2009 10:31:47 +0100
From: Miguel Pignatelli <miguel.pignate...@uv.es>
Subject: Re: [Haskell-beginners] Re: let indenting problems
To: 7stud <bbxx789_0...@yahoo.com>
Cc: beginners@haskell.org
Message-ID: <49acf903.5080...@uv.es>
Content-Type: text/plain; charset=UTF-8; format=flowed
7stud wrote:
> Miguel Pignatelli <miguel.pignatelli <at> uv.es> writes:
>
>> What about...
>>
>> mySort xs = let myCompare x y
>> | lx < ly = LT
>> | lx == ly = EQ
>> | lx > ly = GT
>> where
>> lx = length x
>> ly = length y
>> in sortBy myCompare xs
>>
>
> That doesn't work for me:
>
Yes, sorry about that, it is an issue with indentation while
copy/pasting the code
M;
> -- bhask.hs
>
> mySort xs = let myCompare x y
> | lx < ly = LT
> | lx == ly = EQ
> | lx > ly = GT
> where
> lx = length x
> ly = length y
> in sortBy myCompare xs
>
>
>
>
> Prelude> :load bhask.hs
> [1 of 1] Compiling Main ( bhask.hs, interpreted )
>
> bhask.hs:4:16: parse error (possibly incorrect indentation)
> Failed, modules loaded: none.
> Prelude>
>
>
> Line 4 is the first guard.
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
------------------------------
Message: 7
Date: Tue, 3 Mar 2009 11:05:53 +0100
From: Francesco Bochicchio <bieff...@gmail.com>
Subject: Re: [Haskell-beginners] let indenting problems
To: beginners@haskell.org
Message-ID:
<a6e7dd140903030205m24730981lba6c8f358070a...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
2009/3/2 7stud <bbxx789_0...@yahoo.com>
> I get indenting errors with the following attempts to use let:
>
... three failed exaopmles and a good one ...
But I would like to know how to use let.
From beginner to beginner, they look to me more as syntax errors than
indentation problem.
The syntax for let is
let { decl ; ... decl } in expression
or in layout format
let decl
...
decl
in expression
and your attempts do not respect this syntax. In all three cases, after the
keyword 'in' you need a full expression,
and neither a where clause nor a set of matches are a full expression by
themselves. An expression is either a function apllication or a 'statement'
like if or case, or maybe something more I can't recall.
In my haskell exercises I really appreciate the fact that the haskell mode
of emacs has syntax hints (also
function hints for functions in the prelude). Even now that I know haskell
basic syntax, I find it helpful.
Don't know of any other editors with the same capability for haskell,
though, and if you are not an emacs user, learning
the not-so-standard ways of emacs might offset the benefits of having syntax
hints.
Ciao
---------
FB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090303/63defd80/attachment.htm
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 9, Issue 5
***************************************
