• Research Area
• Introduction
• Type System
• version 2 roadmap
• MIMUW
• Using nianio pattern in JS
• Using nianio pattern in C
• Introduction to json-ptd technology
• json-ptd specification
• PHP json-ptd validator documentation
• JavaScript json-ptd validator documentation
• JavaScript json-ptd validator

NianioLang version 2 roadmap

Things not clear in the current version

simple type

Currently sim is a byte array. sim is used to represent numbers as well. There is no clear distinction when conversion between numbers and strings should be performed. Also it is not clear whether we should treat all numbers as double. Native implementations have their own problems. In particular C implementation implements sim as variant - either string, double or int. Our initial goal was to implement Perl semantics to sim.

In version 2 we consider creating distinct variants for numbers, eg. :INT(sim) and :DOUBLE(sim) and possibly :DECIMAL(sim,precition:sim) . The only one required by implementation would be :INT.

Open questions:

• Is it allowed to index arrays by :DOUBLE
• Is it allowed to create :INT with arbitrary string.
  • What if string is not in a canonical form, eg. ‘034’ or ‘-0’.
• Is it allowed to destruct :INT(x) to x with match.
• Do we have a decimal number literal (eg. 1.23, 1E-10). What value should it create (double? decimal? what precision)
  • Should we change default decimal type from :DOUBLE to :DECIMAL
• Do we have a divide operator? Should it work with :INT type? How?
• Should we have automatic promotion from :INT to :DOUBLE on operators?
• Should string concatenation operator handle :INT or decimal types?

JS im construction and string handling

string vs. byte array

match variant elements with and without value

match (v) case :X {
} case :X(var param) {
}

How should this match be treated. Should we treat variant elements with and without value as separate entities inside match?

function return type

def f(b) {
	if (b) {
		return;
	} else {
		return 5;
	}
}

def g() {
	var x = f(true);
}

• Is it legal to return value in some branch and not return it another?
• If we do not return a value, when should this be turned into error? On access to such value? On assignment of this value?
• Should we allow silent discarding of function value. Or should this be treated as runtime error?

• Should we add discard operator, eg.:

  discard f(false);

string literals

new im format

• 3 versions - one line, multiline and pretty printed

new pretty printer

• remove unncessesary parenthesis

remove short if and for

new operators

• access hash elem as lvalue