Re: Language translation proposal 1.4

["Joshua Rosen" <rozzin at jello dot geekspace dot com>]

Jost Boekemeier writes:

> How could client specify the translator to use.  For example if client
> don't want to use "emacs-lisp" but a different translator to translate
> foo?
> 
> 
> It seems to me that the foo module above is directly coupled with the
> emacs-lisp translator.  Although it is possible to modify the
> search-path so that the module machinery can find the translator that
> client wants, modifying the load-path affects all other modules,
> because it is a global variable located in (config).
> 
> A simple fix would be to define a separate load-path per module.  But
> in general I think changing the translator into a parametric module is
> better. -- The fact that bindings exported from the translator module
> and bindings exported from foo are visible (seem to be "mixed")
> through the intermediate language environment is an artefact of the
> current module system.  In general the interface that clients of a
> parametric module see is the union of the interface of the parametric
> module + the interface of the parameter module: Ip + I.

I can appreciate the power given to the client in the
client-decides-translator model..., but there's also the implication that,
in that model, the client *must* know the language that the module is
written in, which might, most often, just be more inconvenient than useful.

If a module decides, internally, what translator to use, then modules all
`just look like modules', and using the module is simplified. I also think
that the module becomes more `reliable'--you can rewrite it in another
language and none of the software that uses it needs to be changed, because
the software using a module only sees the *interface* to the module, and
knows nothing about the implementation of the module (...and what language
a module is written in is an implementation detail).

I'm not trying to say that the client being able to load arbitrary code
through an aribitrary translator is a bad thing.... Should the
module-system include that, though? Wouldn't it be sufficient to have a
variant of (load "filename") that used arbitrary translators? Or (read
port) when translators are associated with ports?