Re: type equality symbol

Wolfgang Jeltsch: Am Mittwoch, 5. Dezember 2007 17:05 schrieb Simon Peyton-Jones: […] Anyway, while on this subject, I am considering making the following change: make all operator symbols into type constructors (currently they are type variables) This would be highly problem

Re: type equality symbol

I don't think it's highly problematic. I agree that it would be nice to have the type and value levels have a similar structure, but if there are compelling reasons to do otherwise that fine too. You could still allow symbol type variables if they have an explicit binding occurence, which you can

Re: Which ghc versions can build ghc-6.8.1?

Gregory Wright wrote: > > Hi, > > I'm the process of updating MacPort's ghc to 6.8.1 and adding support for > Leopard (OS X 10.5) and have been having] some trouble. Great. I am using 10.5 on a PPC You ought to read the ongoing saga at http://hackage.haskell.org/trac/ghc/ticket/1843 In general

Re: Problems building and using ghc-6.9

Daniel Fischer wrote: Then I tried to build zlib-0.4.0.1: $ runghc ./Setup.hs configure --user --prefix=$HOME Configuring zlib-0.4.0.1... Setup.hs: At least the following dependencies are missing: base >=2.0&&<2.2 ??? okay, there was something with flag bytestring-in-base, removed that, so

Re: About -Wall option

I think that put signatures is a good practice. I will switch to that. Maybe I preferred to not put signatures because is cooler than other languages type systems :-D Wolfgang Jeltsch wrote: > Inserting all type signatures is definitely best practice. Yitzchak Gale wrote: >My personal style is:

Which ghc versions can build ghc-6.8.1?

Hi, I'm the process of updating MacPort's ghc to 6.8.1 and adding support for Leopard (OS X 10.5) and have been having] some trouble. The first task is just to get 6.8.1 running on Tiger (10.4). On PPC, I use ghc 6.4 as a bootstrap compiler and on Intel ghc 6.6. I am traveling with on

Re: C Preprocessor

Simon Marlow wrote: Neil Mitchell wrote: Yes, or just don't use string gaps. ++ works just as well, and GHC will optimise it away when applied to constant strings. There are also other issues, such as ' in variable names (can cause bits to be skipped in that line), /* as an operator, unboxed

Re: C Preprocessor

On Thu, Dec 06, 2007 at 10:43:30AM +0100, Bernd Brassel wrote: > Is it already a known problem that the preprocessor cannot cope with the > whole set of possible string declarations? The cpp is a *C* preprocessor, and if it has been written to adhere to the C standard, it is required to diagnose t

RE: C Preprocessor

> > Yes, sure. (although the ' thing doesn't bite us - perhaps it doesn't > > apply with -traditional?) > I think it bit me last week. I had something like: It bites me too - something like this goes wrong with ghc -cpp: #define C(x) x foo' :: foo C(x) Ganesh ===

Re: C Preprocessor

Hi Simon, > Yes, sure. (although the ' thing doesn't bite us - perhaps it doesn't > apply with -traditional?) I think it bit me last week. I had something like: #define a b foo'bar a In this case it did because "a" wasn't changed to "b". It may have been other complex things going on as well,

Re: C Preprocessor

Neil Mitchell wrote: Yes, or just don't use string gaps. ++ works just as well, and GHC will optimise it away when applied to constant strings. There are also other issues, such as ' in variable names (can cause bits to be skipped in that line), /* as an operator, unboxed varids in #define's

Re: C Preprocessor

Hi > Yes, or just don't use string gaps. ++ works just as well, and GHC will > optimise it away when applied to constant strings. There are also other issues, such as ' in variable names (can cause bits to be skipped in that line), /* as an operator, unboxed varids in #define's Thanks Neil ___

Re: C Preprocessor

Wolfgang Jeltsch wrote: Am Donnerstag, 6. Dezember 2007 10:43 schrieb Bernd Brassel: Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations? Yes, it is. There is cpphs () as an alternative. Yes,

Re: C Preprocessor

Am Donnerstag, 6. Dezember 2007 10:43 schrieb Bernd Brassel: > Is it already a known problem that the preprocessor cannot cope with the > whole set of possible string declarations? Yes, it is. There is cpphs () as an alternative. > […] Best wishes, Wolfgang

C Preprocessor

Is it already a known problem that the preprocessor cannot cope with the whole set of possible string declarations? $ cat long1.hs {-# OPTIONS -cpp #-} s = "abc\ \defg" main = putStrLn s $ ghc long1.hs long1.hs:3:14: lexical error in string/character literal at character 'e' $ cat lo