Partilhar via

Language design for fun and profit

  • Artigo

I've always been into (programming) language design, ever since I was involved in the Dylan programming language (an effort to bring the power of Common Lisp to a mainstream audience).  In recent years, language design has been more of a hobby for me than a work-related thing, but this month a couple different language issues have converged on me.

Something I've been stressing far too much about is forward references of static resources.  In the September CTP, {StaticResource foo} can refer to a "foo" that hasn't been defined yet -- a forward reference.  And these forward references can't be resolved until a later time, when the object being referenced actually exists, this process is called back patching.  Problem is, forward references don't always work, particularly on freezables, because by the time we do the back patching, the freezable is frozen.  After much soul searching, we concluded we couldn't make forward references work without introducing some greater evil like hideous performance or bizarre component initialization rules, so we're now planning to pull support for forward references.

I also had several discussions about whether static resources should use dynamic scoping or lexical scoping.  The intention was always to make them lexical (i.e., matching the textual structure of the document rather than the runtime tree), like almost every well-designed modern programming language.  That's not actually what we've implemented, though -- what we actually have is mostly lexical, but within resource dictionaries we use dynamic scoping.  What happens is in compiled xaml at least, resources are delay-created.  And we don't evaluate the {StaticResource} until the resource is delay-created, at which time we might find a different resource with the same name.  Oops!  I'd like to fix this, although doesn't look like we'll have time to do it in beta 2.

We have a similar dynamic vs. lexical issue with names -- eg, x:Name, Storyboard.TargetName, and Binding.ElementName.  Here, we are consistently dynamic, and we plan to stay that way.  I came reluctantly to that conclusion -- I really like lexical scoping.  But the reality is it would be a pretty big change at this point, requiring numerous API and design changes, and we're trying to stop making breaking API changes not make more of them.  Plus, there's numerous places where lexical scoping doesn't mesh well with how we currently use names, including serialization and triggers (a single trigger instance is shared by multiple instantiated templates, so we can't turn the name into a pointer at parse time as is the obvious implementation of lexical scoping).  So we're looking into cleaning up some of the places where we today don't generate fields for Name'd elements, and sticking with dynamic scoping, which in any case is nicely consistent with how data binding works.

Finally, Ian Griffith has written a series of interesting posts about the new C# 3.0 features.  Some interesting stuff there, I would never have thought anonymous types would actually be useful!

Comments