And other trivialities.
Mars is deliberately short on a lot of common features, in order to keep the language simple and manageable. This is about researching language features, not being useful, so I’m not putting in features that aren’t interesting or necessary. I may put some of these in later on, though.
Deliberately-missing features include:
Operator syntax. You have to type add(x, y) rather than x + y. This was for simplicity, but it’s pretty annoying, so I may fix it. (Equality and inequality operators are the most annoying). Similarly, there is no array syntax (array_ref(a, i) rather than a[i]).
Several primitive types.
- Char (currently all characters are just Ints, and strings are just arrays of Ints). This would be really useful because string literals could print out properly, instead of like [116, 104, 105, 115].
- Float. Mars doesn’t have floats because they’re unnecessary, but a real language would have them. Note that this might complicate things a lot, because operators like add might have to be overloaded!
- Void. A void type would be useful (for returning from functions), to avoid having all these functions returning a dummy 0 value. Would be very handy in interactive mode, to stop them from all printing “0”.
- Tuples. Tuple types ((a, b), (a, b, c), etc) would be very useful for returning multiple values from a function. Currently, the prelude provides a handful of user-defined tuple types with unfriendly syntax.
More built-ins, such as support for command-line arguments, fopen, stdin/stdout, sockets, etc. I didn’t want to make any more built-ins than necessary, because they’re really hard to maintain, especially with multiple backends. It would be better to have a foreign language interface mechanism, so users can implement their own otherwise-primitive operations.
For loops. Very annoying to do without, but I feel that while loops are enough to demonstrate the “imperative style” of programming, and for loops are a rather hefty sugar which I don’t need to support.
Break, continue, else-if.
Variadic functions, optional arguments, keyword arguments, other non-straightforward argument schemes. Definitely something I’m interested in, but one step at a time.
Exceptions. Currently error just terminates the program, with no possibility of parole.
Namespaces. For simplicity, importing a module just lumps in all the imported symbols into the one namespace, like C. Not good for engineering, but nice and simple.
Type classes or inheritance. There’s no way to have general and special types, which is fairly limiting. But not important at this stage.
Yes! Mars has everything required to support CGI scripts: stdin, stdout, and reading environment variables. It is therefore possible to write simple web apps. The library module urllib has some helper functions for writing web apps. The samples directory has an example of a CGI script. CGI scripts should run with no hassles in a web server like Apache – just drop them into the cgi-bin directory and visit them.
Unfortunately, this would require a complex widget API, and wouldn’t be possible without a foreign language interface.
Please report it using the bug tracker at http://bugs.launchpad.net/mars/. Thanks!
Presently, Mars programs can only be interpreted directly. However, I plan to compile to native code through the C or LLVM platforms. This will be done through the marsc program (which is currently fairly useless).
These are “Mars assembly” files. They aren’t actually executable and can’t be read by any program – they are designed for humans to read, so we can debug the Mars compiler.
This can happen in rare circumstances, and it’s a pretty tricky problem to solve. It should only happen at the interactive prompt – if you see this error when running normal code, please report it!
?> x = show ?> x(1) Runtime Error: show:free
This is because when show is assigned to the interpreter variable, Mars must make a decision about which version of show (which type the argument has) to load. Since you haven’t yet chosen a type, Mars chooses a version of show which produces the above error. The solution is not to assign polymorphic functions to interpreter variables (you can still call polymorphic functions on the command-line; for example, show(1) is still valid).
If you are interested in the details, see Type dictionaries.
You may see warnings under the heading “Making Mercury/os/arrayref.o”; a whole bunch of warnings of the form:
arrayref.m: In function ‘arrayref__array_pure_unsafe_resize_3_p_0’: arrayref.m:415: warning: dereferencing type-punned pointer will break strict-aliasing rules
This is because the code generated by Mercury (while correct C code) breaks GCC’s strict aliasing rules under -O2. The supplied Makefile disables this using the -fno-strict-aliasing flag. If you are compiling using mmc, you should set this yourself:
Please let me know if you see other warnings (or errors) during build.