> ... 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 e
Johannes Waldmann <[EMAIL PROTECTED]> writes:
>> ... there have been no submissions accepted in the
>> `application letters' category for the Haskell workshop.
Really?
> a) there ARE no proper real world applications of Haskell
>(only a rather large number of so called pearls)
> b) these t
On Wed, Sep 12, 2001 at 10:04:06AM +0100, [EMAIL PROTECTED] wrote:
> 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.
A minor point: last year i
This is an area of grave concern for me. I am still quite new to Haskell, so
perhaps I should wait until others have spoken, but I'll go ahead anyway. I
certainly don't mean to offend anyone, so please bear with me.
Speaking as an 'industrial' programmer who gave a 30-minute application
presentat
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 difficu
> 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' pro
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 Ha
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) cr
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.)
> Grant
At 2001-09-13 16:00, 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 implementati
[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)
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
Marcin 'Qrczak' Kowalczyk wrote:
> 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 &
"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 o
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.
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
_
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
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
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 s
> 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). ):
>
>
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 t
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
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
-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
Eray Ozkural wrote (on 16-09-01 17:44 +0300):
> 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 conclude
28 matches
Mail list logo