Hello GHC,
Wednesday, September 27, 2006, 9:32:37 PM, you wrote:
> * Problem using `--make` when compiling the base package ([ticket:
> #909]).
it will be really great. now, afaiu, i can't work on this package
without building entire GHC
> * We'd lose the ability to do parallel module building within each
> library ([ticket: #910]).
it don't have anything common with this ticket, imho
> * Currently the implementations don't agree on what `Read` is, as the new
> `ReadP` requires rank-2 or rank-n polymorphism. I am told Haskell' will
> have one or the other, so this will come in time.
we are not developing H98 library. we have very practical goal - make
common lib for commonly used haskell compilers. at this moment, i
think, ghc/hugs/nhc/yhc/jhc should be targeted and all they have it
in common, i think that it will be better to require implementation of
R2P from any compiler that want to use base lib. and i'm sure that at
least R2P will be included in H' because it is used in runST and ReadP
> * For the deps from common packages to impl-specific packages we
> obviously need some sort of conditional support in Cabal.
it is by itself very important ability, we already discussed this. but
for compiler dependencies we can use just custom Setup.hs like this:
-- This custom Cabal build script adds "Win32" package to the list of
-- dependencies if we build on the Windows platform
main = do pkg_descr_file <- defaultPackageDesc
pkg_descr <- readPackageDescription pkg_descr_file
let isWindows = "mingw" `isPrefixOf` System.Info.os
config = if isWindows
then pkg_descr { buildDepends = Dependency "Win32"
AnyVersion
: buildDepends pkg_descr
}
else pkg_descr
defaultMainNoRead config
> * The code used by default class definitions needs to be pretty low down
> in the hierarchy, and in particular `fail s = error s` in the `Monad`
> class pulls in the huge exception type. This might be simplified with an
> extensible exception replacement?
> * Standalone deriving declarations (separate from the data declaration)
> make some things a lot easier. I think bringert has a working
> implementation for GHC, but it only truly helps if it's in all impls;
> something for Haskell'?
i think it's great feature and definitely should be proposed for H'
standard
> * It's unfortunate that we can't make imported and exported class
> instances explicit, so the compiler won't be checking that we are giving
> consistency across impls.
please mention that all this deals with type classes. and the
`base-types-classes` package too. i believe that we can write vase
package without type classes or at least without type classes exposed
to user. type class don't add new functionality, it just provides
simpler access to the existing one
throwing out type classes means that we should write `intMul` instead
of '*' but that is not much loss for such fundamental lib. i think
that core lib should export just functions and types but not operators
nor classes, which should be defined in application libs. this will
allow to make alternate implementations without going into
compiler-specific details. say, for Char it's enough to define
int2Char, char2Int, minCharBound, maxCharBound and then all the instances
for Enum, Ord and likewise classes can be defined in portable way
are you know any examples of compiler-dependent code (i.e. in GHC.*)
that can't be rewritten in class-less way?
> In what follows, I haven't given a huge amount of thought to names, but I
> don't think there's any need to do so yet.
> My conclusions were that ultimately something like this would be good
> (with <impl> replaced with ghc, hugs, ...):
> * `<impl>-prim` at the bottom; defines things like the `Int` type
> (basically all the types and functions needed by the next layer.
> * `base-types-classes` next, which just have class declarations but
> probably no instances.
> * `<impl>-base next`; This is where all GHC's instances with `I#`'s etc
> would go.
> * `base` on top of that, with anything that can't be forked off into
> another package.
this is a smart design, implying that we need type classes in base
package. pros for your design:
* base package already uses classes in compiler-dependent code so it
may be easier to implement
* class-using code is definitely simpler and more readable ('*' vs intMul)
pros for my design:
* it uses two layers instead of four
* it leaves room to make any definitions of base classes in
application libraries. suppose that i want to implement new Read
class. it will look strange with your design. although, on the other
side, compiler deriving mechanism can't work with alternative class
definitions too...
--
Best regards,
Bulat mailto:[EMAIL PROTECTED]
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
