Tuesday, March 28, 2006

Indexers

I had postponed any decision on Freya indexers until I could find a better model for representing name overloading in the symbol table. The original data structure was borrowed from Blue, and it was based in a clever trick: each context table contained a "group symbol" entry, which associated a name like WriteLine to the list of overloaded methods. At the same time, each of these methods was included independently. Since the context table is a kind of hash dictionary, method names were "decorated" or mangled, adding information from the parameter types.
I started with a version of Blue without indexers, and that's the reason why the symbol table only considered overloading for methods, but not for properties. There was another problem with explicit and implicit user defined conversions. The raw op_Implicit and op_Explicit methods violate one important rule in Freya and C#: they cannot be distinguished by the parameters signature! Suppose you write this in C#:
public static operator explicit double(Complex);
public static operator explicit float(Complex);
They translate to something like this:
public static double op_Explicit(Complex);
public static float op_Explicit(Complex);
Both methods have identical parameter lists, and they only differ in their return types. Of course, this is forbidden in C# and Freya... but is supported by the CLR. But the decorated parameter trick was inappropiate for representing this situation.
I have solved the problem by only including the group name for user defined conversions and indexers. Probably, there's no reason for including decorated method names in the hash table, but I won't mess right now with such a far reaching change in the compiler.
Finally, Freya has full functional indexers, following Visual Basic.NET. The reason:
  1. The VB model is the most general.
  2. Surprisingly, you can access secondary indexers from a C# application.
  3. So far, I haven't discovered any important drawback in the VB model.
I have also added lifted operators to Freya: these are automatic extensions for predefined and user operators for dealing with nullable types, and they imitate the behavior of SQL operators when they act on null values.

Labels: ,

5 Comments:

At 6:37 PM, Anonymous Anonymous said...

Disculpa que te escriba en español, pero quiero saber sobre freya, cuando este listo todo el paquete, sera una version pago¿?, habra alguna version "express"¿?, open source¿?; como sera su licenciamiento¿?, etc., etc.

Saludos

 
At 5:26 PM, Blogger Ian Marteens said...

De momento, lo que hemos pensado es que, en el caso de uso más restrictivo, el compilador de línea sería siempre gratuito. Pero lo más probable es que también liberemos el código fuente: creo que la principal utilidad sería servir de punto de partida para otros proyectos. Variante que podría surgir: que apareciese un patrocinado o sponsor, pero incluso en tal caso, creo que al patrocinador le convendría la mayor publicidad posible por el producto, por lo que probablemente seguiría siendo open source.

Es casi seguro que, aparte del compilador de línea, desarrollemos "bindings" para SharpDevelop y Visual Studio 2005.

Estado actual del compilador (abril 28/2006): está implementado todo lo que nos habíamos propuesto para Freya Alpha, y algunas cosas más. Problema pendiente: hay un bug con determinados usos de tipos genéricos abiertos, pero es fácil de localizar.

Temas pendientes ahora mismo en el compilador: iteradores (necesito rutinas de manipulación de árboles más potentes), métodos anónimos (por la misma razón) e inferencia de tipos en llamadas a métodos genéricos. Probablemente empiece por esto último. Esta versión ya vendría con soporte para lambda expressions (que realmente pertenecen a C# 3.0).

El código que estamos generando es bastante bueno. No está todavía implementada la optimización global de saltos, pero incluso en esta etapa hemos "colado" algunas optimizaciones que no están en el compilador de C#. Sobre todo, estamos contentos con el compilador: es estable, es predecible (quiero decir, incluso en los casos en que se compilan características no implementadas aún)... y es rápido.

Por supuesto, escuchamos sugerencias...

 
At 3:47 PM, Anonymous Anonymous said...

La compilacion generada por freya es MSIL?, WIN32?(o como se llame la compilacion normal) o ambos.

Me alegra saber que se avanza rapidamente, en el compilador y la implementacion de nuevas caracteristicas.

Aunque para hacerte sincero, en pocas oportunidades he usado Object Pascal y las aplicaciones que he visto desarrolladas en Delphi si me han impresionado.

Talvez por la facilidad de aprendizaje es lo que me ha llevado a usar C#, aunque no lo he aprendido ni en un 50% de este.

Saludos y sigan adenlante.

 
At 8:34 PM, Anonymous Anonymous said...

Lo siento, no habia leido al inicio del blog que el lenguaje esta diseñado para dotnet v2.0 o superior :), (la costumbre de evitarse la fatiga).

Saludos.

 
At 5:18 PM, Blogger Ian Marteens said...

Es IL, por supuesto. Estamos haciendo las pruebas sólo con Windows, de momento, para simplificar y centrarnos en el compilador.

 

Post a Comment

<< Home