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 does
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 y
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
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 c
On Mon, Jun 11, 2001 at 10:33:20PM -0500, David L. Nicol wrote:
> 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
Hask
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 compi
[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 whic
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.
--
> -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:28
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 wa
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 wa
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 syn
Simon Cozens wrote:
>
> 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
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 w
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 exe
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 ex
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
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.
Considerin
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
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 ar
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 attac
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
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
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 t
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
> do
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 langu
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 mu
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 inde
> > [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
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.
This is the kind of thing that can be dealt with perfectly satisfactorily
with externa
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 whe
> 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 tabl
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
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 Orac
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 = (
> 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, w
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 t
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
> 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 s
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.
--
40 matches
Mail list logo
