Re: Trouble with `export'.

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> OK, I think I understand your approach, although I am not sure about the
> FORCE? import parameter.

Yeah, I should not have included it.  It was meant to provide access
to unexported bindings in a module, akin to the CL syntax
`package::name'.  But I now think this is too obscure for our current
discussion.

> > All conflicts would be reported at lookup time, not when they are
> > effectively introduced.
> 
> I see two points about this idea that I don't like:
> 
> * The need to check for conflicts at lookup time is more time consuming
>   than to do this check at definition time.  While I can not really prove
>   this statement, I base it on the assumption that you typically read a
>   definition more often than you write it.  But, this is a performance
>   issue which does not matter too much.

Yes.  There might be problems, but I imagine to use heavy caching in
the module system anyway, which might skew the picture.

> * Postponing the reporting of a conflict to a later time may leave a
>   system in a buggy state.  [...]  There are reasons for
>   compile time type checking :-)

Yes, this is a very fundamental thing to discuss.  But given that
Scheme is not statically typed, it would feel wrong to me to make the
module system statically checked.  Static checking has benefits, but
in the context of Scheme, I regard it as a additional tool used during
development.  It is not part of the language.

I agree that the module system should give reports about what it
thinks is wrong with it, but I don't think it should report real
errors, tho (in the sense that certain operations are not permitted).

> It seems to me that your main motivation is to keep the system
> comfortably usable when working interactively.  Is that right?

Yes.

> Or do you think that my point (i. e. not to define any precedence
> rules, but report any conflict as an error immediately at import or
> definition time) has principle flaws or that it is theoretically
> inferior to the less restrictive approach?

I'm not sure.  When it comes to type systems, I would say yes, static
typing is theoretically inferior to dynamic typing.  I don't know
whether that is also true for module systems, but I suspect so.

> If I am right that the main counterargument against the more
> restrictive approach is, that you assume a noticeable loss of
> convenience, we should probably think about whether this is really
> the case.  I believe that it should be possible to provide
> convenient ways to fix 'broken' imports and definitions
> interactively.

Yes, however, I wouldn't like it when the interactive ways are
different from the non-interactive ones.  You should be able to issue
`define-module', `use-module' etc statements interactively and have
them modify the module system in consistent ways.