Re: Three Kinds of Logical Trees

dawn wrote:
> Marshall Spight wrote:
> > > > 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.

Okay, but that means you can't in general substitute a subtype for a supertype. That means your language doesn't have subtyping, only inheritance. Of the two, subtyping is the more valuable, so I don't think this is a good design choice.

> ...
> > 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)

Yes, that's common. But sharing common functionality isn't how we normally think of subtyping. Substitutibility is.

> > > 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?

I'm not sure I understand mountain man's ideas. But I certainly think hard coupling applications to schema is going to reduce maintainablitity. Look at how bad this issue is today. (Hey, how do you do ad-doc queries if the database has to know everything ahead of time?) I think the better approach is to figure out how to have applications that are able to adjust to schema dynamicaly.

> > 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.

I don't see it. Type information, schema, and data values need integrity management. What do apps need managed?

> > 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

I think a lot of the issues you are talking about above are language design issues.

> ...
> > 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.

But since the reverse is also true, and the relational model is simpler, that tends in favor of the relational model as the design choice.

> 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(!), ...) [...] 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.

Mostly, these languages are all of the same family. SQL and Javascript are the exceptions. We all know about SQL, ha ha. With Javascript you might not have run into the differences because Javascript often is used in a very dynamically-typed-Java style.

> ==========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,
> > >
> > > Yes, she does.
> >
> > [Let me just state for the record that [...]
>
> [...]
> 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.

Yeah, but then everything else has to become plural, and that's often awkward.

"And once they type the integer in, can they just forget about it? No; the humans are 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, they need a strong suite of tools,"

Marshall Received on Tue Jul 26 2005 - 16:49:04 CEST