This post is off topic in that Mercat is not currently an IF language.
However, a number of people here have stated their interest in a VM system
like Mercat, and so may find Mercat useful as a reference (or even, heaven
forbid, use it themselves). Also, Mercat being cross-platform and
general-purpose, it could quite easily be used as an IF language provided
the appropriate libraries were written for it.
Mercat includes the following features:
* Garbage collection
* Portable binary files
* C-like syntax
* Associative arrays as a primitive type
* Real strings
* Easily expandable through a simple, fast system call interface
* Self-hosted; the compiler and assembler are written in Mercat
* Bitmap text interface
This version is a beta release. DOS (16 and 32-bit) and Linux executables
of the run-time system are provided, but the source is standard Posix C
and should compile on just about anything. The release contains the
compiler, assembler and demo programs in both source and .mo formats.
The demo programs include: paranoia, a port of the BSD game of the same
name; ME, the Mercat Editor, a full-screen editor with drop-down menus
written entirely in Mercat; and Sea Snake, a tacky action(!) game I hacked
up in a week. The last two make extensive use of the bitmap text
interface. And, of course, source for the compiler and assembler are
provided to play with.
Currently documentation is extremely limited; there's one README and the
source, and that's it.
Feedback is extremely welcome!
You can get Mercat at:
Hmmm. How about a sales pitch? I mean, portability, garbage collection and
associative arrays are good, but is that a good reason to invest in a new
You know what I'm getting at? What I'd like to see on your web site is just a
few examples showing why Mercat kicks ass.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Sales pitch. Um. Well, it's, uh, small, and, uh, simple, and... oh, I
don't know. Look, writing a sales pitch is harder than writing the thing
itself, right? Which is why I didn't do one.
Suffice to say it's really small. The compiler's not optimised, the
assembler uses five-byte opcodes when it could use two-byte ones, the
binaries are full of debug information, and the full-screen editor I wrote
in it is still only 15kB.
One thing I'm vaguely aiming at is as a future IF language. I need OO,
function pointers, and stuff like that first but it should be eminently
+- David Given ----------------+
Heh. Spoken like a true engineer. Though you ought to be able to carry on
endlessly about some esoteric point you think is really cool. ;-)
> One thing I'm vaguely aiming at is as a future IF language. I need OO,
> function pointers, and stuff like that first but it should be eminently
I could get behind that, as long as you promise to always post here for the
rest of your life and offer continual updates at six-month intervals. ;-)
I wrote a full-screen editor in it and it's 15kB? Complete with monstrous
amounts of debugging information?
>I could get behind that, as long as you promise to always post here for the
>rest of your life and offer continual updates at six-month intervals. ;-)
What do you want from me, blood? Ha! Served you right if I decided I
didn't owe you anything.
Anyway, watch this space. There will be an update out at some point and it
should become rather more usable then.
+- David Given ----------------+ A friend is someone you call to help
| Work: d...@tao.co.uk | you move. A real friend is someone
| Play: dgi...@iname.com | you call to help you move a body.
+- http://wiredsoc.ml.org/~dg -+
That's pretty cool.
> What do you want from me, blood? Ha! Served you right if I decided I
> didn't owe you anything.
> Anyway, watch this space. There will be an update out at some point and it
> should become rather more usable then.
>That's pretty cool.
It gets better --- I'm working on a new improved assembler that produces
smaller, tighter code. Current estimates indicate that it'll reduce binary
sizes by more than 50%. If I add a peephole optimiser to collapse
instructions together, and stop the compiler producing debugging
information (every time it reads a line of source it emits a LINE <n>
instruction) it'll get even smaller.
So, all we need now is the lifetime assurance that you'll never do anything
else and... ;-)