Re: Proposals for changes to searching behaviour
Simon Marlow wrote: - We could provide the ability to specify a module prefix to associate with a directory in the search path. For example, you could say that the directory '.' is associated with the module prefix Graphics.Rendering.OpenGL and avoid having to place your sources in the directory Graphics/Rendering/OpenGL. I'm not sure what syntax we'd use for this. Henrik suggested placing the module prefix in square brackets before the directory, eg. ghc -i '-i[Graphics.Rendering.OpenGL].' Does that mean I can refer to X.hs as [Graphics.Rendering.OpenGL(.Graphics.Rendering.OpenGL)*/]X.hs ?-) Probably no problem with Haskell's explicit imports. Good point, which should be cleared up. We don't intend GHC to have any knowledge of relative pathnames and the meaning of '.' or '..'. So the meaning of an import path [Graphics.Rendering.OpenGL]D would be simply this: when looking for a module's source/interface, if the module name is of the form Graphics.Rendering.OpenGL.M, then we look for D/M.hs. If it doesn't exist, we move on to the next entry in the search path. One comment relating to this potential new syntax: this is the exact syntax used for filesystem paths in [Open]VMS. I believe VMS paths look like this: DISK:[dir.subdir.subdir]filename.ext, and I think the DISK: part is optional. So, if you should ever want to port GHC to OpenVMS (I believe it is a POSIX compliant system), you might regret this particular choice of syntax. Also, programmers familiar with VMS might be confused by the syntax. My 2ยข: I would personally prefer not to change the import path syntax and go with the other suggestion: allow directories named X.Y.Z. It would be easy just to say -i D and make a directory D/Graphics.Rendering.OpenGL/ with the modules inside it. Also it keeps module hierarchy apparent in the directory structure, rather than being buried in a Makefile somewhere. Regards, Matt Harden ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
An attempt at foldr/build fusion for zip
Hi,
I think I may have found a way to get zip friends to fuse with *both*
of their input lists. I am not a heavy ghc hacker, though, so I may be
missing something important that makes this unworkable. I have no idea
what kind of code this would actually end up creating.
Anyway, here's my attempt; it ties in with the current foldr2 scheme. I
eagerly any await comments or questions, especially from the foldr/build
gurus.
-- foldr2_both.lhs:
Attempting to fuse zip with both input lists.
We seem to be forced to use a recursive datatype to accomplish this.
We're using newtype, so there should be no overhead from
construction/deconstruction of this type, right?
\begin{code}
newtype BuildZip a b = BZ ((a - (BuildZip a b) - b) - b)
bz :: (forall b. (a-b-b)-b-b) - b - BuildZip a b
bz f n = f (\x xs - BZ (\c - c x xs)) (BZ (\_ - n))
{-# INLINE bz #-}
foldr2_both :: (a-b-c-c) - BuildZip a c - BuildZip b c - c
foldr2_both k (BZ xs) (BZ ys) =
xs (\x xs' -
ys (\y ys' -
k x y (foldr2_both k xs' ys')
) )
{-# RULES
"foldr2/both" forall k n (f::forall z.(a-z-z)-z-z)
(g::forall z.(b-z-z)-z-z) .
foldr2 k n (build f) (build g) =
foldr2_both k (bz f n) (bz g n)
#-}
\end{code}
-- END foldr2_both.lhs
Best regards,
Matt Harden
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Instance of Functor for functions of = 2 arguments
For strange reasons I won't get into here, I would like to implement an instance of the Functor class for various function types with 1 or more arguments. I want fmap to transform the result of the function, as opposed to transforming the first argument. Once I figured out the syntax, the instance for (a-b) was easy: instance Functor ((-) a) where fmap g f x = g (f x) -- or, to be cute, fmap = (.) Bear in mind that the "kind" of the Functor class is *-*, so instances of that class need to have the same kind. For functions with 2 or more arguments, I'm stuck. I'd like to do this: instance Functor (a-b-) where fmap g f x y = g (f x y) ...but of course it has invalid syntax. I can't think of a way to write (a-b-) in the ((-) a) form. (a-b-c) would be ((-) a ((-) b c)). I tried a type synonym: type Func2 a b c = (a-b-c) instance Functor (Func2 a b) where fmap g f x y = g (f x y) That doesn't work either: Haskell98 doesn't allow type synonyms to be used to define instances. GHC supposedly lifts this restriction, but it complains: (I'm using version 4.02) type synonym `Func2' should have 3 arguments, but has been given 2 When checking kinds in `Func2 a b' When checking kinds in `Functor (Func2 a b)' So I guess GHC only accepts type synonyms as instances when the kind of the class is *. I could use a datatype renaming (newtype) to accomplish this: newtype Func2 a b c = Func2 (a-b-c) instance Functor (Func2 a b) where fmap g (Func2 f) = Func2 (\x y - g (f x y)) ...but I think this is ugly and it really doesn't accomplish what I want. Any ideas? Thanks, Matt Harden
Re: GHC Version numbers (was: RE: 4.07 release candidate snapshot ava ilable)
Michael Weber wrote: Is there a reason, why omitting z if zero? Making the version number *always* a triple "x.yy.z" is a) more consistent, b) easier to parse (you can rely on having three dot-separated fields and c) additionally a good break, since version numbers up to now are only pairs like "x.yy", so you can just say "Oh, version is not a triple, so it must be a GHC from The Dark Ages(tm)" and continue accordingly. These make the version numbers better for automated processing, but the numbers serve a dual purpose: they should be easy for people _and_ machines, but people come first. Numbers ending in ".0" are counterintuitive to me. well, I've no _really_ strong arguments against it, but is there any good reason I've missed for having anything but numbers (and the dot for separation) in a version? It's perfectly sufficient, and I've always wondered, why people did sth. like the above... (Remember, now an even middle number is indicator for a stable version, so _that_ particular argument is void now). I think the reason is, again, human. It's more obvious that it's an unstable release if there's a keyword like "pre" or "beta" in the version string. The odd middle number is not that obvious, even when you know the rule. Oh, and might I bring the switch `--numeric-version' (for example, emits just "4.09.2609" on a single line) into scope... That actually sounds like a good idea to me, as long as the rules to convert version strings to/from numbers are very solid, and the relationship is 1:1. I support Simon Marlow's proposal as it stands, with the possible addition of the --numeric-version option. Thanks, Matt Harden
