On Tue, Jan 17, 2012 at 9:59 AM, Yitzchak Gale <g...@sefer.org> wrote:
> By the way, thanks to Greg for driving this discussion,
> please keep up the good work!
>
> Simon Peyton-Jones wrote:
>> Can you turn your proposal into a Wiki page?
>
> OK I'll try to get to that later today.
>
>> It's different to Johan's.
>
> Oh? I didn't realize that. OK, I'll look at it more closely.
> I'm basically just using modules the way they are,
> changing almost nothing.
>
> I wrote:
>>> [This has the additional advantage of giving SPJ
>>> motivation to remain engaged, because he seems
>>> to prefer B. :)]
>
>> True: but that's because I think that in the end A will
>> be deemed too clumsy, so we'll end with B anyway.
>> And I'd rather not do both.  But I'm quite open to
>> persuasion!
>
> I agree that B would be great! It just seems harder,
> and I'm worried that we'll get stuck again.
> As long as we are moving forward productively towards
> a solution to B, I'm happy with that.
> I'm trying to suggest a simple, workable approach to A
> as a backup.
>
>> OK, so consider this:
>>        module M where
>>          module T where
>>            data T = MkT { x :: Int }
>>          module S where
>>            data S = MkS { x :: Int }
>> So inside M I can refer to T.x and S.x.
>> Fine!  What does M export?
>
> As it stands, M exports nothing. In my scheme, nested modules
> have almost exactly the same meaning as they would have
> if they were written as separate modules. So far, the only
> differences are: "module T" is syntactic sugar for "module M.T",
> and there are implied import statements added to M, T, and S.
>
> So an module external to M that wants to use T or S would
> need to import them explicitly in addition to the import of M.
> The usual rules would then apply.
>
> Based on your comments, I see that another optional
> enhancement to my proposal could be as follows:
>
> Whenever any module E imports M unqualified without an
> import list, as in:
>
> import M
>
> then the following implied imports would be added to E:
>
> import qualified M.T as T
> import qualified M.S as S
>
> and whenever E imports M qualified without an
> import list, as in:
>
> import qualified M as Q
>
> then the following implied imports would be
> added to E:
>
> import qualified M.T as Q.T
> import qualified M.S as Q.S

I like this and would like to have it independently of which records
system is chosen.

>
> Similarly, if M also contains more deeply nested
> modules and E imports M either qualified or
> unqualified without an import list, the corresponding
> implied imports of the deeply nested modules would
> also be added to E. But in fact, this is nothing
> more than a recursive application of the previous
> rule.
>
> Note that an import statement with an import list
> will never generate any automatic import of
> a nested module.
>
> I will add this additional enhancement to the wiki
> page (when I write it).
>
> Thanks,
> Yitz
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
Work is punishment for failing to procrastinate effectively.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to