Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Command Line Arguments #1

Closed
parsonsmatt opened this issue Nov 17, 2017 · 2 comments
Closed

Command Line Arguments #1

parsonsmatt opened this issue Nov 17, 2017 · 2 comments
Milestone

Comments

@parsonsmatt
Copy link
Owner

kale needs to be able to handle parsing command line arguments, implicitly.

Current strategy

Search for a data Args = Args data type. If it is not present, then we ignore it. If it is not a product type, then we should fail loudly, probably.

Extract the text of the record. So data Args = Args Int gives us Int. data Args = Args { userName :: String } is {userName :: String }. data Args = Args { fooId :: Int <?> "The Foo's ID" } gives us { fooId :: Int <?> "The Foo's ID" }.

Paste the text of the arguments to the record into the creation of that variant of the sum type. So if we have

module FooTask where

data Args = Args { userName :: String }

then the generated code should do:

data Command
  = Foo { userName :: String }

A problem with this is that any duplicate fields need to share a type.

Then, we'll need to transform the Command arguments into the Args constructor:

case cmd of
  Foo {..} -> FooTask.task FooTask.Args {..}

is probably sufficient. hooray for recordwildcards!

@parsonsmatt parsonsmatt added this to the 0.1.0 milestone Nov 17, 2017
@parsonsmatt
Copy link
Owner Author

A problem with the above implementation:

Those types might not be in scope! Suppose:

module FooTask where

import Data.Text (Text)
import qualified Data.Text.IO as Text

data Args = Args { userName :: Text }

task :: Args -> IO ()
task = Text.putStrLn . userName

When the current setup attempts to parse the value and copy it into the Task module, it won't have the types imported!

Possible fix: If we're parsing a Foo.hs that has the preproccessor enabled, then we'll be looking for Foo/Types.hs. If that file is present, we import it. End users can ensure that they reexport all the types they need in there.

@parsonsmatt
Copy link
Owner Author

this is done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant