Thursday, March 20, 2008

New slot accessors merged; future direction for Factor

The new slot accessors that I've talked about here and here have been merged into the core.

Old-style tuple slot accessors are still defined for all tuples. I will be porting code over the next few months to use the new accessors. All new code should use the new accessors. The old accessors will be removed at the end of May.

Next up in the language change department:
  • Implementation inheritance for tuple classes.
  • Removing delegation from the core and replacing it by Daniel Ehrenberg's extra/delegation library.
  • New tuple syntax with named slots.
  • Moving Doug Coleman's singletons to the core.
  • Moving extra/multi-methods into the core and removing the current generic word system; I have blogged about the multi-methods library in the past.
  • Declarative sequence construction using Eduardo's extra/bake library should be merged into the core. It can replace a whole slew of utility words and make Factor easier to learn.

Each one of these changes will be accompanied by refactorings of Factor's codebase to use the new features where appropriate.

I will spend the next few days dealing with the fallout from the new-slots merge; I also have a few minor features I want to get out of the way. Once that is done I will return to working on the web framework while continuing to ponder the implementation details of inheritance in my head. Once those are worked out I will dive back into the core.

These language changes are coming rather late in the evolution of Factor, however their utility, along with the recently merged new-slots, only became apparent after we wrote a lot of code, and so the justification for incorporating these features and removing the ones they replace is based on real experience and not just theoretical concerns.

Once these features are done I will be happy with the state of Factor's language and my focus will shift to performance, documentation, and peripheral libraries. Then, Factor 1.0 will be released and heads will roll.


Anonymous said...


singletons are evil.

They are in the way of proper unit testing.
Just like global functions.

For instance I can not mock up System.currentTimeMillis() in Java which prevents LOTS of unit testing.

Any chance a new language could do better?

Slava Pestov said...

Factor singletons don't have state, they're just symbols which can be dispatched on. They don't hinder unit testing at all.

Anton Tagunov said...
This comment has been removed by the author.
Anton Tagunov said...

> Factor singletons don't have state,
> they're just symbols which can be dispatched on.
> They don't hinder unit testing at all.

Slava, thanks for you reply!
Good to hear this.

Getting deeper into Factor to find out myself what's good and what can be bettered is still no my looongish TODO list. However today I'd decided to write down my long waiting ideas on language modularization and unit testability.

The text may not be worth anybody's attention but since I feel it may be relevant, here's the link

Anton Tagunov said...

definitely got a problem with links. here's a better link my post on the desired programming language support for modularization and unit-testing