The Nexus programming language version 0.5.0 has been released. It is
an "object-oriented, dynamically-typed, reflective programming
language", drawing from Lua and Ruby. www.nexuslang.org
> The Nexus programming language version 0.5.0 has been released. It is
> an "object-oriented, dynamically-typed, reflective programming
> language", drawing from Lua and Ruby. www.nexuslang.org
It seems very fussy about where the { and } go. So:
while (i<10)
{
++i
}
is a syntax error, but:
while (i<10) {
++i
}
works. Yet the former style of braces is used for method definitions. Also, I can't write {return n} inside an if-statement, but have to split the braces a certain way. Any special rules apply? The grammar doesn't say anything about white-space.
(BTW the screen-shot in the Getting Started..Try Me pages suggests for-loops are written as for (i; 1..n) instead of for (i in 1..n); it doesn't like that..)
On Jun 10, 1:46 pm, Nomen Nescio <nob...@dizum.com> wrote:
> > It seems very fussy about where the { and } go. So:
> Tcl does this too. Very frustrating and seemingly pointless.
Welcome to the bracing wars: stylistic arguments, and syntax
woes! ;-)
I know of two potential reasons for this (besides personal taste):
1). Emacs requires { } to be on separate lines in order to recognize
the functions as functions (for use with certain built-in key
bindings).
2). Google's Go used similar syntax because it wanted to avoid tons of
semicolons as statement terminators (a la BCPL ??), so some
terminators are implied "behind the scenes", hence the syntax
restriction of { on same line as function name.
(I'm probably describing it vaguely incorrectly, but you get the idea.)
>> Tcl does this too. Very frustrating and seemingly pointless.
> Welcome to the bracing wars: stylistic arguments, and syntax
> woes! ;-)
> I know of two potential reasons for this (besides personal taste):
> 1). Emacs requires { } to be on separate lines in order to recognize
> the functions as functions (for use with certain built-in key
> bindings).
> 2). Google's Go used similar syntax because it wanted to avoid tons of
> semicolons as statement terminators (a la BCPL ??), so some
> terminators are implied "behind the scenes", hence the syntax
> restriction of { on same line as function name.
> (I'm probably describing it vaguely incorrectly, but you get the idea.)
I don't think that is true. You could use the whitespace as separator and
then define whitespace as set of [space,tab,cr,lf].
In general, I think it is simply a leftover of linebased scanning where
linefeeds had meaning. ( vs scanning of a token stream).
It might be that Emacs default parser was linebased. In the case of GO that
is less logical, since it is so new.
