Platform-specific import types


#1

A discussion we’re currently having around our JVM implementation https://github.com/travisbrown/dhallj is how to handle imports from the JVM classpath. When running on the JVM you basically have two parallel filesystems - the local filesystem and the classpath and imports are potentially ambiguous between the two.

We’ve thought of a few options for solving this and thought we’d seek feedback here.

Option 1: a (very small) extension to the spec

We would allow the user to write let import = cp:/absolute/path/to/import in ... This uses very similar syntax to env imports and requires the user to specify an absolute path to avoid classloader-related ambiguity. I believe the semantics would be pretty much the same as an absolute path local import (including referential sanity), just with a different mechanism for resolving the content of the file.

Option 2

No extension to the spec. We would require the user to pass some kind of discriminating function
prefix : Path -> FileSystem Obvious advantage is that it doesn’t require extending the spec. Disadvantages are the user experience and the fact that it doesn’t really help you if the prefixes are the same on both local and classpath filesystems (unlikely though this may be!)

Option 3

Something else we have’t thought of! Suggestions?


#2

My gut feeling is that option 1 is better here. It doesn’t sit well with me having the same syntax for two different kinds of import, and then using some hack later on to actually decide what kind of import it really is.

Note that you don’t need to change the spec to allow this: I think a conforming implementation can have extensions, such as this one, which would otherwise be a syntax error. But it doesn’t make sense for non-JVM implementations to support classpath imports.


#3

I’d also lean towards Option 1 (except with the minor suggestion to use classpath for the scheme). The main reason why is that code written to use the classpath import can be made compatible with non-JVM implementations by resolving the imports (i.e. like running the code through dhall resolve)

Another thing that will help is to treat the imports as “local” (for the purpose of the referential sanity check), that way people won’t use them in shared packages that are imported remotely. My mental model is “local imports = application code” and “remote imports = library code”, so classifying classpath imports as local will help restrict them to application code, which will limit potential compatibility issues.


#4

For reference, there is some prior art in Spring for classpath: as a URI scheme.


#5

Many thanks for your input @Gabriel439 and @philandstuff! classpath:/... it is :slight_smile: