Bugs item #1059873, was opened at 2004-11-04 00:36
Message generated for change (Comment added) made by volkersf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1059873group_id=8032
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Bugs item #1059873, was opened at 2004-11-04 00:36
Message generated for change (Comment added) made by volkersf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1059873group_id=8032
Category: Compiler
Group: 6.2.1
Status: Closed
Resolution: Works For Me
Hi,
If I have this at the start of a .x file:
{
{-# OPTIONS -w #-}
module Lexer (lex_tok) where
}
then the generated .hs file starts:
{-# OPTIONS -cpp #-}
{-# LINE 2 Lexer.x #-}
{-# OPTIONS -w #-}
module Lexer (lex_tok) where
and the warnings are suppressed
Peter Simons wrote:
The CVS version of the libraries tree comes with all kinds
of neat and dangerously unstable code I'd like to use,
particularly the arrows subdirectory. Now I wonder: Is
there some build.mk magic I could perform to tell GHC to
build these libraries as part of my normal build? So
It's an old thread, but nothing has really happened yet, so I'd like to
restate and expand the question: What should the behaviour of toRational,
fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report
is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on
On Thu, Nov 04, 2004 at 08:08:03PM +0100, Sven Panne wrote:
Peter Simons wrote:
The CVS version of the libraries tree comes with all kinds
of neat and dangerously unstable code I'd like to use,
particularly the arrows subdirectory. Now I wonder: Is
there some build.mk magic I could perform to
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 GHC
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
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 actions
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 -
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 other
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
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
| - String, or
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 like
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 do,
the
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]
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, and that
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 - m1
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 you
On Thu, Nov 04, 2004 at 10:37:25AM +0300, Alexander Kogan wrote:
Hi!
How about this?
let a' = addToFM_C (+) a x 1 in
maybe () (`seq` ()) (lookupFM a' x) `seq` a'
It worked for me.
Thank you. It works for me too, but I don't understand why and how ;-))
Could you explain?
Tomasz Zielonka [EMAIL PROTECTED] writes:
Thank you. It works for me too, but I don't understand why and how ;-))
Could you explain?
I'm a bit puzzled by this discussion, as strictness of FiniteMaps have
rarely been (perceived to be?) a problem for me.
Scott's solution forces (lookupFM a' x)
On Thu, Nov 04, 2004 at 09:24:30AM +0100, Ketil Malde wrote:
Tomasz Zielonka [EMAIL PROTECTED] writes:
Thank you. It works for me too, but I don't understand why and how ;-))
Could you explain?
I'm a bit puzzled by this discussion, as strictness of FiniteMaps have
rarely been (perceived
Hi!
Scott's solution forces (lookupFM a' x) to head normal form (or is it
weak head normal form). This means that the value of type (Maybe v) is
evaluated as much that it is known whether it is Nothing, Just _ or _|_
(bottom). This is probably enough to evaluate the path from FiniteMap's
On Thu, Nov 04, 2004 at 08:03:56AM +0100, Tomasz Zielonka wrote:
How about this?
let a' = addToFM_C (+) a x 1 in
maybe () (`seq` ()) (lookupFM a' x) `seq` a'
It worked for me.
Of course, it is quite inefficient. If you care about constant factors,
better use a FiniteMap with
On Thu, Nov 04, 2004 at 11:44:32AM +0300, Alexander Kogan wrote:
Ok.
I have 2 questions about this:
1. This means seq function evaluates only 'top' of argument, so when I pass,
for example, list as argument, it will be evaluated only to [unevaluated,
unevaluated, ...]? Am I right?
Almost.
Hi!
4 2004 11:54 Tomasz Zielonka (a):
[skip]
Note that the things marked 'unevaluated' above, could be already
evaluated by some other computation.
Ok, I understand.
2. If so, is there method to _completely_ evaluate expression?
Most of the time you don't need it. But if you think you
Sorry, I had to drop out of this thread for a few days...
Ben Rudiak-Gould wrote:
Paul Hudak wrote:
Note that instead of:
data Shape = Circle Float
| Square Float
the Haskell designers might have used the following syntax:
data Shape where
Circle :: Float - Shape
27 matches
Mail list logo
