Aliasing current module qualifier

John Meacham john at repetae.net
Tue Sep 30 20:05:03 UTC 2014


Yes, that is the semantics I use for recursive module imports in jhc. And
you are right in that it does not accept those examples due to being unable
to bootstrap the least fixed point.

How would the 'as M' proposal interact? Would it actually be new entries in
the name table or rewritten as a macro to the current module name? I can
see some edge cases where it makes a difference. I am thinking the easiest
would be to populate entries for all the M.toplevel names where toplevel
are the top level definitions of the module, will implement it and see how
it shakes out.

    John

On Tue, Sep 30, 2014 at 5:18 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello,
>
> What semantics are you using for recursive modules?  As far as I see, if
> you take a least fixed point semantics (e.g. as described in "A Formal
> Specification for the Haskell 98 Module System",
> http://yav.github.io/publications/modules98.pdf ) this program is
> incorrect as the module does not export anything.
>
> While this may seem a bit counter intuitive at first, this semantics has
> the benefit of being precise, easily specified, and uniform (e.g it does
> not require any special treatment of the " current " module).  As an
> example, consider the following variation of your program, where I just
> moved the definition in a sperate (still recursive) module:
>
> module A (M.x) where
>   import B as M
>
> module B (M.x) where
>   import A as M
>   x = True
>
> I think that it'd be quite confusing if a single recursive module worked
> differently then a larger recursive group, but it is not at all obvious why
> B should export 'x'.  And for those who like this kind of puzzle: what
> should happen if 'A' also had a definition for 'x'?
>
> Iavor
>  On Sep 29, 2014 11:02 PM, "John Meacham" <john at repetae.net> wrote:
>
>> You don't need a new language construct, what i do is:
>>
>>      module AnnoyinglyLongModuleName (M.length, M.null) where
>>
>>     import AnnoyinglongLongModuleName as M
>>
>> I think ghc would need to be extended a little to make this convienient
>> as it doesn't handle recursive module imports as transparently.
>>
>>     John
>>
>> On Mon, Sep 29, 2014 at 8:47 AM, Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>>
>>> On Mon, Sep 29, 2014 at 4:19 AM, Herbert Valerio Riedel <hvr at gnu.org>
>>> wrote:
>>>
>>>> Now it'd be great if I could do the following instead:
>>>>
>>>>     module AnnoyinglyLongModuleName (M.length, M.null) where
>>>>
>>>>     import AnnoyinglyLongModuleName as M -- <- does not work
>>>>
>>>
>>> I think if I wanted this syntax, I'd go for:
>>>
>>>     module AnnoyinglyLongModuleName as M where ...
>>>
>>> --
>>> brandon s allbery kf8nh                               sine nomine
>>> associates
>>> allbery.b at gmail.com
>>> ballbery at sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>
>>
>> --
>> John Meacham - http://notanumber.net/
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>


-- 
John Meacham - http://notanumber.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140930/0e7b8a1f/attachment-0001.html>


More information about the ghc-devs mailing list