Add command line option to stack script to open it in ghci instead of running it

[lehmacdj]

I'm aware that this option exists:

but I tend to want to do this while developing a script and at no other time.

It would be useful to have an option stack script --ghci so that I can start a script in GHCi from my editor tooling, but still leave the header the same, so that I can run it normally when I execute it.

I would be happy to implement this if there is interest, and I can get a little bit of help getting started with this repo if I need it.

[friedbrice]

As a proof-of-concept, I recently created a cross-platform (Windows, Linux, and Mac) tool that does something similar. You specify a resolver and your package dependencies in a comment at the top of your file, and the tool invokes Stack to either run the file as a script, load the file in GHCi (or Ghcid), or compile the file at the user's option. The intent is to make it easy for casual programmers to use Haskell for one-off tasks without needing to create a full Stack project. You can find it here: http://hackage.haskell.org/package/runhs

I wonder if it'd be worthwhile to add such a feature directly to Stack. I would rather see it there instead of as a separate tool. If I were to make a PR to add this feature to Stack, would the Stack maintainers approve (assuming, of course, that the code meets the quality standards)?

[lehmacdj]

This looks cool, but I think it would make more sense to integrate with the existing stack script functionality. That way we don't need to have two different formats for headers for files.

[friedbrice]

I agree that two formats would be less than ideal. The problem with Stack's current script implementation is that it hardcodes too much context. As you brought up, it hardcodes stack script when you'd like you load your code in GHCi. Another example is hardcoding of platform information: There's no way to run this script in Windows without changing the source code.

#!/usr/bin/env stack
-- stack script --resolver nightly --package text
{-# LANGUAGE OverloadedStrings #-}
import Data.Text.IO as T
main = T.putStrLn "Hey."

I feel the goal of any fix should address the root problem and define a single format for front matter of extra-project Haskell files that is cross-platform and cross-interpreter (repl, script, or compiler), so that the same source code could be used in any combination of those contexts. This subsumes Stacks current script implementation, so if it would suite your needs (and if the Stack devs agree) it might even make sense to add this feature and deprecate the current scripts implementation.

If that doesn't sound like it'd suite your needs, I'll create a separate issue.

[lehmacdj]

There's no way to run this script in Windows without changing the source code.

I suppose by this you are referring to the shebang. I'm pretty sure that even on windows (don't have Windows easily accessible to test though) you can run this using stack script Hey.hs if this is in a file named "Hey.hs".

In my opinion replacing the existing functionality with runhs would be a minor regression because it would forbid using it as a script interpreter on Linux, and running such a script would always require invoking runhs.

Unless of course runhs also supports being called from a shebang, in which case I suppose it would be advantageous, but the loss of backwards compatibility with existing stack scripts seems like a minor nuissance as well.

[friedbrice]

I'm pretty sure that even on windows (don't have Windows easily accessible to test though) you can run this using stack script Hey.hs if this is in a file named "Hey.hs".

I guess I was premature in saying "no way." What I meant is that it can't be made executable and then invoked at the command line, but as you pointed out, there's a way around that by invoking stack.

Since the primary goal of Stack is reproducible builds, I agree with you that we would not want to see the Stack devs remove the ability to use Stack as a script interpreter. Along those same lines, we wouldn't want them to stop parsing the existing front matter format. I think you're idea, of adding a stack script --ghci MyFile.hs CLI option is probably the way to go.

[Martinsos]

This would be great, I am trying to use Dante with stack scripts and it seems that this is what is missing to get it working: jyp/dante#165 .

@lehmacdj do you still plan to make a PR for this? I would love to help or maybe even do it on my own - I am not sure how much work will this be.

[lehmacdj]

I would probably still be willing to work on this, but I would prefer to have blessing from a contributor to stack before getting started, and agreement on what the design should be.

I don’t expect this will be a terribly large amount of work.

[Martinsos]

@lehmacdj makes sense! My 2 cents: stack script --ghci (or stack script --repl) sounds completely reasonable to me.
Since it has been ~9 months since you opened this issue and no contributors have responded, I am not sure if it is reasonable to expect them to get to it soon - probably they are overwhelmed with other issues/work. Not sure what to do thought - is it polite to ping them directly? If we can't get their attention I would consider doing a PR nevertheless and hoping that PR will get more attention than just an issue. If it is not much work it should not be a huge waste in case PR never goes through.

[Martinsos]

I was just looking at support for stack scripts in haskell-language-server, and it seems they can't implement support for it until Stack adds support for running scripts in ghci (which this issue is about).

This is mentioned here: haskell/hie-bios#217 and here haskell/haskell-language-server#111.

Also interesting: in the issue above, they say that before stack repl script.hs was running the script in ghci, but now it does not any more (instead it ignores the "script" stuff and runs it as a normal module).
Maybe this was intentional, because there was no way then to run the file just as a module via stack repl (although I am not sure why would that be desirable) and it was unexpected behaviour?

Anyway, figuring this out would enable both dante and hls to work with stack scripts.

What I am not sure about is if it should be done as stack repl script.hs or stack script --ghci -> it seems that stack repl script.hs would work with hls and dante immediatelly, while stack script --ghci would need some adjusting?