Questions about roadmap, features, tooling

Jackson Drexler

Teaching myself stanza here and there I'm really starting to itch for things like a REPL, real time syntax-checking, and a package manager. More examples of using stanza with other languages libraries and ways to best import and work with C/C++. I want to dig in to stanza more but i'm finding that my learning is being hindered because of these tooling, serialization, and interop issues, I really want to start wrapping some libraries and using stanza for personal projects but I really need some more examples and tutorials. On another note, I have come across something that struck me as a bad fit for the language and that's access modifiers. Access modifiers, they just stick out like a sore thumb because Stanza is supposed to be free from the class based inheritance heavy OOP tradition. They really aren't needed and basically constitute inline metadata that only adds noise.Off the top of my head OCaml, Clojure( other than interop ), Python, Javascript, Rebol/Red and Erlang don't need them because they aren't class based OOP languages and neither is Stanza. I'll continue learning and hopefully i'll get to the point where i can contribute something meaningful myself. Thanks


Hi Jackson.

Thanks for the feedback. The REPL is still under development. We miss it too, since we're all Lisp hackers. So just hang tight on that feature.

Jake Russo's Stanza package for Atom has some real-time syntax-checking capabilities. You might want to give that a shot.

For using Stanza's FFI, have you checked out the FFI section in the documentation? If that is not enough, you can also work through the Tetris tutorial which has examples of very sophisticated FFI usage.

The access modifiers are similar to what is provided by OCaml and Haskell. They are important for the following scenario. Suppose you are writing a library that will be used by thousands of other packages. By declaring a function private, you are able guaranteed that you can change its signature, or remove it entirely without affecting any of the packages that depend on yours. That's a very powerful and very useful guarantee.



Jackson Drexler

I've checked the Atom tools, I think the atom packages are nice and a great start. I've looked at the FFI documentation and the Tetris tutorial which are well done I think I'm figuring it out now I just wish there were a few other examples out there.

My concern about the module system isn't that it's private by default as I can see the merit of both public/private defaults neither is it about the guarantees it gives you to change implementation details.

I think it's absolutely necessary or at least preferable to be able to control what is part of the publicly available library. My concern is that unlike for instance OCaml (which is just an example) the access/visibility modifiers preface everything else throughout the whole file even if it makes sense to break them up so you have them spread out.

Using OCaml as the example again the signature/interface is on it's own, racket simply uses (provide my-thing) letting you put it at the top of the file. Both of those can keep the code you are writing in the file and modifiers that only come into play when importing.

Some other newer languages with public/private inline marking mark in the name itself,   elixir uses defp for private instead of def and nim marks public with an asterisk at the end of names.

With significant whitespace it seems even more out of place (to me) putting an access modifier in front of your code because only some things are marked public so your defs aren't in a straight line.

I think this makes (more)sense in a class-based language where programs are shuffled into classes that are shared in various ways through inheritance because it's structural and these access modifiers are on things that are inside classes to which they belong and there are commonly a large variety of access modifiers and mutability. When you take out the Class based structural features it seems a bad fit to me.

I love the language and what you are doing, I'm more than happy with the language overall and plan to be a part of the community and contribute what i can as well. I'm just providing a differing point of view and didn't mean to go on a tirade here but i figured that if something doesn't feel right I should speak up now and then let it go because it's not my decision nor in any way a deal breaker for me.

In fact i'd like to know more about any plans you have for things like the package manager, repl, basic necessity libraries for networking/http type stuff or ... especially anything you might have to throw up on github for community involvement I might have a look at.



Thanks for sharing your opinion Jackson. It's always useful to hear other perspectives.

The public/private-modifier-system is, in a sense, completely equivalent to the export-these-symbols-system found in Scheme, Oberon, OCaml, etc. Each can be regarded as syntactic sugar for the other.

But to be honest, I'm actually a little surprised that you prefer the export-these-symbols-system over the modifier-system. Many Scheme programmers I know are a little annoyed at having to keep the list of exported symbols consistent with their definitions. I know I am. 

As far as roadmap goes, here's the rough plan so far:

  - HTTP/Networking will be handled by writing a LoStanza wrapper over a popular C sockets library. It's easily done, if maybe a little tedious, but we haven't done it yet.

  - GUI will be handled by connecting to the QT library (hopefully). 

  - There are some semantic issues to be ironed out for implementing the REPL due to Stanza being a typed language. REPL's for typed languages have traditionally taken some work to design. The current plan is to have something closer to OCaml's REPL (rather than e.g. Scheme's REPL).

  - There is kind of a package manager in place in the sense that the compiler can compile packages into separate .pkg files, and these can be stored in a system-wide location. We have plans to implement a central repository ala. CPAN or Cargo, but will need some time to do that.

So at the current point, Stanza is very young, and it's proven to us to be a very productive language, but only for projects where the ramp-up of connecting libraries is a small proportion of total implementation effort. For smaller, one-off projects/scripts, Stanza is missing libraries still that we hope to just slowly build up.