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.
Hi,
first, I recommend grabbing tomorrowās build .2503, as a lot has improved Mercury side this week that will be in the build.
Enabling Temlates
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).
Using Templates
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.
Importing Projects
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) .elements
project.
Best use case for this, though, is to see how much is still missing, at this stage
Platform Support
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.
IDE Smarts
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
Visual Studio
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.
Feedback appreciated
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
null
for 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!
āmarc