[Bentodev-hacker] More notes

[Eric B. <er...@di...>]

=46rom Michael St. Hippolyte to Eric Brooks:

Excellent.

I'll send you the code this afternoon, unless you want to work on
it before this evening.  I've made a lot of changes since the last
code I sent you, including adding and removing a few classes, and
there are still a few loose ends to tie up.

I'm very happy and excited about the way overloading and parameters
work now.  There's certainly still room for improvement, but the
model we came up with is elegant, clever and in keeping with the
distinctive style of Bento.  The constraint you suggested -- that
definitions be unique -- was the key.  It led very naturally to a
syntax which supports overloading and parameter-dependent
implementation within a single definition.

The reason that I think of it as in the Bento style is that it
reslices the traditional boundaries and structures of OO languages
(classes, instances, fields, methods etc.).  I find it refreshing,
and I suspect at least a few other longtime C/C++/Java coders will
as well.

Here are some tasks for you to choose from:

1. Arrays.  Most of the architecture and a little bit of coding has
been done so far.  This is a pretty broad task and touches a number
of key parts of the system, so if you pick this one you'll find
yourself in deep Bento pretty quickly.

2. Loops.  This would probably make more sense to do after arrays
are implemented, but if you find the idea of "being in the loop"
irresistable then by all means jump in.

3. Unit tests.  If you want to learn JUnit and help bring out your
inner pest control professional, then this one's for you.  We need
not just coding but an architecture, a unit testing model that makes
sense for Bento.  But probably the place to start would be to code a
single unit test for a module of your choice just to get a sense of
the particular testing needs and possibilities Bento has.  Let Bento
"show you the way" in other words.  It has worked well for me so far.

4. Conformance test suite.  This involves coding in Bento rather
than Java.  We need a set of Bento files which exhibit more or less
every feature of Bento, and another set of Bento files which break
more or less every rule of Bento.  In the long run this is actually
the most important task of all, since the conformance test suite
will be the de facto definition of Bento.  The short term value is
for finding bugs and tracking development.

5. Improvements in error detection and reporting.  Most importantly,
we need to correctly identify and report line numbers for syntax
errors.

6. Sample code & demos.

If none of those suit your fancy, I'm sure I can come up with more.

On my plate, after parameters are done I plan to tackle external
object linkage, with Java as the test case.  This is also probably
going to bring in static/dynamic support.  I think I described it
to you briefly when you were here; the basic idea is just to help
Bento cache things efficiently and safely.  Objects defined as
static never change and can be cached indefinitely.  Objects
defined as dynamic cannot be safely cached and must be regenerated
from scratch every time they are instantiated.  The default behavior
if neither modifier is present is to cached conservatively; the
object is cached only as long as the context remains the same.

To fine tune the caching behavior more precisely Bento has a pair
of commands, "keep" and "discard", which let you prevent or force
regeneration at specific points in the code.

Most of these features have not yet been implemented.  I've avoided
working on them because I'm not sure I got them quite right.  It
could be that something simpler would work as well or better.  But
I do think it's appropriate to handle caching in the language.  It's
a lot like memory management: every program needs it, and it's a
breeding ground for bugs.  But we certainly don't need a fancy
implementation for version 1.0.  I'd be curious to know your thoughts
on the matter.

Michael