Re: first-class modules
On Tuesday 26 March 2002 17:31, you wrote: A number of people have discussed the use of implicit parameters to mimic global variables in Haskell. I am wondering if any have done the same for a first-class module system such as that proposed by Shields and Jones. It seems to make a tremendous amount of sense to do it that way: 1. semi-constant values: Things that are calculated or input at the beginning of the program could be handled by Main.main, which would pass the results to the Second module, whose main function it could then call. This seems much more natural than the implicit parameter approach for this purpose. It seems nice for that *specific* purpose. What I like about implicit parameters is the fact that they are a more general approach, and that is IMO very important. You, might for instance, decide that maybe it would be a good idea to, under certain specific conditions, change one of those semi-constant values. Imagine some AI algortithm, you iterate some learning function 'learnF' over and over again. Now you realize that under certain conditions maybe the learning rate (used in learnF) should be changed. Chaging your implementation would be easy with implicit parameters. J.A. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: First class modules (was Existential Typing)
| artificial restriction. I think extending the system with
| some form of
| subtyping between records would be important for a usable
| system. Your
| paper suggested that you are planning to do this. Any
| thoughts on current
| ideas in this direction?
Yes, we should really say something about this in the paper.
A key design choice in our system is to use *nominal* not *structural*
typing. The structural choice makes perfect sense, but it leads to
complications we don't have (as well as benefits). So we don't have
structural subtyping, and it would not be easy to add it.
On the other hand, one could add nominal subtyping without too
much difficulty:
record A = { x,y :: Int }
record B : A = { z :: Int }
We have not done that yet, but Mark thinks it would could be done
without bad interaction with what we have already.
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: First class modules (was Existential Typing)
Simon Peyton-Jones writes:
:
| A key design choice in our system is to use *nominal* not *structural*
| typing. The structural choice makes perfect sense, but it leads to
| complications we don't have (as well as benefits). So we don't have
| structural subtyping, and it would not be easy to add it.
|
| On the other hand, one could add nominal subtyping without too
| much difficulty:
|
| record A = { x,y :: Int }
| record B : A = { z :: Int }
|
| We have not done that yet, but Mark thinks it would could be done
| without bad interaction with what we have already.
Hi.
Could a function of type A-Int be applied to an argument of type B?
That's arguably the most difficult part.
Regards,
Tom
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: First class modules
On 07-Nov-2000, Tom Pledger [EMAIL PROTECTED] wrote: Supposing that (some version of) Haskell had first class modules, and type variables could be universally quantified at the module level, would rule 2 of the monomorphism restriction go away? No. |Rule 2. Any monomorphic type variables that remain when type |inference for an entire module is complete, are considered |ambiguous, and are resolved to particular types using the |defaulting rules (Section 4.3.4). Although this rule refers to the "entire module", its typical for the ambiguity to arise within a single function: foo = show (read "whatever") This expression is fundamentally ambiguous unless you somehow disambiguate what type it is that you are trying to read. I don't see how first class modules could solve that. -- Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit | of excellence is a lethal habit" WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: First class modules
Fergus Henderson writes: On 07-Nov-2000, Tom Pledger [EMAIL PROTECTED] wrote: Supposing that (some version of) Haskell had first class modules, and type variables could be universally quantified at the module level, would rule 2 of the monomorphism restriction go away? No. |Rule 2. Any monomorphic type variables that remain when type |inference for an entire module is complete, are considered |ambiguous, and are resolved to particular types using the |defaulting rules (Section 4.3.4). Although this rule refers to the "entire module", its typical for the ambiguity to arise within a single function: foo = show (read "whatever") This expression is fundamentally ambiguous unless you somehow disambiguate what type it is that you are trying to read. I don't see how first class modules could solve that. Thanks for the analysis. I see how there's no way for another module (or any other declarations in the same module) to disambiguate that. How about the cases where the module boundary plays a part in triggering the MR, like this? module MRDemo where x = return () I've got the impression that these cases are the ones which provoke most of the MR criticism. Would they be relieved by quantifying at the module level, so that the ambiguity gets passed to modules which import MRDemo and use x? Regards, Tom ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: First class modules
Mark Lillibridge wrote: Claus Reinke wrote: `First class modules' are just that: modules that are also first class data objects of the programming language (e.g., records containing functions). I would alter that to "(e.g., records containing functions _and types_)", at least for statically typed programming languages. I don't think you can justify calling something that cannot contain types, a module, in such languages. Well, it's not obvious to me how the extension of a programming language P with both types T and (first class) modules M should look like and I'm quite sure there is more than one possible approach. ? / \ M T \ / P Starting with an untyped language, we could first add modules, then try to type modular programs MP (left side), or we could first add types, then try to modularize typed programs TP (right side). 1. T T MM M / /\ T \ \= MP / = TP P P Of course, the story does not end here in either case. In the typed modular language TMP, we want to have a modular structure for our type language, too. In the modular typed language MTP, we still need to make modules first class, thus giving them types. 2. M M TT \ T\M // / = TMP \ = MTP MP TP The question is: how do we avoid an endless unfolding here? Are there fixpoints, how do they look like? Do both lines have a common goal? Your approach, influenced by the powerful SML module language, seems to follow the right path (geometrically;-) first, then introduces one type language covering both occurrences of T in the last right picture (2.right). Result: first class modules with types inside! [please correct me if I'm misinterpreting you] The right path has an interesting intermediate alternative: using different type systems for P and MTP does not yield first class modules, but corresponds to the two-level design of the current SML core and module language. Now what about the left path? Coming from an implicitly and dynamically typed framework, it is no surprise that I'm a little bit biased towards this alternative, but how does it fit into the Haskell framework (which is typed)? The reason is simple: the official module system, representing the state-of-the-art of 1980, is just too inflexible. It helps to organize the global namespace into smaller environments, connected by a network of import/export-relations, and that's it. Not even support for parameterized modules! Without a powerful module language, Haskell programmers had to resort to other techniques to do modular programming. Perhaps starting with Hughes `Why functional programming matters', and continuing up to recent publications on the construction of `modular interpreters', Haskell's module system has received the small interest it deserves. It's modules are not program building blocks themselves but they contain collections of those, and the real program construction goes on in the base language (of course, along the communication lines allowed by import/export- declarations). So the Haskell picture developed like this: 3. M M \ T \ T /=== / PMP I.e., we have a rather limited upper module language (Modula-style), and inside there is a typed programming language whose features are explored for (and form the main basis of) a modular programming style. The usability of the core language constructs for such a pupose is severely limited by the type system. Result: while extending P with additional constructs towards a modular base language MP, the main problems are the necessary extensions of T. Finally, although the paths were different, the pictures 3.right and 2.left are remarkably similar, and the next natural step for Haskell seems to be a system of first-class modules (through first-class structures with polymorphic components) without type components to fully establish the inner MP in 3.right, with the additional upper module language still in place. Just as the current SML design has two type languages, this design would have two module languages. (Actually, there is even a third module language in the game, as the type class system has its own means to structure type declarations..) I agree with you that this next step would probably not be the final word on modules (though we might have different opinions on what is missing), but it would really be nice to see this next step taken (or at least scheduled) in the not too distant future. Hence my question to the Haskell committee. It is a nice surprise to meet you here (hope you'll be up and about again soon). By the way, do you have information about the module language of ML2000? Will translucent sums be the
