On 2005-12-20, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've finished a first draft of what I call "First steps in Haskell".
> It's intended to be the very first thing a new user sees when they
> decide to try out Haskell.
I should point out a parallel effort that a few of us have
Hello Donn,
Friday, December 23, 2005, 8:30:34 PM, you wrote:
>> so, i think, it is needed to "reassure" imperative programmers at
>> first pages by demonstrating techiques of imperative programming,
>> including conditional execution and IORef/MArray and only after that
>> present more convenient
On Fri, 23 Dec 2005, Bulat Ziganshin wrote:
...
> so, i think, it is needed to "reassure" imperative programmers at
> first pages by demonstrating techiques of imperative programming,
> including conditional execution and IORef/MArray and only after that
> present more convenient alternatives. at l
Hello John,
Thursday, December 22, 2005, 3:48:37 AM, you wrote:
JM> You can't not start with IO for people who already know how to program,
JM> if you are teaching someone programming for the very first time then
JM> starting with the pure functional side is fine. But for people that
JM> already
Hello Daniel,
Thursday, December 22, 2005, 3:13:06 PM, you wrote:
DC> Well, I'm a newbie, and I wrote it. I have "enough" understanding to
DC> generate that code, even if I don't understand it all. This is what I know:
please, don't learn Haskell!!! we will test different tutorials on
you! :)))
Hello Bill,
Wednesday, December 21, 2005, 6:38:33 PM, you wrote:
BW> PS: While looking over my post it occurred to me that the issue is at
BW> least as much methodological as it is linguistic. So I ask: Does
BW> Haskell stand far enough apart from other programming languages to
BW> warrant adap
Hello Daniel,
Wednesday, December 21, 2005, 6:34:10 PM, you wrote:
DC> You can show them this on the first page:
DC> main = do
DC> x <- getLine()
DC> print my_program(x)
this named `interactive` :) try:
main = interactive(map toUpper)
--
Best regards,
Bulat
Paul Moore wrote:
> Not trying to fan the flames, but one thing I struggle with is
> understanding (at a "gut level" - if you explain the theory, I'll
> understand, but go away none the wiser in practice...) why I need mapM
> as well as map (and all the other -M functions, liftM, foldM, etc...)
Al
SKC> This entire discussion is about 'breaking a cyclic graph of conceptual
SKC> dependencies'. Unfortunately, I don't think it can be done well in short
SKC> amount of time.
I bet if we sat down and listed all the concepts required to write
idiomatic Haskell (even idiomatic Haskell 98 (whatever t
On 12/22/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > As I say, I'm not trying to criticize anyone here, but it seems to be
> > quite hard to get across to people who have understood and assimilated
> > this sort of stuff, just how hard it feels to newcomers. We understand
On Thu, Dec 22, 2005 at 02:02:56PM +, Daniel Carrera wrote:
> I had never heard of mapM, or other -M functions. I can't imagine why
> those would be needed. It seems like pointless duplication.
(!!!) then you are missing out. the M functions (and monadic traversal
functions in general) especi
On Thu, 22 Dec 2005, Paul Moore wrote:
...
> FWIW, I don't really see why the -M functions are needed either. It's
> something to do with the fact that map is for lists, and mapM is for
> monads, which are a more general type of sequence than a list. But why
> mapM isn't therefore a superset of map
On Thu, Dec 22, 2005 at 02:02:56PM +, Daniel Carrera wrote:
> Paul Moore wrote:
> >As I say, I'm not trying to criticize anyone here, but it seems to be
> >quite hard to get across to people who have understood and assimilated
> >this sort of stuff, just how hard it feels to newcomers. We under
On 12/22/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > As I say, I'm not trying to criticize anyone here, but it seems to be
> > quite hard to get across to people who have understood and assimilated
> > this sort of stuff, just how hard it feels to newcomers. We understand
Paul Moore wrote:
As I say, I'm not trying to criticize anyone here, but it seems to be
quite hard to get across to people who have understood and assimilated
this sort of stuff, just how hard it feels to newcomers. We understand
the explanations (we do! really! :-)) but even understanding them,
On 12/22/05, John Meacham <[EMAIL PROTECTED]> wrote:
> Just the idea that you can write things like mapM and replicateM is
> enough to blow the mind of many impertive programmers.
Not trying to fan the flames, but one thing I struggle with is
understanding (at a "gut level" - if you explain the th
On 12/22/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> S Koray Can wrote:
> >> As a newbie... I agree that a newbie should be able to write this
> >> fairly early on:
> >>
> >> main = do
> >>x <- getLine()
> >>putStrLn ("The answer is " ++ show(fib(read(x
> >>
> >
> > I'd agre
S Koray Can wrote:
As a newbie... I agree that a newbie should be able to write this
fairly early on:
main = do
x <- getLine()
putStrLn ("The answer is " ++ show(fib(read(x
I'd agree for some definition of 'early'. I'll elaborate:
[snip]
The above code snippet contains t
Daniel Carrera wrote:
As a newbie... I agree that a newbie should be able to write this fairly
early on:
main = do
x <- getLine()
putStrLn ("The answer is " ++ show(fib(read(x
I'd agree for some definition of 'early'. I'll elaborate:
This entire discussion is about 'breaki
On Wednesday 21 December 2005 16:49, Sebastian Sylvan wrote:
> On 12/21/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> > Sebastian Sylvan wrote:
> > > Beginners know that too. In fact, they often think that practical
> > > applications need far more IO than they really do! So to
> > > insinuate ev
The truth is, Haskell friggen rocks at IO compared to imperative
languages. We are all spoiled and see IO in haskell as ugly because we
have been exposed to the pure functional goodness of the rest of
haskell. but teaching haskell as a better impertive language than
imperative ones from the getgo
> > As a newbie... I'll agree with Robin. I /did/ think that IO in
> > Haskell was probably very difficult because it's covered in page 94.
> > I skimmed through YAHT and IO is covered wyyy deep into the
> > document. I haven't read that section yet, but there is a lot of
> > content and to me
On Wednesday 21 December 2005 12:17, Daniel Carrera wrote:
> Robin Green wrote:
> > Whilst localising IO to a small part of the program is generally a
> > good idea, beginners should not be scared off by the thought that
> > IO in Haskell is so hard it has to be covered on page 94. This is
> > not
On 21/12/05, Tomasz Zielonka <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 21, 2005 at 07:13:07PM +, Philippa Cowderoy wrote:
> > > Try running
> > >
> > > putStrLn (unlines (repeat "hello!"))
> > >
> > > You may be surprised ;-)
> >
> > Or not ;-) But yes, I should've checked and my comments on
On Wed, Dec 21, 2005 at 09:30:14PM +, Philippa Cowderoy wrote:
> On Wed, 21 Dec 2005, Tomasz Zielonka wrote:
>
> > I don't know how it's done, but when you compile it with 'ghc -O2',
> > the program runs in constant space. Unfortunately with Hugs and GHCi it
> > grows.
>
> The live set, or ju
On Wed, 21 Dec 2005, Tomasz Zielonka wrote:
> I don't know how it's done, but when you compile it with 'ghc -O2',
> the program runs in constant space. Unfortunately with Hugs and GHCi it
> grows.
>
The live set, or just the heap?
--
[EMAIL PROTECTED]
A problem that's all in your head is stil
On Wednesday 21 December 2005 18:48, Udo Stenzel wrote:
> Donn Cave wrote:
> > Meanwhile, that fellow evidently didn't write any compiler in
> > Haskell at all. Better a C++ program than a Haskell program that
> > offends you?
>
> Oh no, he actually wrote something disgusting built mostly out of
>
On Wed, Dec 21, 2005 at 07:13:07PM +, Philippa Cowderoy wrote:
> > Try running
> >
> > putStrLn (unlines (repeat "hello!"))
> >
> > You may be surprised ;-)
>
> Or not ;-) But yes, I should've checked and my comments on how that'll
> behave stand. It would be nice to think something cle
On Wed, 21 Dec 2005, Tomasz Zielonka wrote:
> On Wed, Dec 21, 2005 at 06:58:14PM +, Philippa Cowderoy wrote:
> > Surely the actual explosion comes about because PutStr forces the lot at
> > once? If PutStr were to evaluate a character at a time, the laziness would
> > be slow and spew a lot
On Wed, Dec 21, 2005 at 06:58:14PM +, Philippa Cowderoy wrote:
> Surely the actual explosion comes about because PutStr forces the lot at
> once? If PutStr were to evaluate a character at a time, the laziness would
> be slow and spew a lot of garbage to collect but not hang on to as much
> s
On Wed, 21 Dec 2005, Peter Simons wrote:
> > Some example for writing a text the IO oriented way:
> > do putStrLn "bla"
> > replicateM 5 (putStrLn "blub")
> > putStrLn "end"
> >
> > whereas the lazy way is
> > putStr (unlines (["bla"] ++ replicate 5 "blub" ++ ["end"]))
>
> Um
On Wed, Dec 21, 2005 at 07:35:28PM +0100, Peter Simons wrote:
> > Some example for writing a text the IO oriented way:
> > do putStrLn "bla"
> > replicateM 5 (putStrLn "blub")
> > putStrLn "end"
> >
> > whereas the lazy way is
> > putStr (unlines (["bla"] ++ replicate 5 "blub"
> Some example for writing a text the IO oriented way:
> do putStrLn "bla"
> replicateM 5 (putStrLn "blub")
> putStrLn "end"
>
> whereas the lazy way is
> putStr (unlines (["bla"] ++ replicate 5 "blub" ++ ["end"]))
Um, maybe it's just me, but I think the first program is far
s
Donn Cave wrote:
> Meanwhile, that fellow evidently didn't write any compiler in Haskell
> at all. Better a C++ program than a Haskell program that offends you?
Oh no, he actually wrote something disgusting built mostly out of
regexes in Perl. I don't think it even works, and I don't think I
cou
On Wed, 21 Dec 2005, Udo Stenzel wrote:
[... re pitfalls of IO for the beginner ]
> Here's another one: I've heard a fellow claim, Haskell is basically
> unsuitable to implement a compiler, because Haskell is weak at IO and
> "everything needs IO, the lexer, the preprocessor, the parser, the
> pre
Am Mittwoch, 21. Dezember 2005 16:30 schrieb Daniel Carrera:
> [...]
> Would it be fair to say that do-blocks are imperative blocks in an otherwise
> functional program?
Not really. do expressions are (normally) equivalent to expressions
containing applications of (>>=) and/or (>>). If the mon
On 12/21/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Sebastian Sylvan wrote:
> > Beginners know that too. In fact, they often think that practical
> > applications need far more IO than they really do! So to insinuate
> > even slightly that Haskell is "bad at IO" by avoiding it for two
> > thir
On Wed, 2005-12-21 at 13:10 +0100, Udo Stenzel wrote:
. . .
> tutorial. Before that, IO should be restricted to the EVA principle
> ("Eingabe, Verarbeitung, Ausgabe" == "Input, Processing, Output"). It
> was a good principle in the 60s, and it still is. Unless you want to
> teach people to pr
Sebastian Sylvan wrote:
Beginners know that too. In fact, they often think that practical
applications need far more IO than they really do! So to insinuate
even slightly that Haskell is "bad at IO" by avoiding it for two
thirds of a book, is really going to inforce the idea that Haskell
isn't a
Sebastian Sylvan wrote:
Well, I certainly disagree there.
I'm not advocating going into a full-blown explanation of monads, just
enough to actually be able to write a real stand-alone program after
the first chapter. They only need to know that do-notation is for
sequencing computations, and (<-)
On 12/21/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 21. Dezember 2005 11:48 schrieb Robin Green:
> > [...]
>
> > If people want Haskell to be treated as a practical language, not just
> > something for doing academic teaching and research with, it should be
> > taught as a pract
On 12/21/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 20. Dezember 2005 20:07 schrieb Sebastian Sylvan:
> > [...]
>
> > It's sometimes beneficial to "lie" a bit when starting out. Perhaps
> > say something like "this is a simplified view of things, for all the
> > gory details see
Daniel Fischer wrote:
P.S.: In May, there was a 'Daniel Carrera' around, too. Isn't that a strange
coincidence?
That was myself, using a different email address. I didn't get too far
with Haskell that time, but I remembered that I liked it, so I'm going
back to it a bit now. But I'm still a n
On 12/21/05, John Hughes <[EMAIL PROTECTED]> wrote:
>
> >
> >--
> >
> >Message: 1
> >Date: Wed, 21 Dec 2005 10:48:08 +
> >From: Robin Green <[EMAIL PROTECTED]>
&
Udo Stenzel wrote:
Unless you want to
teach people to program as they would do in Basic, that is.
I don't know what you mean by that.
You will soon. Once you get used to composing functions instead of
sequencing actions, you'll appreciate the difference.
Ah.
Yes, I do think I understand t
Am Mittwoch, 21. Dezember 2005 13:31 schrieb Daniel Carrera:
> Udo Stenzel wrote:
> > Strange, I always thought predictable, understandable and above all
> > correct code would be the primary goal, with small and quick code coming
> > later.
>
> Depends on what you mean by "quick" and "small". Do y
Robin Green wrote:
> I meant that for *many* but not all
> practical programming tasks, IO is important.
> ...web applications...
Ha, wrong! A CGI script only needs getEnv, getContents and putStr, if
it has persistent state, it also needs readFile and writeFile. Each of
the five is called exact
Creighton Hogg wrote:
> On Wed, 21 Dec 2005, Henning Thielemann wrote:
> > The drawback is that I saw many Haskell programs implemented with IO
> > read/write functions which could be easily implemented without IO, using
> > laziness.
>
> Can you think of any examples of things like that? Given
Wolfgang Jeltsch wrote:
If people want Haskell to be treated as a practical language, not just
something for doing academic teaching and research with, it should be
taught as a practical language - which means that things like IO and
space/time usage come to the forefront.
So programming is onl
Daniel Carrera wrote:
> Depends on what you mean by "quick" and "small". Do you mean that the
> program should execute fast and have a small memmory foot-print?
I was referring to Robin's mentioning space/time usage, so yes, that's
what I meant.
> >To write interactive Haskell code well, you ha
Am Mittwoch, 21. Dezember 2005 11:48 schrieb Robin Green:
> [...]
> If people want Haskell to be treated as a practical language, not just
> something for doing academic teaching and research with, it should be
> taught as a practical language - which means that things like IO and
> space/time usa
Am Dienstag, 20. Dezember 2005 20:07 schrieb Sebastian Sylvan:
> [...]
> It's sometimes beneficial to "lie" a bit when starting out. Perhaps
> say something like "this is a simplified view of things, for all the
> gory details see chapter 19".
>
> Monadic IO is pretty darn cool, sadly that means t
On Wed, 21 Dec 2005, Creighton Hogg wrote:
> On Wed, 21 Dec 2005, Henning Thielemann wrote:
>
> > The drawback is that I saw many Haskell programs implemented with IO
> > read/write functions which could be easily implemented without IO, using
> > laziness.
>
> Can you think of any examples of th
--
Message: 1
Date: Wed, 21 Dec 2005 10:48:08 +
From: Robin Green <[EMAIL PROTECTED]>
Subject: Re: [Haskell-cafe] Re: Tutorial uploaded
Beginners should start with non-monadic functions in order to later
On 21/12/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> Henning Thielemann wrote:
> > IO is always complicated:
>
> I have never once thought it was complicated. All I've ever needed are
> "print()" and "readLine()" and those shouldn't be complicated IMO. And I
> wouldn't want to wait for page 120
On Wed, 21 Dec 2005, Henning Thielemann wrote:
>
> On Wed, 21 Dec 2005, Creighton Hogg wrote:
>
> > I agree with this wholeheartedly. When I first started
> > playing with Haskell, some of the tutorials made it look
> > like it was very difficult to do anything practical with it
> > because doi
Henning Thielemann wrote:
IO is always complicated:
I have never once thought it was complicated. All I've ever needed are
"print()" and "readLine()" and those shouldn't be complicated IMO. And I
wouldn't want to wait for page 120 to learn how to do that. My programs
are not going to be usef
Udo Stenzel wrote:
Strange, I always thought predictable, understandable and above all
correct code would be the primary goal, with small and quick code coming
later.
Depends on what you mean by "quick" and "small". Do you mean that the
program should execute fast and have a small memmory foot
On Wed, 21 Dec 2005, Creighton Hogg wrote:
> I agree with this wholeheartedly. When I first started
> playing with Haskell, some of the tutorials made it look
> like it was very difficult to do anything practical with it
> because doing real input and output seemed like an "advanced
> topic".
T
On Wed, 21 Dec 2005, Robin Green wrote:
> Henning Thielemann wrote:
> > Starting with IO in Haskell is like starting LaTeX with rotating text and
> > making it colorful.
>
> Not at all!
>
> > Indeed IO _is_ complicated regardless of whether it is
> > modelled by Monads in Haskell or differently i
Robin Green wrote:
> If people want Haskell to be treated as a practical language, not just
> something for doing academic teaching and research with, it should be
> taught as a practical language - which means that things like IO and
> space/time usage come to the forefront.
Strange, I always
Robin Green wrote:
Whilst localising IO to a small part of the program is generally a good
idea, beginners should not be scared off by the thought that IO in
Haskell is so hard it has to be covered on page 94. This is not the
case. It should be introduced on page 1.
As a newbie... I'll agree
On Wed, 21 Dec 2005, Robin Green wrote:
> Henning Thielemann wrote:
> > Starting with IO in Haskell is like starting LaTeX with rotating text and
> > making it colorful.
>
> Not at all!
>
> > Indeed IO _is_ complicated regardless of whether it is
> > modelled by Monads in Haskell or differently
Henning Thielemann wrote:
Starting with IO in Haskell is like starting LaTeX with rotating text and
making it colorful.
Not at all!
Indeed IO _is_ complicated regardless of whether it is
modelled by Monads in Haskell or differently in other languages.
Rubbish!
10 PRINT "WHAT IS YOUR NAME?"
Neil Mitchell <[EMAIL PROTECTED]> writes:
> I would have actually said Hugs, and especially the Windows front end
> WinHugs was a lot more suitable for beginners than GHC, but the wiki
> page very much gives the other impression.
Which page are you referring to? I went to look, but couldn't find
On Tue, 20 Dec 2005, Sebastian Sylvan wrote:
> Monadic IO is pretty darn cool, sadly that means that many tutorial
> authors are tempted to spend pages upon pages explaining exactly why
> it's cool and how it works, but that is NOT what most people starting
> out with the language need to read.
>
On Tue, Dec 20, 2005 at 10:04:16PM +0100, Benjamin Franksen wrote:
> and would also be unsafe without some kind of strong guarantee that each
> single 'world' value is unique. (This is how they do it in Clean.)
> Imagine
>
> g :: World -> World
> g world = let world' = putStrLn "first line"
Hello Neil,
Tuesday, December 20, 2005, 11:52:51 PM, you wrote:
NM> Hi,
>> Hugs Interpreter onlySuitable for learning. You'll need GHC for
>> serious work.
NM> This is putting Hugs down quite a bit. I personally prefer Hugs, and
NM> use it for serious work (including developing a Hask
On Tue, 2005-12-20 at 20:58 +0100, Peter Simons wrote:
> Curiously enough, if you check out the reference
> documentation at:
>
>
> http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-ST.html#t%3ARealWorld
>
> ..., you'll find that a "World" type actually exists.
While that
On Tue, Dec 20, 2005 at 08:07:29PM +0100, Sebastian Sylvan wrote:
> I'm still looking for a good *practical* tutorial that I could
> recommend to newcomers.
> IO, data types and QuickCheck in the very first chapter, I say! Real
> program examples from the get go, and go into the theory on why this
On 20/12/05, Benjamin Franksen <[EMAIL PROTECTED]> wrote:
> On Tuesday 20 December 2005 20:58, Peter Simons wrote:
> > Daniel Carrera writes:
> > > I'm scared of monads :) I really don't know what a monad
> > > is.
> >
> > Neither do I, but that doesn't mean that I can't use just
> > fine. ;-)
>
On Tuesday 20 December 2005 20:58, Peter Simons wrote:
> Daniel Carrera writes:
> > I'm scared of monads :) I really don't know what a monad
> > is.
>
> Neither do I, but that doesn't mean that I can't use just
> fine. ;-)
>
> >> putStrLn :: String -> World -> World
> >
> > That seems less sca
Hi,
> Hugs Interpreter onlySuitable for learning. You'll need GHC for
> serious work.
This is putting Hugs down quite a bit. I personally prefer Hugs, and
use it for serious work (including developing a Haskell compiler, and
4 years of academic study and counting). About the only thing
On Tue, 2005-12-20 at 20:07 +0100, Sebastian Sylvan wrote:
. . .
> I'm still looking for a good *practical* tutorial that I could
> recommend to newcomers.
> IO, data types and QuickCheck in the very first chapter, I say! Real
> program examples from the get go, and go into the theory on why thi
Daniel Carrera writes:
> I'm scared of monads :) I really don't know what a monad
> is.
Neither do I, but that doesn't mean that I can't use just
fine. ;-)
>> putStrLn :: String -> World -> World
>
> That seems less scary.
Things become a lot clearer when you think about how to
print _two
Peter Simons wrote:
In my humble
opinion, it's unfortunate that many tutorials and
introductionary texts leave the impression that monadic code
would be something utterly different than "normal" Haskell
code. I feel it intimidates the reader by making a monad
appear like black magic, even though
On 20 Dec 2005 19:52:31 +0100, Peter Simons <[EMAIL PROTECTED]> wrote:
> > == So how do I write "Hello, world"? ==
> >
> > Well, the first thing you need to understand that in a
> > functional language like Haskell, this is a harder
> > question than it seems. Most of the code you will write
>
> == So how do I write "Hello, world"? ==
>
> Well, the first thing you need to understand that in a
> functional language like Haskell, this is a harder
> question than it seems. Most of the code you will write
> in Haskell is "purely functional", which means that it
> returns the same thin
78 matches
Mail list logo
