Re: User-Defined Operators, Re: Function composition and currying

2003-07-18 Thread Dylan Thurston
On Sat, Jul 19, 2003 at 02:06:44PM +1000, Andrew J Bromage wrote: > G'day all. > > On Fri, Jul 18, 2003 at 04:08:25AM -0400, Dylan Thurston wrote: > > > What's wrong with that solution? > > Working with these operators, I would spend a significant amount of > time getting the '<' and '>' notatio

Re: User-Defined Operators (ad-hoc overloading)

2003-07-18 Thread Andrew J Bromage
G'day all. On Fri, Jul 18, 2003 at 11:08:16AM +0200, Christian Maeder wrote: > Mere overload resolution (over monomorphic types) is not NP-hard. (This > is only a common misconception.) No, but as you note below, the "interesting" cases are. Most of the more interesting number-like types are p

Re: User-Defined Operators, Re: Function composition and currying

2003-07-18 Thread Andrew J Bromage
G'day all. On Fri, Jul 18, 2003 at 04:08:25AM -0400, Dylan Thurston wrote: > What's wrong with that solution? Working with these operators, I would spend a significant amount of time getting the '<' and '>' notations right rather than writing code. I don't like that. For example, using the sug

RE: referring to deeply embedded definitions

2003-07-18 Thread Hal Daume
Please ignore my stupid question :) -- Hal Daume III | [EMAIL PROTECTED] "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -Original Message- > From: Hal Daume > Sent: Friday, July 18, 2003 10:23 AM > To: [EMAIL PROTECTED] > Sub

Re: Function composition and currying

2003-07-18 Thread Stefan Karrmann
K. Fritz Ruehr (Wed, Jul 16, 2003 at 11:19:55PM -0700): c0 = ($) -- application > c1 = (.) -- good old composition > > c2 = (.) . (.)-- my (.<) from above > > c3 = (.) . (.) . (.) > > c4 = (.) . (.) . (.) . (.) > >

Re: referring to deeply embedded definitions

2003-07-18 Thread Christian Maeder
Hal Daume wrote: Suppose I have: module M1 where import M2 foo = 'a' and module M2 where import M3 and module M3 where foo = True Now, inside M1, I want to write something like: bar = if M2.foo then M1.foo else 'b' M2 must reexport "foo": module M2 (foo) where import M3 __

Re: How to use functions in dll file in Haskell program?

2003-07-18 Thread Derek Elkins
On Fri, 18 Jul 2003 18:29:35 +0800 "Liu Junfeng" <[EMAIL PROTECTED]> wrote: > Hi__ > If there is a function named "func" with type a->b in a win32 dll > file. In Hugs use the primitive declaration: > --- > primitive prim_func :: a -> b > func = prim_func > ---

referring to deeply embedded definitions

2003-07-18 Thread Hal Daume
Suppose I have: > module M1 where > import M2 > foo = 'a' and > module M2 where > import M3 and > module M3 where > foo = True Now, inside M1, I want to write something like: > bar = if M2.foo then M1.foo else 'b' or > bar = if M3.foo then M1.foo else 'b' but neither of these is valid. Is

Re: User-Defined Operators, Re: Function composition and currying

2003-07-18 Thread Dylan Thurston
On Fri, Jul 18, 2003 at 11:39:48AM +1000, Andrew J Bromage wrote: > > Someone mentioned multiplying by a scalar. I think this is a > > good application, but what we need is to agree (somehow) on > > the symbol used. I've used (*.) and (.*), with the dot being > > on the side the scalar is on (on th

Announce: buddha 0.9 released

2003-07-18 Thread Bernard James POPE
Announcing the release of buddha version 0.9 www.cs.mu.oz.au/~bjpop/buddha Buddha is a declarative debugger for Haskell 98. It is based on program transformation and relies on GHC version 5.04 or greater (but not version 6 yet). It also needs GHC's

How to use functions in dll file in Haskell program?

2003-07-18 Thread Liu Junfeng
Hi, If there is a function named "func" with type a->b in a win32 dll file. In Hugs use the primitive declaration: --- primitive prim_func :: a -> b func = prim_func --- Then the func can be exported to be used in other modules. The question

Re: User-Defined Operators (ad-hoc overloading)

2003-07-18 Thread Christian Maeder
Andrew J Bromage wrote: Of course you could always allow overloading _without_ requiring module qualification (unless the overloading can't be resolved using type information). It'd make type checking NP-hard, but I seem to recall that it's already more complex than that. Mere overload resolution