Import path as absolute path to file

[dhall-lang]

Import path as absolute path to file

[Gabriella439]

@f-f: Alright, I created the relevant issues and added the "standardize me" label to track them:

standardize me

[Gabriella439]

Note that if you have a relative path within a Dhall expression it could expand out to either a filesystem path or URI depending on how the surrounding expression was imported. I'm assuming that if you had separate as Path and as URI features, you would be okay with the behavior changing (i.e. possibly rejecting the relative path literal) depending on where the expression was hosted? Maybe you would even consider that a feature (i.e. ensure that it doesn't expand out to a URI)

I'm also assuming that there would be matching Path/toText and URI/toText built-ins, too

[Gabriella439]

@f-f: What I propose is to create a ticket for each of the missing features to standardize and a label like "To be standardized" to use both for those issues and also other issues in the pipeline (such as toMap)

[Gabriella439]

Another way to approach this could be for as Location to instead return a union of a type like this:

someImport as Location : < Local : Text | Remote : Text | Environment : Text | Missing >

... that way you don't need any additional types/conversion-functions and code can choose to handle as many cases as the tool supports. In other words, if a tool can handle both Local and Remote paths then it can implement support for that.

[ocharles]

I guess if https://hackage.haskell.org/package/dhall-1.8.2/docs/Dhall-Parser.html exported pathParser :: Parser Path I could use exprA (Left <$> absoluteFileParser <|> Right <$> pathParser), and then a custom stage to expand absolute file paths into text literals or imports as necessary. Still, seems like it could be common enough for Dhall to learn this.

[Gabriella439]

Yeah, this seems like a good idea to me and I think it would be simple to standardize and implement because that information already exists under the hood. My only suggestion is to wait until I finish the import semantics standardization (ETA: ~1 month at current rate) so that this can be proposed as a diff to that standard

Also, would this still have type Text or did you intend this to return a new FilePath type?

Also, one minor suggestion I have is to shorten the name to as Path

[ocharles]

Cool, I'm happy to wait - no rush on my side. A FilePath type seems more sensible, assuming that http://foo as Path doesn't type check. Could do as URI and have local paths expand to absolute file:/// paths too. Was mostly spit-balling though, I have no real feelings on the colour of the bike shed.

[Gabriella439]

Or perhaps I should use as File instead of as Path to make it clear that it comes from the filesystem, whereas Path can be the more general term for something that could be either a URI or File

[ocharles]

as File seems to imply reading as raw bytes. So we're back to FilePath 😄

[Gabriella439]

Oh yeah, good point. File would suggest reading the contents of the file, not the path to it.

[ocharles]

Another thought on this, it would be quite nice if I could have properly typed URLs for dhall-to-cabal too:

homepage = https://github.com/ocharles/dhall-to-cabal as URL

or something. Perhaps related to this.

[Gabriella439]

Yeah, I was assuming that this would include as URL, too

[kirelagin]

@ocharles @gromakovsky Do you mind taking a quick look at dhall-lang/dhall-haskell#449?

[ocharles]

@kirelagin has done a great job laying the ground work here. What sections of the standard documents need to change? I tried looking for as Text, but couldn't really see it.

[Gabriella439]

@ocharles: This is because as Text has not yet been standardized because I keep forgetting to 🙂

The relevant part of the standard to change would be somewhere around here:

https://github.com/dhall-lang/dhall-lang/blob/master/standard/semantics.md#import-resolution-judgment

I can get around to it myself soon, if necessary

[ocharles]

If you can do Text, I can follow suit with URL and (File)Path.

[f-f]

@Gabriel439 related: do we have a checklist somewhere of "stuff that is implemented but needs to be standardized"? If not, let's have an umbrella-issue in dhall-lang for it

I think we are missing only:

• as Text
• multiline strings

[f-f]

It looks like we stumbled on a use-case for this one in purescript/spago#244

The problem we have there is that relative paths are included in configurations as Text. The application gets them as they were typed bby the user, but the fact that Dhall files can have relative import means that in some cases the paths will not be correct anymore. So a "relative → absolute" resolution based on the location of the Dhall file (and not on the CWD of the program) as described above would solve this

I can take a stab at standardizing this, but I have some questions:

• Are we fine with having a new Location type or should we have several, like FilePath, URI, etc. If so, why should we have more than one?
• As the PR linked above implemented, I think env:SOMEVAR as Location would cause an error right?

[Gabriella439]

I think whether or not to have two separate types comes down to whether or not we want the type of the expression to change if imported remotely vs locally.

The argument in favor of one type is that code still functions when hosted remotely vs locally (similar to the reason we support custom header forwarding and relative import resolution for remote imports).

The argument against is that code might only work for a path and break for a URL, so the type changing when imported remotely is a feature from that point of view.

[f-f]

@Gabriel439 @ocharles PR for standardizing this up in #585

[f-f]

I'll reopen this to continue discussing as AbsolutePath as detailed in #585 (comment)

[philandstuff]

This has been open for over a year. I'm going to close. If there's still a desire for as AbsolutePath, feel free to reopen or open a new issue.