Programming Language that is Spreadsheet/Table Based

[Hendrik van Rooyen]

"James Stroud" <jstroud at mbi.ucla.edu> wrote:

> Gerard Flanagan wrote:

8<----------------------------------------------

> Thank you, this is very good stuff to think about.
>
> James

 I can't really add to the above train of thought...

And I don't know if this will help - but if you want to think, here is a skewed,
simple view:

If I were to try and do something like this, I would start by defining a spread
sheet like dict to keep everything in, using (column,row) tuples as keys, and
build on top of that.

This would give you the ability to keep *anything* in a cell, and the database
like structures you are thinking of would live on top of this underlying access
structure, with the (column,row) being a direct *pointer* to an element in one
fast step.

I would then also use other dicts to describe what is kept in the "columns" -
something simple like:

header_dict = {0:['name of person','Name','Enter your name'],1:['age of person
since birth','Age','Enter your birthday'], ... }

where the first item in the list is a help string, the second a column header
for printing, the third the string to use as prompt for a GUI, etc... - you
could even keep and enforce type if you wanted to - must be int, must be date,
column width for printing, validation data and rules, - whatever.

In a sense this is a sort of inverted way of looking at a file - instead of
having an underlying dict with (column, row) keys, you could alternatively have
"loose" column dicts only to keep the data in ( note that I have been writing
(column, row) consistently, instead of the more conventional (row,column).) -
this would make adding or deleting columns almost trivial.

You *could* also have references to Python functions or class methods living
alongside the data in the cells, and then things can get hairy - for an age
entry, for instance, the cell can look like:

Data[(column,row)] =                       # (or Age[row] in the alternative
approach)

 [(1947,01,24),self.BirthdayChecker,self.PresentChooser,self.LetterWriter, ...]

where the first entry, the tuple,  represents the data (could have been a list
or dict, of course ) and the rest are methods or functions to use, in this
particular instance.   You could instead have these function references in the
age column's header dict entry, for those of them that have applicability across
all rows of the column, just like the idea of type enforcement or validation
above.

For a kind of row, or row type, you need then simply keep a list of column
numbers that are required for this "record", with a different list defining a
different record type - Gold members need these column entries filled in, while
Silver members need only those... simple, but then you need a record type
column...

This sort of thing organises the stuff, but the code to use it becomes a bit
impenetrable, as you have to write a kind of crawling process to access the
structure to do what is required, but it is all "table driven" and can be very
flexible.  Its not a weekend project though, and when you are finished its a
kind of super relational database...

HTH

- Hendrik