Show HN: Octaspire Dern – Programming language
octaspire.com
octaspire.com
"This is the first language I have ever designed or implemented. There are also a lot of features not yet implemented and probably bugs not yet fixed. The interpreter is currently also just a tree walker, and not a faster bytecode vm."
Interesting approach. I suppose this makes whitespace inside square brackets significant. And quotes inside of these brackets would have to be escaped if written inside C-programs.
I took this square-bracket approach as well in my teaching language (http://akkartik.name/post/mu). Benefits:
a) Since there's distinct characters for each end, nesting strings is convenient.
b) Since there's distinct characters for each end, the need for escaping is reduced. (I reduced the need for escaping further by having a backslash escape a whole series of backslashes rather than just the very next character. That way each iteration of escaping increases a run of backslashes by one rather than doubling it.)
c) In the context of a teaching language, I found it useful to pun square brackets for function definitions and strings. That allowed me to explain this:
def factorial x:num -> result:num [
...
]
The drawback of punning square brackets for function definitions and strings is that in different contexts I want to permit or be oblivious to comments. The rule Mu's lexer uses pervasively is that if the very next character after the '[' is a newline, it's sensitive to comments when detecting nested square brackets to determine where the string ends. This only makes sense because Mu is statement-oriented; every statement is required to start on a new line, and there's no delimiter like a semi-colon to get around that.
Anyways, this is sort of an extended description of a very narrow set of design decisions. Just in case someone finds it useful.
How do you write the string with characters '\' and ']'? It seems like the natural way to write it, [\\\]], would end up being lexed as [\\\] (a string with two backslashes) followed by an unmatched string end character ']'.
Is there a way to write a string that ends with a backslash? The way `slurp_one_past_backslashes` is used seems to make that impossible.
EDIT: I thought typing a literal 0 byte might work, but apparently mu uses a different mechanism to delimit strings in memory.
If you want to construct it from scratch, strings and arrays in general are prefixed with their length. put-index on the final index would be the workaround.
x:address:array:char <- new [abc]
1000: 3
1001: 97 # a
1002: 98 # b
1003: 99 # c
The length of the array cannot be modified, only read (using instruction length). If we need a larger array we must allocate new and copy over, just like in C.
The elements of an array can be read and written using instructions index and put-index, respectively. Here's a fragment of code to make the final character of x a backslash:
len:num <- length *x
last:num <- subtract len, 1
put-index *x, last, 92 # ascii code for backslash
Is there something I'm missing that mitigates this intuition? Does this language (or, for that matter, the demo language you wrote for your class) ignore leading or trailing whitespace inside square brackets? What about excess whitespace between words (that is, whitespace beyond a single space or tab)? If so, if indeed leading/trailing/excess whitespace is collapsed inside of square bracket delimited strings, how would I create a string with leading or trailing whitespace or extra space between words if I wanted to?
Honest questions; don't mean to criticize, just eager to learn.
Interesting. Should this be available as a compiler warning in other languages?
Compilers should stick to their job: turning human readable code into efficient machine executable code with a minimum of fuss, a maximum of speed and errors where the human readable code leads to either undefined behavior or is simply incorrect.
Enforcing coding styles and documentation requirements should be left to plug-ins for your favorite CI set-up or, alternatively, to stand alone executables or scripts.
The only thing forced documentation will lead to is lots of boilerplate or blank stuff to satisfy the compiler, it will not lead to better documentation.
This is roughly the state of affairs with lots of autodoc docs, it's rare to see good documentation that has been automatically produced but it is very common to see page after page of extremely poor automatically generated documentation. Which then of course gets no love at all because after all, the documentation is already done.
/**
* Gets the thing for the ID.
*
* @param id the ID of the thing
* @return the thing
*/
Thing* getThing(int id) {
return things[id];
}