Was asked by Marc (via Twitter) to start a public post here so that he could give me some guidance on getting started (and what the caveats are) with Mercury.
first, I recommend grabbing tomorrow’s build .2503, as a lot has improved Mercury side this week that will be in the build.
In terms of getting going, first, I there’s a secret flag you can set to enable Mercury in Fire and Water (it really just affects whether project templates are visible; you can open existing Mercury Projects (and use the importer) without that flag.
For Water (Windows) set the following registry string value: (The Water key should already be there and have a few other settings, if you started Water at least once)
HKCU\Software\RemObjects Software\Elements\Water Mercury = True
For Fire (Mac) call this in Terminal:
defaults write com.remobjects.Fire Mercury -bool YES
to set the same flag. Restart Fire or Water, and Mercury should show as sixth language choice in the Welcome screen (as of 2503) and in the New Project dialog (in earlier builds too).
There’s a few templates (huge subset of what’s there for the other languages, for now), but on the plus side, most of them should compile and work. I recommend starting with a project from template and playing around, Most simple VB syntaxes will work, but many things don’t yet — so if you get obscure errors (a) let us know, but (b) try working around the language feature that causes is.
you can import
.vbproj projects using the “File|Import Visual C# Project” menu option (which hasn’t been renamed yet on purpose, since Mercury isn’t visible for most users ;). Set your expectations though — virtually any non-trivial .NET project will use features that don’t work yet, so don’t expect your existing VB projects to just compile after import (yet). That said, feedback on the import progress itself is appreciated; it should handle most projects well, port most settings, etc, and give you a workable (if not compiling)
Best use case for this, though, is to see how much is still missing, at this stage
keep in mind, only the language is new, the backing for all the platforms is solid and used by the other 5 shipping languages. So while you’ll run into issues with the compiler not understanding a given VB syntax, if the compiler does understand the code you write, it should work on all the platforms, not just .NET.
Most of them don’t work yet, i.e. no Code Completion, Go to Definition etc.
It’s a just a matter of getting those hooked up, and the IDE smarts team has been busy on other fronts, so once we do, all the features available for the other languages will fall in place; just to set expectations that right now you’ll get “nothing to complete” or worse
While eventually Mercury, like all the languages, will work in VS, right now our focus (aside form the compiler side) has been own getting things set up in Fire and Water, our own IDEs. You’ll find no templates in VS yet. existing Mercury projects will open and build in VS, but (while I haven’t even tried yet) I’d expect weirdness, for example because VS also hosts VB itself, and that will be competing for the file .vb extension (which we deal with for
.cs, but don’t yet for
.vb), but also for other things. Long story short, stick to Water (or Fire, if you’re on Mac — even better ;)) for now.
that said, all feedback is appreciated. But remember it’s early times; I expect it will be a few more weeks (or more) for 99% c common use VB syntax coverage. (and more after that, for adjusting to VB semantics.
Syntax vs. Semantics
Speaking of which: we’re looking at project Mercury in (roughly) three phases. Some of the work will overlap (i.e. some phase two or three stuff is already done, while lots of phase one stuff is not):
- VB Syntax: make the compiler understand the while VB syntax.
- VB Semantics: VB code behaves differently than, say, C# code that “looks the same”. For example, how the “/” operator works on Integers, or how “Nothing” behaves different than
nullfor value types. Namespaces behave slightly different. etc.
Phase 1 is about understanding the syntax, and getting it into our existing compiler’s syntax tree. essentially it’ll behave “like C# or Oxygene or…”, once understood. Phase 2 is to adjust to how things in VB mean something slightly different than they would in the other languages (one example given above,
Nothing is already handled, another
/ isn’t yet.
3/4 will equal
0 until it does).
- Adding our own features and feature requests form VBLang (again, some come for free coz “thats his our compiler already does it”, some are already done explicitly, others will be implemented over the next twenty-five years, if all goes well and we’re all still alive then ;).
That’s it from me for now thanx for reading, and happy playing around!