haskell operator precedence
Hi,
Is the following legal Haskell?
infixr 0 `foo`
infixr 0 `bar`
x `foo` y = "foo(" ++ x ++ "," ++ y ++ ")"
x `bar` y = "bar(" ++ x ++ "," ++ y ++ ")"
dubious a b c = a `foo` b `bar` c
According to the grammar in the Haskell report, I don't think it is.
However, ghc-0.24 (ancient, I know) and Hugs 1.3 both accept it without
complaint.
--
Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit
WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
Re: Existential types, save me now?
On 22-Nov-1999, Alex Ferguson [EMAIL PROTECTED] wrote: Here's some of the threatened examples: data OrdFuncExist = OE (Ord a = Char - a) That's not the syntax for a existential type, that's the syntax for a universally quantified type with rank-2 polymorphism. With that syntax, the argument of `OE' must be a polymorphic function with type `forall a . Ord a = Char - a'. I think the syntax for what you want is data OrdFuncExist = Ord a = OE (Char - a) data OrdListExist = OLE (Ord a = [a]) Is this supposed to be a heterogenous list, or a homogeneous list? That is, must the elements all have the same type `a', or is the choice of `a' supposed to be allowed to vary for each element? If you want a homogeneous existentially quantified list, then use data OrdListExist = Ord a = OLE [a] But I suspect you want a heterogenous existentially quantified list. In that case, you should use something like this: data AnyOrd = Ord a = MkAnyOrd a data OrdListExist = [AnyOrd] emap :: OrdFuncExist - [Char] - OrdListExist emap (OE f) l = OLE (map f l) You'll probably need something along the lines of emap (OE f) l = OLE (map (MkAnyOrd . f) l) The other problem: emax :: OrdListExist - OrdListExist emax (OLE l) = OLE [maximum l] Now, I think I see why this doesn't work: but any ideas on how to fix? Hmm, I'm not sure exactly what you're trying to achieve here... but perhaps you just need to add instance Ord AnyOrd where compare (MkAnyOrd x) (MkAnyOrd y) = compare x y to make it work. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Existential types, save me now?
On 22-Nov-1999, Alex Ferguson [EMAIL PROTECTED] wrote: Is this supposed to be a heterogenous list, or a homogeneous list? Sorry, I should have been a tad less terse: it's intended to be a homogeneous list, else the maximum wouldn't be well-typed. Oh, of course -- you're quite correct. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit" PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.
Re: Overloaded function and implicit parameter passing
On 23-Oct-2000, José Romildo Malaquias [EMAIL PROTECTED] wrote: - cut here module Main where class C a where f :: (?env :: Integer) = a - Integer instance C Integer where f x = ?env + x main = putStrLn (show (f (45::Integer) with ?env = 100)) - cut here ... $ ghc -fglasgow-exts Test1.hs -o test1 Test1.hs:7: Unbound implicit parameter `env_rJX :: Integer' arising from use of `env_rJX' at Test1.hs:7 ... Would anybody comment on what is going on with GHC? That sure looks to me like a bug in GHC's support for implicit parameter passing. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit | of excellence is a lethal habit" WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC HQ are looking for a Linux-IA64 box
On 12-Mar-2001, Julian Seward (Intl Vendor) [EMAIL PROTECTED] wrote: Does any kind person have an IA64 box, running Linux, on which we could have an account? You might want to check out SourceForge: http://ia-64.sourceforge.net/. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit | of excellence is a lethal habit" WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FWD: Re: GHC FFI Return Type Bug
Sigbjorn Finne [EMAIL PROTECTED] wrote:
Julian Seward (Intl Vendor) [EMAIL PROTECTED] writes:
| char fooble ( ... )
| {
| return 'z';
| }
|
| on an x86, 'z' will be returned at the lowest 8 bits in %eax. What I
| don't know is, is the C compiler obliged to clear the upper 24 bits of
| %eax, or does that onus fall on the callee?
The upper 24 bits of eax must be cleared in the callee.
The caller can assume that they are zero.
I don't know if this is documented anywhere, but that is the convention
which GNU C follows (on all architectures -- the C front-end internally
promotes the return type from char to int). I can point you to
the exact line of code in the GNU C front-end if you really want.
I think this is required by traditional KR C code, which does things
like calling such functions without declaring them.
--
Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit
WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FWD: Re: GHC FFI Return Type Bug
On 08-Aug-2001, Fergus Henderson [EMAIL PROTECTED] wrote:
Sigbjorn Finne [EMAIL PROTECTED] wrote:
Julian Seward (Intl Vendor) [EMAIL PROTECTED] writes:
| char fooble ( ... )
| {
| return 'z';
| }
|
| on an x86, 'z' will be returned at the lowest 8 bits in %eax. What I
| don't know is, is the C compiler obliged to clear the upper 24 bits of
| %eax, or does that onus fall on the callee?
The upper 24 bits of eax must be cleared in the callee.
The caller can assume that they are zero.
I don't know if this is documented anywhere, but that is the convention
which GNU C follows (on all architectures -- the C front-end internally
promotes the return type from char to int). I can point you to
the exact line of code in the GNU C front-end if you really want.
I think this is required by traditional KR C code, which does things
like calling such functions without declaring them.
On further investigation it appears that although what I wrote is true
for GNU C, it seems to *not* be true for GNU C++, which was being used in
the code in the original bug report.
I'm not sure why that is. The C++ front-end has some code similar to
the code in the GNU C front-end, to promote function return types,
but the code seems to not get used. I don't know whether that is
deliberate or not.
--
Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit
WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: incompatible signatur syntax within instance definition
On 08-Dec-2003, Christian Maeder [EMAIL PROTECTED] wrote: Fergus Henderson wrote: I think the issue here is that in ghc (with -fglasgow-exts), the a here refers to the same type variable a in the top of the instance declaration, which has already been constained, and cannot be constrained again. Is that a bug or a feature? A feature. It's called scoped type variables. See http://www.haskell.org/ghc/docs/6.2/html/users_guide/type-extensions.html#SCOPED-TYPE-VARIABLES: The type variables in the head of a class or instance declaration scope over the methods defined in the where part.. Or were you referring to the fact that variables which are already constrained can't be constrained again? IMHO that is a feature too. It doesn't make sense to constrain a variable at any point other than the point where that variable is introduced. -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
