On Fri, Sep 21, 2012 at 6:50 PM, Dan Burton <
danburt...@gmail.com> wrote:
> Other prior art in this area would have to include Clojure's leiningen[1].
> lein fills the role of cabal, but apparently also has some sort of plugin
> architecture that lets you generate a new project template with:
>
> lein new [TEMPLATE] NAME
I found this page[1] but it doesn't really give a lot of information
about the format they're using for storing the templates. But it
*seems* like it doesn't provide any kind of conditionals or user
input.
[1]
https://github.com/Raynes/lein-newnew
>
> lein is wildly popular among clojurists, but I doubt it can be easily
> adapted for Haskell use. I think that creating a command line tool on top of
> cabal that adds features like this would be the best approach. Then IDEs
> could simply invoke the correct command to generate the correct template.
Actually, I think I'd like to avoid exactly that. We're currently in a
system where everyone is creating new command line tools (myself
included) that add on behavior we want, and then IDE authors are
required to figure out the command line interface of each individual
tool. I'd be much happier if everyone (again, myself included) instead
provided libraries that, as IDE writers, we could just call. And this
isn't just an advantage for IDEs, but for *any* place where we want to
provide this functionality. Advantages to a library include:
* No concerns of users not having PATH set correctly
* Doesn't cause a problem if the user deletes this seemingly unrelated
file, or never installed it in the first place
* Much more type safety: calling an executable is the equivalent of
`[String] -> IO (ExitCode, String, String)`. I prefer meaningful type
signatures, which will refuse to compile when an API is changed.
>
> As a side note, rather than using JSON, I think Haskellers would find
> XMonad-esque Haskell syntax config files more appealing.
Why? I'm not recommending that people *edit* the JSON files, they
would be simply for serialization. It would certainly be possible to
create a tool that converts from Haskell syntax to/from JSON: it would
essentially boil down to `show . decode` and `encode . read`, but JSON
has the advantage that the libraries for dealing with it in almost
every language (include Haskell thanks to aeson) are very well
developed and mature. If someone decides to create a Visual Studio
plugin and wants to generate Haskell project templates in C#, I think
they'd be annoyed that they need to write a parser for the
XMonad-esque config file.
Michael
> --
>
>