On Tue, Oct 14, 2014 at 10:26:46PM +0200, S. Doaitse Swierstra wrote:
> The GHC manual already for quite a number of version states:
>
> • Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever
> arr, (>>>), first, app, (|||) and loop functions are in scope.
> But unli
GHC implements data kinds by promoting data declarations of a certain
restricted form, but I wonder if it would be better to have a special
syntax for kind definitions, say
data kind Nat = Zero | Succ Nat
At the moment, things get promoted whether you need them or not, and
if you've made some m
On Fri, Jul 13, 2012 at 01:21:25PM +0100, Wolfgang Jeltsch wrote:
> I’m strongly opposed to the
>
> case of { ... }
>
> syntax, because there seems to be no natural arrow expression analog of
> it.
>
> A notation that starts with \ (like “\case”) can be carried over to
> arrow expressions by
On Sun, Jan 15, 2012 at 11:42:28AM +, Ben Moseley wrote:
> The real application is trying to process a structure containing GADTs -
> something more like this:
>
> {-# LANGUAGE GADTs,Arrows,Rank2Types #-}
> import Control.Arrow
>
> data G a where
> G1 :: Int -> G Char
> G2 :: Int ->
On Sun, Jan 15, 2012 at 09:34:35AM +, Ben Moseley wrote:
> Consider the code below:
>
>
>
> {-# LANGUAGE Arrows,Rank2Types #-}
>
> import Control.Arrow
>
> -- cmdcomb :: Arrow a => (a (env,x) x) -> a (env,x) x
> -- cmdcomb aegg = aegg
>
> cmdcomb :: Arrow a => (forall x . a (env,x) x)
On Thu, Dec 22, 2011 at 03:29:48PM +, Serge D. Mechveliani wrote:
> DExport.hs:26:8:
> Ambiguous module name `Prelude':
> it was found in multiple packages: base haskell98-2.0.0.1
> --
>
> Please, what is the best way out?
You need to remove either the dependency
Johan Tibell writes:
> As part of GHC releases users also get a bunch of libraries. These
> libraries (e.g. array-0.3.0.3 in the last release) aren't uploaded on
> Hackage.
They have been in the past, by either Ian or me, but it seems a few
were missed for 7.2.1.
__
Simon Peyton-Jones writes:
> (Plan A) Add a module 'Prelude' to package 'haskell98'.
>Now you can compile a pure H98 program thus:
>ghc -c Main.hs -hide-all-packages -package haskell98
>(Cabal puts the -hide-all-packages in for you.) And this will
>
On Sat, Jul 24, 2010 at 01:10:56PM +0200, Jürgen Doser wrote:
> This seems to be a bug in ghc. First, let's fix bar to give the full
> three arguments (Int, Float, Double) to g:
>
> bar f g = proc x -> do
> (f -< x) `foo` (\n m k -> g -< (n,m,k))
>
> ghc infers the type:
>
> bar :: (t -> Str
There's also an underlying semantic issue, which is not yet resolved.
The GHC implementation of mdo (following Levent and John's paper)
performs a dependency analysis on the statements in the mdo to apply
mfix to the shortest possible subsegments of statements. For example,
mdo
a <- f b
On Tue, Feb 23, 2010 at 03:05:56PM -, Bayley, Alistair wrote:
> Just a wild guess, but the package description has this non-ascii text:
>
> author: Ralf Lämmel, Simon Peyton Jones
>
> It could well be Latin-1 encoded, rather than UTF8.
No, syb-0.1.0.3/syb.cabal is UTF-8-encod
On Tue, Feb 02, 2010 at 03:51:18PM +0100, Jose A. Ortega Ruiz wrote:
> [...] The problem is that the size and
> some of the offsets of the C struct statfs computed by hsc2c are wrong:
> i'm in a 32bit linux system, and i've checked, using a C program, that
> sizeof(struct statfs) is 64 (hsc2 is giv
-td25198347.html
-Ross
On Nov 15, 2009, at 8:03 AM, Luca Ciciriello wrote:
> Thanks a lot Christophe.
> This solve my problem.
>
> Luca.
>
>
> On Nov 15, 2009, at 1:49 PM, alpheccar wrote:
>
>> Hi,
>>
>> Change your /usr/bin/ghc to
>>
>> #
On Mon, Nov 02, 2009 at 02:05:01PM +, Simon Marlow wrote:
> You need array 0.3.0.0 which comes with GHC 6.12rc1, but is
> (probably) not on Hackage yet.
No it isn't: array-0.3.0.0 will be defined by what's released in GHC 6.12.
___
Glasgow-haskell-us
On Tue, Nov 18, 2008 at 10:30:01AM +, Malcolm Wallace wrote:
> > When the -XUnicodeSyntax option is specified, GHC accepts some Unicode
> > characters including left/right arrows. Unfortunately, the letter
> > "greek lambda" cannot be used. Are there any technical reasons to not
> > accept it?
On Thu, Sep 18, 2008 at 12:30:42AM +0100, Claus Reinke wrote:
> So far, I had assumed that every tool defined its own macro,
> but it seems that __GLASGOW_HASKELL__ is defined by
> ghc and by cabal, while __HADDOCK__ is defined only by
> the latter. Is that right?
Yes, Cabal defines __HADDOCK__ on
On Fri, Aug 15, 2008 at 04:17:44PM +0200, Sean Leather wrote:
> module A where
> class A t where
> a :: t
>
> module B where
> import A
> instance A Int where
> a = 0
> a0 :: Int
> a0 = a
>
> module C where
> import A
> instance A Int where
> a = 1
> a1 :: Int
> a1 = a
>
> module Main wher
On Fri, Aug 15, 2008 at 03:09:16PM +0200, Sean Leather wrote:
> Ross Paterson wrote:
> With implicit import, it just doesn't work to have different instances in
> different places. Suppose two modules use your library in the different
> ways you envisage. Then those
On Fri, Aug 15, 2008 at 02:21:33PM +0200, Sean Leather wrote:
> In my case, it does matter where instances are in scope. My library
> requires orphan instances by design. If the programmer imports the
> top-level module, then s/he gets a default set of instances. But the
> programmer has the option
On Thu, Aug 14, 2008 at 08:00:25PM +0200, Sean Leather wrote:
> Well, the warning is right that you don't need to re-export module B:
> instances are implicitly exported. So you could just remove the export of
> "module B", unless there's a reason to export it (such as, you might add
>
On Mon, Aug 11, 2008 at 04:17:59PM +0100, Simon Marlow wrote:
> The main obstacle with just switching the core libraries is that they
> are shared by other implementations and other maintainers. So I see no
> alternative but to create forks of those repositories for use by GHC,
> unless/until the
On Wed, Mar 26, 2008 at 08:52:43PM +, Ganesh Sittampalam wrote:
> I'm a bit confused about why the following program doesn't compile (in
> any of 6.6.1, 6.8.1 and 6.9.20080316). Shouldn't the Ord (a, b) context
> be reduced?
>
> {-# LANGUAGE FlexibleContexts #-}
>
> module Test2 where
>
> foo
On Sat, Mar 15, 2008 at 12:32:29AM -0700, Jason Dusek wrote:
> Simon Marlow <[EMAIL PROTECTED]> wrote:
> > GHC...can't guarantee to generate a prototype that is exactly
> > the same as the C prototype given in the header file (e.g. it
> > doesn't know about const)...
>
> Why doesn't GHC know abo
On Fri, Mar 14, 2008 at 12:05:18AM +, Ian Lynagh wrote:
> On Thu, Mar 13, 2008 at 10:52:24PM +0000, Ross Paterson wrote:
> > On Thu, Mar 13, 2008 at 03:31:37PM -0700, Simon Marlow wrote:
> > > Setting the locale *might* have side-effects, for instance we noticed
>
On Thu, Mar 13, 2008 at 03:31:37PM -0700, Simon Marlow wrote:
> Setting the locale *might* have side-effects, for instance we noticed
> before that heap profiling broke in some locales because the RTS code to
> generate the .hp file was using fprintf to print numbers, and the number
> format
On Thu, Mar 06, 2008 at 12:23:35AM +, Duncan Coutts wrote:
> However for ghc:
>
> foreign import ccall unsafe "foo.h foo" foo :: IO ()
>
> does not escape because ghc does not track which .h file should be
> #included later. It's not that it couldn't escape according to the FFI
> spec but tha
On Wed, Mar 05, 2008 at 11:16:14PM +, Duncan Coutts wrote:
> I was under the impression that with ghc, ffi import declarations like
> this do not escape the module:
>
> foreign import ccall unsafe "foo.h foo" foo :: IO ()
GHC can inline the stub across module (and thus package) boundaries,
so
age has some discussion of implementation issues.
>>
>> Oh yes, so it is. Did this proposal get discussed on any mailing list?
>> I'd like to see what people thought. Was there any conclusion about
>> feasibility?
>
> Ross proposed this on the libraries list in 2005:
On Mon, Oct 22, 2007 at 03:43:38PM +0100, Ian Lynagh wrote:
> On Mon, Oct 22, 2007 at 03:04:15PM +0100, Ross Paterson wrote:
> > On Mon, Oct 22, 2007 at 02:11:03PM +0100, Ian Lynagh wrote:
> > > On Mon, Oct 22, 2007 at 12:43:05PM +0100, Duncan Coutts wrote:
> > >
On Mon, Oct 22, 2007 at 02:11:03PM +0100, Ian Lynagh wrote:
> On Mon, Oct 22, 2007 at 12:43:05PM +0100, Duncan Coutts wrote:
> > ==
> > arrows
> >
> > HEAD repo: http://darcs.haskell.org/packages/arrows
> > Released version: 0.3 (on hackage)
> > Current version:0.3
> > Chang
On Mon, Dec 11, 2006 at 12:16:06PM +, Simon Peyton-Jones wrote:
> [...] Just to summarise, the difficulty is this:
> I have a dictionary of type (C a b1)
> I need a dictionary of type (C a b2)
> There is no functional dependency between C's parameters
>
> PS: the comple
On Mon, Nov 06, 2006 at 12:53:55PM +, Simon Marlow wrote:
> Incedentally, this is also one reason I think lazy I/O is a wart (despite
> its obvious usefulness): because it necessarily requires talking about
> evaluation order.
What is lazy output? Buffering?
___
On Mon, Nov 06, 2006 at 05:21:04PM +, Ross Paterson wrote:
> Apart from that, the only thing wrong with seq is its name.
I take back that part. Simon's "strong hint" suggestion looks like a
good idea. It's just one of a number of implicit assumptions we make
abou
On Mon, Nov 06, 2006 at 06:25:48PM +, Malcolm Wallace wrote:
> When I use `seq`, it is sometimes in a construction like
>
> unsafePerformIO (emit "squawk!) `seq` x
>
> where I am trying to force the impure side-effect to happen, exactly and
> immediately before x is evaluated. Whilst thi
On Mon, Nov 06, 2006 at 01:53:52PM +, Malcolm Wallace wrote:
> So the doubly bizarre thing is that, actually, `seq` does not control
> the evaluation order (which is the only valid reason for wanting to use
> it in the first place), but nevertheless it undesirably changes the
> semantics of pro
On Fri, Oct 13, 2006 at 04:05:49PM -0700, Sigbjorn Finne wrote:
> Afraid I have to disappoint you (again :-( ) wrt OpenAL/ALUT. A bit
> too late, but _if_ there's a wider agreement that including a
> package such as this would be generally useful, I'd be happy to
> do something about it the next ti
On Sun, Oct 08, 2006 at 05:30:25PM -0500, Brian Smith wrote:
> I was looking under "latest stable version" on the Cabal website. I
> thought it was the latest version of the docs because the URL had
> "latest" in it.
Hmm, quite a bit of historical stuff there.
> I see that it is documented in lat
On Sun, Oct 08, 2006 at 02:48:03PM -0500, Brian Smith wrote:
> Finally, something was mentioned about the Cabal version number only being
> accurate for when somebody uses Cabal sdist --snapshot mechanism. However,
> this isn't documented, and the documentation for "sdist" claims that it
> doesn't
On Thu, Oct 05, 2006 at 01:16:12PM +0300, Esa Ilari Vuokko wrote:
> I think that version number in repo should always be bigger than
> released version, so that snapshot names reflect versioning better.
You need to use something like setup sdist --snapshot to get an
accurate version for a snapshot
On Tue, Oct 03, 2006 at 06:06:02PM +0400, Bulat Ziganshin wrote:
> (i'm moving thread to the ghc-users where this discussion continues in
> ghc-related aspects)
I don't see how compiler-independence is a GHC-specific topic.
___
Glasgow-haskell-users mai
On Thu, Sep 21, 2006 at 10:15:45AM +0200, Christian Maeder wrote:
> How does haddock handle characters in comments?
Section 3.8.3 of the Haddock manual:
3.8.3. Character references
Although Haskell source files may contain any character from the
Unicode character set, the
With reference to the documentation that just appeared in darcs:
Result type signatures are now equivalent to attaching the signature
to the rhs, i.e. redundant.
How about finishing the decoupling of type variable binding from pattern
type signatures by introducing an (optional) pattern form
On Tue, Sep 05, 2006 at 02:13:33PM +0100, Malcolm Wallace wrote:
> > > So does anyone have any objections if I go ahead and commit the
> > > replacement (compatibility) implementation of Data.FiniteMap to the
> > > main repository for packages/base?
> >
> > I'd rather see HaXml updated to use Data
On Tue, Sep 05, 2006 at 02:21:31PM +0200, Duncan Coutts wrote:
> On Tue, 2006-09-05 at 12:19 +0100, Ross Paterson wrote:
> > On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote:
> > > So does anyone have any objections if I go ahead and commit the
> > >
On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote:
> > > > HaXml (no longer builds)
> > >
> > > In what way does HaXml fail to build for Hugs? Is it easily
> > > fixable?
> >
> > ... and there's the famous Data.FiniteMap.
>
> So does anyone have any objections if I go ahead and
On Tue, Sep 05, 2006 at 12:50:39PM +0400, Serge D. Mechveliani wrote:
> More about instance overlaps with the GHC library:
>
> I need to print in a special way the data of
> [Equation], (Term, Term), [(Term, Term)], (Equation, Equation).
>
> The first can be by defining showList in instance Sh
On Thu, Aug 24, 2006 at 12:22:05PM +0100, Simon Marlow wrote:
> Bulat Ziganshin wrote:
> >at least we can start by removing from ghc distribution large
> >graphics/sound libraries that was already cabalized. are there such
> >beasts?
>
> All those packages are already Cabalized. Hugs uses Cabal t
On Wed, May 31, 2006 at 12:20:02PM +0200, Michael Marte wrote:
> when importing Data.Queue in 6.4.2, I am told that it is deprecated and
> that I should use Data.Sequence instead. However, Data.Sequence is not
> part of the base package - it is there but it is missing from the
> package.conf fil
On Thu, May 11, 2006 at 01:46:43PM +0100, Ben Rudiak-Gould wrote:
> Otakar Smrz wrote:
> > data ... = ... | forall b . FMap (b -> a) (Mapper s b)
> >
> > ... where FMap qf qc = stripFMap f q
> >
> >the GHC compiler as well as GHCi (6.4.2 and earlier) issue an error
> >
> >My brain just expl
On Mon, Feb 06, 2006 at 05:49:42PM +0300, Bulat Ziganshin wrote:
> one question - will be the same rules incorporated in Hugs? as you
> know, i'm trying to made Hugs+GHC compatible library, so this matters
Hugs does not attempt to restrict instances to enforce termination --
it just makes context
On Mon, Feb 06, 2006 at 01:53:17PM +0100, Doaitse Swierstra wrote:
> I have not followed this completely, but do these new rules now allow:
>
> class F a b c where
> f: a -> b -> c
>
> and then
>
> instance F a a a where
Yes. Indeed they allow any unconstrained instance. They would
also all
On Mon, Feb 06, 2006 at 12:07:54PM +, Ross Paterson wrote:
> On Mon, Feb 06, 2006 at 11:53:17AM -, Simon Peyton-Jones wrote:
> > Your (1-Ross) ensures that every variable in the assertion does occur in
> > the head. But I'm not sure that the size-reduction argument
ted). But they must all appear in the HEAD.
Ah, but you added the no-repetition requirement a few weeks ago in
response to the example
class C a b
instance C b b => C (Maybe a) b
> Your (1-Ross) ensures that every variable in the assertion does occur in
> the head. But I&
A patch implementing a relaxed termination constraint is at
http://www.soi.city.ac.uk/~ross/instance-termination.patch
Here is the description:
With -fglasgow-exts but not -fallow-undecidable-instances, GHC 6.4
requires that instances be of the following form:
(1) each assertion
On Tue, Jan 17, 2006 at 11:44:00AM +0200, Krasimir Angelov wrote:
> Oh, Sorry! I didn't see it at first sight and I immediately went to
> GHC.Unicode. In this case is the GHC.Unicode module still in use?
It's an internal module, like most GHC.* modules (except GHC.Exts).
_
On Tue, Jan 17, 2006 at 11:29:42AM +0200, Krasimir Angelov wrote:
> The problem is that I have to use 'generalCategory' function which
> isn't exported. It returns the general category which tells me a lot
> more about the character.
But Data.Char does export generalCategory.
On Tue, Jan 17, 2006 at 10:33:51AM +0200, Krasimir Angelov wrote:
> I saw that GHC already has complete support for Unicode character
> classification. I tend to use it but I saw that currently GHC.Unicode
> exports only few of all classification routines. Is it intentional?
It exports some functi
On Fri, Jan 13, 2006 at 04:43:47PM +, Simon Marlow wrote:
> All of the packages are sync'd from CVS except for Cabal - it seemed
> more sensible to use the existing Cabal repo directly. However I've
> taken a branch of that Cabal repo to add the fptools Makefiles for now;
> the branch is in
On Tue, Dec 20, 2005 at 03:50:02PM +, John Goerzen wrote:
> On 2005-12-19, Malcolm Wallace <[EMAIL PROTECTED]> wrote:
> > Ross Paterson <[EMAIL PROTECTED]> writes:
> >> But how about having a separate repository for each library package?
> >
> > Sec
As a termination test, how about no restrictions on context and head
except:
Each assertion in the context must satisfy
* the variables of the assertion are a sub-multiset of those of the
head (though they may be the same), and
* the assertion has fewer type constructors and varia
cs, so darcs will be the only way to get an up-to-date GHC
> source tree.
>
> [...]
>
> Malcolm, Ross - since you both also use the CVS libraries tree, is it
> going to be possible for you to switch to using darcs to get the
> libraries? Any idea how long you'll need?
On Mon, Dec 12, 2005 at 03:38:18PM -, Simon Peyton-Jones wrote:
> Interesting example. Yes, GHC builds recursive dictionaries these days.
> There's a bit of discussion in our SYB paper in ICFP'05.
> http://research.microsoft.com/%7Esimonpj/papers/hmap/ And Martin
> Sulzmann has a whole
I'm puzzled that the following is accepted. Is some sort of greatest
fixed point computation used for instances?
{-# OPTIONS_GHC -fglasgow-exts #-}
module M where
class C a b where c :: a -> b -> Bool
instance C b b => C (Maybe a) b where c x y = c y y
f :: Maybe a -> Bool
f x = c x x
___
On Thu, Nov 17, 2005 at 05:43:28PM -0800, John Meacham wrote:
> On Thu, Nov 17, 2005 at 01:17:02PM +0000, Ross Paterson wrote:
> > On Thu, Nov 17, 2005 at 12:46:31PM -, Simon Peyton-Jones wrote:
> > > On 17 November 2005 12:45, Ross Paterson wrote:
> > > | I think
On Thu, Nov 17, 2005 at 12:46:31PM -, Simon Peyton-Jones wrote:
> On 17 November 2005 12:45, Ross Paterson wrote:
> | I think the H98 rule is arbitrarily restrictive. But what about
> | going further and considering the occurrences of type constructors
> | in instance declar
On Thu, Nov 17, 2005 at 12:32:37PM -, Simon Peyton-Jones wrote:
> Yes it's deliberate. (Turned out to be easy and convenient.) Yes it
> goes beyond H98, so GHC types a few too many programs even in H98 mode.
> I guess I should document it.
I think the H98 rule is arbitrarily restrictive. B
The Haskell 98 Report says kind inference is to be done over dependency
groups with polymorphic kinds defaulted to *, and hence the following
example (from 4.6) is illegal:
data Tree a = Leaf | Fork (Tree a) (Tree a)
type TreeList = Tree []
GHC 6.4 seems to perform kind inferenc
bundled with a copy of the library. I've placed one at
http://www.soi.city.ac.uk/~ross/cabal-setup-1.0.tar.gz
That builds a program that can be used as a Cabal setup script for most
packages, including Cabal itself.
___
Glasgow-haskell-
On Sun, Apr 10, 2005 at 10:39:08PM +0100, Simon Marlow wrote:
> On 10 April 2005 14:20, Thomas Schwinge wrote:
> > [ Grrr. Why do I have to subscribe just to post this message? ]
>
> Sorry for the inconvenience, it's because I don't have time to wade
> through all the spam.
Is it possible to all
There's currently no way to give a permanent URL for the best available
version of the 6.4 documentation, i.e. the latest minor release.
How about either a symlink 6.4-latest, or renaming the directory 6.4
as 6.4.0 and making 6.4 a symlink to the latest? Same goes for dist,
I suppose.
On Wed, Mar 09, 2005 at 11:59:40PM +0100, Remi Turk wrote:
> - It's one thing more to learn. The difference between types and
> typevariables (upper/lowercase) is better visible than the
> difference between operator(variables) and infix-types ("Does
> it start with a colon?") Which, I have t
The User's Guide says:
The only thing that differs between operators in types and
operators in expressions is that ordinary non-constructor
operators, such as + and * are not allowed in types. Reason:
the uniform thing to do would be to make them type variables,
On Tue, Mar 01, 2005 at 09:42:17AM -, Simon Marlow wrote:
> One thing I'm going to do for the 6.4 docs is include a link to the
> source code file (pointing to cvs.haskell.org) for each module.
Of course this won't work when the exported names are defined elsewhere.
But I also think it would b
On Tue, Feb 22, 2005 at 05:45:39PM +, Duncan Coutts wrote:
> In gtk2hs we have one huge module which defines all the types (this is
> produced by a code generator from a text file which describes the Gtk+
> class hierarchy). However we don't ever want this module to be exposed
> to users. We re
If a program calls exitWith, runghc produces an extra line of output:
*** Exception: exit: ExitSuccess
or
*** Exception: exit: ExitFailure 3
and then exits with status 0. It should do what a ghc-compiled
program does: silently exit with the appropriate status.
_
For commands other than register, ghc-pkg --user operates on both the
user and global package databases, whereas the the docs and online
help says it operates on the user database only.
Also, ghc-pkg list queries only the system database (unless --user
is given), but the the docs say it queries bo
On Tue, Feb 01, 2005 at 11:02:45AM -, Simon Marlow wrote:
> So the new approach is to try to build up a global table of the "best"
> destinations to link to for each entity.
Having a canonical home location for each entity might also help with
another bugbear with Haddock: determining whether
On Tue, Feb 01, 2005 at 03:19:11PM -, Simon Marlow wrote:
> On 01 February 2005 11:31, [EMAIL PROTECTED] wrote:
> > On Tue, Feb 01, 2005 at 11:02:45AM -, Simon Marlow wrote:
> >> So the new approach is to try to build up a global table of the
> >> "best" destinations to link to for each ent
On Tue, Feb 01, 2005 at 11:02:45AM -, Simon Marlow wrote:
> I'm making some changes to the way Haddock creates links, and I'd like
> to solicit comments on possible alternatives.
>
> The existing approach is for each non-locally-defined identifier in the
> current module, we hyperlink to a mod
On Tue, Jan 11, 2005 at 01:07:38AM +0100, Peter Simons wrote:
> Lemmih writes:
>
> > But no worries; HaXml is cabalized and should be
> > available in your CVS source tree.
>
> I see, thanks for the info! Any advice on how to
> build/install it with Cabal? I've tried it, but when Cabal
> tries
ibraries/Makefile should be easy (see
> the SUBDIRS handling there). I'm not sure about the current status of
> the arrows package. Ross?
You'd want to change TOP in libraries/arrows/Makefile to .. as well,
but that should be it. There's no plan to incl
On Wed, Sep 15, 2004 at 03:38:43PM +0200, Sebastian Boldt wrote:
> I am a bit confused about command stacks. I tried to run the following
> code in ghc:
>
> mshowA :: (Arrow a, Show b) => a (b, String) String
> mshowA = proc (x,s) -> returnA -< s ++ show x ++ s
>
> f :: Arrow a => a Int String
>
On Wed, Sep 01, 2004 at 04:39:30PM -0700, John Meacham wrote:
> I should mention I have a new version of the CWString library in
> development that conforms to the new FFI spec and works on all posixy
> systems, not just those that have unicode wchar_t's like my first
> posting.
>
> It is not qu
On Wed, Sep 01, 2004 at 10:16:23AM +0100, Bayley, Alistair wrote:
> I want to call a foreign C function that takes a UTF-8 encoded string as one
> of its arguments (and there's also a version of the function that receives
> UTF-16). Can someone point me to documentation or examples of how this woul
On Thu, Jun 17, 2004 at 10:53:28AM +0100, I wrote:
> Digging around in the source code comments, I found a restriction that
> is biting me:
>
> > We *insist* that all overloaded type variables are specialised to ground
> > types, (and hence there can be no context inside a SPECIALIZE pragma).
>
>
Digging around in the source code comments, I found a restriction that
is biting me:
> We *insist* that all overloaded type variables are specialised to ground
> types, (and hence there can be no context inside a SPECIALIZE pragma).
The latter is fine, but the former seems too restrictive. For e
On Tue, Jun 08, 2004 at 03:02:37PM -0700, John Meacham wrote:
> On Tue, Jun 08, 2004 at 03:47:04AM +0300, Lauri Alanko wrote:
> > When I use arrows, I find that many of my primitives are of type (a () b)
> > (for some arrow type a): they produce a value but don't take any input.
> > E.g. determinis
Would someone who's building from CVS under Windows like to try make
in libraries/Win32, libraries/HGL and libraries/HGL/examples, and
even run the programs in the latter directory (should they happen
to compile)?
___
Glasgow-haskell-users mailing list
[E
On Fri, Dec 19, 2003 at 12:17:42PM -0800, John Meacham wrote:
> 1. written the CWString library (now a part of the FFI) which lets you
> call arbitrary C functions doing all the proper character set conversion
> stuff.
Do you plan to update this and merge it with the hierarchical libraries
to comp
On Fri, Sep 26, 2003 at 01:16:50PM +0100, MR K P SCHUPKE wrote:
> Will the arrow's notation be in 6.2?
Yes
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Fri, Aug 22, 2003 at 08:34:55AM +0100, Simon Peyton-Jones wrote:
> No, it's only in the HEAD, which you may be able to pick up from a
> development snapshot, or you can build from source. It'll be in 6.2
>
> I'm not certain if the syntax is identical; Ross will
On Mon, Aug 11, 2003 at 07:16:08PM +0200, Tomasz Zielonka wrote:
> I think it would be better to derive Show instance for Tree instead of
> providing a pretty printing one. Then it would be possible to have a
> complementing Read instance. The pretty printing function could be
> provided under a di
On Sun, Jul 06, 2003 at 05:31:59PM +0100, MR K P SCHUPKE wrote:
> I am trying to define the left operator for a CPS arrow of type:
>
> newtype CPSFunctor ans a b c = CPS ((a c ans) -> (a b ans))
>
> [...]
> So I try and apply this to left and get:
>
> left (CPS f) = CPS $ \k -> arr (\z -> case z
On Tue, Jun 24, 2003 at 07:18:33PM +0200, Peter Simons wrote:
> Simon Peyton-Jones writes:
>
> >-farrows
>
> Is this switch documented somewhere? I looked through the docs in the
> latest CVS version of GHC and couldn't find anything about it ...
It has just appeared, and is still very brit
The hsc2hs way of handling header files does not fit well with what is
described by the FFI spec, making it difficult for non-GHC implementations
to use .hsc files. Typical .hsc files may contain several #include
lines, which turn into OPTIONS -#include pragmas. The portable way is to
specify the
On Tue, Nov 12, 2002 at 05:56:13PM -, Simon Marlow wrote:
> Absolutely. I didn't mean to sound so GHC-centric. It would be great
> if the same infrastructure supports multiple compilers/interpreters.
On the other hand, my impression is that if someone did something that
worked with GHC it wo
On Fri, Nov 01, 2002 at 10:38:14AM -, Simon Marlow wrote:
> It didn't always used to be this way: before GHC 5.00, IOError was what
> is now called IOException. We changed it so that IOError == Exception
> because it seems simpler this way: IO.ioError can be used to throw
> exceptions, and Ex
Shouldn't IOError be identified with IOException rather than Exception?
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Wed, Jul 24, 2002 at 02:35:37PM -0400, Ken T Takusagawa wrote:
> I'm having difficulty compiling under 5.04 using both Arrays
> and UArrays:
>
> module Main where{
> import Array;
> import Data.Array.Unboxed;
>
> [...]
>
> This gets me the errors
> Ambiguous occurrence `array'
> It
99 matches
Mail list logo
