Counting the infinite sequences

Doesn’t it strike you as odd, that you can write such code in C#:

if (sequence.Any()) ...

and it is efficient as it can be, but when you rely on Count method:

if (sequence.Count() > 0) ...

you may fall into a trap of extensive computation despite you just need confirmation whether the sequence is empty or not. Well, this disparity annoyed me for a long time and all I could think of was passing somehow a predicate to Count. It is as fishy as it sounds, and it annoyed me even more.

Until the perspective changed — who said Count should count anything? Why Count should jump right away with exact answer?

Count should be lazy and it should simply return the instance of some numeric like type, say SequenceCount — that type should keep reference to the sequence, have implicit conversion to Int and — what is crucial — it should also overload comparison operators. With all those goodies you could finally write:

// Skila syntax
if (1...).count() > 0 then 
  stdOut.writeLine("not empty");
end

to see a printout after a few CPU cycles.

Now when I solved this issue I can think of general lazy evaluation design for Skila…

Advertisement

Double-edged constraints with a twist

One of the types in Skila library is generic Sequence (the counterpart of IEnumerable interface in C#). Assuming method concat is not supposed to create exactly the same type as the original one (as in Array for Array, List for List, and so on) but simply some Sequence how its signature should look like?

In C# it is defined as an extension method:

public static IEnumerable<TSource> Concat<TSource>(
	this IEnumerable<TSource> first,
	IEnumerable<TSource> second
)

Which is almost fine until you have to play with such code:

animals = cats.Select(it => (Animal)it).Concat(dogs);

Obviously it is an obstacle and those are not welcome in Skila — here is our signature:

interface Sequence<out T>
  // ~ stands for Sequence
  def concat<C>(seq ~C) ~C
    where C base T;
    ...
  end
end

Unlike C#, Skila has two-way constraints — you can say some type parameter A has to inherit from B (A is B), or A has to be inherited by B (A base B). As for concat it is enough to write:

animals = cats +++ dogs; // temporary syntax for concat operator

base constraint works for type inference as well — of course noticing that Object is base of any other type is correct, but not very productive, thus for each constraint the lowest common ancestor (LCA) is computed. Still correct and probably exactly what you would like to see:

def twist<C,D,A>(b Bool,c C,d D) A
  where 
    A base C;
    A base D;

  return b ? c : d;
end

When you absorb this let Skila infer Animal type for you:

animal = twist(true,cat,dog);

Properties — enough with monkey typing

The more I use properties in C# the more annoyed I am with repetitions. Consider such code:

private SomeType field;
public SomeType Field
{
  get { return this.field; }
  set 
  {
     // some logic with previous value
     this.field = value;
     // some logic with new value
  }
}

Triggering events, logging data in a database, you name it — this pattern occurs over and over again. And the best you can come up is writing Wrapper class and using it like here (still C#):

private Wrapper<SomeType> field = new Wrapper<SomeType>();
public SomeType Field
{
  get { return this.field.value; }
  set { this.field.value = value; }
}

Some advise the solution to this is using snippets which is hilarious idea — it is like saying that you can reduce the amount of code by typing faster. Besides I am not a monkey, so I look for the solution elsewhere.

Somewhere along AOP or Scala-like traits — I am thinking of property specialized overlays:

overlay Wrapper // implicit first generic parameter: T
  def set(value T)
    // some logic with previous value
    inner.set(value);
    // some logic with new value
  end
end

Since overlay will be mixed with property we have to connect it somehow to the already existing setter or getter — all we need is inner reference. And the usage could be reduced to this:

def field SomeType with Wrapper; 

The type of the field would be SomeType, keyword with does not change a type, it just indicates what wiring compiler should do behind the scenes.

It is just a vague idea, but it has to be done, yesterday my inner monkey wrote:

private SomeType field;
public SomeType Field
{
  get { return this.field; }
  set 
  {
     // some logic with new value
     this.field = value;
     // some logic with previous value
  }
}

So it is about time to make properties right.