%module-public-interface

%module-public-interface

[Andy Wingo]

Hello,

As you might well know, in every module that actually has a public
interface (most all of them), there is an extra symbol bound in that
module: %module-public-interface. It references, um, the public
interface.

Also in every module that has submodules, like (language tree-il) and
(language tree-il compile-glil), the "supermodule" has a binding for the
submodule. Do a (module-ref (resolve-module '(ice-9)) 'threads)
sometime.

It is, as my southern-US family would say, "turrible". But somehow it
normally doesn't affect us.

I'm pretty sure that the submodule thing can be changed without any
problem. But it seems that the %module-public-interface is used
explicitly, at least by texmacs and lilypond.

Any ideas on what the right thing to do is? Just leave it? Add fields to
modules for the public interface and submodules, but keep the
%module-public-interface binding? Throw up our hands and dance around?

Let me know,

Andy
-- 
http://wingolog.org/

Re: %module-public-interface

[Ludovic Courtès]

Howdy!

Andy Wingo <wingo@pobox.com> writes:

> Do a (module-ref (resolve-module '(ice-9)) 'threads)
> sometime.

That’s the hierarchical naming scheme, not related to
%module-public-interface but probably worth a discussion.

> I'm pretty sure that the submodule thing can be changed without any
> problem. But it seems that the %module-public-interface is used
> explicitly, at least by texmacs and lilypond.

How do they use it?

> Any ideas on what the right thing to do is? Just leave it? Add fields to
> modules for the public interface and submodules, but keep the
> %module-public-interface binding? Throw up our hands and dance around?

Yeah!

And we could add a ‘public-interface’ slot to ‘module-type’ and have
‘module-public-interface’ and ‘set-module-public-interface!’ refer to
it; for backward compatibility we’d also initialize the
‘%module-public-interface’ binding.  How does it sound?

Thanks,
Ludo’.

Re: %module-public-interface

[Andy Wingo]

On Tue 30 Mar 2010 22:56, ludo@gnu.org (Ludovic Courtès) writes:

>> I'm pretty sure that the submodule thing can be changed without any
>> problem. But it seems that the %module-public-interface is used
>> explicitly, at least by texmacs and lilypond.
>
> How do they use it?

Linking to the evil empire:

http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search
http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface+lang%3Ac%2B%2B&sbtn=Search

>> Any ideas on what the right thing to do is? Just leave it? Add fields to
>> modules for the public interface and submodules, but keep the
>> %module-public-interface binding? Throw up our hands and dance around?
>
> Yeah!
>
> And we could add a ‘public-interface’ slot to ‘module-type’ and have
> ‘module-public-interface’ and ‘set-module-public-interface!’ refer to
> it; for backward compatibility we’d also initialize the
> ‘%module-public-interface’ binding.  How does it sound?

Dancing? OK!

Also back compatibility. Er, yeah :)

Andy
-- 
http://wingolog.org/

Re: %module-public-interface

[Ludovic Courtès]

Hello,

Andy Wingo <wingo@pobox.com> writes:

> On Tue 30 Mar 2010 22:56, ludo@gnu.org (Ludovic Courtès) writes:
>
>>> I'm pretty sure that the submodule thing can be changed without any
>>> problem. But it seems that the %module-public-interface is used
>>> explicitly, at least by texmacs and lilypond.
>>
>> How do they use it?
>
> Linking to the evil empire:
>
> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search
> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface+lang%3Ac%2B%2B&sbtn=Search

Lilypond does:

--8<---------------cut here---------------start------------->8---
      mod = scm_call_0 (maker);
      scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
                         mod);
--8<---------------cut here---------------end--------------->8---

Solution: do something like:

--8<---------------cut here---------------start------------->8---
#ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
  scm_set_module_public_interface_x (mod, mod);
#else
  scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
                     mod);
#endif
--8<---------------cut here---------------end--------------->8---

(We just need to add that function.)

TeXmacs does:

--8<---------------cut here---------------start------------->8---
    (let* ((m (resolve-module which))
           (m-public (module-ref m '%module-public-interface)))
      (module-map (lambda (sym var) sym) m-public)))
--8<---------------cut here---------------end--------------->8---

and:

--8<---------------cut here---------------start------------->8---
           (let* ((m (resolve-module ',module))
                  (p (module-ref texmacs-user '%module-public-interface))
                  (r (module-ref p ',name #f)))
             (if (not r)
                 (texmacs-error "lazy-define"
                                ,(string-append "Could not retrieve "
                                                (symbol->string name))))
             (apply r args))))))
--8<---------------cut here---------------end--------------->8---

Solution: use ‘resolve-interface’.

Gossip does:

--8<---------------cut here---------------start------------->8---
        (append! (delq! '%module-public-interface
                        (module-map (lambda (sym var) sym) mod))
                 (hash-fold (lambda (k v r) (cons k r)) '() blocks)))
--8<---------------cut here---------------end--------------->8---

This snippet won’t see any difference.

>> And we could add a ‘public-interface’ slot to ‘module-type’ and have
>> ‘module-public-interface’ and ‘set-module-public-interface!’ refer to
>> it; for backward compatibility we’d also initialize the
>> ‘%module-public-interface’ binding.  How does it sound?

Actually the trick wouldn’t work in cases where the
‘%module-public-interface’ binding is mutated, as with Lilypond.

Given this and the above examples, I’d suggest dropping that binding
completely and sending patches to the Lilypond/TeXmacs people.

What do you think?

Thanks,
Ludo’.

Re: %module-public-interface

[Andy Wingo]

On Tue 30 Mar 2010 23:52, ludo@gnu.org (Ludovic Courtès) writes:

>>> And we could add a ‘public-interface’ slot to ‘module-type’ and have
>>> ‘module-public-interface’ and ‘set-module-public-interface!’ refer to
>>> it; for backward compatibility we’d also initialize the
>>> ‘%module-public-interface’ binding.  How does it sound?
>
> Actually the trick wouldn’t work in cases where the
> ‘%module-public-interface’ binding is mutated, as with Lilypond.
>
> Given this and the above examples, I’d suggest dropping that binding
> completely and sending patches to the Lilypond/TeXmacs people.

Hm. I guess you're right.

In the case with deprecated foo enabled, we can add a
%module-public-interface definition in the root module, which maps to a
module with a binder procedure that will raise an error. That way we can
catch apps that we don't know about.

Andy
-- 
http://wingolog.org/

Hierarchical name space

[Ludovic Courtès]

Hey,

Andy Wingo <wingo@pobox.com> writes:

> Also in every module that has submodules, like (language tree-il) and
> (language tree-il compile-glil), the "supermodule" has a binding for the
> submodule. Do a (module-ref (resolve-module '(ice-9)) 'threads)
> sometime.

I think I found a possible use case for the hierarchical name space.  :-)

Suppose we want something like PLaneT or Eggs, let’s call it GUMM
(Guile’s Unified Module Machinery).  Ideally, we’d want to be able to
write this:

  (use-modules (gumm foo bar))

Such that:

  - If a (foo bar) module exists locally, it is used

  - else if ftp://example.org/gumm/foo/bar.scm exists it is downloaded
    and ‘resolve-interface’d

  - else an error is raised.

The hierarchical name space allows the (gumm) module to have a lazy
binder procedure that will catch all such lookups so that it can
actually do its job.  QED?

Thanks,
Ludo’.

Re: Hierarchical name space

[Andy Wingo]

On Wed 31 Mar 2010 22:42, ludo@gnu.org (Ludovic Courtès) writes:

> Hey,
>
> Andy Wingo <wingo@pobox.com> writes:
>
>> Also in every module that has submodules, like (language tree-il) and
>> (language tree-il compile-glil), the "supermodule" has a binding for the
>> submodule. Do a (module-ref (resolve-module '(ice-9)) 'threads)
>> sometime.
>
> I think I found a possible use case for the hierarchical name space.  :-)
>
> Suppose we want something like PLaneT or Eggs, let’s call it GUMM
> (Guile’s Unified Module Machinery).  Ideally, we’d want to be able to
> write this:
>
>   (use-modules (gumm foo bar))

Ew. I even forgot that I did this with slib a while back.

I'm still inclined to think that the module namespace hierarchy (and it
is a hierarchy) should not impinge on the environment of an evaluation.
But, not something we can change right now.

A
-- 
http://wingolog.org/

Re: %module-public-interface

[Ian Hulin]

Hi Ludovic,

On 30/03/10 22:52, Ludovic � wrote:
> Hello,
>
> Andy Wingo<wingo@pobox.com>  writes:
>
>> On Tue 30 Mar 2010 22:56, ludo@gnu.org (Ludovic Courtès) writes:
>>
>>>> I'm pretty sure that the submodule thing can be changed without any
>>>> problem. But it seems that the %module-public-interface is used
>>>> explicitly, at least by texmacs and lilypond.
>>>
>>> How do they use it?
>>
>> Linking to the evil empire:
>>
>> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search
>> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface+lang%3Ac%2B%2B&sbtn=Search
>
> Lilypond does:
>
> --8<---------------cut here---------------start------------->8---
>        mod = scm_call_0 (maker);
>        scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>                           mod);
> --8<---------------cut here---------------end--------------->8---
>
> Solution: do something like:
>
> --8<---------------cut here---------------start------------->8---
> #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
>    scm_set_module_public_interface_x (mod, mod);
> #else
>    scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>                       mod);
> #endif
> --8<---------------cut here---------------end--------------->8---
>
> (We just need to add that function.)
>

> TeXmacs does:
<snip>
>>> And we could add a ‘public-interface’ slot to ‘module-type’ and have
>>> ‘module-public-interface’ and ‘set-module-public-interface!’ refer to
>>> it; for backward compatibility we’d also initialize the
>>> ‘%module-public-interface’ binding.  How does it sound?
>
> Actually the trick wouldn’t work in cases where the
> ‘%module-public-interface’ binding is mutated, as with Lilypond.
>
> Given this and the above examples, I’d suggest dropping that binding
> completely and sending patches to the Lilypond/TeXmacs people.
>
 > What do you think?

If you do add scm_set_module_public_interface_x, could you back-port it 
to Guile V1.8.6 and V1.8.7?

Those are the lowest versions of Guile the upcoming stable release of 
Lilypond will support.

Cheers,

Ian Hulin

Re: %module-public-interface

[Ludovic Courtès]

Hi Ian,

Ian Hulin <ian@hulin.org.uk> writes:

> On 30/03/10 22:52, Ludovic � wrote:

>> Andy Wingo<wingo@pobox.com>  writes:
>>
>>> On Tue 30 Mar 2010 22:56, ludo@gnu.org (Ludovic Courtès) writes:
>>>
>>>>> I'm pretty sure that the submodule thing can be changed without any
>>>>> problem. But it seems that the %module-public-interface is used
>>>>> explicitly, at least by texmacs and lilypond.
>>>>
>>>> How do they use it?
>>>
>>> Linking to the evil empire:
>>>
>>> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search
>>> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface+lang%3Ac%2B%2B&sbtn=Search
>>
>> Lilypond does:
>>
>> --8<---------------cut here---------------start------------->8---
>>        mod = scm_call_0 (maker);
>>        scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>>                           mod);
>> --8<---------------cut here---------------end--------------->8---
>>
>> Solution: do something like:
>>
>> --8<---------------cut here---------------start------------->8---
>> #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
>>    scm_set_module_public_interface_x (mod, mod);
>> #else
>>    scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>>                       mod);
>> #endif
>> --8<---------------cut here---------------end--------------->8---
>>
>> (We just need to add that function.)
>>
>
>> TeXmacs does:
> <snip>
>>>> And we could add a ‘public-interface’ slot to ‘module-type’ and have
>>>> ‘module-public-interface’ and ‘set-module-public-interface!’ refer to
>>>> it; for backward compatibility we’d also initialize the
>>>> ‘%module-public-interface’ binding.  How does it sound?
>>
>> Actually the trick wouldn’t work in cases where the
>> ‘%module-public-interface’ binding is mutated, as with Lilypond.
>>
>> Given this and the above examples, I’d suggest dropping that binding
>> completely and sending patches to the Lilypond/TeXmacs people.
>>
>> What do you think?
>
> If you do add scm_set_module_public_interface_x, could you back-port
> it to Guile V1.8.6 and V1.8.7?

We could back-port it to the 1.8 series, but not to the already-released
1.8.7 and 1.8.6.  We’d have to make a 1.8.8 release, but I’m not sure
that would really help anyway since that would force Lilypond users to
switch to that version.

> Those are the lowest versions of Guile the upcoming stable release of
> Lilypond will support.

How about doing #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X in your
code?

We still have to agree on the change and actually implement it, the
latter being easy. ;-)  When is the new Lilypond release due?

Thanks,
Ludo’.

Re: %module-public-interface

[Ian Hulin]

On 02/04/10 10:37, Ludovic � wrote:
> Hi Ian,
>
> Ian Hulin<ian@hulin.org.uk>  writes:
>
>    
>> On 30/03/10 22:52, Ludovic � wrote:
>>      
>    
>>> Andy Wingo<wingo@pobox.com>   writes:
>>>
>>>        
>>>> On Tue 30 Mar 2010 22:56, ludo@gnu.org (Ludovic Courtès) writes:
>>>>
>>>>          
>>>>>> I'm pretty sure that the submodule thing can be changed without any
>>>>>> problem. But it seems that the %module-public-interface is used
>>>>>> explicitly, at least by texmacs and lilypond.
>>>>>>              
>>>>> How do they use it?
>>>>>            
>>>> Linking to the evil empire:
>>>>
>>>> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search
>>>> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface+lang%3Ac%2B%2B&sbtn=Search
>>>>          
>>> Lilypond does:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>>         mod = scm_call_0 (maker);
>>>         scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>>>                            mod);
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> Solution: do something like:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
>>>     scm_set_module_public_interface_x (mod, mod);
>>> #else
>>>     scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>>>                        mod);
>>> #endif
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> (We just need to add that function.)
>>>
>>>        
>>      
>>> TeXmacs does:
>>>        
>> <snip>
>>      
>>>>> And we could add a ‘public-interface’ slot to ‘module-type’ and have
>>>>> ‘module-public-interface’ and ‘set-module-public-interface!’ refer to
>>>>> it; for backward compatibility we’d also initialize the
>>>>> ‘%module-public-interface’ binding.  How does it sound?
>>>>>            
>>> Actually the trick wouldn’t work in cases where the
>>> ‘%module-public-interface’ binding is mutated, as with Lilypond.
>>>
>>> Given this and the above examples, I’d suggest dropping that binding
>>> completely and sending patches to the Lilypond/TeXmacs people.
>>>
>>> What do you think?
>>>        
>> If you do add scm_set_module_public_interface_x, could you back-port
>> it to Guile V1.8.6 and V1.8.7?
>>      
> We could back-port it to the 1.8 series, but not to the already-released
> 1.8.7 and 1.8.6.  We’d have to make a 1.8.8 release, but I’m not sure
> that would really help anyway since that would force Lilypond users to
> switch to that version.
>
>    
>> Those are the lowest versions of Guile the upcoming stable release of
>> Lilypond will support.
>>      
> How about doing #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X in your
> code?
>
> We still have to agree on the change and actually implement it, the
> latter being easy. ;-)
I'm sure that would be easy enough, if guile provided 
HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X in the V2.0
guile-config (or the pkg-config guile-2.0 data which I believe is 
replacing it), that looks like it would be the most painless route for 
both projects.

> When is the new Lilypond release due?
>
>    
I'm not the ReleaseMeister for Lilypond; you'll get a better picture by 
talking to Graham Percival (graham@percival-music.ca).

But FWIW it looks like we're on our few last development releases before 
the stable V2.14 comes out.  It's near enough for a spoof release 
announcement to have gone out on the mailing list on April 1st which 
suckered me!

I reckon plans are for Lilypond to stick with Guile V1.8.7 at least 
until the next Lilypond stable version after V2.14, but again, mileage 
may vary if you talk to more experienced Lilypond people.

Currently there are only a couple of people in the Pond looking at 
Lilypond/Guile V2.0 transition, and there are a few compatibiilty 
breakages we've identified.

1. Lilypond configure looks at guile-config --version to get the guile 
version - the guile V2.0 guile-config says it's being deprecated in 
favour of pkg-config --atleast-version/--exact-version/--max-version.

2. Lilypond has *lots* of guile code which it needs to build the project.

3. There's a  restriction introduced in Guile V2.0 whereby dynamic use 
of define, define-public and variants will cause the guile compilation 
to fail with diagnostics.  We have these in our basic Scheme files 
(lily.scm and lily-library.scm).  These compilation failures currently 
stop Lilypond building altogether.

4. We've already seen the %module-public-interface thing in the Lily 
C++.  There's probably more smelly stuff lurking in the C++ interface, 
which won't surface until we start trying to use Guile 2.0 more.

Graham, Vincent, is it worth opening a tracker to capture 
forward-compatibility issues with Guile?

Thanks for your feedback so far, Ludo.  The other Lily developer who has 
done anything with Guile 1.9/V2.0 is Patrick McCarty (pnorks@gmail.com).

Cheers,

Ian

Re: %module-public-interface

[Patrick McCarty]

On 2010-04-02, Ian Hulin wrote:
> 
> 3. There's a  restriction introduced in Guile V2.0 whereby dynamic
> use of define, define-public and variants will cause the guile
> compilation to fail with diagnostics.  We have these in our basic
> Scheme files (lily.scm and lily-library.scm).  These compilation
> failures currently stop Lilypond building altogether.

This is really just a stricter adherence to the Scheme R5RS.

(if ...) can only contain *expressions*, IIUC, and (define ...) is a
top-level definition, not an expression.

But yes, either LilyPond will need to adapt to these stricter
guidelines, or Guile will loosen its policy with respect to (if ...)
statements.

> 4. We've already seen the %module-public-interface thing in the Lily
> C++.  There's probably more smelly stuff lurking in the C++
> interface, which won't surface until we start trying to use Guile
> 2.0 more.

I think almost everything is fixed on the C++ side now.

> Graham, Vincent, is it worth opening a tracker to capture
> forward-compatibility issues with Guile?

We already have one (sort of):
http://code.google.com/p/lilypond/issues/detail?id=963

> Thanks for your feedback so far, Ludo.  The other Lily developer who
> has done anything with Guile 1.9/V2.0 is Patrick McCarty
> (pnorks@gmail.com).

That's <pnorcks@gmail.com>.  I don't want any email reaching the wrong
mailbox.  :-)

-Patrick

Re: %module-public-interface

[Graham Percival]

On Fri, Apr 02, 2010 at 11:50:08AM -0700, Patrick McCarty wrote:
> On 2010-04-02, Ian Hulin wrote:
> > 
> > Graham, Vincent, is it worth opening a tracker to capture

ITYM Valentin.

> > forward-compatibility issues with Guile?
> 
> We already have one (sort of):
> http://code.google.com/p/lilypond/issues/detail?id=963

Not really; that's intended for things like "we need to use
fontforge 2010.03.02 or higher!".  And it'll be closed in a few
weeks.


I've added issue 1055:
http://code.google.com/p/lilypond/issues/detail?id=1055

Cheers,
- Graham

Re: %module-public-interface

[Han-Wen Nienhuys]

On Fri, Apr 2, 2010 at 8:58 AM, Ian Hulin <ian@hulin.org.uk> wrote:
>>>>>> How do they use it?
>>>>>>
>>>>>
>>>>> Linking to the evil empire:
>>>>> http://www.google.com/codesearch?hl=en&lr=&q=%25module-public-interface&sbtn=Search

(ehh?)


>> When is the new Lilypond release due?
>>
>>
>
> I'm not the ReleaseMeister for Lilypond; you'll get a better picture by
> talking to Graham Percival (graham@percival-music.ca).
>
> But FWIW it looks like we're on our few last development releases before the
> stable V2.14 comes out.  It's near enough for a spoof release announcement
> to have gone out on the mailing list on April 1st which suckered me!
>
> I reckon plans are for Lilypond to stick with Guile V1.8.7 at least until
> the next Lilypond stable version after V2.14, but again, mileage may vary if
> you talk to more experienced Lilypond people.

Is Guile 2.0 already released?

I think it makes sense to forget about guile 2.0 for the 2.14 release,
and require 2.0 for the 2.16 release.  We could scrap lots of hairy GC
code if we could move to 2.0 (2.0 supports boehm GC, right?)


> 4. We've already seen the %module-public-interface thing in the Lily C++.
>  There's probably more smelly stuff lurking in the C++ interface, which
> won't surface until we start trying to use Guile 2.0 more.

There may be lots of hairiness in the module interface; I sort of made
up functions as I went along, since it was largely undocumented.

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: %module-public-interface

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <hanwenn@gmail.com> writes:

> On Fri, Apr 2, 2010 at 8:58 AM, Ian Hulin <ian@hulin.org.uk> wrote:

[...]

>> I'm not the ReleaseMeister for Lilypond; you'll get a better picture by
>> talking to Graham Percival (graham@percival-music.ca).
>>
>> But FWIW it looks like we're on our few last development releases before the
>> stable V2.14 comes out.  It's near enough for a spoof release announcement
>> to have gone out on the mailing list on April 1st which suckered me!
>>
>> I reckon plans are for Lilypond to stick with Guile V1.8.7 at least until
>> the next Lilypond stable version after V2.14, but again, mileage may vary if
>> you talk to more experienced Lilypond people.
>
> Is Guile 2.0 already released?

No.  1.9 pre-releases are available from alpha.gnu.org (make sure to
give it a try!); 2.0 should happen within a couple of months.

> I think it makes sense to forget about guile 2.0 for the 2.14 release,
> and require 2.0 for the 2.16 release.  We could scrap lots of hairy GC
> code if we could move to 2.0 (2.0 supports boehm GC, right?)

Yes.

Thanks,
Ludo’.

Re: Hierarchical name space

[Julian Graham]

Hi Andy and Ludo,


> I'm still inclined to think that the module namespace hierarchy (and it
> is a hierarchy) should not impinge on the environment of an evaluation.
> But, not something we can change right now.

This is actually causing me some difficulty -- I'm implementing the
R6RS composite library, which imports and then re-exports the bindings
of a lot of the individual R6RS standard libraries.  I'm running into
a problem with `(rnrs syntax-case)', which exports `syntax-case'.
Using the conventional set of module system introspection procedures
(`module-ref', `module-variable', etc.), there's no way to see the
syntax transformer and not the module -- to obtain the former, you
need to use `nested-ref' (or some other workaround) instead.

Any ideas?


Regards,
Julian

Re: Hierarchical name space

[Ludovic Courtès]

Hi,

Julian Graham <joolean@gmail.com> writes:

>> I'm still inclined to think that the module namespace hierarchy (and it
>> is a hierarchy) should not impinge on the environment of an evaluation.
>> But, not something we can change right now.
>
> This is actually causing me some difficulty -- I'm implementing the
> R6RS composite library, which imports and then re-exports the bindings
> of a lot of the individual R6RS standard libraries.  I'm running into
> a problem with `(rnrs syntax-case)', which exports `syntax-case'.

Unfortunately I don’t think a module names can contain ‘syntax-case’,
just like they can’t contain ‘eval’, ‘+’, etc.  :-(

I can’t think of a work around.

Thanks,
Ludo’.

Re: Hierarchical name space

[Andy Wingo]

Hi,

On Thu 08 Apr 2010 01:01, ludo@gnu.org (Ludovic Courtès) writes:

> Julian Graham <joolean@gmail.com> writes:
>
>>> I'm still inclined to think that the module namespace hierarchy (and it
>>> is a hierarchy) should not impinge on the environment of an evaluation.
>>> But, not something we can change right now.
>>
>> This is actually causing me some difficulty -- I'm implementing the
>> R6RS composite library, which imports and then re-exports the bindings
>> of a lot of the individual R6RS standard libraries.  I'm running into
>> a problem with `(rnrs syntax-case)', which exports `syntax-case'.
>
> Unfortunately I don’t think a module names can contain ‘syntax-case’,
> just like they can’t contain ‘eval’, ‘+’, etc.  :-(

Explain more?

> I can’t think of a work around.

We need to separate module namespaces from value namespaces. Lazy
binding / module lookup can be implemented differently from lazy
binders.

Andy
-- 
http://wingolog.org/

Re: Hierarchical name space

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> writes:

> Hi,
>
> On Thu 08 Apr 2010 01:01, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Julian Graham <joolean@gmail.com> writes:
>>
>>>> I'm still inclined to think that the module namespace hierarchy (and it
>>>> is a hierarchy) should not impinge on the environment of an evaluation.
>>>> But, not something we can change right now.
>>>
>>> This is actually causing me some difficulty -- I'm implementing the
>>> R6RS composite library, which imports and then re-exports the bindings
>>> of a lot of the individual R6RS standard libraries.  I'm running into
>>> a problem with `(rnrs syntax-case)', which exports `syntax-case'.
>>
>> Unfortunately I don’t think a module names can contain ‘syntax-case’,
>> just like they can’t contain ‘eval’, ‘+’, etc.  :-(
>
> Explain more?

Well, the problem has apparently vanished in 1.9:

--8<---------------cut here---------------start------------->8---
$ cat foo.scm 
(define-module (foo) #:export (bar)) (define bar 1)

$ cat foo/eval.scm
(define-module (foo eval) #:export (foo)) (define foo 2)

$ guile -L .
GNU Guile 1.9.9
Copyright (C) 1995-2010 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (foo))
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-autocompile argument to disable.
;;; compiling ./foo.scm
;;; compiled /home/ludo/.cache/guile/ccache/2.0-0.P-LE-8/home/ludo/src/nixpkgs/foo.scm.go
scheme@(guile-user)> (use-modules (foo eval))
;;; compiling ./foo/eval.scm
;;; compiled /home/ludo/.cache/guile/ccache/2.0-0.P-LE-8/home/ludo/src/nixpkgs/foo/eval.scm.go
scheme@(guile-user)> 

$ ./result/bin/guile -L .
guile> (use-modules (foo))
guile> (use-modules (foo eval))
ERROR: In procedure struct-vtable:
ERROR: Wrong type argument in position 1 (expecting struct): #<primitive-procedure eval>
ABORT: (wrong-type-arg)
guile> (version)
$1 = "1.8.7"
--8<---------------cut here---------------end--------------->8---

Fishy...

Thanks,
Ludo’.

Re: %module-public-interface

[Andy Wingo]

Hi Ian,

On Fri 02 Apr 2010 02:11, Ian Hulin <ian@hulin.org.uk> writes:

> On 30/03/10 22:52, Ludovic � wrote:
>>
>> Lilypond does:
>>
>> --8<---------------cut here---------------start------------->8---
>>        mod = scm_call_0 (maker);
>>        scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>>                           mod);
>> --8<---------------cut here---------------end--------------->8---
>>
>> Solution: do something like:
>>
>> --8<---------------cut here---------------start------------->8---
>> #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
>>    scm_set_module_public_interface_x (mod, mod);
>> #else
>>    scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>>                       mod);
>> #endif
>> --8<---------------cut here---------------end--------------->8---
>>
>> (We just need to add that function.)

As it appears here that you are trying to export everything from that
module (in a somewhat incorrect formulation -- I can explain if you
like), and that seems to be a sort of pattern, I'd suggest that instead
we offer a module-export-all! function. Here is some code to provide
such a function for pre-2.0 guile:

    (cond-expand
      ((not guile-2)
       (define (module-export-all! mod)
         (define (fresh-interface!)
           (let ((iface (make-module)))
             (set-module-name! iface (module-name mod))
             ;; for guile 2: (set-module-version! iface (module-version mod))
             (set-module-kind! iface 'interface)
             (set-module-public-interface! mod iface)
             iface))
         (let ((iface (or (module-public-interface mod)
                          (fresh-interface!))))
           (set-module-obarray! iface (module-obarray mod))))))

Use that to export all bindings instead. As it is, there are some shims
for %module-public-interface hackery to keep on working if deprecated
code is compiled in, but you should migrate to calling
module-export-all!, I think.

Then your C code would unconditionally:

   scm_call_1 (scm_variable_ref (module_export_all_var), mod);

Regards,

Andy
-- 
http://wingolog.org/

Re: %module-public-interface

[Ian Hulin]

Hi Andy,

On 27/04/10 21:34, Andy Wingo wrote:
> Hi Ian,
>
> On Fri 02 Apr 2010 02:11, Ian Hulin<ian@hulin.org.uk>  writes:
>
>> On 30/03/10 22:52, Ludovic � wrote:
>>>
>>> Lilypond does:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>>         mod = scm_call_0 (maker);
>>>         scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>>>                            mod);
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> Solution: do something like:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> #ifdef HAVE_SCM_SET_MODULE_PUBLIC_INTERFACE_X
>>>     scm_set_module_public_interface_x (mod, mod);
>>> #else
>>>     scm_module_define (mod, ly_symbol2scm ("%module-public-interface"),
>>>                        mod);
>>> #endif
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> (We just need to add that function.)
>
> As it appears here that you are trying to export everything from that
> module (in a somewhat incorrect formulation -- I can explain if you
> like), and that seems to be a sort of pattern, I'd suggest that instead
> we offer a module-export-all! function. Here is some code to provide
> such a function for pre-2.0 guile:
>
>      (cond-expand
>        ((not guile-2)
>         (define (module-export-all! mod)
>           (define (fresh-interface!)
>             (let ((iface (make-module)))
>               (set-module-name! iface (module-name mod))
>               ;; for guile 2: (set-module-version! iface (module-version mod))
>               (set-module-kind! iface 'interface)
>               (set-module-public-interface! mod iface)
>               iface))
>           (let ((iface (or (module-public-interface mod)
>                            (fresh-interface!))))
>             (set-module-obarray! iface (module-obarray mod))))))
>
> Use that to export all bindings instead. As it is, there are some shims
> for %module-public-interface hackery to keep on working if deprecated
> code is compiled in, but you should migrate to calling
> module-export-all!, I think.
>
> Then your C code would unconditionally:
>
>     scm_call_1 (scm_variable_ref (module_export_all_var), mod);
>
> Regards,
>
> Andy

Lilypond currently has a patch submitted to use your suggested guile 
code to avoid using the reference to %module-public-interface in 
Lilypond C++ code.

Please can you confirm that module-export-all! will be supplied in Guile 
V2.0.

Cheers,
Ian Hulin

Re: %module-public-interface

[Andy Wingo]

On Sat 15 May 2010 22:32, Ian Hulin <ian@hulin.org.uk> writes:

> Please can you confirm that module-export-all! will be supplied in Guile
> V2.0.

Yep, it's in git.

Cheers,

Andy
-- 
http://wingolog.org/