guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Auto compile from many different languages that interoperates with g


From: William ML Leslie
Subject: Re: Auto compile from many different languages that interoperates with guile
Date: Fri, 8 Sep 2017 11:39:25 +1000

On 2 September 2017 at 06:45, Stefan Israelsson Tampe
<address@hidden> wrote:
> form is either specified or current-language and what I propose is to add a
> knob that enables another version of the default for from e.g. something
> like the following.
>
> (define %extension-map '((("py" "python") python) ((("pl" "prolog") prolog)
> (("scm") scheme)))
> (define %use-extension-map #f)
> (define (default-from-file file)
>   (define default (current-language))
>   (if %use-extension-map
>        (let* ((ext   (get-extension file))
>                (lang  (find-language ext %extension-map)))
>            (if lang lang default))))
>

...

> I think that we already have variables that discovers the source files that
> guile can compile and I don't think that we should get name clashes as long
> as we use the prefix (languge prolog module) as a prefix for modules in
> other languages than scheme.
>
> WDYT

It's really nice that you are thinking about this.  Thank you for
suggesting one direction to move in.

I think python's own mechanism for having different relationships
between the module requested and where it is drawn from is quite
elegant.  In your solution you use the current language to favor a
list of file extensions over others, but I think you will also may
want to have different search paths per extension as well as different
module search algorithms and compile-time module generation.  Some big
python modules find out the ideal implementation for your system and
then replace themselves in the module list, for example, depending on
whether certain FFI modules are available or what operating system we
are running on.

The mechanism for doing this in python is a list of ``importers``.
Importers are tried in order and asked if they can provide the package
with a certain name.  If they can, they return a loader which can load
that package.  In a polyglot environment, it would be reasonable for
each language to have its own importer in the shared importer list,
and also have each language order its own importers first when that
language is making the initial request.

https://docs.python.org/3/library/importlib.html#module-importlib

It is an open question in my mind as to how dynamic the module search
system should be.  At the extreme end you have languages like TCL
which scare me a bit.  Similarly python had some great potential with
setuptools' ``require`` system to have multiple versions of a package
installed and have the application specify which version to run but it
was lacking just that last bit of tooling.  Still, I think importers
are a nice sweet spot at providing a cross-language module system.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]