This document closely follows the naru programming language in a nutshell, but provides the rationale for the syntaxes and semantics.
The word naru (pronounced NAH-roo) is chosen because it is short, easy to romanize and still easy to pronounce for most persons; it does not contain a consonant cluster (which is represented as a final consonant in Korean, for example) and every syllable contains a soronant (compared to a variety of obstruents like k or t). Other than these linguistic concerns, the name was chosen almost randomly.
The word itself means a ferry in Korean (나루터 narooteo) and many verbs like “to establish” (成る) or “to fertilize” (生る) in Japanese. It is also used as a proper name of some Koreans and Japaneses. However they are obvious coincidences given the shortness of the word.
naru is never capitalized, because all four characters do not have ascenders in most fonts and thus the word looks uniform.
It is not mandatory, but the proposed extension for naru source codes (
.n) collides with some other languages (e.g. Nemerle). Until naru became sufficiently common, this precautionary step would be necessary.
The future extension is expected to supply standardized extensions that can be used with this directive.
Using newlines for separating statements is very common, except for C-like languages. Due to its friendliness only using semicolons was not an option. From languages to languages, however, the exact behavior differs significantly:
3 +won’t end the statement. There are several other places where newlines are ignored.
def followed by
a is valid (since
a is a function name and it can be preceded by newlines) but
class followed by
A is invalid (since
A is a class name and does not have such a special casing). This inconsistency is attributed to the sheer size of Ruby’s
return followed by
(a + b + c)). And most importantly, they won’t work when the postfix operator is introduced.
The rule for Haskell is intuitive, but it is clearly indentation-oriented and not appropriate for the use in naru. The rule for Python is also intuitive and does not depend on the parser (only the tokenizer needs the change). Therefore naru uses the rule for Python.
naru follows the so-called maximal munching tokenization: if some code may start with two or more tokens, the parser chooses the longest one. TODO
There are several approaches to the polymorphism: examples include the subtype polymorphism (inheritance-based OOP), the parametric polymorphism (type parameters and static parameters) and the ad-hoc polymorphism (simple overloading and type classes). Prototype-based OOP can be regarded as a special, highly dynamic variant of the subtype polymorphism.
naru supports these three kinds of polymorphism to the certain extent, but the principal approach to polymorphism is the class-based subtype polymorphism. There are several reasons to this decision:
data X = Y ... | Z; data Z = ...in Haskell. However you can bring the pattern matching into the subtype polymorphism easily.)
Note that the full support for subtype polymorphism does not necessarily mean the full support for object-oriented programming. Unlike the traditional object-oriented languages, naru does not have a strict concept of visibility and encapsulation; many use cases for them are handled by the unified scoping rules.
The concept of visibility is greatly exaggerated in object-oriented languages. It does not give an additional advantage over idioms like
privatename_. And if you want the best performance, you still need all private properties to compile the code using that class; in this regard, it is even inferior to the opaque pointer which is commonly used in C to emulate the object orientation. (The problem with the opaque pointer is, of course, that it’s not very convenient.)
Therefore naru primarily relies on the idiom for this problem, instead of the separate language feature. However this idiom is sacred; identifiers starting with
_ can be freely reorganized or moved by the compiler, so it still retains the benefits of the visibility approach.