Re: Multi-dimensional arrays and relational db data
On Sunday, 10 June 2001, Peter Scott [EMAIL PROTECTED] wrote: He's right. I do a lot of DBI stuff with Oracle, and every so often I have a hankering for some kind of structured tied variable that would look like my database. Then I wake up and realize that modeling of a single table doesn't do squat for me, and modeling of the whole database requires knowledge of the foreign key relationships, and even with those, no variable structure suggests itself. And then I remember this is why I wrote object classes modeling the things I want to get out of/put into the database. Even if your database is so simple that you do just want to model single tables, it would be easy to build atop DBI. I beg to disagree. DBI is complicated and verbose. It takes many lines of code to do simple things with DBI. Sometimes you don't need that. I'm going to be a bit annoying here -- I'm going to refer to another language, and I'm going to recommend that it's of interest to this group. Briefly: There's a language (K, see www.kx.com), which has been used to implement a rather elegant (fast, small) sql server. I think its implementation of multi-dimensional arrays is worth knowing about. A couple highlights: [1] sql tables are physically stored as individual columns (a speed advantage for the problem domain it's aimed at). [2] the language supports triggers and dependencies. This is much more general than array slices: this allows simple implementation of sql views, user interface mechanisms, etc. On the downside: If you don't already know apl and scheme, you'll have a steep learning curve with the language. Some people might even call its syntax ugly. Also, while the language (and the sql interpreter) are available for free download, it is a commercial product and no source is available (if you consider k code to be ugly, this lack of source code might be something to be grateful for). FYI, -- Raul
Re: Multi-dimensional arrays and relational db data
At 10:33 PM 6/11/2001 -0500, David L. Nicol wrote: [EMAIL PROTECTED] wrote: You may wish to read this thread about lazy arrays and object persistence to get an idea of what you're getting into. http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/ Taking lazy as far as we can, has anyone been thinking about a compilation mode in which all expensive accesses get deferred until there is a decision to be made? Yup, I seriously considered this when all the lazy stuff cropped up ages ago. It could give all sorts of speed boosts when dealing with large arrays and hashes in addition to the function calls. It runs afoul of perl's active data, though, which is kind of a bummer. Bits of this will be used by the compiler and runtime, if for no other reason than to make this: ($foo, $bar) = BAZ; or this: $#bar = 10e6; ($foo, $baz) = @bar; more efficient. (In the first case we read two lines then seek to EOF (if that's what in list context will still do in perl 6) and in the second we just grab the first two elements of @bar rather than dumping the whole darned thing on the stack and plucking off the first elements) I'm still trying to formulate a good set of rules on how I think active data should perform under optimization to pass on to Larry. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multi-dimensional arrays and relational db data
Dan Sugalski wrote: I'm still trying to formulate a good set of rules on how I think active data should perform under optimization to pass on to Larry. Dan How about, Active data doesn't get optimized. Static data doesn't care if you access ir or not, and most data is static, is not burdened with magic that makes it send home a post card every time someone looks at it. If you're a camp counselor and one of your wards is such a neurotic, it is incumbent upon you to make a daily run to the post office. If all your kids are content to write postcards on tuesdays, you just have to go to the post office on tuesdays. -- David Nicol 816.235.1187 Signature closed for repaving
Re: Multi-dimensional arrays and relational db data
At 02:07 PM 6/12/2001 -0500, David L. Nicol wrote:
Dan Sugalski wrote:
I'm still trying to formulate a good set of rules on how I think active
data should perform under optimization to pass on to Larry.
How about, Active data doesn't get optimized. Static data doesn't
care if you access ir or not, and most data is static, is not
burdened with magic that makes it send home a post card every time
someone looks at it.
That's less easy than you might think. Quick:
$foo = bar();
is $bar active or not? Or:
my $foo;
if ($bar) {
tie $foo, Bar;
}
how about then?
This is a considerably less simple problem than you (and *definitely* I)
might like. :(
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Multi-dimensional arrays and relational db data
On Sun, Jun 10, 2001 at 10:13:28PM -0800, Vijay Singh wrote: Why is it that Me is *mouthing off*, but you're not? Why is that? What makes you so *special*? In Me's defence, at least they do occasionally produce some useful thoughts about Perl 6, and are not here simply for personal attacks on one particular contributor. The fact you wrote a Perl book?! A book with more typographical errors than it has pages? *Zut!* You know they say Publish and be damned! :) -- The primary difference between a teenage male and an adult man is that a man has learned to think of something else *while* he's thinking of sex. - Mark Atwood
Re: Multi-dimensional arrays and relational db data
OK. My last addition to this painful thread. Your position depends on having a syntax so simple that it is somehow worth implementing as a native capability instead of the tied modules others have pointed out. No it does not. I am not suggesting that a rdb modelling tied version of MD arrays would be in core. Of course it would not. I am suggesting that a rdb modelling tied version of MD arrays might be nice. And that for it to be its nicest: A) the general mechanisms that these tied arrays would need to work adequately will need to be in place in core; and B) the syntax and behaviors chosen for the core MD array features shouldn't jar with what makes sense for the db modelling tied version of MD arrays. I'll wrap with a final thought. I think there's scope for a simple generalized relational model (Nd arrays, joins between arrays, and Nd discontiguous slice subsets across joined arrays) to be a powerful yet simple general purpose algebra for creating normalized tabular datastructures. This has nothing to do with dbs, even less to do with SQL, and everything to do with general purpose programming expressiveness. OK. No more from me on this topic, at least not in the perl world.
Re: Multi-dimensional arrays and relational db data
Sam Tregar wrote: Perl 6 will allow you to mutate your syntax at runtime any way you want. At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Daniel
Re: Multi-dimensional arrays and relational db data
Me wrote: I don't think it's reasonable to say I propose you change something that hasn't yet been defined. Rather, it is precisely because you haven't yet defined the MD array syntax that I thought it worth at least considering how it parallels db data BEFORE you define it. Considering how something will be used is often a good idea. What syntax do you propose as being SQL-friendly? This is a sure way to find out if your syntax looks strange for other purposes as well. Daniel
Re: Multi-dimensional arrays and relational db data
At 10:26 PM 6/10/2001 +0100, Simon Cozens wrote: It doesn't matter, because the user can redefine the syntax anyway. I'm staying completely out of the argument that spawned this (Though the idea of welding SQL directly into perl has some appeal--it was one of the few (okay, the only one I can think of, but there must have been others) nice things about PL/SQL), but I would like to note that this statement, while true, is effectively meaningless. Might as well say the same about perl 5 because anyone who wanted to could hack toke.c. Just because things are possible doesn't make them easy and, while they'll be easier in perl 6 that still doesn't mean they'll be easy. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multi-dimensional arrays and relational db data
On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote: At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Before? Bah, woosy. *AS* it executes. -- I think i'll take my girlfriend to vegas for a win'98 burn/upgrade -- Megahal (trained on asr), 1998-11-06
Re: Multi-dimensional arrays and relational db data
At 04:20 PM 6/11/2001 +0100, Simon Cozens wrote: On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote: At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Before? Bah, woosy. *AS* it executes. Hah! Wimp. After it executes, retroactively. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multi-dimensional arrays and relational db data
On Mon, Jun 11, 2001 at 11:20:15AM -0400, Dan Sugalski wrote: nice things about PL/SQL), but I would like to note that this statement, while true, is effectively meaningless. Might as well say the same about perl 5 because anyone who wanted to could hack toke.c. OK, I'll put it another way: domain-specific syntax modifications are something we want to encourage in all cases, not just in the case of databases. (There's that generalisation thing again.) On the other hand, I don't think it's worth getting bogged down in argument at this stage over how people can apply that concept - specific applications don't necessarily go in core, they're an external thing; (and certainly don't help us get the Perl 6 language itself designed) it's just as useless as discussing not only what modules should be in the Perl 6 equivalent of CPAN but what their interfaces should be. -- I don't think so, said Rene Descartes. Just then, he vanished.
Re: Multi-dimensional arrays and relational db data
Simon Cozens wrote: scream This is the kind of thing that can be dealt with perfectly satisfactorily with external modules; ergo, it does NOT need to be in the core. Ergo, it probably *does* *not* *need* *discussing* *here*. Much of the discussion on this list seems to concern what will be the syntax for expressing common semantics, such as array references or properties, to name a few recent ones. This thread seems to be another one such: what will be the default syntax for multidimensional arrays and how will that syntax hamper or encourage mapping it to SQL semantics. You're (that's to say, the person at self-reference.com who is not prepared to reveal their real name) exhibiting a common trait amongst perl6-language people, and that's to concentrate on a specific application *of* the language, and then from there making the bizarre leap of logic to believing that it needs to be *in* the language. I think his point was simply that you should keep this example in mind as you design the language. While one may build a general tool or product, people invariably fall on their face if they don't keep in mind the use or customer of the tool or product as they build it. This is hugely bogus and leads very quickly to second system effect, as the RFC process has shown us. Don't do it. Focus on the bigger picture instead. Good language design starts when you stop thinking I want this and this and this and start thinking how can we solve all these problems in one generalized way? Examples of successful people in the field of theoretical work point to the conclusion that the only way to achieve good abstractions is to 1 - start with lots of examples, work them out, and then 2 - try to find what they had in common and thereby generalize from them. Halmos' answer to how to learn mathematics: examples. Feynman's answer to how to do physics: examples. More than any other language I've ever seen, Perl seems to be designed by making sure that the most common 2 000 things someone has ever needed a computer to do real quick are expressible in the least amount of typing. While this leads to the funny car of programming languages, its a pretty useful funny car. Screaming at people however, is not terribly funny. But of course, I'm sure you already know what makes good language design, because otherwise you wouldn't be mouthing off in here. Right? Somehow this comment seems to apply to all of us on this list, including you. How dare we to think for ourselves! Don't you need a license for that? /scream
Re: Multi-dimensional arrays and relational db data
Dan Sugalski wrote: At 04:20 PM 6/11/2001 +0100, Simon Cozens wrote: On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote: At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Before? Bah, woosy. *AS* it executes. Hah! Wimp. After it executes, retroactively. I was trying to remain well-defined. I'm sure its possible if you can modifiy it *as* it executes, and certainly possible if you can modify it *after* it executes, to define semantics that have *no* value at all. For example, the going back in time and preventing your grandparents from having sex situation. Daniel
Re: Multi-dimensional arrays and relational db data
At 04:43 PM 6/11/2001 +0100, Simon Cozens wrote: On Mon, Jun 11, 2001 at 11:20:15AM -0400, Dan Sugalski wrote: nice things about PL/SQL), but I would like to note that this statement, while true, is effectively meaningless. Might as well say the same about perl 5 because anyone who wanted to could hack toke.c. OK, I'll put it another way: domain-specific syntax modifications are something we want to encourage in all cases, not just in the case of databases. That's a much better way. :) On the other hand, I don't think it's worth getting bogged down in argument at this stage over how people can apply that concept - specific applications don't necessarily go in core, they're an external thing; That's fine as far as it goes, but it is a good thing to examine likely candidate applications to find out what support might be handy to have available. (It'd kinda suck to have Unicode support without normalization built-in, for example...) On the other hand, I don't know that anything beyond: tie @foo, SQLish, select name, age from personnel; would be rational--DB work tends to be either simple or wildly odd, at least in my experience, which is why I've not gotten involved. (I don't think there's anything that really warrants Nifty Builtin Features, but I could be wrong) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Multi-dimensional arrays and relational db data
-Original Message- From: Simon Cozens [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 3:46 AM To: Vijay Singh Cc: Me; [EMAIL PROTECTED] Subject: Re: Multi-dimensional arrays and relational db data On Sun, Jun 10, 2001 at 10:13:28PM -0800, Vijay Singh wrote: Why is it that Me is *mouthing off*, but you're not? Why is that? What makes you so *special*? In Me's defence, at least they do occasionally produce some useful thoughts about Perl 6, and are not here simply for personal attacks on one particular contributor. The fact you wrote a Perl book?! A book with more typographical errors than it has pages? *Zut!* You know they say Publish and be damned! :) Hey, I like your book. I've never read it, but I did buy it. Mostly because it wasn't ORA. And if you think Simon's book is bad, you evidently haven't seen the ORA books coming out nowadays. I wonder if they are even proofread at all anymore. p
Re: Multi-dimensional arrays and relational db data
Vijay Singh wrote: Just how much $foo can dance on the head of a dot operator The current Annals Of Improbable Research (http://www.improb.com) has a piece on applying modern physics to the age-old question, you know, about the boogieing angels. -- David Nicol 816.235.1187 Signature closed for repaving
Re: Multi-dimensional arrays and relational db data
[EMAIL PROTECTED] wrote: You may wish to read this thread about lazy arrays and object persistence to get an idea of what you're getting into. http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/ Taking lazy as far as we can, has anyone been thinking about a compilation mode in which all expensive accesses get deferred until there is a decision to be made? I know some functional languages (and Algol 68?) do this, when they can -- just stack up Things To Do until an output or a decision is required, then figure out just what is needed to generate or make the output/decision. How would this work in perl? We'd have to stop relying on side effects and well defined short-circuiting, for one -- or would we?
Re: Multi-dimensional arrays and relational db data
I think you could only delay function calls automatically like this if you could ensure that they are truely functional. That is, their output must depend only on the arugments given and must have no mutation side-effects. It seems to me that this is hard to guarantee in Perl, even for the compiler. David L. Nicol wrote: [EMAIL PROTECTED] wrote: You may wish to read this thread about lazy arrays and object persistence to get an idea of what you're getting into. http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/ Taking lazy as far as we can, has anyone been thinking about a compilation mode in which all expensive accesses get deferred until there is a decision to be made? I know some functional languages (and Algol 68?) do this, when they can -- just stack up Things To Do until an output or a decision is required, then figure out just what is needed to generate or make the output/decision. How would this work in perl? We'd have to stop relying on side effects and well defined short-circuiting, for one -- or would we?
Re: Multi-dimensional arrays and relational db data
On Sat, Jun 09, 2001 at 10:57:25PM -0500, Me wrote: B) any syntaces chosen for core features won't jar with what makes sense for the relational data sub-language (at least not accidentally). But since the end user is going to be able to redefine the syntax anyway, this isn't an issue. -- #define struct union /* Great space saver */
Re: Multi-dimensional arrays and relational db data
the end user is going to be able to redefine the syntax anyway, Yes. But if the syntax for arrays and db data are to be simultaneously the same and as ideal as possible, then either the core array syntax needs to be relatively ideal for relational db data, or one needs to redefine the array syntax to match a created db syntax and thus have a version of perl that doesn't use the standard array syntax. While the latter is pretty cool, it's a whole lot less cool than the former (assuming that multi-dimensional arrays and relational db data are as close cousins as I think they may be).
Re: Multi-dimensional arrays and relational db data
On Sun, 10 Jun 2001, Me wrote: Yes. But if the syntax for arrays and db data are to be simultaneously the same and as ideal as possible, then either the core array syntax needs to be relatively ideal for relational db data, or one needs to redefine the array syntax to match a created db syntax and thus have a version of perl that doesn't use the standard array syntax. While the latter is pretty cool, it's a whole lot less cool than the former (assuming that multi-dimensional arrays and relational db data are as close cousins as I think they may be). You're not making sense. If array syntax really is a good analogy to database access (it's not) then Perl's array (or hash, you don't seem to care) syntax should be just fine. Get started now - Perl 5's tie and overload support should be more than sufficient. On the other hand, if Perl's array syntax isn't a good fit for database access (bingo) then you propose we change our array syntax to be a better fit. That makes no sense at all. Perl 6 will allow you to mutate your syntax at runtime any way you want. If you want to create some awful embedded-database-access beast then you're more than free to do so. It's my opinion that your misguided project is already fully possible in Perl 5. I think you should get started as soon as possible - the sooner to realize what a huge mistake it is to try to replace SQL with Perl! -sam
Re: Multi-dimensional arrays and relational db data
On Sun, Jun 10, 2001 at 01:56:21PM -0500, Me wrote: Yes. But if the syntax for arrays and db data are to be simultaneously the same and as ideal as possible, then either the core array syntax needs to be relatively ideal for relational db data, or one needs to redefine the array syntax to match a created db syntax and thus have a version of perl that doesn't use the standard array syntax. Other people have pointed out that you are not making any sense, but I will try again: It doesn't matter, because the user can redefine the syntax anyway. -- yes /dev/kmem # Shutdown is broken. This'll have to do - plan9 has a bad day
Re: Multi-dimensional arrays and relational db data
If array syntax really is a good analogy to database access (it's not) Agreed. So long as you are talking about Perl 5's arrays. I disagree, if you are talking about 2 dimensional structures. If you don't think a two dimensional structure is a good basic fit with a lot of database access, what do you suggest IS a good fit? array (or hash, you don't seem to care) Records have named fields so one dimension is like a hash. Get started now - Perl 5's.. ...arrays are one dimensional. tie and overload support should be more than sufficient. Aiui, overload won't get me past the one-dimensionality of Perl 5's arrays. Without a native 2d syntax, the win from tying isn't significant. On the other hand, if Perl's array syntax isn't a good fit for database access (bingo) then you propose we change our array syntax to be a better fit. I don't think it's reasonable to say I propose you change something that hasn't yet been defined. Rather, it is precisely because you haven't yet defined the MD array syntax that I thought it worth at least considering how it parallels db data BEFORE you define it.
Re: Multi-dimensional arrays and relational db data
At 05:58 PM 6/10/2001 -0400, Sam Tregar wrote: SQL via DBI. It's got a terrible learning curve but it's still around for a reason. You learn all about SQL's strengths if you start trying to replace it with arrays and hashes. Go forth and learn! He's right. I do a lot of DBI stuff with Oracle, and every so often I have a hankering for some kind of structured tied variable that would look like my database. Then I wake up and realize that modeling of a single table doesn't do squat for me, and modeling of the whole database requires knowledge of the foreign key relationships, and even with those, no variable structure suggests itself. And then I remember this is why I wrote object classes modeling the things I want to get out of/put into the database. Even if your database is so simple that you do just want to model single tables, it would be easy to build atop DBI. DejaVuDidn't we have this discussion about six months ago???/ I do think it's worth thinking about new variable types for Perl. I keep thinking to myself, how do we continue the progression C - Perl 4/5 - ..., where Perl 4/5 said things like, let's make hashes basic variable types, since they're so mind-bogglingly useful. Not that you couldn't do them in C with library functions, but look how much easier they are to read. So I think, what's the next step? But I just keep drawing a blank. Once I spent some time wondering about design patterns and templates, but that didn't lead anywhere either. The thing I don't want to happen is for all the work to go into O-O features, because at the end of the day, all O-O programs look much the same: instantiate a bunch of objects and call methods on them. Then it seems like the only thing left to talk about is whether you use - or . for component separators. I want Perl to make it easy to implement algorithms, rather than just trying to compete on the same playing field as other O-O languages, because it's just too handicapped by things like performance and lack of static analysis.
Re: Multi-dimensional arrays and relational db data
On Sun, 10 Jun 2001, Me wrote: Agreed. So long as you are talking about Perl 5's arrays. I disagree, if you are talking about 2 dimensional structures. You appear to have some fundamental misunderstanding about Perl 5. Perl 5 does indeed support multidimentional arrays: my @matrix = ( [ 1 2 3 ] [ 4 5 6 ] [ 7 8 9 ] ); print $matrix[1][2]; You could easily use either tie or the new -[] overloading in Perl 5 to access relational databases in Perl 5. Are you going to make me show you an example before you believe me? If you don't think a two dimensional structure is a good basic fit with a lot of database access, what do you suggest IS a good fit? SQL via DBI. It's got a terrible learning curve but it's still around for a reason. You learn all about SQL's strengths if you start trying to replace it with arrays and hashes. Go forth and learn! -sam
Re: Multi-dimensional arrays and relational db data
Sam, I don't think we're on the same wavelength. So a direct response seems pointless. Larry himself said: while allowing multidimensional arrays to distinguish between [this and that] in a manner more conducive to database programming Ok, I did s/numerical/database/, but what's a programming domain between friends?
Re: Multi-dimensional arrays and relational db data
modeling of the whole database Doesn't seem like it's hard to do. With MD arrays, you are all but there anyway: Table: A 2d array. Whatever is introduced to more directly support handling MD arrays could very plausibly help in more directly supporting handling of single table data. This includes basic syntax, and standardized MD array sorting, filtering, and aggregating functions (which will all but inevitably emerge once standard direct support for MD arrays is in place). Virtual dataset from one table: A 2d 'slice' or rectangle. Both slices must support, er, discontiguousness. 'Horizontal' slice picks certain fields from the set available. I would expect it to be a small (or zero) hop, from whatever MD array syntax Perl 6 ends up with, to having a slice serve as a field selector. 'Vertical' slice picks certain records based on column data. This will be a bigger hop, involving some array filtering function, but it again seems inevitable that Perl 6's MD arrays will have this sort of filtering function/feature available. So, again, possibly zero extra work required. Dataset from multiple 'joined' tables (A pair of joined tables can be visualized as two spreadsheet like grids that intersect at right angles with the intersection point being the joined column. The vertical slice picks out rows where the joined column values from the two tables are the same.) Whatever is used to support vertical slicing based on col data should be extensible to do joining too. With the above, you have all the direct support I need to do all the non-transactional database crunching I have done with perl for the last several years. ALL of it. I'm pretty sure I'd be able to do grand sweeping db operations in one liners! DejaVuDidn't we have this discussion about six months ago???/ I searched the perl6-all archives for any discussion of this sort of stuff when I first started to think about it. I used the string SQL. I read all the posts (about 50-100 iirc). None went down this path.
Re: Multi-dimensional arrays and relational db data
At 06:06 PM 6/10/2001 -0500, Me wrote: Dataset from multiple 'joined' tables (A pair of joined tables can be visualized as two spreadsheet like grids that intersect at right angles with the intersection point being the joined column. The vertical slice picks out rows where the joined column values from the two tables are the same.) Whatever is used to support vertical slicing based on col data should be extensible to do joining too. I can't envisage this. Particularly I can't envisage it for multicolumn joins or outer joins. Perhaps you could reveal an example. I don't know where I was thinking of this being a previous thread. There is some interesting stuff in http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-03/msg01830.html and the followups. I'm still enamored of the $dbh =~ qs// idea.
Re: Multi-dimensional arrays and relational db data
On Sun, Jun 10, 2001 at 03:31:09PM -0700, Peter Scott wrote: Even if your database is so simple that you do just want to model single tables, it would be easy to build atop DBI. That'd be Tie::DBI, then. scream This is the kind of thing that can be dealt with perfectly satisfactorily with external modules; ergo, it does NOT need to be in the core. Ergo, it probably *does* *not* *need* *discussing* *here*. You're (that's to say, the person at self-reference.com who is not prepared to reveal their real name) exhibiting a common trait amongst perl6-language people, and that's to concentrate on a specific application *of* the language, and then from there making the bizarre leap of logic to believing that it needs to be *in* the language. This is hugely bogus and leads very quickly to second system effect, as the RFC process has shown us. Don't do it. Focus on the bigger picture instead. Good language design starts when you stop thinking I want this and this and this and start thinking how can we solve all these problems in one generalized way? But of course, I'm sure you already know what makes good language design, because otherwise you wouldn't be mouthing off in here. Right? /scream -- Why do programmers get Halloween and Christmas mixed up? Because OCT(31) == DEC(25)
Re: Multi-dimensional arrays and relational db data
[joining 2d arrays] I can't envisage this... Perhaps you could reveal an example. Well, for a trivial example, here's two 2d arrays: foo, bar, baz, qux, quux, waldo and rab, foo, baz, xuuq, qux, zug Joining the first col of array 1 with the second col of array 2 would pick both rows from both arrays. Seems simple to me. Perhaps you meant the concrete method and/or syntax to achieve the join, or to reference the two arrays, or to reference the result table. But thinking of concrete details like that is way premature. For one thing, if Simon and Sam are anyone to go by, this thread has zero chance of getting over the basic this is worth considering consensus hurdle, so concrete details are pointless. Particularly I can't envisage it for multicolumn Joining the first and last cols of array 1 with the second and last cols of array 2 would pick the first row from both arrays. Again, this seems simple to me. If you were considering my intersecting grids example, you need to view the multiple columns from each table as one column. outer joins. Let's just consider a left outer join. That just means picking all rows from the first table referenced in what syntax is used (the left table) and either matching rows from the right table, or pretending there is a matching blank row from the right table. So, an outer left join between array 1 and 2 above, joined on the last col of array 1 and the last col of array 2 would pick both rows of array 1, and the first row of array 2, to go with the first row of array 1, and an unitialized row from array 2 to go with the second row of array 1. It's cumbersome describing this in english, but I would expect it to be really brain dead simple intuitive as a computer syntax and semantics.
Re: Multi-dimensional arrays and relational db data
On Sun, 10 Jun 2001, Sam Tregar wrote: On Sun, 10 Jun 2001, Me wrote: Agreed. So long as you are talking about Perl 5's arrays. I disagree, if you are talking about 2 dimensional structures. You appear to have some fundamental misunderstanding about Perl 5. Perl 5 does indeed support multidimentional arrays: my @matrix = ( [ 1 2 3 ] [ 4 5 6 ] [ 7 8 9 ] ); print $matrix[1][2]; You could easily use either tie or the new -[] overloading in Perl 5 to access relational databases in Perl 5. Are you going to make me show you an example before you believe me? At the risk of receiving a flame perl5 does not have multi-dimensional arrays. It has something that will do the job with a massive memory overhead ands lots of pain when dimensionality is high. If it had true support for N-dim arrays then PDL would never have been invented. The main problem PDL has is that Perl does not have a syntax for N-dim slices so it has to bolt something on the side by specifying a slice as a string. (see eg PDL::Slices). Numerical applications will get a significant boost if N-dim arrays with native slicing are possible in perl6. -- Tim Jenness JAC software http://www.jach.hawaii.edu/~timj
Re: Multi-dimensional arrays and relational db data
On Sun, Jun 10, 2001 at 04:05:20PM -1000, Tim Jenness wrote: At the risk of receiving a flame perl5 does not have multi-dimensional arrays. It has something that will do the job with a massive memory overhead ands lots of pain when dimensionality is high. If you need it, I can finish off multi-dimensional array access in Tie::VecArray, then you'll have true multi-dimensional arrays. Very compact, but slower than a snail race in January since its tied. :( Perl 5, with its dynamically resized scalars, can't easily have vector-based arrays. Since Perl 6 is introducing types it should be safe to assume that an array of type 'int' (or some other fixed-width type) will be optimized to a vector. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Multi-dimensional arrays and relational db data
On Sat, Jun 09, 2001 at 10:57:25PM -0500, Me wrote: For this post (and hopefully thread), I'm interested in focusing on the fact that a multi-dimensional array syntax, whatever it might end up being, is clearly going to be a direct analog of tables You're on the wrong list. All the language aspects here are covered since you can redefine the syntax on the fly and/or tie, a point Simon has been beating you over the head with. The Perl Object-Oriented Persistence Group list is probably where you want to discuss the database ideas. Let me warn you, when it comes to SQL, its never as easy as you think. http://lists.sourceforge.net/lists/listinfo/poop-group -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Multi-dimensional arrays and relational db data
On Sun, Jun 10, 2001 at 03:31:09PM -0700, Peter Scott wrote: He's right. I do a lot of DBI stuff with Oracle, and every so often I have a hankering for some kind of structured tied variable that would look like my database. Then I wake up and realize that modeling of a single table doesn't do squat for me, and modeling of the whole database requires knowledge of the foreign key relationships, and even with those, no variable structure suggests itself. And then I remember this is why I wrote object classes modeling the things I want to get out of/put into the database. Alzabo, Class::DBI, Tangram, etc... -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Multi-dimensional arrays and relational db data
At 11:07 PM 6/10/01 -0500, Me wrote: [joining 2d arrays] I can't envisage this... Perhaps you could reveal an example. Seems simple to me. Perhaps you meant the concrete method and/or syntax to achieve the join, or to reference the two arrays, or to reference the result table. But thinking of concrete details like that is way premature. No it isn't. Your position depends on having a syntax so simple that it is somehow worth implementing as a native capability instead of the tied modules others have pointed out. My point is that I don't think there is a syntax that's simple enough to be worth it. Particularly I can't envisage it for multicolumn Joining the first and last cols of array 1 with the second and last cols of array 2 would pick the first row from both arrays. Again, this seems simple to me. I understand relational joins. I'm looking for the syntax you propose to use for expressing them. It's cumbersome describing this in english, but I would expect it to be really brain dead simple intuitive as a computer syntax and semantics. I still don't think there's anything to be gained here. As far as I can tell, you're saying, I want it to be easier to express relational database operations. Me too. I just don't think they get any easier than they already are. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Multi-dimensional arrays and relational db data
Previously, on St. Elsewhere... Simon(e) writes... But of course, I'm sure you already know what makes good language design, because otherwise you wouldn't be mouthing off in here... Why is it that Me is *mouthing off*, but you're not? Why is that? What makes you so *special*? The fact you wrote a Perl book?! A book with more typographical errors than it has pages? *Zut!* Me may be s/wrong/clueless/... but I don't think any one of you has actually understood what he/she is talking about. Me is at least one level of abstraction higher than all of the rebuttals that have been fired back in this thread. That's why Me mentioned *wavelength* in a previous post... That being said - I am not disgreeing with s/you/Sam/Peter/etc/... mySQL...together with *PHP4 and Zend*...is the only way to go! Right or wrong, Me or *you* for that matter...has the same right to post to this list...Otherwise, it should be a private list, perhaps: Larry Wall, Damian and the Acolytes of Doom debating Perl6 or... Just how much $foo can dance on the head of a dot operator Is that you really want? Why can't we (cough...) just get along? Think about it (for a change...). Now for something *completely* different... Simon(e) writes... You're (that's to say, the person at self-reference.com who is not prepared to reveal their real name)... If you want to know who he (or she!) is, pls send me email off-list. Hint: Me might just be the first two letters in their family name... Example: Me Or, maybe not... Must dash! -- Vijay -- He was always a miserable child. Oxford was just our excuse. __
Re: Multi-dimensional arrays and relational db data
As this has drifted off-topic, I've set the Reply-To on this to POOP-group, please send replies there and not perl6-language. On Sun, Jun 10, 2001 at 06:06:27PM -0500, Me wrote: modeling of the whole database Doesn't seem like it's hard to do. HA! Think Lights Out: It...is...harder...than...you...think! You may wish to read this thread about lazy arrays and object persistence to get an idea of what you're getting into. http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/ I'm not trying to discourage you (well, maybe I am), just trying to transplant some hind-sight from me to you. Table: A 2d array. Rows are refered to by primary keys. Primary keys are often not numbers. Switch to a hash and you might have a chance. Whatever is introduced to more directly support handling MD arrays could very plausibly help in more directly supporting handling of single table data. This includes basic syntax, and standardized MD array sorting If you can map an aribtrary Perl sort function onto SQL and do it efficiently AND make it work on more than one database, I will be extremely impressed. filtering, and aggregating functions (which will all but inevitably emerge once standard direct support for MD arrays is in place). Again, this must all be mapped onto SQL. To do this efficiently is extremely difficult. Virtual dataset from one table: A 2d 'slice' or rectangle. Both slices must support, er, discontiguousness. 'Horizontal' slice picks certain fields from the set available. I would expect it to be a small (or zero) hop, from whatever MD array syntax Perl 6 ends up with, to having a slice serve as a field selector. Two problems. SQL columns have names, not numbers. Refering to them by number is a Great Leap Backward. Use a hash. 'Vertical' slice picks certain records based on column data. The 23rd row of a table doesn't have much meaning without a sort order. Even then, its relatively rare to want to pick out the 23rd row of a SELECT. Typically you just get them in order. Occasionally you'll want a slice (ie. rows 51-100) but few databases support this syntax efficiently (MySQL is an exception). A filehandle would be a closer analogy. In fact, its very close. Trying to model an SQL table as an array is similar to modeling a file as an array. For example, $lines = @file; is expensive just as $rows = @select (assuming there's a WHERE clause involved). $file[42] and $select[42] are also both expensive. And what do you do with rows 0..41? Throw them out? Hang onto them and eat memory? Dataset from multiple 'joined' tables (A pair of joined tables can be visualized as two spreadsheet like grids that intersect at right angles with the intersection point being the joined column. The vertical slice picks out rows where the joined column values from the two tables are the same.) That will only work for extremely simple joins. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
