RE: proposal: standardize interface to Haskell' implementations
| (*) a standard haskell' api providing the commands of ghci/hugs | style interactive systems would be a start, together with an | annotated AST, parser/typer/pretty printer. more detailed | specifications could be left for future revisions. Claus, A reasonable suggestion, but I'm unsure what you actually have in mind. I think that perhaps you mean that Haskell' should specify a (Haskell) library through which one can compile, load, and execute Haskell programs? Is that right? That is, you have in mind precisely the sort of thing that GHC-as-a-library tries to offer? I ask because that isn't exactly what Java reflection, for example, offers. If that is what you have in mind, then yes indeed, it would be great to have such an interface specified. But it's a big task. The data types involved are large, and there are lots of design choices. We've simplified the problem in GHC by exposing some of GHC's internal types (e.g. Type, Class, TyCon, Id etc) which have themselves evolved over time. And that's before you start asking about what interfaces are suitable for loading, renaming, typechecking, optimising etc. I, for one, would love it if you and others felt able to contribute to the Haskell-as-a-library interface (i.e. what it should look like to the client). Whether we'd be anywhere near done for Haskell' I'm less certain. There's a (GHC-specific) Wiki page for suggestions about GHC as a library, which might be good place to start. http://haskell.org/haskellwiki/GHC/As_a_library Simon
| (*) a standard haskell' api providing the commands of ghci/hugs | style interactive systems would be a start, together with an | annotated AST, parser/typer/pretty printer. more detailed | specifications could be left for future revisions. A reasonable suggestion, but I'm unsure what you actually have in mind.
what I have in mind are things to come, which would be quite different from the initial steps we could reasonably expect Haskell' to take. initially, a separate libary may be an acceptable start; but ultimately, I don't want two separate Haskell implementations shipped for each installation. for the moment, I'd like the Haskell' committe to say this is useful, and commit to making a start, then see how far we can get. at the very least, Language.Haskell needs to be expanded on, to cope with modules, to provide type information, and to cope with language extensions [also, one might want to check whether SYB-style traversals, which are so useful for annotated ASTs, are permitted within the limitation of Haskell']. but even there, adding and maintaining a type/module system implementation would be more work than exposing the existing one, and the same goes if we want loading/evaluation as well. the difference between such an extended Language.Haskell and the standardized interface I suggested is that the former is one naive implementation of the latter. the difference between an extended Language.Haskell and the implementation by reflection I had in mind is that the latter reuses the underlying Haskell implementation to provide the same interface more efficiently (even if that might involve translating between internal types and those in Language.Haskell+). It is meta-programming because it allows Haskell programs to operate on representations of Haskell programs. It may use reflection to do so, if it permits Haskell programs access to their own representations and to parts of the implementation they are running on. I don't say to do it all perfectly for Haskell', but just to make a start that goes beyond current Language.Haskell. For that start, it may still be sufficient to leave most things in an library (**), and it doesn't have to support everything GHC's API does (though it does have to define implementation-independent interfaces). But ultimately, there will be ramifications for future language definitions (how to pass from programs to representations and back? how to type these things? how to extend programs at runtime? ... all the issues common to Template Haskell, hs-plugins, and type Dynamic [as done in Clean, not the poor man's version of Haskell]). Simon M adds extensible data types to the list. I'm sure there's more, once we start looking. I find it interesting to note the the folks who claim this is a libary-only problem are willing to put up with lots of non-Haskell' hacks, not to mention partially functioning work-arounds for features that belong in the language definition (a proper type Dynamic, for instance, with support for polymorphism, and with a way to address the issue of representations of types originating from separate programs). I'd prefer to flush out these secret hacks hidden in so-called libraries, and to call a language feature a language feature. Cheers, Claus "Ideals are like stars. You may never be able to reach them, but you can navigate by them." (**) one of the attractive things about early Haskell reports was the combination of language definitions and libraries.
Dear all, Claus Reinke wrote:
what I have in mind are things to come, which would be quite different from the initial steps we could reasonably expect Haskell' to take. initially, a separate libary may be an acceptable start; but ultimately, I don't want two separate Haskell implementations shipped for each installation.
for the moment, I'd like the Haskell' committe to say this is useful, and commit to making a start, then see how far we can get.
I don't think anyone is saying a library like this would not be useful.
at the very least, Language.Haskell needs to be expanded on, to cope with modules, to provide type information, and to cope with language extensions [...] But ultimately, there will be ramifications for future language definitions (how to pass from programs to representations and back? how to type these things? how to extend programs at runtime? [...] Simon M adds extensible data types to the list. I'm sure there's more, once we start looking.
I find it interesting to note the the folks who claim this is a libary-only problem are willing to put up with lots of non-Haskell' hacks [...] I'd prefer to flush out these secret hacks hidden in so-called libraries, and to call a language feature a language feature.
Point taken. However: 1. I'm sorry, but it seems to me that the scope of the project you are suggesting is just way beyond what possibly could fit within the Haskell' effort. 2. It seems the language features you would need standardized to be able to design suitably comprehensive and flexible library (like extensible data types) are also way beyond what we can hope to cover within the Haskell' effort. At this point it is not even clear what these features really are. Thus, if it at this point is can be convincingly argued that there is a small, well-defined set of some minor extensions that, if they were part of Haskell', would make it possible to do a substantially better job than the present "Haskell.Language", then that case should be made. But, in my opinion, arguing that case must not amount to a complete library design: there just isn't time for that. Otherwise, I'm sure a separate effort to standardize an interface to Haskell<whatever>, would yield some very valuable input to design of the next major version of Haskell. Yes, not doing that work as part of the Haskell' effort or in parallel with it, might mean that Haskell' isn't as "future proof" as it ideally should be. However, I think the next major Haskell revision is likely to include some changes that breaks backwards compatibility seriously anyway, so I am not too worried about that. All the best, /Henrik
"Ideals are like stars. You may never be able to reach them, but you can navigate by them."
Not terribly accurately though, which is why they invented GPS. :-) -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
On Mon, Feb 20, 2006 at 03:21:27PM -0000, Simon Peyton-Jones wrote:
I, for one, would love it if you and others felt able to contribute to the Haskell-as-a-library interface (i.e. what it should look like to the client). Whether we'd be anywhere near done for Haskell' I'm less certain.
I personally wouldn't want to see such a thing in haskell'. It feels like something that should be a portable library, not a part of the language spec. There would be no reason to have multiple implementations to standardize across, if someone wants to do something new and interesting, those new and interesting things would be reflected in the interface breaking the point of standardization anyway. We should be thinking not what libraries we want to use, but rather what absolutely needs to be in the language spec to allow the libraries we want to use to be portable. I was always planning on spinning off the jhc front end as a library, but it most likely would not be compatable with ghc-as-a-library by design as it would have different goals and want to explore different things. someone should be able to install both and use them side by side. Artificial standardization would only hurt such a project. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (4)
-
Claus Reinke -
Henrik Nilsson -
John Meacham -
Simon Peyton-Jones