Planned language modes and list of incompatibilities

[Araq]

Nimony will offer two language modes called aufbruch (there is no English word for it...) and compat. "compat" is supposed to be as compatible as possible with Nim 2 without bringing too much implementation complexity into the Nimony project. Nimony in "compat" mode might grow to become Nim version 3.

Mode compat

Even in mode compat these interoperability problems are anticipated:

• The string, seq and ref implementations are not ABI compatible with Nim 2.0.
• Due to strings' copy-on-write nature you cannot pass the result of mystring[i] to a var char parameter anymore.
• A seq cannot be cast'ed to string nor vice versa.
• Conversions from string to cstring may become more expensive as we try to get rid of the terminating zero for Nim's strings so that slicing can become cheaper.

Mode aufbruch

Mode aufbruch is the current focus of development. Here is what it offers:

• mm:atomicArc is the only memory management scheme in development.
• not nil is the default.
• The runtime is supposed to handle OOM gracefully.
• The macro system is replaced by a compiler plugin mechanism.
• Tiny standard library that only offers a couple of collection types, basic IO and some OS related primitives.

Aufbruch does not depend on exceptions:

• Array indexes are checked and proven correct at compile-time thanks to .requires and .ensures annotations.
• Integer arithmetic does saturate or wraps around or traps depending on what was requested.
• Type conversions are proven correct at compile-time.
• APIs return an ErrorCode.
• Out of memory is dealt with a unique, quirky but effective way: If a container needs to be resized
  and this resize cannot be done because the system ran out of memory, the container is kept as is
  and system.oomHandler is called. ObjectRef(...) can be tested against nil.

List of features not available

Here is what it currently lacks:

• Overloading of the () operator.
• Dirty templates.
• Identifier construction via backticks.
• Term rewriting macros.
• The range subtype.
• The effect system: No tags, no raises, no sideEffect.
• User definable pragmas.
• Closure iterators.
• The elaborate mechanism of running code at compile-time, via static or otherwise. (But arbitrary code can be run via the plugin mechanism.)

Please be assured that most of these features will be added, eventually.

[blackmius]

where i can see how requires pragma evaluated in compile time? will we need to implement guards above idx, for example simple program what echoes value from array which index is prompted via stdin.

how wide is a scope of usage? will it replace all assert calls?

[Araq]

proc outOfBounds(a: array[0..12, int]; index: int): int =
  result = a[index] # Error: Cannot prove array index operation correct

The requirements that the index is within bounds are part of the type must become part of the
signature of the proc:

proc outOfBounds(a: array[0..12, int]; index: int): int {.requires: index >= 0 and index < a.len.} =
  result = a[index]

Now this requirement propagates to the caller and potentially to the caller's caller etc until
some upper level of the call chain has to do:

let x = readInt(stdin)
if x >= 0 and x < a.len:
  call(a, a)
else:
  echo "invalid index"

[blackmius]

won't this feature lead to the user having to constantly tell the compiler that he knows what is doing? i see situations when compiler cant prove indexing where programmer relies on some invariant

[Araq]

.invariant for object fields is also planned...

[AmjadHD]

Due to strings' copy-on-write nature you cannot pass the result of mystring[i] to a var char parameter anymore.

Is this still relevant?

[Araq]

Yes. The COW here refers to string literals which we really want to have. SSO doesn't change it.

[AmjadHD]

Are literals also subject to SSO?

[Araq]

I don't know.