References: <11D1CF78-B9D9-4E69-AF07-972B52093D17@gmail.com>
            <4D860EEF.1010206@morningstar2.co.uk>
Mime-Version: 1.0 (iPad Mail 8F190)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Message-ID:  <F89A4042-7431-4E2E-8D60-0DB79EF5BDFF@gmail.com>
Date:         Mon, 21 Mar 2011 01:23:23 +1030
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: expl3 translation of the NFSS
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <4D860EEF.1010206@morningstar2.co.uk>
Precedence: list
Status: R

On 21/03/2011, at 12:57 AM, Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK> wrote:

> Impressive that you've got this far, but a quick look at the code does
> flag up a potential danger from this approach. You're pretty much tied
> to what seemed like a good idea at the time in terms of
> _implementation_, not just in terms of interface. The later is pretty
> good, I think we all agree, but I'm not sure I would choose anything
> like the same implementation. Perhaps we first need a LaTeX3 translation
> of the current code as you say, in order to see where to go.

Right, my only goal so far is a relatively straightforward translation. Since we already have a well-tested codebase and an interface to remain compatible with, this seemed the best way to start. (I'm much more of the philosophy of evolving from the inside out; I very rarely like to rewrite code from scratch.)

There are some aspects of the implementation that have had somewhat of an impedance mismatch with expl3 (e.g., delimited data inside a sequence is probably better put inside a property list) but on the whole it's worked well. 

Once the implementation is working (there are some headaches to think about when replacing the NFSS) and we've got some nice test files working then we'll be in a better state to start ripping the guts out if necessary. Consolidating the implementation and shaking out the cobwebs should give us a good indication of what is still working well and what would be better replaced nowadays by an alternate approach. 

Will