The syntax of accessing static elements

Until now, I didn’t realize how twisted is the history of design of such little feature. In C++ you can access static elements from an instance or a type:

my_obj.InstanceField;
my_obj.StaticField;
MyType::StaticField;

Not bad, but of course Java guys had to simplify things:

my_obj.InstanceField;
my_obj.StaticField;
MyType.StaticField;

C# designers noticed there are too many dots here, and there is too little difference between the first two calls so… they removed external access to type element from an instance. The only options available are:

my_obj.InstanceField;
MyType.StaticField;

And this is the worst choice you could make, because sometimes all you have is an instance (object) and you have to jump through some hoops just to get the type of instance.

Skila brings sanity back:

my_obj.InstanceField;
my_obj::StaticField;
MyType.StaticField;

Such syntax is consistent with accessing namespace elements (Skila borrows it from C#, not C++) and it also improves readability — when you access an element via an instance by looking at next symbol (dot vs. colon) you can say whether it is a type or an instance element. One can think of a dot as the same level access (type to type, instance to instance) while double colon serves as cross level access (instance to type).

Advertisement

From goal-driven execution to macros

I keep reading how goal-driven execution model looks like, and while I really like natural feel of such condition:

if (a < b < c)

yesterday I found the piece of code which put me off. Consider printing out the just-read line in Icon:

write(read())

When read hits the EOF it fails, and thus entire chain of expressions fails — here it means write won’t be called. Let’s say you would like to catch the content of the line nevertheless, so you do a little rewrite:

line := read()
write(line)

OK, we have 2 lines, but the code basically does the same thing… Wait, it does not. It is not even close. Now when read hits the EOF the chain of expressions ends at the assignment, so it will be omitted and line will keep its previous value. Since the second line is completely unrelated it will be executed with the old line value.

Sure, I am surprised, and maybe part of the surprise is because I am not used to the way Icon works. But I think transparency of adding temporary objects to keep intermediate results is pretty fundamental concept, and Icon breaks it — something I cannot like.

From that point there are two approaches — give up or design improved goal-driven model (it might the same path though).

As for giving up I went back to my old idea of returning tuple — pair of function outcome and error:

if ((success:@,value) = dict["hello"]).success then
  // we have direct access to value
  // success is dropped

The syntax has a lot to be desired, so how about adding when construct which could handle exactly such cases:

when value = dict["hello"] then
  // we have direct access to value

This would be syntactic sugar only — pure internal rewrite to the if presented above.

And then it struck me — forget about Lisp homoiconicity, uniformity stupid! Lispers have to struggle with ugly syntax:

(if (= 4 (+ 2 2)) (...

instead of clean “syntax for the masses”:

if 4 = 2+2 then...

but Lisp syntax is uniform, and because of that Lispers don’t have to wait for anyone to bring new construct to the language. They add their when whenever they like — it blends in perfectly.

On the other hand in C-derivatives all you have is function-like expansion, you cannot add another for or while. Any attempt to bring Lisp-macro to C world would require allowing the user to alter the grammar of the language.

I didn’t solve anything with goal-driven model — instead I added yet another puzzle for myself. What to sacrifice in the design to bring power of macros to Skila?

If you find this topic interesting, more readings for you — The Nature of Lisp, Homoiconicity isn’t the point and Lisp: It’s Not About Macros, It’s About Read.

Fragments — multi-syntax language?

As an avid reader of old Joel on Software blog I am fully aware of the complain actually any developer can make:

They [people who don’t Get Things Done] will say, “Spreadsheets are really just a special case of programming language,” and then go off for a week and write a thrilling, brilliant whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful.

Quoted from: The Guerrilla Guide to Interviewing.

I would like to be useful but after tinkering with syntax for collections I realized that maybe it is wrong path — one reason is I have only limited ASCII set so it is hard to satisfy all expressions I like to have and make them look nice at the same time. The other is if Skila is supposed to be really multi-purpose language can one syntax fit all the needs? Maybe another approach is required — one language, multiple syntaxes (one could think of the analogy of Java world — one byte code, multiple languages and thus multiple syntaxes).

I am not the first one with this idea, take for example TeX with its environments, once you start math mode all the symbols are treated differently than in the main block. In programming language it might pay off, because when writing general code you would like to be more self explanatory:

1/Math.Pow(x,2.0)

But if you have a function which does only heavy mathematical computation it could be more useful to make a switch:

#math
1/x^2
#end math

Who knows? It is an odd idea, but could be a right vehicle if you would like to have the same semantics but different syntax for given domain, you could say inner DSL.

Heavy lifting with interfaces

Once I touched the interfaces subject it seems the time it was sufficient to change a syntax a bit to make some progress passed away — this weekend I finished overloading, next time I plan to tackle overriding.

I barely had time to make minor adjustments:

• interface name has to start with capital letter “I” (it is a requirement, not a convention),
• the root type in Skila is “IObject”,
• there is multiple type inheritance (one class + multiple interfaces),
• I reversed and shortened Ruby syntax for mutators — “x!ChangeMe()” instead “x.ChangeMe!()”,
• and I made “Void” result type optional when declaring or defining a function — so it is more like Pascal procedure.

Once I deal with interfaces I have to redo almost entire backend — so far I relied on PHP classes but I think this won’t pay off. First of all PHP has only virtual methods, so it is a dead end for me no matter how I look at it. The second reason is JavaScript — its object model is so different, that sooner or later I would have to find common denominator among backend languages to save my time. I think I should be safe with using just structures, standalone functions and custom dispatcher.