Re: Three Kinds of Logical Trees

Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:

I'll try to snip mercilessly and attempt short responses

> I don't believe it's possible to have a static type system where
> you can update variables in such a way that they become of a more
> general type.
...
> Once you do that, the type of the variable has to
> change at runtime,

A value can be seen as being of a more general type with a different variable. I might not have my terms correct, but I think of it as static typing if each variable itself doesn't change type. There is no reason to require exactly one name/type per data attribute value. That is what I propose, recognizing there are associated risks. A compiler can only find inconsistencies within a compiled unit, but a database that includes all code that uses the dbms api would have all such units available.
...
>
> > > So I can have a variable
> > > of type int, with an int value in it (which is also a string) and
> > > invoke a method to prepend a ~ character to the string, right?
> >
> > Yes and that would not violate that this was a string.
>
> But it *would* violate that this was an int, and so the *variable*
> would either have to change its type,

The key to this is that you also have another variable referencing the very same value, but of a different type. You asked if you could have a variable of type int, with an int value and invoke a method ... and you can, but you would not stick the tilde into that value using your int variable. If there is a chance for your int variable to do something with such a value after you do that, that would give a compiler error.
...
> On a related note, I really don't think that if you sat down and,
> without thinking about representation, wrote down all the operators
> that apply to string and all the opertors that apply to int, I don't
> think you'd see much overlap.

No, but look at your data and see how often a value intended to be an int needs to be treated as a string (e.g. UI I-O)

> > Since I want
> > that source code all persisted with any databases it updates, each
> > database would have all the data and functions it needs to address
> > inconsistencies.
>
> This seems like it would really increase the coupling,

Where are schema stored today? Do you have this same concern with mountain man's approach of putting everything in the dbms?

> which I don't
> think you'd want to do. Wouldn't it be better to have the system
> such that the applications were *less* coupled to the dbms rather
> than *more* coupled?

Software apps could be seen as metadata, including validations, contraints, etc. Lots more could be said on this one. ...
> > Basically, I'm taking the schema and constraints out of the dbms tool
> > and putting it with all of the rest of the code, so it is handled just
> > like other data models used in the code, such as the UI data model.
> > The software applications should be able to execute a function on a
> > model of some data that gets the output to a browser and another that
> > gets the output to a database for storage on disk. It should be able to
> > execute a function on a model of data that pulls in values from a
> > browser or from a web service, xml document, or database.
>
> Have you worked much with multi-application databases?

Yes, but not with databases where more than one company could use the database api directly. I'll grant that in this case (do you know any such cases, I'm sure there are some?), my thinking is flawed (and it is likely flawed elsewhere too).

> Because this
> seems hard to do in that situation. The UI for a particular
> program is not shared among different applications; the schema
> and constraints are.

Don't forget that I'm requiring all code that uses the dbms api to be available to the dbms.
...
> I hope the above helps. Again, it's not that the nodes don't have
> anything in them, it's just that, if I'm thinking specifically about
> trees, I don't want to consider *at the same time* issues that SQL
> has whether my data is tree-structured or not.

That didn't clarify it for me. I think at this point I would need your definition of this type of tree restated, with an example of such a tree and your claim about how SQL has any relationship to this type of tree. However, if you are sure that what you are thinking is accurate, you don't need to try to bring me along for the ride. Sometimes my brain just doesn't work.
...
>
> If you're thinking about *language design*, you should probably
> incorporate this information right away.

I have no plans to design a language, but I'm happy to learn anyway ...
> Any time I see two language
> features, and I have to have both of them, and one is a superset
> of the other, I figure it makes sense to put the larger one in,
> and define the smaller one in terms of the larger. Roughly speaking.

Funny, but that is precisely why I advocate for a graph model over a strictly relational model. There is no practical problem of which I am aware in including set operations along with a graph model. ...
> I can't recommend looking at lots of different languages enough.
> If all you've ever encountered is the Algol-family, like I had
> when I started this whole thing, you've encountered only a very
> narrow slice of what's possible.

I'm at least passable in the following general purpose languages: Java, COBOL/CICS, Fortran & BASIC (all of which I have taught to college students at one time or another) and dabbled with several others (Pascal, C, C++, RPG(!), ...). I did read a bit about Haskell and other functional languages, but haven't played with them. Of course, this is in addition to several non-general purpose languages such as SQL, HTML (is it a language or a parm file?), maybe even JavaScript.

> > > > ... XQuery.
> > >
> > > Uh, does it have natural join?
> >
> > I'm guessing you know the answer, eh?
>
> I'm guessing it's "no." Having used join a lot and been wildly
> impressed
> by its expressive power, I now consider it a must-have language
> feature.
I don't actually know the answer, I just figured you did, given the question. Perhaps an investigation is in order?

cheers! --dawn

==========OT below =============================


> > > And once you type the integer in, you can just forget about it?


> > > No; the human is also in charge of the integer as it moves around

> > > the computer, across function calls, across the network, into the

> > > database, etc. And to manage this process effectively, he needs

> > > a strong suite of tools,

I was hoping you would jump on that one. I just had a break-through in this ongoing discussion with my husband. I proofread something he wrote (that might sound ridiculous for anyone reading me here as I don't proofread these and sometimes ramble on and on like this). I told him that I really disliked the alternating he/she pronouns and much preferred the plural pronoun to match a singular noun.

I used this specific document to show him that when the author is intending to make the reader relate to a scenario but then tosses in a pronoun that is not a match for the reader, the reader adapts by thinking of some other person of the matching gender. They can still understand the sentence and might not mind it, but they do not relate to the statement in the same way. (See how easy it was to read "they" for the reader -- it will get even easier to roll with it over time). The scenario is then about someone else and not about the reader.

Given that we already use "you" for both singular and plural, what is the harm in adapting our language to use "they" and "their" for both as well? Let's just do it and be done with it. He agreed with the argument this time (perhaps I've just worn him down) but changed the wording to avoid the problem. Received on Tue Jul 26 2005 - 16:18:38 CEST