Yeah decimal as a native type, not the existing currency, would be nice
Esp since for financial applications currency has some issues and may not have sufficient range or precision
A native type would be nice ESP for use with a database the supports such types like MS SQL , Postgresql, Oracle or … just about every one on the planet now 
Without it DB interactions may lose precision 
Some interesting details on the compiler and libs in Xojo:
The Xojo IDE contains a plugin that contains the compiler. When Xojo builds an app, it does the same that you’d do with XojoScript: It takes the written code of the project, prepends its own libs (also written in Xojo) and then sends it all to the compiler. And since the compiler is a plugin, there are hacks where one replaces the compiler with one’s own plugin - and that plugin can then see ALL the Xojo code, including the stuff the IDE prepends.
And the IDE’s included frameworks are nothing more than those Xojo code pretexts, just encrypted so one cannot easily look into them. And the decryption key is embedded in the IDE, so with some persistency, it can be found and then you can simply decode those frameworks as well - the same code that the compiler plugin gets.
Plus, there are plugins, mostly written in C or C++. Those you cannot easily decode (only at a logical level, eg. with “Hopper Disassembler” or the more advanced IDA Pro, but there’s of course no code comments nor do you get meaningful variable and parameter names). If you use XojoScript, you could, in theory, also add your own accessors to make the plugin functions available. Over 20 years ago we had already written tools to fetch the information from plugins (they have one entry point which then returns points to tables describing the methods, classes and props it offers).
With all this knowledge, you can do a lot that the Xojo IDE can do. You still have to re-implement the GUI stuff and the runtime code that’s not coming from plugins (which is still a lot). And, of course, you can’t legally use the Xojo plugins and frameworks for you own purposes, I suppose (always depends on the local laws in the end).
Personally I haven’t used single or double precision floats in forever in .NET, I grew weary of being bitten by rounding errors where numbers can’t be precisely represented in floating point format. Decimal is slower but not enough to matter on modern hardware and it makes the problem go away. Any remaining rounding issues are under your control (maybe premature rounding when rolling up / summarizing rows or some such; the general rule is delay any rounding as long as at all possible).
But then I am a line-of-business dev, maybe I’d think differently if I were doing matrix algebra or games or something. Something were memory consumption is truly pressured by decimal’s less compact internal representation, say.
Wow, hadn’t realised how much commentary this post had received. Cool.
I think ObjoScript is a feasible replacement for Xojoscript for many use cases, after all, that’s exactly why I created it.
It’s principle advantage is that it is so much easier to debug an ObjoScript than a XojoScript - that’s literally a fundamental design choice I made when I created the VM.
I personally think extending the language and passing data between the script and the host application is a lot tidier and easier to organise than the XojoScript Context mechanism. ObjoScript’s “slot array” pasteboard (pinched from Lua) is easy to get your head around.
@Garry
re : ObjoScript: Looking for implementation advice - General - Xojo Programming Forum
some crazy folks, like me would need for syntax like
switch function_call()
case another_function_call()
case yet_another_function_call()
end switch
I’ve almost got it working (just writing unit tests). I’ve gone for the simplest approach which is essentially each value in a case evaluates itself and then compares that result with the switch value.
Your use case should work.