Lars Lundgren writes:
> [EMAIL PROTECTED] writes:
>
> > the problem of doing stateful things and IO at the same time. Eventually I
> > realised it is not possible to nest monads,
>
> But it is possible! You just need to use a monadtransformer:
>
> class MonadTrans t where
> lift :: Monad m =
On Thu, 16 Sep 1999, Lars Lundgren wrote:
[snip]
> myProg:: StateMT IO Int
> myProg = return 5
>
> main = do n <- runSMT myProg
> print n
>
I forgot to show something interesting in my first example, try this
instead:
myProg:: StateMT IO Int
myProg = do lift $ putStrLn "HelloWorld!"
On Wed, 15 Sep 1999 [EMAIL PROTECTED] wrote:
>
> * stToIO . This is often necessary for programs that do stateful things as well
> as IO. A few years ago, having read all relevant papers, I was very perplexed by
> the problem of doing stateful things and IO at the same time. Eventually I
> reali
| > * stToIO . This is often necessary for programs that do
| > stateful things as well as IO. A few years ago, having read
| > all relevant papers, I was very perplexed by the problem of
| > doing stateful things and IO at the same time. Eventually I
| > realised it is not possible to n
Tim about applications of polytypic programming:
>I didn't mean to imply that business applications involve any
sophisticated data
>structures. I had in mind just the kind of boring record values you mention,
>with no recursion required. Nonetheless, these record values need to be
stored,
>edited
Mark P Jones writes:
> | I agree. Computer science and other scientific applications tend
> | to be clever programs such as compilers, where data is well
> | structured and processing is complex. But business applications
> | typically have rather shallow processing, with lots of semi-arbitra
Simon Peyton-Jones writes:
> It's hard to make two independently-developed systems 100% compatible.
> For example, it would make it difficult for either GHC or Hugs to offer
> some feature or improvement without ensuring that the other system did too.
>
> However, your point is a good one.
On Tue, 14 Sep 1999, Mark P Jones wrote:
> given further enhancements. So perhaps I should have said: "Some
> folks out there want to write programs in a stable language.
> For them, there's Haskell 98." For the rest, there are choices to be
> made. One person may decide that programming in "gh
In a previous message, I wrote:
| Some folks out there want to use Haskell to write real programs. For
| them, there's Haskell 98.
To which Alex replied:
| To be clear, I am not an academic researcher. I develop real world
| web sites. I would really like to use Haskell for this process, but
> what ghc compiles. I'd like to also use Hugs, for a more interactive
development
> environment, but it shows little sign of ever being sufficiently
compatible (it
> is becoming increasing compatible in core aspects, but I want to use most
of the
> features of ghc, and the benefit of having an in
>I don't want to give the impression that I think the advocates of
>polytypism or arrows (...etc...) have done a poor job of describing
>them. Far from it -- there are lots of papers about polytypism for
>example, and it is fine work. But as a not-very-bright implementor
>I'm just not going to g
S. Alexander Jacobson writes:
> > At 03:55 AM 9/9/99 , Mark P Jones wrote:
> > Some folks out there want to use Haskell to write real programs. For
> > them, there's Haskell 98.
>
> To be clear, I am not an academic researcher. I develop real world
> web sites. I would really like to use
Simon Peyton-Jones wrote:
> It may be my own ignorance, but I can't readily lay my hands on a
> document entitled "Proposal for adding arrows to Haskell" for example.
It's called "Haskell Proposal: Syntactic Sugar for Arrows"; I posted a
URL here in January, and it's linked from the Future of Has
The debate about library documentation has been illuminating indeed.
I have observed the following:
* There have been lots of messages --- more so than most topics that
appear on the list. Obviously there is lots of interest; the topic
seems be one with which most people have encountered pr
> In asking about e.g. generic programming, arrows, etc, I am
> not suggesting
> we converge on a standard right now. I am trying to explore how much
> stock the language implementors currently put into these
> proposals.
I can't speak for others, but I can give my own impressions. In genera
> * There have been lots of messages --- more so than most topics that
> appear on the list. Obviously there is lots of interest; the topic
> seems be one with which most people have encountered problems in
> the past so are keen to do something about.
I think Richard has it right here.
On 09-Sep-1999, Christian Sievers <[EMAIL PROTECTED]> wrote:
> Jon Fairbairn wrote:
>
> > [3] I think this example is slightly easier, though on second thoughts
> >
> > unzip [('a', 1), ('b', 2), ('c', 3)] = (['a', 'b', 'c'], [1, 2, 3])
> >
> > is better still.
>
> It's a good idea to
--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Thu Sep 09 1999, Christian Sievers ->
> Two poeple suggested to use Strings in the example for unzip,
> (and they even suggested the same strings!)
>=20
> > unzip [("a", 1), ("b", 2), (
Jn Fairbairn wrote:
> > It's a good idea to use two different types in an example, but Char
> > is not well chosen, because the canonical way to write the above
> > result is ("abc",[1,2,3]).
>
> Good point. String is best:
>
> unzip [("a", 1), ("b", 2), ("c", 3)] = (["a", "b", "c"], [1, 2,
Two poeple suggested to use Strings in the example for unzip,
(and they even suggested the same strings!)
> unzip [("a", 1), ("b", 2), ("c", 3)] = (["a", "b", "c"], [1, 2, 3])
This is better, but now beginners might get the impression that "c"
is the way to name a Char, so I suggest to chan
> At 03:55 AM 9/9/99 , Mark P Jones wrote:
> Some folks out there want to use Haskell to write real programs. For
> them, there's Haskell 98.
To be clear, I am not an academic researcher. I develop real world
web sites. I would really like to use Haskell for this process, but the
tools and lib
Thu, 9 Sep 1999 14:48:50 +0100 (BST), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> pisze:
> I missed the discussion that decided that show should omit the
> syntactically unnecessary spaces when converting lists and tuples.
> While this may save space in files, I don't see that we are
>
On 9 Sep, Christian Sievers wrote:
> It's a good idea to use two different types in an example, but Char
> is not well chosen, because the canonical way to write the above
> result is ("abc",[1,2,3]).
Good point. String is best:
unzip [("a", 1), ("b", 2), ("c", 3)] = (["a", "b", "c"], [1, 2,
Jon Fairbairn wrote:
> [3] I think this example is slightly easier, though on second thoughts
>
> unzip [('a', 1), ('b', 2), ('c', 3)] = (['a', 'b', 'c'], [1, 2, 3])
>
> is better still.
It's a good idea to use two different types in an example, but Char
is not well chosen, because the
On 9 Sep, George Russell wrote:
> Here is my revised version of the documentation.
my :-) (which incorporates some of the other suggestions.)
I've given reasons at the bottom.
Type:
> unzip :: [(a,b)] -> ([a],[b])
unzip takes a list of pairs and returns a pair of lists.
Definition
Josef Sveningsson wrote:
> The report doesn't even say that Haskell should be lazy, only that it's
> non-strict. Now, it happens that most (all?) implementations have very
> similar operational semantics, but I don't think that a Haskell library
> should assume anything more about the semantics o
Michael (& the Haskell mailing list)
On Thu, 9 Sep 1999, Phil Molyneux wrote:
[stuff deleted]
> unzip :: [(a,b)] -> ([a],[b])
> unzip [] = ([],[])
> unzip (a,b):ps
> = (a:as,b:bs)
> where
> (as,bs) = unzip ps
>
Of cours
On Thu, 9 Sep 1999, Martin Norb{ck wrote:
> Thu Sep 09 1999, Josef Sveningsson ->
> Just because it's only informally defined in the report, doesn't mean it
> does not exist. For practical programming purposes, the informal
> semantics suffices. If you are a compiler/interpretor designer you may
Michael (& the Haskell mailing list) --- I empathise with your remarks:
we're in the process of switching our teaching from using Miranda to
Haskell/Hugs & your comments prompted me to mail my colleagues with a few
questions (copy below). The Haskell language is intended for allcomers but
the Hask
For comparison, see
http://www.cs.bell-labs.com/~jhr/sml/basis/pages/list-pair.html
I think this style of documentation is fairly useful, and it doesn't take long to
see if the function you want is there. My only quibble with this format is that it
separates the type of a function from its de
On Thu, 9 Sep 1999, George Russell wrote:
> Here is my revised version of the documentation. Sorry I can't
> manage the pretty formatting:
>
> unzip :: [(a,b)] -> ([a],[b])
> -
>
> Description:
>unzip takes a list of pairs and returns a pair of lists.
>
> Examples:
>unzip [(1,2),(
On Thu, 9 Sep 1999, George Russell wrote:
> Here is my revised version of the documentation. Sorry I can't
> manage the pretty formatting:
>
> unzip :: [(a,b)] -> ([a],[b])
> -
> Description:
>unzip takes a list of pairs and returns a pair of lists.
Minor quibble: the verbal descriptio
--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Thu Sep 09 1999, Josef Sveningsson ->
> This strikes me as odd. How can you define the operational semantics of a
> function when Haskell does not have an operational semantics?
Just becaus
--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Thu Sep 09 1999, George Russell ->
> This is very much better than what we have already, but I'll make
> the following quibbles anyway:
> (1) it should be possible to view all the specificat
On Thu, 9 Sep 1999, S. Alexander Jacobson wrote:
> On Wed, 8 Sep 1999, Andy Gill wrote:
> >
> > Literate Haskell is simply a way of including comments.
> > Javadoc attaches meaning to stylized comments,
> > such that the tool can produce annotated indexes.
> >
> > The two concepts are orthogona
On Wed, 8 Sep 1999, Andy Gill wrote:
>
> > At 05:54 PM 9/8/99 , Andy Gill wrote:
> > >I've been playing will possible formats of such documentation.
> > >Have a look at http://www.cse.ogi.edu/~andy/gooddoc.htm
> > >for what I'm currently thinking of.
> >
This looks real nice. As someone else on
Andy Gill wrote:
[snip]
> I've been playing will possible formats of such documentation.
> Have a look at http://www.cse.ogi.edu/~andy/gooddoc.htm
> for what I'm currently thinking of.
This is very much better than what we have already, but I'll make
the following quibbles anyway:
(1) it should be
At 05:33 AM 9/9/99 , you wrote:
>unzip
>=
>Type:
> [(a,b)] -> ([a],[b])
> unzip takes a list of pairs and returns a pair of lists.
>Description:
> -
>Examples:
>.
>.
>.
I like this. A lot. The type information is, for Haskell, a vital part of
documentation. It's just shouldn't be th
At 03:55 AM 9/9/99 , Mark P Jones wrote:
>My short term hope is for a stable Haskell 98, that's well-documented,
>well-supported, and well-used, both for writing useful applications,
>and for exploring potential ideas for later versions of the language.
>Good documentation for the H98 libraries (a
At 03:55 AM 9/9/99 , Mark P Jones wrote:
>I hope that my comments here will help you to understand Erik's
>message more fully, and to begin to appreciate how useful types
>can be in reading, understanding, and writing Haskell code.
I understand what Erik said and how useful types can be in such
S. Alexander Jacobson writes:
> Are we talking about documentation for the H98 libraries?
> Are these libraries relevant? Don't MPTC, Existential Types, Restricted
> Type Synonyms, Arrows, and an FFI substantial change the architecture,
> interface, and implementation of the libraries? As th
On Wed, 8 Sep 1999, Andy Gill wrote:
> Literate Haskell is simply a way of including comments.
> Javadoc attaches meaning to stylized comments,
> such that the tool can produce annotated indexes.
>
> The two concepts are orthogonal.
They are only sort of orthogonal. Another approach that combin
Josef Sveningsson wrote:
>
> Maybe the definition of a function should be left out from the
> documentation, at least by default. Javadoc has a number of options so
> that one can choose how much information the documentation should contain.
> If we have a good specification and a set of axioms a
| Are we talking about documentation for the H98 libraries?
| Are these libraries relevant?
Yes, in my opinion, these libraries are very relevant --- to
anyone who wants to build code using Haskell 98. Stability and
compatibility are the rewards that you get by choosing to write
a program in Has
Hi Michael,
| > OK, you fire up Hugs and type :t unzip and Hugs tells you that
|
| > unzip :: [(a,b)] -> ([a],[b])
|
| > Completely clear, unzip takes a list of pairs and returns a
| pair of lists.
|
| As a new user (and a complete newbie to FP), perhaps I can shed some light
| on something
Andy's example of function documentation looks fine to me. I'd also
like to see HaskellDoc work at the module level too: define attributes
such as an author, a version, Haskell system version, export list,
imported modules, web site, repository, whatever ...
In particular, I'd really like to see
> "Erik" == Erik Meijer <[EMAIL PROTECTED]> writes:
> The nice thing about Haskell is that the type of a polymorphic
> function tells you a lot about what the function does.
So just from the type of the following polymorphic function,
what does it do?
unzap ((a,b):abs) = let bang x = x : b
> [...]
> unzip = foldr (\(a,b) ~(as,bs) -> (a:as,b:bs)) ([],[])
>
> Not exactly intuitive. Could be better. I'm assuming that George's point
> is that this documentation leaves plenty of room for expansion.
OK, you fire up Hugs and type :t unzip and Hugs tells you that
unzip :: [(a,b)] -> ([a]
At 05:54 PM 9/8/99 , Andy Gill wrote:
>I've been playing will possible formats of such documentation.
>Have a look at http://www.cse.ogi.edu/~andy/gooddoc.htm
>for what I'm currently thinking of.
This is what I would classify as "reasonable documentation" based upon my
current level of Haskell ex
Michael Hobbs wrote:
> I think I might be able to clarify George's point with an example:
> unzip. Presumably, the unzip function will stay, no matter what happens
> with existential types, arrows, etc. The problem is, I don't know what
> unzip *does*. (Actually, I do, but I'm taking the POV of a
On 8 Sep, George Russell wrote:
> Don't add more functions like concatSep to the standard library or prelude.
Certainly not to the prelude, but I think there is a strong case for
evolving the standard library based on what people use. I use
((concat .) intersperse) quite a lot, and having a st
Andy Gill wrote:
> Simon Marlow and I are looking at including a Javadoc
> like tool (Haskelldoc) as an extended example for Happy,
> for release with soon to appear Happy 1.6. If only we could find
> time to write it :-) A Haskelldoc program would take
> a Haskell module annotated with stylized c
On Wed, 8 Sep 1999, S. Alexander Jacobson wrote:
> Are we talking about documentation for the H98 libraries?
> Are these libraries relevant? Don't MPTC, Existential Types, Restricted
> Type Synonyms, Arrows, and an FFI substantial change the architecture,
> interface, and implementation of the l
>> unzip = foldr (\(a,b) ~(as,bs) -> (a:as,b:bs)) ([],[])
>> Not exactly intuitive. Could be better. I'm assuming that George's point
>> is that this documentation leaves plenty of room for expansion.
> OK, you fire up Hugs and type :t unzip and Hugs tells you that
> unzip :: [(a,b)] -> ([a],[b
Michael Hobbs wrote:
>
> What's the thinking on this? As a supplement to, or instead of Literate
> Haskell? Not that I've ever really used Literate Haskell, but I had
> always planned on using it someday. ;-)
Literate Haskell is simply a way of including comments.
Think of it like you write a l
"Michael T. Richter" wrote:
>
> At 05:54 PM 9/8/99 , Andy Gill wrote:
> >I've been playing will possible formats of such documentation.
> >Have a look at http://www.cse.ogi.edu/~andy/gooddoc.htm
> >for what I'm currently thinking of.
>
> This is what I would classify as "reasonable documentati
"Michael T. Richter" wrote:
> Good docs, on the other hand, are very helpful. Even if it strikes an
> old-timer as redundant to explain "unzip = foldr (\(a,b) ~(as,bs) ->
> (a:as,b:bs)) ([],[])" as "this function takes a list of pairs and returns a
> pair of lists", believe it or not this actual
If you have some type of generic programming interface, then unzip changes
too. Unzip gets generalized from working only with lists to working with
any recursive data structure (see http://www.cs.chalmers.se/~patrikj/poly/).
I agree that we will have some version of unzip either way, I am just n
Are we talking about documentation for the H98 libraries?
Are these libraries relevant? Don't MPTC, Existential Types, Restricted
Type Synonyms, Arrows, and an FFI substantial change the architecture,
interface, and implementation of the libraries? As these language
features are becoming more ac
I think I might be able to clarify George's point with an example:
unzip. Presumably, the unzip function will stay, no matter what happens
with existential types, arrows, etc. The problem is, I don't know what
unzip *does*. (Actually, I do, but I'm taking the POV of a novice here.)
The only docume
60 matches
Mail list logo
