[om-list] simulating time/place and context

[Luke Call]

This is good; I'm glad we're all on the project. The language stuff is 
interesting and possibly related to Eric Raymond's articles--have you 
read his "how to become a hacker" and "why python"? I haven't got far 
but python's syntax or one similar may be good for mere mortals in this 
context; I don't know but it's a thought. They are both off that same 
tuxedo.org web page. By choosing python if we're going to embed a 
language it would expand our userbase of people already familiar with 
how to use this, available instructions and community, etc. Either way 
I'm wondering if python or scheme would be the ones; also the framerd 
looks like a good place to start at least for prototyping for now--do 
you think so as well?

Luke

Mark Butler wrote:

> Luke,
> 
> What you have described is a reasonable run time implementation - we just have
> to be able to store the variant data efficiently in the first place.  If we
> use a LISP style database we virtually eliminate the problem on the storage
> side because it is easy support attributes and relations that have functional
> dependencies if you can substitute an expression anywhere we might have had a
> scalar before.
> 
> Of course, that means that the run-time components have to be capable of LISP
> style expression manipulation, much like Mathematica.  This is certainly
> practical in LISP itself or Java or C++.  In the latter two languages, you
> simply build the same runtime environment as you have in a LISP interpreter -
> you might look at the FramerD source code in the "scheme" subdirectory - it is
> quite instructive.
> 
> I think it might be a good idea to support LISP or Scheme directly, but I
> would also like to write a higher level language with the flexibility of LISP
> and a C++ style syntax.  If we are going to support functional attributes, we
> need a syntax that mere mortals can write simple functions in (as in modern
> spreadsheets).  Naturally, such user defined functions would need to be
> translated into a LISP like intermediate form before evaluation.
> 
> Besides LISP style function representation, we also need a way to efficiently
> represent regularly sampled functions such as time series, sampled images, and
> so forth.  We also need similar techniques for irregularly sampled data and
> hybrids of the two.  We could certainly store schema dependency as just
> another abstract dimension for a functionally dependent attribute, although
> care needs to be taken to prevent schema cross-pollution.
> 
>  - Mark
> 
> _______________________________________________
> om-list mailing list
> om-list at onemodel.org
> http://www.pairlist.net/mailman/listinfo/om-list
> 
> 
>