Vala Language Server
I’m working with a library called GNOME Vala Language Server (GVls), as a proof of concept for a server that will serve autocompletion, syntax highlighting and that kind of stuff, but found something interesting by accident.
I’ve added an interface called Client, may is not it final name, but it allows to locale a symbol in a already parsed file, along with some goodness from other interfaces and implementations, I’ll talk about in another article.
The Accident
While trying to create a in-line parser to detect if the actual word is an object or any other kind of symbol to, in the near future, propose a list of properties and methods or a list of method’s parameters, by accident Client now can parse in-line Vala code, so you push text to this Client object and a Server (the object that parse and handle Symbol collection), parse it and just add new Symbols to its collection, without any effort or parse errors for incomplete code!!!!
So now if you push the folowing text:
class Push {\n
Server now find a Push symbol representing a new Vala class. Inserting a medhod:
public void callme () {
You can find in the Server a new symbol for Push.callme method. Just no error, even if the code is not completed yet.
Vala Scripting?
Well not for now. But with this work the doors are opening. This include Genie, because it has more script suitable syntax than Vala. Any way, leave to the time and some others’ help of course.
Shouldn’t the goal at this point to be to move away from Vala for reasons of maintainability (both on the side of the programmer developing in Vala and the programmers developing the Vala toolchain) and longevity?
Previously:
https://www.bassi.io/articles/2017/02/13/on-vala/
https://worldwidemann.com/finally-terminated/
I don’t mean to throw it away entirely, but it seems that Vala would benefit greatly if it weren’t actually an attempt to implement, er… Vala. So pick some language with independent appeal and, through breaking changes, begin evolving the Vala frontend to accept the grammar of that language instead of the current Vala grammar. All else remains the same, but the surface-level details are morphed into a form that’s less likely to turn people away who are now thinking, “I’m supposed to invest my time and place my bets on an already-niche language that probably won’t even be around in 5 years? No thanks.” In this world “Vala” no longer refers to a language, but is the codename for this project that provides a backend for $LANGX integrates with GLib and GObject.
Vala really wants to be C#, so why not just *be* C#, then? Still-unresolved patent issues with .NET aside, C#-the-language isn’t the same as .NET, and patent issues with C# itself stopped being a problem 4 years ago when Roslyn became Apache 2.0. (The idea that Vala was *ever* shielded against any patent issues was pretty dubious in the first place, considering the nature of patents. You don’t get to say you’re in the clear just because you do your own thing—if your new thing also violates the patents, then it violates the patents!)
I’m not saying this as a C# programmer, either, because I’m not one. Another candidate would be Haxe, which has passionate supporters and has sufficiently shown that it’s going to be around for awhile. I have no agenda except as a person who wants to see healthy FOSS projects avoid unhealthy choices.
While I would like to response here, I wrote an Article instead.
Patent issue will require to a review to see if is real a thread. If so, then switch to Genie, will be the choice, because it uses same code base as Vala to produce for a code tree.
Healthy choices means, use the right tool and for complex projects based on GObject and with focus to be share with GObject Introspection, Vala is really the right one.
No other language out there provides the same level of productivity than Vala, to produce C GObject compatible libraries, so do applications.
Daniel, thanks writing a reply. However, I think you misunderstood what I was trying to say.
In my original message, I write that there are *not* patent concerns with Vala. The point of my message was this:
Vala’s features were heavily inspired by C#. At the time Vala was created, there were patent concerns with C#. Today, however, there are no patent concerns for implementing C#. So why continue to push the Vala language if C# (or another language) can be used?
See also: https://robert.ocallahan.org/2018/10/the-costs-of-programming-language.html
If Vala had been extremely successful—and there were many legacy projects written in Vala—then, yes, there would be a good reason to be concerned to continue supporting Vala. However, Vala today remains a very niche language. There are several dozen projects written in Vala, but it is niche. This means you will almost never encounter someone who is a Vala and wants to get involved with Gnome. (If a person is a Vala programmer, it’s almost certain that they are already involved with Gnome—they probably learned Vala *because* of Gnome.) This is a bad strategy for trying to get contributors. The number of people who will adopt a new language is small. The number of people who want to invest time into a bespoke language with a dubious future is smaller. So switching to another bespoke language (Genie) doesn’t fix this problem. Because using a bespoke language is the problem. Another strategy is to (a) pick an existing language, and (b) fix the Vala compiler to accept its grammar, (c) write your programs in that non-Vala language instead.
Consider this, too: people advocating for Gnome and FOSS ideals have finite resources. Spending those resources to recreate tooling for a new language (a secondary objective) reduces the resources available to advance the primary objective (competitive FOSS desktop). For example, in this blog post, you are explaining the progress you’ve made on the Vala language server. But did you need to? Other languages with mature, healthy ecosystems already exist and have language servers. If you didn’t have to spend time and effort on your GVLS side quest, what milestones from your original mission could you have completed instead?
GNOME is mainly C based. There where efforts to use Java and C#, even me use C#, most of this efforts has been abandoned for a while, at least that is my impression. Vala is more a macro language, because it produce C code, so you can use any library you write every where, even in any other programming language; no other language allows that so easy, even Rust, as you need to write some additional “code” to do so, in Vala do don’t need to worry about that in 98% of the cases.
Vala’s compiler has a Parser and a C code generator, leave compilation to GCC or LLVM.
Because GNOME is C based and elementary OS uses Vala, if you want to contribute to GNOME’s infrastructure you have to use C, if you want to write applications to GNOME you can use any language you choose, but Vala allows no overhead with the minimum effort and great productivity. I really want to see more useful and powerful applications for GNOME, so Vala is one of the choices.
There is no such “dubious future” in Vala, as for recent improvements on C generation. As I sed, Vala is the right tool for complex GObject/GInterface applications. If you want to use a Object Oriented Programming with no focus to GNOME, you can choose any thing out there, but if you want to use C code with/for GNOME to avoid overhead, Vala is a very productive choice.
Vala hasn’t a big company behind it, yet. Its advantage is its productivity, no other language out there provides it, so even with the lack of powerful tools, it is more productive than C and produce GNOME/GObject C code compatible, to create any amazing applications, jet libraries.
GVLS has started as a toy for me, but it may will help to find issues and opportunities on Vala, to make it even more productive. Fortunately, may effort on GVLS will not push back resources on Vala or any other project, like GDA, but will help any other in the future.
So should now be possible to write a REPL to Vala then?
Appreciate your work a lot Espinosa, Vala is missing so much a language server, luckily there are popping a lot of implementations for this.
GVls can provide that kind of things implementations, if any one would like to implement it, because you need to track start and stop of definitions across lines like using double enter after trigger a definition (like
public class), then GVls will allows you to generate a tree of definitions you can use to generate (on they fly) classes and variables, usable in your interactive environment. Resume: “It could be possible”.