Re: New module system option :duplicates

[Marius Vollmer]

Mikael Djurfeldt <address@hidden> writes:

> If I haven't missed something, there are no problems with implementing
> the current :duplicate option within the framework of new-model.text.

Ok, that is the important bit as far as I am concerned.  I'm still a
bit wary about merge-generics from a language design point of view,
but since it is an optional feature and we can support it in the
future, I don't see a problem with offering it.

> > [...]
> > Such a model can easily support an interface like
> >
> >    (define-module (foo)
> >      :use-module (blarg)
> >      :use-module ((bar) :select (mumble))  ; explicitely import mumble
> >      :use-module (baz)                   ; also imports mumble
> >                                          ; but only implicitely and
> >                                          ; since we have an explicit
> >                                          ; mumble, we won't see it
> >      :duplicates check)                  ; we expect no explicit duplicates
> 
> Do I understand this correctly in that you suggest having bindings
> with two "priority levels": "explicitly imported" = priority 1,
> "implicitly imported" = priority 2.  Only duplicate bindings with
> priority 1 causes an error (:duplicates check) while other duplicate
> pairs are resolved (at lookup-time) according to :duplicates first
> with precedence for the binding of higher priority.

Yes.

> Hmm... Isn't this a little conceptually complex?

Yeah, perhaps.  ADA and VHDL do a similar thing with their "potential
visibility" and their rules are indeed complex (I only reall about
know VHDL, tho).  After getting my head around the concept of
potential visibility, however, I find it quite intuitive.

When there are no conflicts, the rules are still very simple: you get
to see every imported binding.  However, when there are conflicts and
you have asked explicitely for one of the conflicting bindings, you
get the one you asked for.

But we can probably implement this as an option in the module system
as well, if we ever want to.  That's the basic motivation behind
new-model.text: modules should be able to implement a very rich and
hackable behavior without the compiler having to know about it.

> What is the gain of differing between "potentially imported" and
> "actually imported"?  It seems like a nice thing to be able to
> determine the set of imported bindings when the module is
> constructed.

Yes, the effect will mostly be as if the module has been fixed after
the 'define-module' statement, but while 'define-module' does its
thing, incrementally importing one set of bindings after the other,
not all information is available to resolve conflicts.  The
distinction between potentially imported and actually imported
bindings in there to support such a incremental construction of a
module in a natural way.  Also, it defines what happens when you
interactively change a module with 'use-modules', say.

> Is the aim to support the current "lazy binding" technique used in
> guile-tcltk?

No, only to support lazy resolution of naming conflicts.  In effect, a
conflict is only then reported when it actually matters and when no
resultion has been specified yet by the user.


One fundamental concept in new-model.text is that a module never
shrinks: once a binding has been found in a module, it can not be
removed or changed.  The potentially imported bindings would not be
known by the compiler and as such, could still be removed and changed.
Once the compiler asks for a binding and the module finds it among the
potentially imported bindings, it must become 'actually' imported and
can no longer change.

Imagine an interactive session like

  guile> (use-modules (graphics 2d))   ; exports make-point
  guile> (use-modules (graphics 3d))   ; also exports make-point
  guile> (define p (make-point 0 0))
  ERROR: 'make-point' is ambigous (in (graphics 2d) and (graphics 3d)).
  guile> (use-modules ((graphics 2d) :select (make-point)))
  guile> (define p (make-point 0 0))
  #<point 0 0>

Only when make-point is actually used, we check for conflicts.  Once a
resolution is provided by the user, the session can continue.

> Regarding the transition: What about making "check" the default
> duplicates handler but provide a form which the user can put in
> his/her .guile if he/she want to be backward compatible?
> 
>   (default-module-duplicates-handler 'last)

I'd rather have this the other way around.  Making '(warn last)' the
default is OK, I'd say, since it does not stop code from working.

> >   ;; merge 2d-x and 3d-x into x.  Likewise for y and z.
> >   (merge-prefix-generics (2d 3d) x y z)
> >
> > This is not much more tedious than ":duplicates merge-generics" but
> > much more precise.  No unexpected mergings are done and the remaining
> > collisions of non-generics are also dealt with in a useful way.
> 
> I like this.  However, I'd like to provide this facility *in addition*
> to giving the license to merge.

Yes, very good.

> Given that we already had `define-extended-generic' I've now added
> 
>   (define-extended-generics (x y z) #:prefix (2d: 3d:))
> 
> I chose this form because I have the feeling that we might want to
> have other additional ways of selecting the generics in the future.
> 
> Please tell me if you like your `merge-prefix-generics' better or if
> you have a third suggestion.

'define-extended-generics' is better.

> > Also, merging of generic functions might be a useful thing to do, even
> > without using the module system explicitely.
> 
> Yes.  We've had `define-extended-generic' for a while, but I have not
> come to documenting it in NEWS.  I'll fix my old sins ASAP.

Ahh! :-)  I didn't know about it indeed...

> > Does this make sense, Mikael?
> 
> Given my recent commits, I guess I have to return the question.  Do
> you think my recent additions make sense?

Yep, very much.

> The default duplicates handler is:
> 
>   (replace warn-override-core check)

I would like to have a default that works exactly like what we have
now, with additional warnings.  That way, code does not suddenly stop
working, but people get warnings and are 'encouraged' to fix their
code anyway.  Would

    (warn last)

work?  People can still use (default-module-duplicates-handler ...).

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405