Re: ACID et al

From: paul c <>
Date: Mon, 05 Dec 2005 23:19:32 GMT
Message-ID: <8W3lf.53244$Gd6.33630_at_pd7tw3no> wrote:
> paul c,
> I agree with your comments regarding excel and the need for a "minimal
> but respectful implementation of the RM" --- I like that phrase too.
> I'm working on a similar problem ( for details), only I
> don't assume an in-memory db, and I allow for multi-threading. You
> might find it of interest.
> Regards,
> Paul Mansour

Thanks. I think you are on to something more ambitious than I could attempt. The in-memory stuff is partly so that I can avoid multi-threading, although I wouldn't do it solely for that reason - it has to be useful too. The only homage to APL that I had in mind was to be completely language-neutral as far as syntax is concerned, but let installations invent their own operator names based on patterns, if they wanted to. I think at first I'd have to limit things to UTF-8 but I think there are enough non-alpha symbol keys on my keyboard to do what I want!

I think that there are significant bits of TTM and even parts of Tutorial D that I understand well enough to make an engine for. But there are large parts, such as the typing theory that I haven't yet seen through, so I think I'll be limited to fairly simply domains at first but with some ability for users to define their own domain operators which is a requirement that I've seen many times. The type 'name aliasing' that I've seen here and there in SQL implementations some years ago seemed a bit of a farce to me, although I have mixed feelings about strong typing at 'compile' time.

One thing that confuses me yet with TTM and which I'll have to grasp fairly soon, is the notion of "LOAD" array or list in TD which strikes me as an ironic kind of 'impedance mismatch', but I'm saying that with the admission that my feeling for TD is as yet quite naive. I would just as soon have a recursive api that is defined at the language level to somehow deal with subsets. This is partly why I'm interested in the functional style (it might also let me duck having TCLOSE per se which bothers me for reasons that I can't explain very well). Maybe that's crazy, I don't know yet.

As you might also observe, it does give one some leverage if one can piggy-back on an environment, eg. an existing APL environment, if only so as to avoid re-inventing a million built-in wheels, such as date and financial routines. Believe it or not, I haven't ruled out co-existing with javascript/ecmascript for this reason and a few others since it is fairly easy to package from what I've read. I think javasript would be quite neat if it had a 'relation' built-in type. The Mozilla Xul stuff looks interesting except for the fact that its 'templates'/rdf thing have a rather bizarre, maybe even ignorant, notion of relations. I looked at the JVM many years ago with the idea of porting a language I had worked on to it. At that time, it was a pretty good fit (I would have been able to hide the OO stuff from app programmers). But I'm out of touch with Java now and a bit worried about whether I would have to accept a lot of baggage in the form of its packaged classes just to get some reasonable builtin routine support. Also, I think Java's bloat is proof once again that a virtual machine that has almost the same low-level operations as a real machine will be destined to repeat the same history (either more language complexity or more environment complexity, or both) as all the other procedural languages that compile to real machines. Ideally, I'd like every 'program' to be a relation in a sense, in fact possibly several relations but I don't think I'll achieve that in the first go-round.

p Received on Tue Dec 06 2005 - 00:19:32 CET

Original text of this message