Re: More on lists and sets

"Jan Hidders" <hidders_at_gmail.com> wrote in message news:1143038044.822819.175380_at_v46g2000cwv.googlegroups.com...
>
> David Cressey wrote:
> >
> > [...] If you have already made the decision that what you want is a
> > declarative manipulation language then what you say is true. It's not
clear
> > to me that programmers really want that. Or that they should want that
if
> > they don't.
>
> I guess this depends upon whether you are designing a query language,
> i.e., a language in which we issue a request to a database, or a
> programming language i.e., a language we tell the client to compute
> something. For a query language declarativeness is a must-have because
> only that way the DBMS has enough room to do query optimization and
> achieve data independence. For a programming language declarativeness
> may or may not be a good idea, depending on what the programmer is
> trying to achieve.

Isn't a "query language" and a "data sublanguage" essentially the same thing?

If so, the answer to your question is basically yes. Except that I want the interface to be even more automatic than SQL cursors. I want a transformer that on one side looks like a query, and accepts a result table (set), and on the other side looks like a list that can be opened and read one element at a time.

Going the other way, I want to be able to build a list, one element at a time, and then shove the entire list into a transformer, and have the list contents inserted into one of more tables.

>
> So you are thinking about a non-declarative programming language and
> you want to integrate sets and lists there? Would that not largely be a
> matter of coming up with the right libraries / class definitions?
>

I think Marshall wants to do this. I want to deal only with lists in the programming language, and only with sets in the data sublanguage that interfaces with the database. Received on Wed Mar 22 2006 - 21:28:50 CET