Zankoku-Okuno / octopus

A highly-dynamic language inspired by Kernel, Javascript, Clojure, Arc and science.
GNU General Public License v3.0
41 stars 1 forks source link

Where to start? #1

Open alexanderkyte opened 10 years ago

alexanderkyte commented 10 years ago

I've seen interest and I'm sure that many passively want to get involved. I do, personally. Can we have a triage of the goals for the next release?

Zankoku-Okuno commented 10 years ago

I'm actually really surprised to have interest so quickly, which is awesome, but I thought I'd have a bit of time to get more built. There's that TODO file, but it's likely inscrutable, being just personal notes. I was just about to fall asleep, but I'll give a quick idea of what I think is important.

In each section, more important things are further up, roughly. The parser and interpreter sections are the ones I'm focusing on; I'm particularly avoiding performance for now. If an item ends in a question-mark, I haven't decided whether the feature is truly useful.

Since people are actually looking, the biggest item is probably a quick driver that can interpret a file passed on the command line. An interactive REPL would be nice, too, but more complex. Another big thing is implementing letrec sugar. Since scope/environments are immutable, recursive functions would have to be defined using a fixpoint operator, and that's annoying, especially for mutual recursion; a letrec statement would simply desugar out into the appropriate fixpoint.

There are plenty of smaller things can use some tender, loving care: in particular I'm thinking primitive data types and operations. I'll push a list of the core primitives soon, along with a checklist for implementing one fully. It'd be nice to write some Octopus for things that keep recurring: curried vau, lambda, __let__, __modify__, ... Most of that should be pretty straightforward. The other thing is documentation: esp. a user guide and a small-step semantics.

All that said, I pretty much am using my head to know what I'm doing. This basically means I'm going hard after the big stuff already, so to avoid duplication of work, I might advise working on those smaller elements I mentioned.

And, now that I know I'm not the only person who cares, I'll actually be responsive to issues. Post any questions, clarifications, ideas, and whatever in the issues. I've got no problem with having tons of issues around, even if they simply end up as fodder for user guides.

I hope that gives some direction to people out there looking to contribute, or if not, then yell at me more here.

Zankoku-Okuno commented 10 years ago

New information: at least there's a driver to interpret files, which at least means it's easy to write/run octopus code now.

The best thing to do now, for anyone unsure about how to contribute to the Haskell source, is to write Octopus code. Obviously, we'll need a rich standard library (nice IO, common functional code, manipulate sequences). Further, writing and running Octopus programs should shake loose bugs in the interpreter, as well as highlight issues that might need some design overhaul or else turn into documentation.

I would like to release an Octopus standard library under a permissive license. I haven't decided on a particular one yet, though, so I'm open to input before we end up in licensing hell.

For contributing to the interpreter itself, there's now a file development_stages that outlines the big milestones. Again, it's still a matter of I know how to do it, so open an issue before starting and I'll dump my ideas at you.