as it is fragile wrt changes
in the module structure of the library I have constructed.
jvl
- Original Message -
From: Simon Marlow marlo...@gmail.com
To: John Lask jvl...@hotmail.com
Cc: glasgow-haskell-users@haskell.org
Sent: Monday, June 01, 2009 9:15 PM
Subject: Re: ghc - force
in declaring fixity for an operator (\\) to get it to compile using ghc
6.10.4, I needed to use the following code
infixl 9 \\\
(\\) a b = etc ...
where I assume the first \ escapes the second \, using infixl 9 \\ generates
a syntax error
infixl 9 \\ used to compile no problems with ghc
indeed it was the cpp, and the behaviour is consistent beetween versions, I
must have introduced some changes that affected the eol marker. Thanks for
your tip.
jvl
- Original Message -
From: Duncan Coutts duncan.cou...@worc.ox.ac.uk
To: John Lask jvl...@hotmail.com
Cc: glasgow
Hello
I hope someone can provide some guidance on how I can solve a certain
problem.
I have a library that taps into the ghc c rts: specifically when the rts
is single threaded I am pumping events in via: stg_pending_events, when
the threaded rts is used I use sendIOManagerEvent.
i.e. I
(installing callback);
g_callback = sighandler;
CreateThread(NULL,0, (LPTHREAD_START_ROUTINE)alarm_callback,
(void*)0,0,0);
}
On 01/02/10 13:36, John Lask wrote:
I understand these are internals of ghc and subject to change. The
reason for their use
Whilst I have nothing against the change in syntax for recursive do aka
http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html
Instead of writing
mdo
a - getChar
b - f c
c - g b
putChar c
return b
you would write
do
a - getChar
rec { b - f c
; c
I think this would just require the lex layout rules already in place for
do/let in GHC; my guess is that your example would work if the body were
indented past the r of rec.
for the record ...
t2 =
do rec
a - getChar
b - f c
c - g b
putChar c
return b
re ...
As I understand it the generated code is not exported from the
translation unit so there are no collisions at link time. We could do
the same if we could force the generated type class instance to not be
exported from the module.
I have encountered several occasions when I wished
relating to the ghc trac discussion ...
for some time I have had a ghc trac login, but every time I login it
asks for an email verification token
(http://hackage.haskell.org/trac/ghc/verify_email) but no token has ever
been sent to me, nor when I change my email or request a resend is one
What is really required is a pluggable back-end infrastructure -
whereby various back-ends could be maintained (or not) at the discretion
of their originators and separate to the official ghc back-ends.
Ideally pluggable back-ends would be installable as packages.
such infrastructure, I
On 3/08/2011 2:10 PM, Brandon Allbery wrote:
On Wed, Aug 3, 2011 at 00:31, John Laskjvl...@hotmail.com wrote:
What is really required is a pluggable back-end infrastructure - whereby
various back-ends could be maintained (or not) at the discretion of their
originators and separate to the
for what it is worth, I would like to see both System.IO and Directory
export internal functions where the filepath is a Raw Byte representation.
I have utilities that regularly scan 100,000 of files and hash the path
the details of which are irrelevant to this discussion, the point being
that
My primary concerns are (in order of priority - and I only speak for myself)
(a) consistency across platforms
(b) minimize (unrequired) performance overhead
I would prefer an api which is consistent for both win32, posix or other
os which only did as much as what the user (us) wanted
for
On 1/02/2012 12:26 AM, AntC wrote:
Simon Peyton-Jonessimonpjat microsoft.com writes:
Beyond that, it would really help namespacing in general to appropriately
extend the module system to allow multiple modules to be declared within a
single file -- or, better yet, submodules. [snip] the
On 13/07/2012 3:08 AM, Cale Gibbard wrote:
Personally I don't see why everyone appears to prefer the syntax with
\ in it over just the obvious case section syntax which was originally
proposed.
case of { ... }
looks much better to me than
\case of { ... }
and the former makes sense to me as
15 matches
Mail list logo
