bentodev-hacker — Bento developer community

[Bentodev-hacker] suggested table syntax

[Michael St . H. <ma...@br...>]

One of the unfinished bits in the design of Bento is the syntax for tables 
(data tables, not html tables).  Here is my suggestion for this syntax:

Table Definition:

  <TableDef> ::= [<Type>] <TableName> "{" ["+" | <Length>] "}" 
[<TableInitExpr>]
                            <TableInitExpr> ::= "=" "[" [ 
<TableElementDefList> ] "]"

  <TableElementDefList> ::= <TableElementDef> ( "," <TableElementDef> )*

  <TableElementDef> ::= "{" <Key> "," <Object> "}"


Add Element to Table:

  <AddElement> ::= <TableName> "{" ["+" | <Index>] "}" "=" <TableElementDef>

Table Element Reference:

  <TableElement> ::= <TableName> "{" <Key> "}"


As with arrays, tables can be either fixed size or growable.  
Here are some examples:

   /** this defines a fixed-size table with room for four elements,
       none of which are defined initially **/
   x{4} = []

   /** this defines a fixed-size table with the length (two) inferred
       from the initialization list **/
   label_table{} = [ { "EN", english_labels }, { "FR", french_labels } ] 
   /** this defines a growable table with three elements **/   age{+} = [ { 
"Tommy", 9 }, { "Xena", 9 }, { "Jordan", 8 } ]

   /** this adds another element to the above table */
   age{+} = { "Alison", 4 }

   /** this displays a name and the age associated with that name,
       retrieved from the table defined above **/
   show_age(name) [|
     <p>Name: [= name; =]
     <p>Age: [= age{name}; =]
   |]

One possible enhancement of this syntax would be to allow the definition of a 
default entry in the table.  This would be characterized by an entry without a 
key value.  For example, the following would add a default entry containing 
the string "unknown" to the age table defined above:

   age[+] = { "unknown" }

Comments?

------------------------------------------------
Michael St. Hippolyte

[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

[Bentodev-hacker] Notes from Michael St. Hipployte

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

=46rom Michael St. Hippolyte to Eric Brooks:

Now onto sub...

sub is a keyword very much like "super" and "this".  From Bento's
point of view, they are aliases for definitions: "this" refers to
the definition containing the reference, "super" refers to the
superclass of this definition, and "sub" refers to the subclass
of this definition.

But there are actually two subtly but significantly different ways
in which these keywords are used: to instantiate them directly or
to refer to definitions they contain.

The first usage, which is signified by the keyword immediately
followed by a semicolon (e.g. "sub;"), has strict rules:

   1. only "super;" and "sub;" may be used this way ("this;" is illegal)

   2. only one such statement may appear in a single definition

   3. "sub;" and "super;" cannot be mixed in the same class tree; in
      other words, a definition may not contain the statement "super;"
      if any of its ancestors contain "sub;", and may not contain
      "sub;" if any of its ancestors contain "super;".

This usage and associated rules seem to work quite nicely, though it
needs a lot more testing.

In the second usage, the keyword is not being instantiated directly
but is being used in a definition reference, generally in a reference
to a child of the specified class.  For example, "super.title" refers
to a definition named "title" in the superclass.  The design issue in
question relates to the meanings of "this" and "sub" used in this way.

In Java, "this" is a dynamic reference to the current instance, which
means the class which was instantiated, which could be a subclass or
deeper descendant of the class in which it appears.  In Bento, however,
"sub" plays this role and "this" just refers to the local definition
in which it appears.  Here are the various issues with this design:

-- it might be confusing to C++ and Java programmers

-- "this" is just a nickname for the containing definition and is
    therefore doesn't really add any capability to the language.

-- having "sub" refer to the ultimate subclass in this usage conflicts
    with its meaning in the first usage, which is a reference to the
    immediate subclass.  If the current instance is more than one level
    of inheritance below the definition in which "sub" appears, the
    two usages point to two different definitions.

It's the last point that's a killer -- I'm a total convert to your
notion that the meanings of things should be unambiguous and
consistent.

One obvious solution would be to change the second usage of "sub"
to match the first usage (i.e., have it point to the immediate
subclass) and change the meaning of "this" to point to the
ultimate subclass.  This would bring it in line with Java, but    =20
would have the curious effect of making the definition referred to
by "sub" possibly the superclass of the definition referred to by
"this".

Another possibility would be to drop the second usage of "sub"
altogether (and maybe drop "super" as well) and change "this" to
point to the ultimate subclass.

Or perhaps some other sort of syntactic or semantic change could
solve the problem.  I'd be eager to see any ideas you might have.

Does this description of the issue make sense, or do you need more
background information to make sense of it?

Michael


--=20
Eric Brooks (er...@di...)