May 2004 - Glasgow-haskell-users

RE: F#
by Simon Marlow 21 May '04

21 May '04

On 21 May 2004 01:07, John Sharley wrote: > I note this remark on the Microsoft Research site > (http://research.microsoft.com/projects/ilx/fsharp.aspx) > <quote> > Purely functional languages like Haskell are excellent within certain > niches, but unfortunately some simple programming exercises can > quickly turn into problems that require a PhD. to solve. > </quote> > > Are the Microsoft Research people working on GHC or anyone else on > this list also of this opinion? If so, why? > > What if anything does the quoted remark mean for the prospects of > seeing a production Haskell compiler from Microsoft? It's possible that the remark is referring to the use of monads to do IO in Haskell, but I wouldn't read too much into it. Cheers, Simon

1 0

RE: Statically linked binary?
by Simon Marlow 21 May '04

21 May '04

On 21 May 2004 14:17, Jochen L. Leidner wrote: > sorry for an urgent newbie question: how can I create a statically > compiled version of a Haskell program on Linux with GHC that does not > rely on external shared libs (also for any of its libraries it uses)? > > I would like to build a binary that works on a 3-processor machine > with an older Linux SMP kernel as well as RH9/FC2. The GHC flag '-optl-static' is your friend. Note that it is still possible to end up with a binary that is kernel-version-dependent. Cheers, Simon

1 0

Re: F#
by MR K P SCHUPKE 21 May '04

21 May '04

> but unfortunately some simple programming exercises can quickly turn > into problems that require a PhD. to solve. Of course you could say that the excersise is not actaully as simple as you believe, and other languages will let you get away with stuff you really shouldn't be doing. A good example of this is threads. There are apparently very few programmers that can do threads well, I heard of one survey that stated most programming shops only have one 'threads expert' and problems inevitably get referred to them. Haskell solves a lot of the problems you have in dealing nicely with threads in other languages (no side effects - built in channels and MVars so no visible mutexes). # One of the biggest problems in software is dealing with complexity, so anything that helps sort this out is a plus... Most large software projects are delivered late or not working due to complexity. I guess the person that wrote that article was thinking about 'scripting' rather than programming (as in visual basic style stuff) - Well thats my opinion at least... Keean.

1 0

RE: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 21 May '04

21 May '04

I have seen very compact Prolog implementations in Haskell, and I also know that constraints, modelled by CHRs can be evaluated directly in Prolog. Why not just bolt one of these compact Prologs onto the compiler, and just feed it the facts and rules... Keean.

1 0

ghc-devel for darwinports
by Gregory Wright 20 May '04

20 May '04

Hi, Due to overwhelming popular demand (well, Sven asked), darwinports now includes a port 'lang/ghc-devel', which builds from the head of the cvs. The default build includes support for openGL, so this is a way to get the latest OpenGL support for ghc, which now supports almost all of version 1.5. The ghc-devel port installs as ghc-6.3. (All of the executables have the "-6.3" suffix, so you can install ghc and ghc-devel without conflict. You invoke the new compiler as ghc-6.3 and the interactive environment as ghci-6.3.) ghc-devel depends on ghc, alex and happy, so if you have none of these installed and say sudo port install ghc-devel you'll get a full bootstrap build of the released version of ghc, along with builds of alex and happy (the lexer and parser generators, respectively), followed by a build of ghc from cvs. This may take some time (about 10 hours on an 800 MHz G4), but what would you rather have your CPU doing? Best Wishes, Greg Gregory Wright Antiope Associates LLC gwright(a)antiope.com

2 2

Re: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 20 May '04

20 May '04

I think you should read the GHC manual (assuming it is up to date and undecidable instances means what it says it does, the difference is... Without undecidable instances at least one type in the instance must not be a type variable. With undecidable instances you can have a default-instance (all type variables) or a class synonym (one instance - all type variables) Thats it... Neither GHC nor Hugs pay any attention to the dependancies when choosing which instance to use. The dependancies are only considered after the decision has been irrevocably made. If the dependancies don't hold, the only option the compiler has is to bail out with a compile time error. Keean.

2 1

Re: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 20 May '04

20 May '04

that is not the case with "-fallow-undecidable-instances" ... as far as I understand it , ghc never considers the dependancies when selecting an instance. If you don't think so you will need to show me an example where it clearly does... as I haven't seen one yet (but just because I haven't seen it doesn't mean its not possible),,, IMHO, things should either stay as they are (only instance heads supported) or it should switch to full Prolog style backtracking. Given who I mean, given two instances like: instance a b c instance d e f there is no way to tell between them... if you said choose a in preferenc 'a' would be chosen all the time. Keean.

2 1

Re: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 20 May '04

20 May '04

I don't think you get it... naming does not help, the problem is the compiler cannot distinguish between the instances. The alternative to the current situation is to take into account the dependancies of instances when selecting. The problem here is that the compiler may select an instance, evaluate its dependencies, only to discover somewhere further on that the dependencies cannot be met. At this point it has to backtrack (reverse its previous decisions) and try another instance. This effectively means implementing a Prolog style solver in the compiler - which leads to the further problems of the compiler possible not terminating (ie taking forever to not compile something)... Keean.

2 1

RE: Overlapping, undecidable, incoherent -- or worse?
by Simon Peyton-Jones 20 May '04

20 May '04

Actually, you're right, GHC will infer the type you suggest. GHC is lazy, and tries to postpone context reduction as long as possible, until forced by some user-supplied context. But I don't think that makes the subtleties go away. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Stefan Reich | Sent: 20 May 2004 13:48 | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: Overlapping, undecidable, incoherent -- or worse? | | Simon Peyton-Jones wrote: | > As a trivial example, try | > | > f a = a |= a | > | > What type shall we infer for f? | > f :: (Bounded a, Enum a, SemiRing a) => a -> a | > or | > f :: (CSemiRing a) => a -> a | | This has always confused me - GHC always seems to use the strongest | possible conditions when inferring types (CSemiRing is stronger than PO | because it implies it). Why isn't the type just | | f :: (PO a) => a -> a | | ? Isn't this the most straight-forward (and universal) typing, | especially in the presence of overlapping/undecidable instances? | | -Stefan | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Re: Overlapping, undecidable, incoherent -- or worse?
by MR K P SCHUPKE 20 May '04

20 May '04

>I wasn't talking about _any_ notion of ordering of instance heads; I >said that prioritising instance _declarations_ themselves, explicitly, >by 'name' would suffice. How does that help... if you name the instances differently are they not just ordinary functions, as they would no longer be overloaded? Keean.

2 1