Member access syntax: dots, brackets, and functions

I've spent some time thinking about common alternative syntaxes for accessing object members. By members, I mean methods or fields or whatever. For example, we have the struct dot syntax:

person.age
array.length

And so on. C++ extended C to use the same syntax for method calls:

person.age() or person.getAge()
array.length()
pen.moveTo(x, y)

Languages like Eiffel, Ruby, or Fan that treat all method calls as abstract messages don't distinguish between field access and method calls.

Anyway, then we have array or hashtable access syntax, a different kind of membership:

persons[4]
properties["background"]

And languages like JavaScript unify the two; properties.background and properties["background"] mean the same thing. There's some nicety to that.

But I'm working through a series of issues that will eventually get tangled. First, I need to go back to C. I can abstract member access there, too:

age(person)
length(array)
moveTo(pen, x, y)

I'll pretend to have those namespaced for the moment (since otherwise in C they'd have uglier names), and if I have dynamic dispatch on the first (or more) arguments, this syntax could have the same meaning as virtual methods in C++ or Java or whatnot. For example, MATLAB can do OOP method dispatch with standard function call syntax.

So the syntax question becomes do you like nested function calls or postfix member dot access? I think the postfix (or somewhat infix) C++ style is easier to understand:

toUpper(firstName(person)) vs.
person.firstName.toUpper

The chain is just easier to read. And apparently the C# folks thought so enough that they introduced extension methods. A semi-complicated way of allowing dot chain syntax. Why not just make a language such that both syntaxes are equivalent?

One reservation. Here's that tangle to which I was referring. Lets look at arrays again. Why do we really need a separate array access syntax vs. function call syntax? An array is just a function that hardcodes the responses, in one way of looking at it. So, like Scala or MATLAB, we could make them the same:

persons(4) vs.
persons[4]

And that frees up brackets for other uses (like generics in Scala). But, if like JavaScript, we consider struct membership and array-ish access to be the same, then 'persons[4]' is the same as 'persons.4', and that would be the same as '4(persons)', and all the worse if it's the same as 'persons(4)'.

So, it tells member that array/hashtable lookup should best be separate syntax from function calls. I like it ('persons[4]') as shorthand for notions like 'persons.get(4)'. I think otherwise the unification of concepts leads to entanglement.

At least, I haven't worked out another solution I like better.

Teaching Ideas: Quick Syllabus

I've been thinking about teaching ideas. I'm still rather sold on the weekly, multiple choice, open book quiz thing.

I think I've also decided that the syllabus should fit in one page. I'd love to get to real content even the first lecture. And the first quiz should include questions about the syllabus.

Unrelated question: Could it possibly be easier to introduce Python and then teach Java in one semester than just to jump directly into Java? Maybe for some people. Not sure I'd be that brave (or be able to get approval) to try it out, though.

I do hope to get the chance to teach soon.

Tamarin Nanojit

I sometimes get a hankerin' for programming languages. And I love script-style execution and high speed. I also love fast start-up and low memory consumption. Both of those points are making me more and more shy of the JVM.

So, how do you get your hands on a well-maintained cross-platform JIT? Maybe Nanojit (used by Tamarin and therefore Flash; also used by Firefox 3.5's TraceMonkey) is a good choice. Looks small and fast. Maybe even tasty. Something to keep in mind perhaps.

Tamarin also includes a garbage collector, as a related morsel. Here's hoping it's all thread-safe.

Again, just notes for the future.

Parameterized Subtasks

I've been studying logical planning and hierarchical reinforcement learning. It's common to see parameterized subtasks. For example, "grab the apple" vs. "grab the box". Those could be seen as function call "grab(apple)" and grab(box)".

Some of the logical systems manage to deal with parameterized tasks really as parameters, using some strategy for plugging in possible argument values. But not all. It's easier to look through the options if you just instantiate every possible case (or at least the relevant cases???). So instead of the general "grab(x)", you deal with "grab(apple)" and "grab(box)" as individual cases.

All of the reinforcement learning algorithms I've seen so far deal with it this way (instantiating each individual case). But it's hard to read every paper. Maybe I just haven't seen the right papers yet. Anyway, depending on the representation of the arguments, it seems like you lose a lot of ability to learn general concepts by learning each of the instantiations from scratch.

I also wonder about genetic programming. Do they generate parameterized functions there? Or do they usually just generate lower-level constructs?

LDS General Conference

The 179th Semiannual General Conference of the Church of Jesus Christ of Latter-day Saints is this Saturday and Sunday (October 3-4). It's a chance to receive guidance from living prophets, apostles, and others chosen by Christ. (For those of you who aren't familiar with Mormonism, yes, I meant what I said.) Anyway, you can watch most of it online.

Sadly not available for Linux (or is there some way to view or listen to Windows Media?). We've viewed byu.tv streams on Mac and Windows before. It's usually high quality video, even if the interface on the site is quirky.

Anyway, I highly recommend tuning in if you get the chance. Don't expect raw entertainment, though. It's a rather formal occasion.