This page doesn't do a good job of explaining what is interesting or unique about the language or why I might want to learn more about it. I'd suggest revising the 'About' section to try and focus more on answering those questions. Although given it's name means 'obscure language' maybe that's deliberate.
Yeah I think this was more of a fun-time hobby project than a serious candidate for the NBL. Quoting the note:
"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."
> Note that string delimiters in Dern are [ and ] and not "; this way dern code can be written inside C-programs without escaping.
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.
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 [
...
]
as a command (def) that takes some primitive arguments and a bit of text, turns it into code and adds it to the list of a computer's functions, somehow. That helps introduce students to the idea of a compiler. (Long before we delve further into it, of course.)
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.
> Every variable and function definition in Dern must be documented by a documentation string. Dern also makes sure that every formal function parameter is documented in the documentation of function definition.
Interesting. Should this be available as a compiler warning in other languages?
Definitely not. I can't imagine exploratory programming in a language that dictates overhead right from the beginning, and even later on some stuff is just too obvious to document.
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.
[+] [-] mattnewport|9 years ago|reply
[+] [-] zengid|9 years ago|reply
"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."
[+] [-] undershirt|9 years ago|reply
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.
[+] [-] akkartik|9 years ago|reply
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:
as a command (def) that takes some primitive arguments and a bit of text, turns it into code and adds it to the list of a computer's functions, somehow. That helps introduce students to the idea of a compiler. (Long before we delve further into it, of course.)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.
[+] [-] patrickmn|9 years ago|reply
Interesting. Should this be available as a compiler warning in other languages?
[+] [-] jacquesm|9 years ago|reply
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.