Hey All,

So, I started a crazy project a week ago to create a new front end for the verge compiler. (That the part that parses the VC and makes something out of it, in this case, a parse tree.) Well, I've got to the point that it's working for almost everything (just a couple operators to add in) and it's producing equivalent Lua code. (There's still a lot of type- and consistency-checking to be added in.) The original intent was to replace the verge core with Lua's runtime and so run the VC that way. This would make it real easy to add cool new features because we could easily add anything we could write in Lua. Lua, of course, supports calls into and from C++ code.

Weeelll, it turns out that Lua's not an especially good choice. It supports ints, but can't support floats at the same time, so that avenue is nixed. It also has different rules about truth and falseness that don't correspond well to verge's. And the built-in arrays are all implemented as string-keyed hashes, and so would probably be slow/memory intensive for large arrays. Something like python might be a better match.

So, my question is, to those that care about verge internals: now that I have the start of a new compiler, what might we do with it? Target it to produce current verge opcodes? Target it to produce python and replace the verge core with that? Create a new VM and target that? Throw the new front end away? Any thoughts?

The front-end is written using Flex/Bison (like lex/yacc) and treecc for the resulting parse tree and operations. It's quite small, so it would be easy to retarget or, say, replace treecc with, say, a C++-based parse tree. Let me know if you'd like to take a look at the source, but I warn you it was mostly to see how feasible that approach was, not to create a beautiful implementation.

For maximum derangedness? PHP.

Why? Because it would be highly inappropriate!

RE: Lua.

Why is int/float interoperability bad, jesse? Just enable the float mode and be done with it. It's not as if floats aren't a superset of ints.

Quote:


True, but that will break a lot of old code, since 1/2 won't be 0 anymore, it'll be .5. Lua can either be "everything is a float" or "everything is an int".

Good point, Grue; this is why I'm asking for opinions. Certainly, it's mostly compliant. It seems to run VC code I've tested quite nicely (with stubs for builtins, right now.) The cool part with Lua is that it's mallable enough that you could write Lua code that looks almost like VC, too (like, with the same builtin vars and funcs.) And it could call into Lua'd VC and vice-versa.

Lua's got other troubles, though, like I mentioned (ie. no arrays). That's why I'm asking for other ideas before I put too much more work into it.

God help me, but I like Verge C.

However, my twisted tendencies are already catered for by VERGE as it stands, so don't let my preferences put you off doing something nifty-awesome :)

Er...nevermind. Pick the best language.

Oh, I see.

Actually, vergec implemented as a .NET language would let you use the .NET backend and keep vergec to a tee.

The problem is the afforementioned mono not being quite ubiquitous, and also verge becoming dependant upon runtimes.

What about TinyC, Jesse?

No, probably not.

Is Lua's arraylessness a systemic thing? No pointer-math hacks around such things?

(Yes, I know nothing about Lua in specific, I'm just tossing out idears.)

Bah, hashes-only works for backend array impl, Jesse. Just hash to sequential numeric keys!