On 15-Sep-2001, Mark Carroll [EMAIL PROTECTED] wrote:
On 14 Sep 2001, Mike Gunter wrote:
The problem is not a loss of referential transparency but the
requirement that evaluation order must be specified. E.g.
what should
raise left + raise right
return?
(snip)
Ah!
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes:
Parsec [uses some variant of the error monad] and similar things. It
tries to generate reasonable messages of the form expecting foo,
found bar or unexpected bar annotated with source position,
making use of labels of higher level syntactic
Sat, 15 Sep 2001 15:44:52 -0500, Duncan Coutts [EMAIL PROTECTED] pisze:
I've been using a few variants: single error, multiple error and multiple
error/warning types. I'm also particularly pleased with one that has an
extra combinator which allows seperate 'branches' of an expression to
Marcin 'Qrczak' Kowalczyk wrote (on 16-09-01 09:30 +):
Getting right descriptions of what was expected or unexpected is not
trivial. For example when there is no separate lexer, we rarely have
anything besides raw characters as unexpected. We have something
more descriptive only if the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 16 September 2001 04:30 pm, Frank Atanassow wrote:
A bit off-topic, but after some experience using combinator parsers in
Haskell (not just Parsec) where the lexical and syntactical bits were done
in the same grammar, I concluded that
Mike - I hope you don't mind passing this to the list - but it's a great,
simple explanation of a big problem with my approach.
On 14 Sep 2001, Mike Gunter wrote:
The problem is not a loss of referential transparency but the
requirement that evaluation order must be specified. E.g.
what
On Fri, 14 Sep 2001, Mark Carroll wrote: (snip)
simplistic (but adequate for my immediate needs, which are currently
being served with lots of ifs and Maybes!).
Oh - and I should add, lots of two-tuple return values which are
basically of the form (Maybe a, error details). ):
-- Mark
At 2001-09-15 08:31, Mark Carroll wrote:
AFAICS a simple way to get
out of this is to only have one exception type that carries no information
instead of different ones so we can't distinguish one exception from
another, but that's obviously not great.
Isn't that what 'bottom' is?
--
Ashley
On Sat, 15 Sep 2001, Ashley Yakeley wrote:
At 2001-09-15 08:31, Mark Carroll wrote:
AFAICS a simple way to get
out of this is to only have one exception type that carries no information
instead of different ones so we can't distinguish one exception from
another, but that's obviously not
Alastair David Reid wrote:
| existential types, functional dependencies, other
| experimental-but-apparently-crucial features [...]
:
| I do use the IO monad, IORefs (sparingly), constructor
| classes, lots of libraries, the foreign function
| interface (lets you call C and C++), parser
Fri, 14 Sep 2001 01:00:06 +0200, Lennart Augustsson [EMAIL PROTECTED] pisze:
I have been writing substantial Haskell programs and I use *NO*
experimental features.
In a 2000-line interpreter I used:
- FiniteMap (for environments),
- Dynamic Exception (for exceptions in the language being
Manuel M. T. Chakravarty wrote:
Maybe it should be clarified that there are exceptions in
H98, but *only* in the IO monad. What the extension is
about are exceptions in pure functions.
Further clarification: the extension allows you to _raise_ exceptions in pure
functions, but you may only
On Fri, 14 Sep 2001 [EMAIL PROTECTED] wrote:
(snip)
Further clarification: the extension allows you to _raise_ exceptions in pure
functions, but you may only catch them in the IO monad.
This asymmetry is very important for Haskell, since otherwise evaluation order
would be observable. This
[ Meant for this to go to the mailing list ... ]
--
Andy Moran Ph. (503) 526 3472
Galois Connections Inc. Fax. (503) 350 0833
3875 SW Hall Blvd. http://www.galconn.com
Beaverton, OR
I may as well send my reply to the list too, then! (-:
On Fri, 14 Sep 2001 [EMAIL PROTECTED] wrote:
Mark Carroll wrote:
(snip)
Oh, certainly, but couldn't the compiler do all the rewriting for you,
though, so existing code would still work and new code would still look
nice?
I'm not
Fri, 14 Sep 2001 12:10:27 +1000, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
Maybe it should be clarified that there are exceptions in
H98, but *only* in the IO monad. What the extension is
about are exceptions in pure functions.
BTW, Exceptions are useful for something other than
Quick reply to just one point (more later, I hope):
Also, do these books have good coverage of things like
existential types, functional dependencies, other
experimental-but-apparently-crucial features that are hard to find
documentation for?
I consider myself a fairly hardcore
Thanks, that's very valuable information. It's hard to appreciate the
relative utility (as you can see :-)) of different experimental features.
It's also confusing that things like exceptions, concurrency, and FFI are
labeled 'experimental'. They're so (IMHO) crucial that I find myself saying,
[EMAIL PROTECTED] wrote:
Thanks, that's very valuable information. It's hard to appreciate the
relative utility (as you can see :-)) of different experimental features.
It's also confusing that things like exceptions, concurrency, and FFI are
labeled 'experimental'. They're so (IMHO)
Lennart Augustsson wrote:
I have been writing substantial Haskell programs and I use *NO* experimental
features. What I'm currently working on is over 2 lines of Haskell 98.
No extensions whatsoever. (It even compiles and runs with all available
Haskell implementations.)
Granted, I
[EMAIL PROTECTED] wrote,
Thanks, that's very valuable information. It's hard to appreciate the
relative utility (as you can see :-)) of different experimental features.
It's also confusing that things like exceptions, concurrency, and FFI are
labeled 'experimental'. They're so (IMHO)
A thought to dicscuss for next year's Haskell
workshop. This is the second year running that
there have been no submissions accepted in the
`application letters' category for the Haskell
workshop. It seems that this comes from the
fact that these are not getting the same grades
as submissions
... there have been no submissions accepted in the
`application letters' category for the Haskell workshop.
that seems strange indeed. two reasons come to mind:
a) there ARE no proper real world applications of Haskell
(only a rather large number of so called pearls)
b) these things do
-
From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 2:04 AM
To: [EMAIL PROTECTED]
Subject: Application letters at the Haskell workshop: suggestion
A thought to dicscuss for next year's Haskell
workshop. This is the second year running
I think there's a lot of truth in all you said in your message and I
make the following comment merely as a point of information.
I think I speak for the majority of 'industrial' programmers when I
say Haskell is a very difficult language to approach. I believe a
great deal of this
I think there's a lot of truth in all you said in your message and I
make the following comment merely as a point of information.
[Bryn Keller]
Thanks very much, I was hoping my comments would be taken
constructively.
I think I speak for the majority of 'industrial'
26 matches
Mail list logo
