On Fri, Jan 27, 2012 at 9:13 AM, Edward K. Ream <[email protected]> wrote:
> It is becoming clear that the settings-related code in leoConfig.py
> and leoKeys.py urgently needs a significant revision. As I said just
> now in another thread, I plan to consider such a revision only after
> fixing the present serious key-related bug.
On second thought, delay seems foolish. In this case, not doing
something will take more energy than doing it. It should be safe
enough: the new code can be folded into Leo's code base gradually.
[big snip]
> The challenge is to devise a fruitful interaction between our classes and our
> unit tests.
This is the tip of a large iceberg. Here, I'll just give a hint about
the shape of the iceberg.
1. In fact, the interaction is between code (in general) and all
other tools, including leoInspect script and unit tests. We can
imagine packaging leoInspect scripts as unit tests, creating new kinds
of unit tests:
- Distribution tests: check that Leo's code base is ready for distribution.
- Build tests: check that Leo's code base is ready to be translated
into cython :-)
2. The assertion that any particular form of type analysis is
infeasible is really an assertion about all possible tools applied to
all possible programs, regardless of additional constraints that may
be imposed on those programs, perhaps by yet other automated tools.
To me, such assertions seem fundamentally misguided. Better tools
*are* possible, and they may indeed impose significantly useful
constraints on our programs. These new constraints create the freedom
to translate safely.
3. Ideas from last year are being recycled in this context. In my
experience, this is a sign that good things are happening. For
example, we can imagine adding support in leoInspect.py for what might
be called tool-oriented assertions. Such assertions might be "housed"
in do-nothing statements:
type_assert(isinstance(x,y))
The leoInspect module could detect such assertions. A script that
translates Leo into cython might use these assertions in some way.
In short, we can imagine many kinds of tools that help us programmers
to understand our programs better. My plan is to use Leo as a test
bed for creating useful new programming tools.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
