Good luck w/ your studies. Viable alternatives to SQL are always welcome.
;-)
On 3/23/07, Darren Duncan <[EMAIL PROTECTED]> wrote:
At 7:15 PM -0700 3/23/07, John Beppu wrote:
>You might find Dee interesting:
>
>http://www.quicksort.co.uk/
This Dee project in Python is a worthy thing to study
At 7:15 PM -0700 3/23/07, John Beppu wrote:
You might find Dee interesting:
http://www.quicksort.co.uk/
A relational language extension for Python
Inspired by 'The Third Manifesto', a book by Chris Date and Hugh Darwen,
we're putting forward an implementation of a truly relational language usi
You might find Dee interesting:
http://www.quicksort.co.uk/
A relational language extension for Python
Inspired by 'The Third Manifesto', a book by Chris Date and Hugh Darwen,
we're putting forward an implementation of a truly relational language using
Python (Dee). We address two problems:
1.
On 3/18/07, Darren Duncan wrote:
On Sun, 18 Mar 2007, Aaron Crane wrote:
> That's easy even in Perl 5. This modifies %hash in-place:
> my @values = delete @[EMAIL PROTECTED];
> @[EMAIL PROTECTED] = @values;
[...]
If %hash contained keys a,b,c and @old_names was a and @new_names
was b
On Sun, 18 Mar 2007, Uri Guttman wrote:
> as for rename on hash keys, why not call it rekey? also even if it is
> called rename as a hash method it is different than rename as a function
> to rename a file so there is no ambiguity.
The name "rekey" or some such sounds like a reasonable name, and i
> "AC" == Aaron Crane <[EMAIL PROTECTED]> writes:
AC> That's easy even in Perl 5. This modifies %hash in-place:
AC> my @values =
AC> @[EMAIL PROTECTED] = @values;
you can even do:
@[EMAIL PROTECTED] = delete @[EMAIL PROTECTED];
and i am sure a simple p6 thing can be wri
On Sun, 18 Mar 2007, Aaron Crane wrote:
> David Green writes:
> > In the meantime, Darren's proposal still raises a lot of interesting
> > language questions. For example, how *do* you rename a hash key?
>
> That's easy even in Perl 5. This modifies %hash in-place:
>
> my @values = delete @[E
David Green writes:
> In the meantime, Darren's proposal still raises a lot of interesting
> language questions. For example, how *do* you rename a hash key?
That's easy even in Perl 5. This modifies %hash in-place:
my @values = delete @[EMAIL PROTECTED];
@[EMAIL PROTECTED] = @values;
Whil
On 3/16/07, Darren Duncan wrote:
On Wed, 7 Mar 2007, Smylers wrote:
>[...]
Perl is a better language than SQL, in general, [...]
Likewise, we shouldn't have to write in SQL, or in pseudo-Perl-SQL,
but just write in Perl.
A database is supposed to be a base for *data*, after all. I'd love
to
P.S. Sorry for not replying to this for so long, but I have been without
a computer for the last week ... and possibly for the next week too ...
right now, I'm on someone else's machine.
--
On Wed, 7 Mar 2007, Smylers wrote:
> On February 27th Darren Duncan writes:
> > One common us
On February 27th Darren Duncan writes:
> At 4:45 PM + 2/27/07, Nicholas Clark wrote:
>
> > > 4. rename():
>
> > rename is a Perl 5 builtin.
> I see this situation as being similar to Dog.bark() vs Tree.bark();
The difference is that those are methods. Having different objects
which have
At 4:45 PM + 2/27/07, Nicholas Clark wrote:
> 4. rename():
rename is a Perl 5 builtin. I didn't think that it had been dropped for
Perl 6.
At 6:22 PM + 2/27/07, Smylers wrote:
> 1. join() aka natural_join():
Remember that Perl already has a C function, for joining strings.
To b
Darren Duncan writes:
> I believe that ... some common relational operations would be a lot
> easier to express if Perl 6 had a few more operators that make them
> concise.
I am prepared to believe that. But what I'm unclear on is when I'd want
to perform a common relational operation.
Please c
On Tue, Feb 27, 2007 at 12:18:20AM -0800, Darren Duncan wrote:
> 4. rename():
>
> function rename of Mapping (Mapping $m, Str $old_k, Str $new_k) {
> ... }
>
> This operator takes one Mapping argument and derives another
rename is a Perl 5 builtin. I didn't think that it ha
Darren Duncan writes:
> I believe that there is some room for adding several new convenience
> operators or functions to Perl 6 that are used with Mapping and Hash
> values.
> I also want to emphasize that I see this functionality being generally
> useful, and that it shouldn't just be shunted off
All,
I believe that there is some room for adding several new convenience
operators or functions to Perl 6 that are used with Mapping and Hash
values.
Or getting more to the point, I believe that the need for the
relational data model concept of a tuple (a "tuple" where elements
are address
16 matches
Mail list logo
