Call for Papers
Workshop on Virtual Machines and Language Implementations (VMIL’23)
Co-located with SPLASH 2023
October 22-27, 2023, Cascais, Portugal
https://2023.splashcon.org/home/vmil-2023
==
---
PERFORMANCE CALL
The ACM SIGPLAN Workshop on Functional Art, Music, Modeling, and Design (FARM)
at the International Conference on Functional Programing (ICFP) is seeking
audio/visual works that utilize functional programmi
CALL FOR PAPERS
19th International Workshop on OCL and Textual Modeling
Co-located with
MODELS 2019 ACM/IEEE 22nd International Conference on Model
Driven Engineering Languages and System,
September 15-20, 2019
Of course, Haskell submissions are very welcome at the FARM!
5th ACM SIGPLAN International Workshop on Functional Art, Music, Modelling
and Design
Oxford, UK, September, 9th 2017
Call for Papers and Performances
Key Dates:
Paper submission deadline June 1, 2017
Performance submiss
5th ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and
Design
Oxford, UK, September, 9th 2017
Key Dates:
Submission deadline June 1, 2017
Author Notification July 1, 2017
Camera ReadyJuly 13, 2017
Call for Papers and Demos:
T
Hello everyone,
some of the people here on the list asked whether there will be
recordings of the workshop.
Now I can announce that we were able to record the whole event and
talks are accesible here:
http://staff.computing.dundee.ac.uk/frantisekfarka/tiap/
Also, all the speakers were kind enou
Hello everyone,
as the 12th of May is getting closer I would like to invite you
yet again for the Workshop on Type Inference and Automated Proving
at University of Dundee.
Please send me an email if you wish to attend as described bellow.
It helps us with organization.
For those who have not dec
On Thu, 16 Apr 2015 11:13:19 +0700
Kim-Ee Yeoh wrote:
Hi Kim-Ee,
I am afraid we currently do not plan to record the talks. But if
anything changes anf there will be any recordings I will send an email
to let the people in this mailing list know.
Best,
Franta
> Hi František,
>
> Do you think
*
WORKSHOP ON TYPE INFERENCE AND AUTOMATED PROVING
Tuesday the 12th of May, 12PM to 6PM
School Of Computing,
University of Dundee
http://staff.computing.dundee.ac.uk/frantisekfarka/tiap/
***
13th International Workshop on Termination (WST)
Centro Residenziale Universitario di Bertinoro (near Bologna, Italy)
http://www.imn.htwk-leipzig.de/WST2013/
submission: July 22, 2013
notification: July 25, 2013
final version: August 10, 2013
workshop: August 29 - 31, 2013
The W
ll-Typed) and a talk by Kevin Hammond (University of
St. Andrews, Scotland; talk in English).
More information on the website (with program and registration form):
http://portal.imn.htwk-leipzig.de/events/hal6-haskell-workshop
Best,
Janis.
--
Jun.-Prof. Dr. Janis Voigtländer
http://www.iai.
-- Forwarded message --
Date: Fri, 8 Jul 2011 12:11:45 + (UTC)
From: Johannes Waldmann
Subject: [Haskell-cafe] CfP: Haskell Workshop in Leipzig, Germany, October 7
Call for submissions
for our local Haskell Workshop in Leipzig, Germany.
Tutorials, talks, demonstrations
The 2010 ACM SIGPLAN Workshop on ML
http://www.cs.rit.edu/~mtf/ml2010
Baltimore, Maryland, United States
Sunday, September 26, 2010
co-located with ICFP 2010
Call for Participat
Dear all,
Due to popular request we have decided to extend the WGP deadline for
3 days. The new deadline is
on wednesday June 16th. See below.
==
CALL FOR PAPERS
WGP 2
Dear all,
This a final reminder that the deadline for WGP submissions is in one
week! See the call for papers below:
==
CALL FOR PAPERS
WGP 2010
6th ACM SI
Workshop on Advances in Message Passing (AMP)
Languages, Compilers, and Run-time Support
at the SIGPLAN 2010 Conference on Programming Language Design and
Implementation
Dear all,
the Workshop on Generic Programming is only a few days away: 20th
September 2008 (http://www.regmaster.com/conf/icfp2008.html).
==> Invited talk: The Generic Paradigm
==> Lambert Meertens (Utrecht University)
==> We have reserved 20 minutes for *lightning talks*. If you plan to
==> att
CALL FOR PAPERS
Workshop on Generic Programming 2008
Victoria, Canada, 20th September 2008
http://www.comlab.ox.ac.uk/ralf.hinze/wgp2008/cfp.{html,pdf,ps,txt}
The Workshop on Generic Programming is sponsored by AC
Just a reminder that the deadline for the Haskell Workshop is this
Friday, 15th of June!
More info:
http://www.cse.unsw.edu.au/~keller/haskellws/HaskellWorkshop.html
Cheers,
Gabriele
___
Haskell mailing list
Haskell@haskell.org
http
My apologies if you receive multiple copies of this:
-
ACM SIGPLAN 2007 Haskell Workshop
Call for Papers
Freiburg, Germany
Dear Haskellers,
In celebration of the 10th Haskell Workshop, that took place in
Portland, Oregon, on the 17th September 2006, the proceedings
of the very first Haskell workshop, in La Jolla 1995, have
now been made available off the Haskell Workshop home page:
www.haskell.org/haskell
Please note that the early registration deadline is August 18, 2006.
Cheers,
Andres
---
ACM SIGPLAN 2006 Haskell Workshop
Call for Participation
[apologies for mutliple copies]
---
Deadline extension for the WLPE'06 workshop.
New deadline is in two weeks: May 28 !
---
WLPE' 06 - DEADLINE EXTENSION
Apologies for multiple copies; feel free to distribute further.
Cheers,
Andres
ACM SIGPLAN 2006 Haskell Workshop
Call for Papers
Portland, Oregon
17 September, 2006
The Haskell
Apologies for multiple copies; feel free to distribute further.
Cheers,
Andres
ACM SIGPLAN 2006 Haskell Workshop
Call for Papers
Portland, Oregon
17 September, 2006
The Haskell
At the Haskell workshop in Tallinn in September it was decided to set
up a Haskell Workshop Steering Committee.
The main purpose of the Haskell Workshop Steering Committee is to
provide continuity of the workshop and to offer help and advice to
the current organizer(s) of the workshop
2005 Haskell Workshop
Tallinn, Estonia, 30 September, 2005
http://www.cs.uu.nl/~daan/hw2005
Call for participation
-- Important Dates ---
Early registration deadline : July
Final call for papers, with still two working weeks to go:
2005 Haskell Workshop
Tallinn, Estonia, 30 September, 2005
http://www.cs.uu.nl/~daan/hw2005
Final Call for papers
-- Important Dates
[I apologize for cross-postings. Please forward to interested colleagues]
2005 Haskell Workshop
Tallinn, Estonia, 30 September, 2005
http://www.cs.uu.nl/~daan/hw2005
Second Call for papers
-- Important Dates
[I apologize for cross-postings. Please forward to interested colleagues]
2005 Haskell Workshop
Tallinn, Estonia, 30 September, 2005
http://www.cs.uu.nl/~daan/hw2005
Call for papers
-- Important Dates
CALL FOR PARTICIPATION
Commercial Users of Functional Programming
(CUFP)
Sept 18, 2004
Co-located with ICFP
http://www.galois.com/cufp/
Functional languages have been under academic development
for over 2
Dear Colleague,
The deadline for submitting to the 2004 Haskell Workshop is getting
close. Please find the Call For Papers enclosed. The workshop is
to be held on 22 September in Snowbird, Utah, USA in association with
ICFP'04. The submission deadline is 4 June.
See http://www.cs.nott.ac.uk
Please find enclosed the Call For Papers for the 2004 Haskell Workshop,
to be held on 22 September in Snowbird, Utah, USA in association with
ICFP'04.
The submission deadline is 4 June: just a little more than a month away!
See http://www.cs.nott.ac.uk/~nhn/HW2004/ for further details, incl
Please find enclosed the Call For Papers for the 2004 Haskell Workshop,
to be held on 22 September in Snowbird, Utah, USA in association with
ICFP'04.
My apologies for multiple copies.
Best regards,
/Henrik
--
Henrik Nilsson
School of Computer Science and Information Technology
The Unive
[EMAIL PROTECTED] writes:
>> - There are features you might want to *disable*. eg.
>>GHC lets you turn off the monomorphism restriction.
"NoMonomorphismRestriction"?
>> Perhaps something like this:
>> {-# LANGUAGE Haskell98 +FFI -MonomorphismRestriction #-}
> Nice!
I feel pragmas embedd
> Looks fine to me. A few things to think about:
>
> - Some of the keywords specify an entire language (eg. Haskell98),
> whereas some are language modifiers (eg. FFI). We might want
>to make a distinction. Currently GHC supports only Haskell98 +
> modifiers.
Yes.
> - Are exte
>{-# LANGUAGE #-}
>
> where is one or more (if compatible) of keywords like
>
> Haskell98 Pure Haskell 98, no extensions.
> SharedExtenisons (Haskell02???) A set of agreed-upon extensions
> implemented by all "major"
Dear Haskellers,
Mark Jones writes:
> As a solution to that problem, the many-command-line-options
> scheme described seems quite poor! It's far too tool specific,
> not particularly scalable, and somewhat troublesome from a software
> engineering perspective.
I've also been thinking about this
On 11/09/2003, at 9:46 PM, Simon Marlow wrote:
I know that some of these problems can be addressed, at least in
part, by careful use of Makefiles, {-# custom pragmas #-}, and perhaps
by committing to a single tool solution. But I'd like to propose
a new approach that eliminates some of the comman
hello,
it's a pity i don't know how to get my mailer to reply to a few messages
at once :-)
i also like mark's idea. i know that ghc can alredy achive some of that
with the OPTION pragmas, but i think it is nice if we can reuse what is
already in the language rather than making programmers le
Mark P Jones writes an interesting suggestion:
...
> Hmm, ok, but perhaps you're worrying now about having to enumerate
> a verbose list of language features at the top of each module you
> write. Isn't that going to detract from readability? This is where
> the module system wins big! Just
Mark Jones writes:
> As a solution to that problem, the many-command-line-options
> scheme described seems quite poor! It's far too tool specific,
> not particularly scalable, and somewhat troublesome from a software
> engineering perspective. We're not talking about a choice between
> two poin
> Karl-Filip Faxen wrote:
>
> | Yes, things are clearer and I rather like the idea.
> | The only thorny issue is that the update function for
> | field 'wibble' is formed from but not equal to the
> | field name itself.
>
> This could be solved by having an abstract type Field
> thusly (*):
Karl-Filip Faxen wrote:
| Yes, things are clearer and I rather like the idea.
| The only thorny issue is that the update function for
| field 'wibble' is formed from but not equal to the
| field name itself.
This could be solved by having an abstract type Field
thusly (*):
type Field r a
| We at GHC HQ agree, and for future extensions we'll move to
| using separate options to enable them rather than lumping
| everything into -fglasgow-exts. This is starting to happen
| already: we have -farrows, -fwith, -fffi (currently implied
| by -fglasgow-exts).
|
| Of course, if we chang
In article <[EMAIL PROTECTED]>,
Graham Klyne <[EMAIL PROTECTED]> wrote:
> > - implicit parameters
> > - template haskell
> > - FFI
> > - rank-N polymorphism (forall keyword)
> > - recursive 'do' (mdo keyword)
...
> Where do multi-parameter classes fit in?
I think some of the type exten
At 13:13 10/09/03 +0100, Simon Marlow wrote:
Of course, if we change the language that is implied by -fglasgow-exts
now, we risk breaking old code :-) Would folk prefer existing syntax
extensions be moved into their own flags, or left in -fglasgow-exts for
now? I'm thinking of:
- implicit p
On Wednesday 10 September 2003 10:51, Ketil Z. Malde wrote:
> And now, let's just screw any backwards compatibility, and re-engineer
> the records system¹.
>
> I don't need any of this, and it makes my life harder. Are you guys
> going to keep at it, until I regret ever using Haskell?
I can't spe
On Wednesday 10 September 2003 07:22 am, Hal Daume III wrote:
> I agree with Malcolm, with the possible addition of:
>
> keep -fglasgow-exts as it is (or, even, perhaps continue making it the
> "add all extensions keyword). also have -fffi, -farrows, -fth, etc.
> but also have, -fnoth and -fnoff
I agree with Malcolm, with the possible addition of:
keep -fglasgow-exts as it is (or, even, perhaps continue making it the
"add all extensions keyword). also have -fffi, -farrows, -fth, etc.
but also have, -fnoth and -fnoffi. that way, if a lot of us have code
that uses all the extensions ot
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> Of course, if we change the language that is implied by -fglasgow-exts now,
> we risk breaking old code :-) Would folk prefer existing syntax extensions
> be moved into their own flags, or left in -fglasgow-exts for now? I'm
> thinking of:
>
> - im
> > I also think that having backwards compatability is not much of an
> > issue. After all, ghc has introduces a number of not backward
> > compatable changes to haskell, and I never heard any complaints.
>
> Oh no?
>
> Implicit parameters: I'm sure it is a great thing, but I'd already
> us
> On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote:
> >
> > Shouldn't that rather be:
> >
> > class HasWibble a where
> > wibble :: a -> Int
> > set_wibble :: a -> Int -> a
> >
> > class HasWobble a where ...
>
> Or even:
>
> class HasWibble a b | a -> b
> [EMAIL PROTECTED] (Ketil Z. Malde) writes:
>
> > Robert Ennals <[EMAIL PROTECTED]> writes:
>
> BTW, isn't this more or less exactly what Simon suggested (at the very
> top of this thread)?
Not really, no.
I assume you mean the system suggested by Peter Thieman, outlined in the
initial email
On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote:
>
> Shouldn't that rather be:
>
> class HasWibble a where
> wibble :: a -> Int
> set_wibble :: a -> Int -> a
>
> class HasWobble a where ...
Or even:
class HasWibble a b | a -> b where
wibble :: a -
> On Wed, 10 Sep 2003 10:26:04 +0100, Robert Ennals
> <[EMAIL PROTECTED]> wrote:
>
> >class Wibble a where
> >wibble :: a -> Int
> >wobble :: a -> String
> >set_wibble :: Int -> a -> a
> >set_wobble :: String -> a -> a
> >
> >
> >data Foo = Foo {wibble :: Int, wobble :: String}
> >
[EMAIL PROTECTED] (Ketil Z. Malde) writes:
> Robert Ennals <[EMAIL PROTECTED]> writes:
BTW, isn't this more or less exactly what Simon suggested (at the very
top of this thread)?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Robert Ennals <[EMAIL PROTECTED]> writes:
[Heavy snippage, hopefully preserving semantics]
> data Foo = Foo {wibble :: Int, wobble :: String}
> deriving Wibble
> We could imagine the definition of Foo being automatically desugared to the
> following:
> data Foo = Foo Int String
> instan
On Wed, 10 Sep 2003 10:26:04 +0100, Robert Ennals
<[EMAIL PROTECTED]> wrote:
>class Wibble a where
>wibble :: a -> Int
>wobble :: a -> String
>set_wibble :: Int -> a -> a
>set_wobble :: String -> a -> a
>
>
>data Foo = Foo {wibble :: Int, wobble :: String}
> deriving Wibble
>
> Yes, things are clearer and I rather like the idea. The only
> thorny issue is that the update function for field 'wibble'
> is formed from but not equal to the field name itself.
>
> In short, the magic thing would be in the 'deriving' clause:
>
> If the data type declares fields with names x_
Yes, things are clearer and I rather like the idea. The only
thorny issue is that the update function for field 'wibble'
is formed from but not equal to the field name itself.
In short, the magic thing would be in the 'deriving' clause:
If the data type declares fields with names x_1, ..., x_n
an
> Hi!
>
> > So in summary, here is my proposal:
> >
> > No specific "extensible records" system.
> >
> > Define record update to be a function just like record selection is.
> >
> > Allow these functions to be in type classes.
>
> I do not understand the second and third point: As I understand
Hi!
> So in summary, here is my proposal:
>
> No specific "extensible records" system.
>
> Define record update to be a function just like record selection is.
>
> Allow these functions to be in type classes.
I do not understand the second and third point: As I understand your
idea, record sel
I'd like to add a voice of dissent here.
I would much prefer it if Haskell didn't add specific extensible records
support - even if it could be done without breaking backwards compatibility.
This is because I believe that extensible records encourage poor style. They
encourage people to expos
Johannes Waldmann <[EMAIL PROTECTED]> writes:
> What about "ad-hoc overloading" (allowing visible entities to share names,
> as long as they can be distinugished by their typing).
> This is orthogonal to the "proper records" issue (?)
> but it might improve the current situtation (?)
> and it see
What about "ad-hoc overloading" (allowing visible entities to share names,
as long as they can be distinugished by their typing).
This is orthogonal to the "proper records" issue (?)
but it might improve the current situtation (?)
and it seems backward-compatible (?)
Of course this would need an
Iavor Diatchki <[EMAIL PROTECTED]> writes:
> Adrian Hey wrote:
>> IMHO preserving the status quo wrt records should be low priority.
>> It really doesn't bother me much if new (useful) language features break
>> existing code. I think this is a better option than permanently
>> impoverishing the
On Wednesday 10 September 2003 04:54, Andrew J Bromage wrote:
> G'day all.
>
> On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote:
> > but this might be an issue for others, who have to maintain "legacy"
> > code.
>
> You know a language has made it when we're talking about "legacy"
G'day all.
On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote:
> but this might be an issue for others, who have to maintain "legacy" code.
You know a language has made it when we're talking about "legacy" code.
On the other hand, you have to worry about a pure declarative langua
Hi.
Here's another opinion for the "Records! Records!" chorus:
- The record and module system is one of the two big things I'd like
to see changed in Haskell. (OT: the other is subtyping.)
- It shouldn't happen before Haskell 2, because of backward
compatability. (The dot operator
Coming from the ML world, I can say that I find the lack of
proper records a real loss. It is extremely convenient to
write functions which take many parameters as taking a record,
for then you don't have to worry so much about the order
of arguments. SML gets this much right, but the ad hoc
trea
hello,
i think records are very useful, and we don't use them much in haskell,
becuase the current record system is not very good.
Adrian Hey wrote:
IMHO preserving the status quo wrt records should be low priority.
It really doesn't bother me much if new (useful) language features break
existin
On Tuesday 09 September 2003 13:52, Johannes Waldmann wrote:
> On Tue, 9 Sep 2003, Adrian Hey wrote:
> > I rarely use named fields in my Haskell progs with Haskell as it is ...
>
> but you sure agree records are useful for collecting heterogenous data?
Yes, I would agree that even the current situ
Hello,
I may be wrong but can't we keep old records and add new ones (as
proposed in the First Class Modules paper)
with a different syntax?
Ussual records and extensible records are both usefull, in different
cases.
Best regards,
Nicolas Oury
Le mardi, 9 sep 2003, à 14:52 Europe/Paris, Joh
On Tue, 9 Sep 2003, Adrian Hey wrote:
> I rarely use named fields in my Haskell progs with Haskell as it is ...
but you sure agree records are useful for collecting heterogenous data?
for example, see data DynFlags here:
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/CmdLin
On Tuesday 09 September 2003 01:57, [EMAIL PROTECTED] wrote:
> Here is how Simon Peyton Jones summarized the discussion:
>
> The conclusion I took away was this
>
> There are undoubted advantages to having better records, but
>
> (a) they all make the language more complicated
>
>
Dear Haskellers,
This year's Haskell Workshop, held in Uppsala as a part of PLI, traditionally
concluded with a discussion on the future of Haskell. This time an attempt
was made to structure the discussion a little bit by focusing on two specific
topics, and by having each topic being intro
ACM SIGPLAN 2003 Haskell Workshop
Uppsala, Sweden, End of August 2003
pending approval
http://www.functional-programming.org/HaskellWorkshop/cfp03.html
Call For Papers
The Haskell Workshop forms part of the PLI 2003
The 2002 Haskell Workshop proceedings are now available
online from the ACM Digital Library:
http://www.cse.unsw.edu.au/~chak/hw2002/
Cheers,
Manuel
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
This is a brief account of the discussion on the future of
Haskell at the Haskell workshop, Oct 3, 2002, in Pittsburgh.
After Simon Peyton Jones discussed the copy-right issue of
publishing the report, we had a brief discussion about the
future of Haskell.
The first point raised was that the
The detailed programme for the 2002 Haskell Workshop is
available at
http://www.cse.unsw.edu.au/~chak/hw2002/
It turns out that we still have one free slot for a 10min
talk. Please email me if you are interested. First come,
first served.
See you soon in Pittsburgh!
Manuel
[My apologies if you receive multiple copies of this message]
ACM SIGPLAN
2002 Haskell Workshop
Pittsburgh, PA, USA
3rd October 2002
(as part of PLI&#x
SIGPLAN
2002 Haskell Workshop
Pittsburgh, PA, USA
3rd October 2002
(as part of PLI'02)
===
The purpose of the Haskell Workshop is to discuss experience
with Haskell
2002 Haskell Workshop
Pittsburgh, PA, USA
3rd October 2002
(as part of PLI'02)
===
The purpose of the Haskell Workshop is to discuss experience
with Haskell, and pos
[My apologies if you receive multiple copies of this message]
---
C A L L F O R P A P E R S
---
ACM SIGPLAN
2002 Haskell Workshop
[My apologies if you receive multiple copies of this message]
--
PROVISIONAL CALL FOR PAPERS
(Approval for PLI'02 pending)
--
2002 Haskell Wor
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
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
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
-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
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
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
>
> 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). ):
>
>
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
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
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
[ 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 9
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
_
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.
"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
1 - 100 of 132 matches
Mail list logo
