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!" -- a
| * 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 nest
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-arbitrary
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 "ghc"
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,
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
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 get
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 Haskell
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
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
* 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 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 combines
--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
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 the list
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
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),(3,4),(5,6)]
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
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 and
--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 because
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
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
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 course, 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:
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 (and
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
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
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
Don't add more functions like concatSep to the standard library or prelude. Instead
document
what is there better. I found it far easier to find functions in the Standard ML Basis
library than in the Haskell standard. Here are some suggestions for what could be
done:
(1) document the IO
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
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
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
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
"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 documentation" based
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
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
"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 : bang x in
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
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
[...]
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 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 actually
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
41 matches
Mail list logo
