[Grace-core] Importing resources

[Michael Homer]

On Fri, Feb 7, 2014 at 9:55 PM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
>> Here is the system that I am semi-proposing. All existing working
>> import statements continue to have their current meaning. We instate a
>> syntactic restriction on the import paths of Grace modules: the given
>> import path may not contain a "." character (U+002e FULL STOP) after
>> the final occurrence of "/" (U+002f SOLIDUS).
>
> alternatively, how about: if the important path does not contain a
> "." character  (U+002e FULL STOP) after the final occurrence of "/" (U+002f SOLIDUS).
> then:  we interpret the string as if it had with a ".grace" postfix
This doesn't permit non-source modules like gtk or dom.
> similarly, if there's no name: prefix, we interpret it as a "load:" or "grace:" prefix.
>
> (I'm assuming the html file loader will require an http: prefix, or some distinguishing mark...
HTML should be fine; HTTP I would handle in the same way as the
package manager: import paths are conventionally schemaless absolute
URIs, and so when you install something the resources would be fetched
along with it into the local modules tree. There'd be no innate remote
retrieval - all location would go through the exact same machinery it
does for other imports and in the same way. If you're running on the
web, the same mapping can be performed and then retrieved through the
browser (if the remote server is set up appropriately).

I don't think general HTTP (or filesystem, or FTP, or Gopher) access
makes sense as part of the import machinery, or at least when it does
that's moving more into the type provider area I'm not addressing
here. Maybe it could be useful outside of that too, but it's at least
not obvious to me when it would be. Prefixes may make sense for
something like that and perhaps /^[-.a-z0-9]+:/ is reserved for such
future use. I'm not proposing to address any of that now, though.

Implicit URI access through the standard IO subsystem is different
than imports. It also needs careful thought, because it's clearly very
useful but also can be a significant potential security problem (see:
PHP).
>> There are some lingering issues with this:
>> 1) This global registry may be subject to conflict if two different
>> third-party modules both want to hook onto the same extension. Some
>> way of resolving an ambiguity may be required.
>
> or at least detecting it...
Detecting it (dynamically) isn't a problem. If there's no conflict
resolution you end up unable to use two modules with the same type
bound, or at least unable to use the resource imports you want.
>> 4) The registry introduces an ordering dependency for imports. If I
>> want to import a PNG resource as a GTK+ image, I need to have imported
>> the GTK+ module first. This may lead to errors sometimes. Note that
>> import order is already semantically important for ordinary modules.
>
> I think the Object-Capability stuff comes to the rescue here.
> Assume that modules that who want to define a rule have to say something like
>
> registry.handle("png")  with(myLoader.new)
>
> or even just registry.register( myLoader )
>
> the point is that only modules that can get to the registry can register handlers.
> (well assuming none of those modules then hand of the registry to someone else -
> and that's an easy check...)
Where do they get the registry from? They can only have imported it
(or obtained it from the prelude), which can certainly be checked, but
anyone can get hold of it without its being given to them.

The issue I was getting at is that this:
  import "logo.png" as logo
  import "gtk" as gtk
is either an error (no mapping for png) or it's got a different
behaviour for the other order of the lines (if there's a default
mapping).
> so can we load those modules first, before any others that use those handlers...?
You can enforce that people write them in that order, or at least that
all module imports come before any others. That may be enough.
-Michael