evhub
Improve Coconut tooling
I think we should have a proper linter/checker for coconut, something like flake8 for pure Python. What do you think?
That wouldn't be my first choice for a tooling effort. Coconut needs plugins for widely-used Python IDEs in order to drive adoption. Pycharm, Pydev, VSCode, maybe VS too if plugins are a thing in that world. I remember when I first starting hacking on Scala back around 2011, and "lousy tooling" was one of the main reasons you'd hear to explain why people/organizations did not choose the language. That and the slow compile speeds. Tooling quickly got a lot better but if it hadn't I could imagine Scala being as fringe as F# is today.
@eshansingh @Nexus6 All of the above are things I would like to do! Would love specific suggestions of things you would like to see. Somewhat a duplicate of #229.
@Nexus6 Well, what would those plugins do? I imagine, lint and correct Coconut code, given that is a dynamic-ish language.
@evhub Well, I think reusing other popular linters is the best bet, and just correcting them so they don't consider Coconut code to be syntax errors, and adding special checks for Coconut specially. Like maybe....
- ~~Building a rocket~~
- ~~Fighting a mummy~~
- Check whether pattern matches are actually valid
- Ensure stylistic conventions.
- Suggest places where pipelines could be used.
- Suggest places where partial functions could be used.
- Suggest replacing namedtuples with
data - Suggest places where recursion can be used (this seems tricky)
In addition, we could add a "bear" (custom linter) to a project like Coala.
What are your thoughts?
Coconut is a compiled language, and among the things an IDE plugin would do would be to compile one's code on the fly as changes are made. The program would then be immediately available for running and debugging. Which brings me to ... debugging ... a plugin would display not Python code, but Coconut code, and would support features such as setting breakpoints in Coconut code (that is to say, on lines in the .coco source, not just on the generated Python), and single-stepping through Coconut code (again, not the compiled Python). The plugin might support attaching the debugger to an already-running Coconut program. The plugin would prevent the IDE from flagging Coconut code as syntactically invalid, in contrast to, say, stock Pycharm, which will tag "foo |> map$(bar)" with a bright red error-underline. The plugin could understand not just .coco files, but entire Coconut projects and perform incremental compilation as needed. The plugin would probably support a wide variety of linting features.
I personally am not so keen on having a "nanny linter" complaining about style or pushing me to use one abstraction or another. With Python IDEs I don't want the IDE to pester me about PEP-8 issues unless I ask it to. I wouldn't want a Coconut IDE plugin nagging me to use partial functions or pipelining or composition or any other paradigm vs what I've already chosen to use. Unless I ask it to. It wouldn't be there to teach me Coconut programming, it would be there to catch the problems that I define to be problems.
I'm coming from Pycharm and Pydev and IDEA+Scala plugin and the Scala IDE (Eclipse), so my expectations are in part shaped by those tools. I've just started playing with VSCode and have a feeling that it might be a good place to start if the goal is to provide a lightweight Coconut IDE. It seems to have a lot of mindshare/enthusiasm right now and already supports a number of functional languages such as Haskell, F#, and OCaml via plugins.
@nexus6 I definitely see where you're coming from here, and it makes a lot of sense. I hadn't thought about it that way before. Thanks!
@Nexus6 Debugging based on Coconut source is definitely something that could be improved right now. Currently, the only real solution is to pass -kl (--keep-lines --line-numbers) and then use a Python debugger.
Syntax highlighting (not tagging foo |> map$(bar) with bright red underlining) is also definitely something that could be improved, but the problem there is that there are just so many different syntax highlighters--we've already got Pygments, Sublime, TextMate, Vim, Emacs--but there are so many that it's difficult to try to do all of them.
@eshansingh I think adding stuff like that as warnings that show up when --strict is used would be a good idea--it's a nice way to optionally help people learn to really use Coconut to its fullest extent. I definitely don't think that sort of stuff should show up without the flag, though.