Guys! Welcome to the Timber list. lots to do. One thing I'd like to visit is String = [Char]. Is this the right thing for Timber? We have data [a] = ... , how about data Vector a = ... where Vector is an 0 index'd array, and, String = Vector Char? Is this too much of a departure from Haskell? What parts of Haskell type classes might we want to keep? Can we simplify the hierarchy? Both of these questions relate to how much of Haskell we carry forward, and how much we change. AndyG
Guys!
Welcome to the Timber list. lots to do.
One thing I'd like to visit is String = [Char]. Is this the right thing for Timber?
We have data [a] = ... , how about data Vector a = ... where Vector is an 0 index'd array, and, String = Vector Char?
Is this too much of a departure from Haskell?
What parts of Haskell type classes might we want to keep? Can we simplify the hierarchy?
Both of these questions relate to how much of Haskell we carry forward, and how much we change.
I'm also in favor of shifting to some more "traditional", or at least more memory-efficient representation of strings. But the main question as I see it is what kind of programming pattern an array- based representation would support. We can't simply reuse list recursion, and we don' want to force all string computations up to the imperative level. Would it be possible to play with overloading here? Or to generalize the list comprehensions? I don't care too much whether we depart from Haskell or not, since Haskell's string handling probably isn't its strongest point. But I don't know of any better alternative that is both convenient and purely functional. Regarding type classes we should not feel any constraints at all. Simplification sounds like a good thing! -- Johan
I'm also in favor of shifting to some more "traditional", or at least more memory-efficient representation of strings. But the main question as I see it is what kind of programming pattern an array-based representation would support. We can't simply reuse list recursion, and we don' want to force all string computations up to the imperative level.
Would it be possible to play with overloading here? Or to generalize the list comprehensions?
I don't care too much whether we depart from Haskell or not, since Haskell's string handling probably isn't its strongest point. But I don't know of any better alternative that is both convenient and purely functional.
Regarding type classes we should not feel any constraints at all. Simplification sounds like a good thing!
Thanks for the heads up. I hate the numeric overloading classes; it was by far the darkest corner of the snowball compiler. I've got the compiler compiling again; a number of undefined were used, but you can see the patches. I propose. - moving the *hs files into $ROOT/src - creating a simple test directory - Starting testing the parser, and working my way down the compiler pipeline, towards small examples working. AndyG
participants (2)
-
Andy Gill -
Johan Nordlander