Tag Archives: types

Type unions and intersections

This is something I wanted to do from the first days of Skila, however the engine in Skila-1 was such a patchwork that it died before it was possible. Skila-3 finally has both kinds of sets:

let y *Submarine & *Plane = ••• 
let x *Submarine | *Plane = •••

The first line declares an intersection — we are making here some really super vehicle which can fly, dive and speedUp, because it has all the members of given element types.

On the other hand, the second line builds somewhat limited vehicle using a type union — we can only speedUp, because it has only common members, which are present in each of the given element type.

Is it practical in real life or is it just a fancy academia stuff? The former, the lack of set types in C# is killing me — I can mitigate the problem a little when I am getting data:

void loan<V>(V vehicle) 
  where V : Submarine, Plane

which gives me an intersection, but I am toasted when it comes to the output:

V create<V>() 
  where V : Submarine, Plane

It breaks the responsibility rule, because caller of create has to specify concrete type and inside create we have no chance to really create it (except for trivial case with default constructor).

And I have to cope with it all the time when writing wrappers for devices — I take them specifying their capabilities as constraints but I am unable to specify the capabilities of what I create (unless I am willing to create ton of interfaces — TelescopeWithThis, TelescopeWithThat).

Tagged , , ,

It

Mundane tasks are for computers, not me — I was bored with all the typing class Iterator<T> ••• and then somewhere later ••• Iterator<T>. It is current class, why do I have to repeat myself? So I added alias to current (compile time) type — It.

Tagged ,

Polishing the parser generator

The best way to get a reason for improvement is using your own program — currently I constantly switch between Skila and NLT parser generator, because every feature I add makes my work on Skila much easier.

I added types definitions, so no longer I have to cast the symbol objects in the code blocks:

types
  expression Expression;
  IDENTIFIER IdentifierSymbol;
end

With such definitions I can use symbol object “expression” and C# code will know it is of type “Expression”.

With sets and sequences I can reduce amount of rules significantly — sets:

fparam -&gt; [ r:REF s:SINK e:EXCL ]? id:IDENTIFIER 
          { new FunctionParameter(...) };

Here we see an optional set (very similar notion to regular expressions) — identifier can be preceded by “PARAM_REF” or “SINK” or “EXCLAMATION” or (set above is optional) nothing.

Once I implemented set, sequence was an obvious addition:

field -&gt; id:IDENTIFIER t:type (EQ ex:expression)?
         { new ClassField(...) };

Type can be followed by “ASSIGN” and “expression”. Unlike set it is everything (entire sequence in given order) or — in case of optional sequence, like here — nothing.

On Skila front I made some progress working on reference types (class) but finishing it will take some more time.

Tagged , , ,

Types and Void

The hierarchy of type system in Skila will be similar to Scala or C# — Object as root, and then each type inherits from the other (single-/multi-inheritance, traits, and so on — another time). I didn’t yet decided about Nothing from Scala.

Unlike C# Object provides nothing — there is no forcing developer to implement ToString (no every type has to have textual representation) or GetHashCode (not every type has to be prepared to be put in collection or even compared).

Another deviation from those two languages is “no type” type — Void. It is single type outside entire hierarchy, it has only one value — void, so for example you can write:

fun hello() : Void =
  return void;
end;

Omitting void (value) here is valid.

The reason for introducing such “no type” is annoying dichotomy in C# libraries — Func and Action come to mind first. The only reason for having two distinct families is the fact Action does not return anything (i.e. it returns void) and Func returns something. This is not an issue with Skila – you can use:

Func<Int,T>

(function with parameter of type Int, and returning some type T). If T is Void (type) then… so what? it is good type as any other.

Tagged