stdlib and prelude

[langston-barrett]

Progress on #54, requires #57, fixes #64

[langston-barrett]

Honestly, in the spirit of small, atomic changes, we could just merge this as-is and add more stuff to the prelude and stdlib in follow-up PRs.

[david-christiansen]

I like having small atomic changes :-)

I have a concern about this way of doing it. I am afraid that it ties Klister to running from the root of the repository.

Shouldn't we be using Cabal's data-files feature to arrange for the stdlib to be available, so that Klister need not be run from the source repository?

[langston-barrett]

I think that "stdlib" should be removed from Main.hs, then your KLISTERPATH determines where to find the prelude and standard library. Does that address your concern?

[langston-barrett]

I like the idea of installing the stdlib using data-files.

[david-christiansen]

I think that "stdlib" should be removed from Main.hs, then your KLISTERPATH determines where to find the prelude and standard library. Does that address your concern?

It does not!

I'd like Klister programs that use the standard library to just work, regardless of the CWD or the setting of environment variables. In other words, the Klister executable should be able to find the stdlib directory to consider as part of its search path.

I think there's three reasonable ways to achieve this:

1. Require that the stdlib be near the executable. This means that users can't stick the executable in /usr/bin, so I'm not a big fan.
2. Use Cabal's data-files feature, which will point source-local builds at the stdlib in the source tree, and installed ones at something like /usr/local/share/klister/stdlib, but it means that we basically just ignore it and let Cabal solve it. Idris does this. In this solution, it's almost like the stdlib is baked into the compiler, which I like for the simplicity of it.
3. Use XDG directories, so it's something like ~/.local/share/klister, perhaps with fallback to /usr/local/share or something. This lets people mess with their stdlib more easily.

I like 2, because the standard library is standard, and really part of the language, and should just always be there.

[gelisam]

I like having small atomic changes :-)

me too! large changes take me forever to review (sorry it's taking me so long)

[david-christiansen]

One further issue to think of: with KLISTERPATH, I can break a library by adding a local file with a name that conflicts. The import in the library, which may be a purely internal thing, might become ambiguous with something I've just created.

What about resolving ambiguities thusly: first, check for adjacent files with the given name. Then, check for stdlib. Only after that, fall back on KLISTERPATH.

Or we could indicate these situations by expanding the concrete syntax of module paths a la Racket.

[langston-barrett]

What about resolving ambiguities thusly: first, check for adjacent files with the given name. Then, check for stdlib. Only after that, fall back on KLISTERPATH.

I like this! Eventually, we could also have logical module paths like Haskell or Coq, rather than a flat namespace. I think that would complement the search order.

I will make the change to use Cabal data files before merging.

[langston-barrett]

I think there's three reasonable ways to achieve this:

One other way (maybe this fell outside of "reasonable" 😄) would be to bake the standard library into the Klister executable using Template Haskell. This has the advantage of always "just working" for the user, and has some performance advantages (no need to touch the filesystem, do expansion, nor parse when importing a stdlib module).

[langston-barrett]

Use Cabal's data-files feature, which will point source-local builds at the stdlib in the source tree, and installed ones at something like /usr/local/share/klister/stdlib, but it means that we basically just ignore it and let Cabal solve it. Idris does this. In this solution, it's almost like the stdlib is baked into the compiler, which I like for the simplicity of it.

For precedent on this approach, we can look to Cryptol: https://github.com/GaloisInc/cryptol/blob/7e841e915f34a21bbfad67070c7338662ac28601/cryptol.cabal

[david-christiansen]

I think this looks good!