I would like to sound out the Haskell community on what the feeling are most desirable to improve the "commerciality" (i.e. its general use) of ghc and Haskell in general (as distinct from feature set) my pick would be to 1) GHC runtime to be dynamically loaded. Enable the ghc runtime system to be loaded as a shared object/dll rather than being statically compiled in. I think the reason this has yet to be done is because it is a rather tricky issue, perhaps those in the know can comment. 2) Improving Haskell support for records. There has been much discussion over the years, some experimentation, but which alas has amounted to no change or improvement in Haskell record support. Again in my opinion the area that Haskell compares least favourably with other languages is in the area of record support particularly a) no distinct namespace for record fields (forcing people to resort to the module system to resolve name space clashes) b) subclassing on records would be great. All these things have been discussed before. The most important is (a) as it would obviate some of the tortured coding that currently appears in many Haskell modules. Additionally c) first class labels would be nice 3) Macro / conditional compilation / compiler meta language / additional binding forms These are perhaps distinct issues but can be discussed together. The prevalent use of #ifdef and the cpp is indicative of the general need to have some standard means by which differences between compilers ghc/hugs/nhc can be accommodated for in the source code. To date this issue has not been tackled in any meaningful way, perhaps we can continue to use cpp but for the sake of portability A means of defining additional binding forms would be nice as it would further facilitate embedded dsl for which Haskell is pre-eminent, and which use is a great motivator for venturing into Haskell in the first place. 4) Taking up the issue of portability and byte codes in a recent thread. The lvm used in the helium compiler perhaps offers the opportunity of defining a standard Haskell byte code platform which other compilers can target for instance ghc/hugs (hugs has in its code base the possibility of writing out a compiled form aka compiler) - thereby separating the compile time and run time platforms, providing a standard Haskell target platform.
(Sorry about replying at the top. This web interface doesn't seem to want to let me do otherwise.) I was just reading Wadler's article "How enterprises use functional languages, and why they don't" when your message came through. A definite "must read" for anyone wanting to promote the use of Haskell, IMO. Just a couple of thoughts: An easily installable integrated development environment is a must. I understand I was fortunate in getting GHC to compile on the first try (but I "cheated" and used DarwinPorts to download and compile it under OS X -- it worked beautifully, but took forever). Another issue is training. I can go to the bookstore and pick up books on Scheme or Common Lisp, but I had to send away for a Haskell text, and am still finding it a challenge. I think of myself as a pretty quick study when it comes to programming languages, but wrapping my head around the monad concept (to my satisfaction, anyway) is still proving quite a challenge. The mechanics aren't the problem: it's the intuition. I think Einstein once said that if you can't explain something to a school child, you don't really understand it. How do you explain monads to a school child? What about examples of real projects? Anyone that is interested can download source for open source projects and see C or Perl or Java in action. For people that learn best by example, where do they start with Haskell? Oh, and there's another big one: databases. I work in medical record systems, which means large highly transactional databases. One of the reasons I'm jumping so quickly into the monad concept is that I had been thinking about is a method of structuring database applications. The three big questions that come to mind when I think about Haskell (or any new language) are: How do I program TCP/IP? How do I program databases? and, How do I program graphical user interfaces? John Lask <jvlask@hotmail.com> wrote: I would like to sound out the Haskell community on what the feeling are most desirable to improve the "commerciality" (i.e. its general use) of ghc and Haskell in general (as distinct from feature set) my pick would be to 1) GHC runtime to be dynamically loaded. Enable the ghc runtime system to be loaded as a shared object/dll rather than being statically compiled in. I think the reason this has yet to be done is because it is a rather tricky issue, perhaps those in the know can comment. 2) Improving Haskell support for records. There has been much discussion over the years, some experimentation, but which alas has amounted to no change or improvement in Haskell record support. Again in my opinion the area that Haskell compares least favourably with other languages is in the area of record support particularly a) no distinct namespace for record fields (forcing people to resort to the module system to resolve name space clashes) b) subclassing on records would be great. All these things have been discussed before. The most important is (a) as it would obviate some of the tortured coding that currently appears in many Haskell modules. Additionally c) first class labels would be nice 3) Macro / conditional compilation / compiler meta language / additional binding forms These are perhaps distinct issues but can be discussed together. The prevalent use of #ifdef and the cpp is indicative of the general need to have some standard means by which differences between compilers ghc/hugs/nhc can be accommodated for in the source code. To date this issue has not been tackled in any meaningful way, perhaps we can continue to use cpp but for the sake of portability A means of defining additional binding forms would be nice as it would further facilitate embedded dsl for which Haskell is pre-eminent, and which use is a great motivator for venturing into Haskell in the first place. 4) Taking up the issue of portability and byte codes in a recent thread. The lvm used in the helium compiler perhaps offers the opportunity of defining a standard Haskell byte code platform which other compilers can target for instance ghc/hugs (hugs has in its code base the possibility of writing out a compiled form aka compiler) - thereby separating the compile time and run time platforms, providing a standard Haskell target platform. _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell === Gregory Woodhouse <gregory.woodhouse@sbcglobal.net> "Einstein was a giant. He had his head in the clouds and his feet on the ground." -- Richard P. Feynman
John Lask wrote:
I would like to sound out the Haskell community on what the feeling are most desirable to improve the "commerciality" (i.e. its general use) of ghc and Haskell in general (as distinct from feature set)
I think more standardization on an extended feature set would be nice. It has gotten better, and is still improving. Still, it would be nice to be able to say that something is valid "haskell 05", instead of -98.
1) GHC runtime to be dynamically loaded.
Why does this matter? Is anybody really running many, distinct Haskell programs simulatneously? I always compile with -optl-static anyway, just to avoid possible breakage when binaries are moved between machines.
2) Improving Haskell support for records.
Right - the problem is that nobody seems to agree exactly how to do this. I like the fact that record access looks like (is?) a simple function application, and conversely, dislike that the record update syntax is different.
To date this issue has not been tackled in any meaningful way, perhaps we can continue to use cpp but for the sake of portability
I think it was Simon that said that most uses of CPP directives was adaption to Windows vs. Unix. My only(?) use is to provide file names and line numbers for exceptions (e.g. #define head (\x -> case x of {(x1:_) -> x1; [] -> error "head: empty list (__FILE__:__LINE__)") -- or something like that). Unfortunately, CPP doesn't support macros for infix operators (array dereference, for instance).
4) Taking up the issue of portability and byte codes in a recent thread. The lvm used in the helium compiler perhaps offers the opportunity of defining a standard Haskell byte code platform which other compilers can target for instance ghc/hugs
Personally, I fail to see why this is so important - well, I guess if you want to distribute proprietary (closed-source) software and hope that suffices to compile and test it on only one platform. IMO, this isn't true of Java, and this model only manages to combine the disadvantages of compilation with the drawbacks of interpretation. :-) Anyway, Microsoft's CLR might also work, and I think there was some work in that direction. -k
On Thu, Nov 17, 2005 at 10:03:00AM +0100, Ketil Malde wrote:
2) Improving Haskell support for records.
Right - the problem is that nobody seems to agree exactly how to do this. I like the fact that record access looks like (is?) a simple function application, and conversely, dislike that the record update syntax is different.
Whereas I take the opposite approach. The simple function application is often a bad function--one that may return bottom--and I'd rather be able to place hedges around dangerous functions like that. In contrast, pattern matching is safe. Record update (on the third hand) is unsafe, but uses similar syntax to pattern matching. It's a mess. The whole namespace issue only exists for record access functions, which is a feature that I'd prefer to have dropped from the language anyways. Which just goes to show that nobody agrees... -- David Roundy http://www.darcs.net
I vote for a separate namespace for record access functions. To me a gameID in one record is always the same gameID in another record and having to add prefixes to each access field sucks when records number in the hundreds :-(. My users now have to deal with tiGameID, blahBlahGameID, etc. and they are all the same. My previous big project was in Erlang and it uses more or less the same approach to records as they are hacked on top of tuples. They _are_ tuples in Erlang and you can access fields with element(x, mytuple). Still, record labels in Erlang are not considered global functions. They are just... lables which makes a whole lot of sense and simplifies ones work immensely! Thanks, Joel /who has just coded about 250 packets as records/ On Nov 17, 2005, at 1:46 PM, David Roundy wrote:
On Thu, Nov 17, 2005 at 10:03:00AM +0100, Ketil Malde wrote:
2) Improving Haskell support for records.
Right - the problem is that nobody seems to agree exactly how to do this. I like the fact that record access looks like (is?) a simple function application, and conversely, dislike that the record update syntax is different.
Whereas I take the opposite approach. The simple function application is often a bad function--one that may return bottom--and I'd rather be able to place hedges around dangerous functions like that. In contrast, pattern matching is safe. Record update (on the third hand) is unsafe, but uses similar syntax to pattern matching. It's a mess. The whole namespace issue only exists for record access functions, which is a feature that I'd prefer to have dropped from the language anyways.
On 11/17/05, Joel Reymont <joelr1@gmail.com> wrote:
I vote for a separate namespace for record access functions.
I agree, but ... My users now have to deal with tiGameID, blahBlahGameID, etc. and
they are all the same.
To solve this problem I just made them all instances of a class with a gameId function. Still, not ideal. Fraser.
Don't get me started, please :-). I tried making each field a separate class but then needed to compose records of difference field instances which led to HList which led to GHC eating up all my memory and crashing, etc. I can see where you are going but if I have 250 records with shared fields then that's a whole lot of extra boiler plate code to marshall between the functions with prefixes to the class method implementations. The road to hell is paved with good intentions ;-). Thanks for the tip, though. On Nov 17, 2005, at 2:12 PM, Fraser Wilson wrote:
To solve this problem I just made them all instances of a class with a gameId function. Still, not ideal.
On Thu, 2005-11-17 at 15:12 +0100, Fraser Wilson wrote:
On 11/17/05, Joel Reymont <joelr1@gmail.com> wrote: I vote for a separate namespace for record access functions.
I agree, but ...
My users now have to deal with tiGameID, blahBlahGameID, etc. and they are all the same.
To solve this problem I just made them all instances of a class with a gameId function. Still, not ideal.
That gives you a getter function but you would then need an extra setter function. Duncan
To solve this problem I just made them all instances of a class with a gameId function. Still, not ideal.
That gives you a getter function but you would then need an extra setter function.
But there is no need to have two names for each label when you only want to talk about two ways of using any given label (untested code here, but I've used something similar in practice, and similar patterns are in use in various libraries, I think): -- what we expect from record field labels data Label t r = Label { get :: r -> t, put :: t -> r -> r } -- some record, with internal field labels data R a b = R { field_x :: a, field_y :: b } emptyR = R{} -- and its externally visible field labels x = Label { get = field_x, put = \t r->r{field_x=t} } y = Label { get = field_y, put = \t r->r{field_y=t} } -- example r = (x `put` True) $ (y `put` "Hi") $ emptyR r1 = (x `put` False) r main = print (get y r,get x r,get x r1) -- some might prefer something like (:=) for put and (:?) for get.. -- (x := False) r -- x :? r1 -- this uses extraneous internal field names, which I'd like -- to hide (losing direct pattern matching), but no overloading; -- so you're free to overload the field labels for selection from -- different record types (or perhaps for recursive selection from -- nested records?); -- claus
On Thu, 2005-11-17 at 22:11 +0000, Claus Reinke wrote:
To solve this problem I just made them all instances of a class with a gameId function. Still, not ideal.
That gives you a getter function but you would then need an extra setter function.
But there is no need to have two names for each label when you only want to talk about two ways of using any given label (untested code here, but I've used something similar in practice, and similar patterns are in use in various libraries, I think):
-- what we expect from record field labels data Label t r = Label { get :: r -> t, put :: t -> r -> r }
Indeed we use this "named label/attribute is a pair of getter and setter" idea in Gtk2Hs (which we borrowed from wxHaskell which in turn borrowed it from Yampa). This is for monadic attributes rather than pure record labels. We end up with a syntax like so: set button [ label := "blah", borderWidth := 10 ] something <- get label These can be made instances of classes so that different objects can have the same attribute names (wxHaskell does this). Duncan
On Thu, Nov 17, 2005 at 08:46:50AM -0500, David Roundy wrote:
On Thu, Nov 17, 2005 at 10:03:00AM +0100, Ketil Malde wrote:
2) Improving Haskell support for records.
Right - the problem is that nobody seems to agree exactly how to do this. I like the fact that record access looks like (is?) a simple function application, and conversely, dislike that the record update syntax is different.
Whereas I take the opposite approach. The simple function application is often a bad function--one that may return bottom--and I'd rather be able to place hedges around dangerous functions like that. In contrast, pattern matching is safe. Record update (on the third hand) is unsafe, but uses similar syntax to pattern matching. It's a mess. The whole namespace issue only exists for record access functions, which is a feature that I'd prefer to have dropped from the language anyways.
Which just goes to show that nobody agrees...
personally, I'd like to see a standard library version of HList included, and then come up with some syntatic sugar for working with and pattern matching on HLists. the same way 'do' notation is a simple rewriting of the monad operators. This would also give us sane error messages when working with them. perhaps some syntax for automatically creating label names would be in order to. though, there are many ways to improve the current record system more conservativly. (like, why is update partial? it should not be partial. grr.) John -- John Meacham - ⑆repetae.net⑆john⑈
My 2 cents: John Lask (Thu, Nov 17, 2005 at 08:57:52AM +1030):
I would like to sound out the Haskell community on what the feeling are most desirable to improve the "commerciality" (i.e. its general use) of ghc and Haskell in general (as distinct from feature set)
3) Macro / conditional compilation / compiler meta language / additional binding forms These are perhaps distinct issues but can be discussed together. The prevalent use of #ifdef and the cpp is indicative of the general need to have some standard means by which differences between compilers ghc/hugs/nhc can be accommodated for in the source code. To date this issue has not been tackled in any meaningful way, perhaps we can continue to use cpp but for the sake of portability
A means of defining additional binding forms would be nice as it would further facilitate embedded dsl for which Haskell is pre-eminent, and which use is a great motivator for venturing into Haskell in the first place.
The macro languages tend to become more and more complex over time. Eventually, you have two complex languages. First, a Haskell Macro Language, second Haskell. Why can we not use staging like in Omega, cf. [1], or Template Haskell? Maybe Haskell itself can generate the compiler and system specific source? [1] http://www.cs.pdx.edu/~sheard/Omega/index.html Regards, -- Stefan Karrmann
participants (10)
-
Claus Reinke -
David Roundy -
Duncan Coutts -
Fraser Wilson -
Greg Woodhouse -
Joel Reymont -
John Lask -
John Meacham -
Ketil Malde -
Stefan Karrmann