Date: Mon Jul 28 02:00:08 CEST 2003
© 2003 ich
Proposal (patent idea) for a better spread sheet
The purpose of the memo is to claim ground for the interest
of the public domain (before someone patents the idea).
Background: I think, that the idea of spread sheets as we
know them by year 2003 is too limited: they normally use a
grid to place data and formulas. This limits you in various
- they urge you to use lists of data
- they cannot deal with objects
- they have limitations calculating with units
- the intelligence (the formulas) are scattered over the whole sheet.
- they do not allow you to comment on your formulas
- Adding comments between your data disrupts the grid
(your comment does not fit into one cell...)
My idea of a better spread sheet
My proposal of a better spread sheet follows. It should
have the following features:
- It does use a grid for placing data only optionally,
i.e. to emulate a "classic" spread sheet. It provides
other/further ways to typeset data and formulas.
- It support programming in object oriented languages. (i.e.
it uses an embedded python compiler/interpreter).
- it allows you to comment on your formulas
- data can be any object type; new object types can be defined
- One of the basic data types (object type) it provides is
that of a combination of number and accociated unit.
- it supports unit calculation by unit conversion
- formulas and/or data can be defined in a central place.
- typesetting can thus be independant of data entry an
- it lets you define multiple "formatters" for one object type;
thus one can create different views on one object type, thus
aiding in typsetting (i.e. lets one typeset a terse and a verbose
representation of your data).
- as "cells" are no longer the mandatory default data container, it
uses other containers, i.e. object variables or arrays/trees
- it allows bidirectional editing: first define the intelligence,
the formulas; then add the data (i.e. singletons, lists, trees);
then desing the typesetting (if needed). When viewing the
typesetting, one can pick a piece of data and track down its
origin in the formulas/dataset/datasource.
- renaming variables changes their names in any referencing place
to avoid orphants.
- it provides list-data-to-object-mappings, ie. it may query
an external databse, but presents the results in a set of objects.
It support the other way too: flattening an object to a database.