Koen Claessen wrote:
> Imagine a commutative monad, CIO. Commutative monads have
> the property that it does not matter in what order actions
> are performed, they will have the same effect. In other
> words, for all m1 :: CIO A, m2 :: CIO B, k :: A -> B -> CIO
> C, it should hold that:
>
> do a
Jo'n Fairbairn wrote:
> The idea is simply that we should provide a mechanism of
> saying to a compiler "this file (of data) is a module that
> exports only the variable v". ...
> So we tell the compilation system that file
> /somewhere/contains-v contains the value of the variable
> v::String, an
> But I just realized that it will probably be necessary to declare (not
> bind!) implicit parameters at the top level to avoid capture problems.
Yep, this is the way it would have to go.
--KW 8-)
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.
Benjamin Franksen wrote:
>On Thursday 04 November 2004 17:20, Ben Rudiak-Gould wrote:
>
>>This is one of the several ways in which the current implementation of
>>implicit parameters is broken. Clearly they *should* belong to the
>>module namespace, and if we modify the implementation so that they
Koen Claessen wrote:
>Ben Rudiak-Gould wrote:
>
> | I'm not convinced this is a problem either. All you have
> | to do is use a single parameter (?MyModule.globals ::
> | MyModule.Globals), where MyModule.Globals is an abstract
> | type, and you've hidden your implementation as completely
> | as if
On Thursday 04 Nov 2004 5:54 pm, George Russell wrote:
> However virtually everyone seems to have their own patent solution,
> and we are no closer to agreement.
FWIW, what Koen describes is exactly what I want (I think :-).
So there's at least 2 votes for the "non-IO" monad approach,
provided the
On Thursday 04 November 2004 18:54, George Russell wrote:
> John Peterson wrote (snipped):
> > The implementer of these functions has to guarantee that the
> > actions do not destroy the commutativity of the CIO monad.
>
> Sorry, but several of my variable initialisation actions involve
> things
On Thursday 04 November 2004 18:28, Koen Claessen wrote:
> Ben Rudiak-Gould wrote:
> | I think the OP is proposing the same thing, except
> | without the ellipsis: i.e. we just write
> |
> | pretty :: Doc -> String
> |
> | and the compiler infers pretty :: (?width :: Int) => Doc
> | -> S
On Thursday 04 November 2004 17:20, Ben Rudiak-Gould wrote:
> Koen Claessen wrote:
> >(1) Whenever a module uses an implicit parameter like that,
> >it has to have a name that is different from all implicit
> >parameters used by any other (future) module. (Yes, implicit
> >paramers cannot be qu
John Peterson wrote (snipped):
> The implementer of these functions has to guarantee that the
> actions do not destroy the commutativity of the CIO monad.
Sorry, but several of my variable initialisation actions involve
things like starting up child processes or rapid exits from the program
if unsu
Ben Rudiak-Gould wrote:
| I'm not convinced this is a problem either. All you have
| to do is use a single parameter (?MyModule.globals ::
| MyModule.Globals), where MyModule.Globals is an abstract
| type, and you've hidden your implementation as completely
| as if you had used unexported glo
On Thursday 04 November 2004 16:16, Koen Claessen wrote:
> The problem with John's approach is that it breaks
> modularity. It does this in two ways:
>
> (1) Whenever a module uses an implicit parameter like that,
> it has to have a name that is different from all implicit
> parameters used by any
On 2004-11-04 at 16:16+0100 Koen Claessen wrote:
> Benjamin Franksen wrote:
>
> | 1) I strongly disagree with ideas to execute IO actions
> | implicitly in whatever defined or undefined sequence
> | before or during main for whatever reasons.
>
> I agree with the objections you make. Having fu
I've been meaning to get into this debate ...
Koen proposes:
Imagine a commutative monad, CIO. Commutative monads have
the property that it does not matter in what order actions
are performed, they will have the same effect. In other
words, for all m1 :: CIO A, m2 :: CIO B, k :: A -> B ->
Koen Claessen wrote:
>Benjamin Franksen wrote:
>
> | 1) I strongly disagree with ideas to execute IO actions
> | implicitly in whatever defined or undefined sequence
> | before or during main for whatever reasons.
>
>I agree with the objections you make. Having full IO actions
>as initialization ac
Benjamin Franksen wrote:
| 1) I strongly disagree with ideas to execute IO actions
| implicitly in whatever defined or undefined sequence
| before or during main for whatever reasons.
I agree with the objections you make. Having full IO actions
as initialization actions might be a bit too much
Hello,
> We are looking into parsing full Haskell98 (probably using SableCC)
> [...]
> b) any LALR(1) grammar for Haskell98,
This file contains the grammar used in GHC.
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/parser/Parser.y.pp
Note that there's also a module in the G
Hi!
We are looking into parsing full Haskell98 (probably using SableCC)
as an input language to our program verification environment
(http://www-i2.informatik.rwth-aachen.de/AProVE).
Does anyone know about and can point me to either
a) a SableCC style Haskell98 grammar description,
b) any LALR(1) g
18 matches
Mail list logo
