Re: DBI v2 - The Plan and How You Can Help

[Dean Arnold]

RE: Placeholders: since DBIv1 already supports both forms of
PH's, I see no reason to deprecate or abandon either form.
Furthermore, to my knowledge, none of (ODBC, JDBC, ADO.NET)
has abandonded or deprecated the ? form, so I don't see
the need for DBI to.

RE: LOBs and "SQL Parse Trees": having recently implemented
LOB support for a JDBC driver (and soon for a DBD), I can assure
you that SQL parse trees are unneeded to support them. For databases
robust enough to support LOBs, they'll almost always provide
sufficient metadata info and/or SQL syntax to manipulate them;
only databases which don't support LOBs have that difficulty.
Furthermore, a quick review of the current DBI will indicate that
Mssr. Bunce has already implemented some stub methods for
generalized support.

RE: SQL Parse Trees (or other non-SQL query input)

Since none of (ODBC, JDBC, ADO.NET) seems compelled to
impose this concept on driver writers, I don't see why
DBI should be the vanguard.

However, implementing a subclass of DBI to support it
seems technically feasible, so I'd suggest that
those of you championing this requirement implement one
on DBI v1. Feel free to use DBIx::Chart to bootstrap
your project. As the proponents of this notion
are so generous with their requirements for those of us
who develop DBI drivers and/or contribute
development efforts to the DBI itself, I'm sure they won't
object if I provide a few requirements:

1. For DBI drivers which support them, your subclass
must support
- arbitrary numbers and levels of JOINs (including
various outer, and non-equijoins)
- arbitrarily nested subqueries (including correlated)
- HAVING and GROUP BY clauses
- ORDER and LIMIT clauses
- updatable cursors
- database-specific SQL extensions

2. It must function with current versions of 40% of DBD's
created or updated on CPAN since Jan. 1, 2003. Said 40%
must include
- DBD::ODBC
- DBD::Oracle
- DBD::Pg
- DBD::MySQL
- DBD::CSV
- one 'exotic' driver (e.g.,
DBD::iPod or DBD::Amazon, but excluding DBD::Google,
whose syntax is too simplistic for a meaningful test)

(FWIW: Past experience (e.g., execute_array()) leads me to believe
Mssr. Bunce's requirements are likely much higher than 40%, so
"choose wisely, grasshopper")

BTW: If you need a list of DBD's meeting said requirement, let me know,
I just pulled one down.

3. It cannot require any changes to either DBI or the
selected DBD's.

4. It must produce a database-independent conforming set of error codes
(feel free to use SQLSTATE aka $h->state)

5. It must be uploaded to CPAN, and list, and demonstrably function against,
the DBD's selected in requirement (2) above.

Once you've implemented the subclass, you'll have empirical proof
of the feasibility, and, more importantly, you'll be able to port
the subclass to DBIv2, without any additional burden on DBI
developers.

Regards,
Dean Arnold
Presicient Corp.

Raw bytes in perl6

[David Formosa \(aka ? the Platypus\)]

How do we intend to manipulate raw binary in Perl6?  Perl5's use
bytes; pragma is rather poor (forcing all strings to be raw in its
scope or requiring do {use bytes; ...} type tricks to deal with them)
and now Perl6 has real typing perhaps it would be more usefull to have
a bytestring type (or and octect string type) that doesn't get
utf8ed.

-- 
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.

Re: User-defined infix subs/methods?

[Autrijus Tang]

On Sat, Jul 09, 2005 at 03:58:45PM -0700, Larry Wall wrote:
> It should take a little more effort to mess with the minds of
> unsuspecting modules, so maybe the standard syntax is cloned out of
> *STANDARD_PERL_6 or some such scary package name.  It's the default for
> starting all require-like Perl 6 parses.

Note that this requirement is already satisfied, under the "separate
compilation doctrine" in the hackathon notes.

Each compilation unit needs to be compiled without any information to
the symbols in the caller environment.  It may export symbols, but may
not silently make use of caller's symbols, which naturally includes
user-defined operators.

Thanks,
/Autrijus/


pgpqaHnKc8q8K.pgp
Description: PGP signature

Re: DBI v2 - The Plan and How You Can Help

[Dean Arnold]

BTW: If you need a list of DBD's meeting said requirement, let me know,
I just pulled one down.



Sure, send it over.


[   ] DBD-ADO-2.94.tar.gz 31-Jan-2005 02:4041k  GZIP compressed docume>
[   ] DBD-ASAny-1.13.tar.gz   31-Oct-2003 15:0030k  GZIP compressed docume>
[   ] DBD-Amazon-0.10.tar.gz  23-May-2005 15:4158k  GZIP compressed docume>
[   ] DBD-AnyData-0.08.tar.gz 19-Apr-2004 03:1620k  GZIP compressed docume>
[   ] DBD-CSV-0.22.tar.gz 31-Mar-2005 18:0636k  GZIP compressed docume>
[   ] DBD-Chart-0.81.tar.gz   26-Jan-2005 19:59   212k  GZIP compressed docume>
[   ] DBD-DB2-0.78.tar.gz 19-Sep-2004 10:3475k  GZIP compressed docume>
[   ] DBD-File-0.34.tar.gz21-Jun-2005 01:14 8k  GZIP compressed docume>
[   ] DBD-Google-0.11.tar.gz  04-Mar-2004 18:5120k  GZIP compressed docume>
[   ] DBD-Informix-2005.01..> 14-Mar-2005 19:01   267k  GZIP compressed docume>
[   ] DBD-Ingres-0.51.tar.gz  12-Jan-2004 06:1846k  GZIP compressed docume>
[   ] DBD-InterBase-0.43.t..> 25-Feb-2004 04:3078k  GZIP compressed docume>
[   ] DBD-LDAP-0.06.tar.gz12-Mar-2004 21:4825k  GZIP compressed docume>
[   ] DBD-Log-0.22.tar.gz 27-May-2005 06:5114k  GZIP compressed docume>
[   ] DBD-MaxDB-7_5_00_26...> 18-Apr-2005 08:3879k  GZIP compressed docume>
[   ] DBD-Mimer-1.00.tar.gz   25-Nov-2003 15:5171k  GZIP compressed docume>
[   ] DBD-Mock-0.27.tar.gz11-Jul-2005 11:3634k  GZIP compressed docume>
[   ] DBD-Multiplex-1.96.t..> 25-Jan-2005 17:30 9k  GZIP compressed docume>
[   ] DBD-ODBC-1.13.tar.gz08-Nov-2004 10:1595k  GZIP compressed docume>
[   ] DBD-Oracle-1.16.tar.gz  22-Oct-2004 05:17   230k  GZIP compressed docume>
[   ] DBD-Pg-1.43.tar.gz  23-Jun-2005 08:09   128k  GZIP compressed docume>
[   ] DBD-PgPP-0.05.readme09-May-2004 08:06 3k
[   ] DBD-PgPP-0.05.tar.gz13-May-2004 12:5616k  GZIP compressed docume>
[   ] DBD-PgSPI-0.02.tar.gz   06-Dec-2004 00:3021k  GZIP compressed docume>
[   ] DBD-Redbase-0.22.tar.gz 21-Oct-2003 22:5128k  GZIP compressed docume>
[   ] DBD-SQLite-1.09.tar.gz  20-Jun-2005 11:42   464k  GZIP compressed docume>
[   ] DBD-SQLite2-0.33.tar.gz 10-Sep-2004 11:50   355k  GZIP compressed docume>
[   ] DBD-Sprite-0.56.tar.gz  12-Jun-2005 21:5286k  GZIP compressed docume>
[   ] DBD-Sybase-1.05.tar.gz  19-Dec-2004 05:01   183k  GZIP compressed docume>
[   ] DBD-TSM-0.04.readme 22-Mar-2005 16:05 2k
[   ] DBD-TSM-0.04.tar.gz 23-Jun-2005 16:32 9k  GZIP compressed docume>
[   ] DBD-Teradata-1.20.ta..> 17-Sep-2004 19:2736k  GZIP compressed docume>
[   ] DBD-Trini-0.01.tar.gz   15-Jul-2003 03:1821k  GZIP compressed docume>
[   ] DBD-Unify-0.31.tgz  16-Mar-2004 11:0731k  GZIP compressed tar ar>
[   ] DBD-XBase-0.241.tar.gz  21-Nov-2003 09:25   109k  GZIP compressed docume>
[   ] DBD-Yaswi-0.01.tar.gz   21-Feb-2005 19:46 4k  GZIP compressed docume>
[   ] DBD-iPod-0.01.tar.gz06-Jan-2005 02:4113k  GZIP compressed docume>
[   ] DBD-mysql-3.0002.tar.gz 11-Jul-2005 12:49   127k  GZIP compressed docume>
[   ] DBD-mysql-AutoTypes-..> 02-Mar-2004 06:03 3k  GZIP compressed docume>
[   ] DBD-mysql-SimpleMySQ..> 28-Apr-2004 16:39 4k  GZIP compressed docume>
[   ] DBD-mysqlPP-0.04.tar.gz 24-Jan-2003 06:14 7k  GZIP compressed docume>

- Dean

WTF? - Re: method calls on $self

[Juerd]

Larry Wall skribis 2005-07-11 18:29 (-0700):
> is that we simply outlaw .foo notation at *compile* time in those
> scopes where we know (at compile time) that $_ and $?SELF diverge.
> In such a scope you *must* specify $_ or $?SELF (or equivalent).

What?

That makes having a default at all useless, it makes moving code without
breaking it impossible again, it requires a lot of extra typing with
shifted keys, it adds an arbitrary looking exception, and it is wildly
undwimmy and impractical, and thus unperlish by every definition I know.

This is, by far, the silliest solution for this problem that I have seen
proposed, because it is a combination of almost all the cons, and comes
at a time in which all the pros and cons of other solutions are already
known and discussed.

> That's the default, and I'm not changing my mind ever again, at least
> till next week.

I can wait till next week.

>   use self "this";
>   use self "self";
>   use self "o";
>   use self "./";
>   use self "";

Any of these must be the default, and frankly I do not care much which
one it is, if that means the current non-solution goes away.

Obviously, use self "" is the least attractive of these, but I would
still prefer it to outlawing .foo.

If the default isn't sane, the language isn't sane. That there is a
pragma to change things, should never be a reason to stop picking good
defaults.

> Yes, this is possibly a hazard for cut-n-pasters.  But then,
> you weren't supposed to be cutting-n-pasting anymore, were you?

No, but I do refactor. I do add loops and methods around existing code.
I do use for (or given in p6) to topicalize, to be able to type LESS.

In Perl 5, I really hate

for ($object) {
$_->method(...);
$_->method(...);
$_->method(...);
}

And the Perl 6 equivalent until your revelation,

given $object {
.method(...);
.method(...);
.method(...);
}

was the perfect solution. Killing off a useful and much used idiom even
before the first release is quite an accomplishment.

Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: WTF? - Re: method calls on $self

[Yuval Kogman]

I feel a "me too" post is in order.


I've written code that is 2-3 levels of nested given/when in a
method of an object that wasn't the topic.

I did not feel confused at all, juggling .foo and ./foo, which are
visually distinct, and different to type. They convey a big
difference of meaning, even if it's only 1 char apart.

I think a solution to the problem of being able to use those two
well, is not a solution, because there isn't a problem.

On Tue, Jul 12, 2005 at 12:59:22 +0200, Juerd wrote:
> Larry Wall skribis 2005-07-11 18:29 (-0700):
> > is that we simply outlaw .foo notation at *compile* time in those
> > scopes where we know (at compile time) that $_ and $?SELF diverge.
> > In such a scope you *must* specify $_ or $?SELF (or equivalent).
> 
> What?
> 
> That makes having a default at all useless, it makes moving code without
> breaking it impossible again, it requires a lot of extra typing with
> shifted keys, it adds an arbitrary looking exception, and it is wildly
> undwimmy and impractical, and thus unperlish by every definition I know.
> 
> This is, by far, the silliest solution for this problem that I have seen
> proposed, because it is a combination of almost all the cons, and comes
> at a time in which all the pros and cons of other solutions are already
> known and discussed.
> 
> > That's the default, and I'm not changing my mind ever again, at least
> > till next week.
> 
> I can wait till next week.
> 
> > use self "this";
> > use self "self";
> > use self "o";
> > use self "./";
> > use self "";
> 
> Any of these must be the default, and frankly I do not care much which
> one it is, if that means the current non-solution goes away.
> 
> Obviously, use self "" is the least attractive of these, but I would
> still prefer it to outlawing .foo.
> 
> If the default isn't sane, the language isn't sane. That there is a
> pragma to change things, should never be a reason to stop picking good
> defaults.
> 
> > Yes, this is possibly a hazard for cut-n-pasters.  But then,
> > you weren't supposed to be cutting-n-pasting anymore, were you?
> 
> No, but I do refactor. I do add loops and methods around existing code.
> I do use for (or given in p6) to topicalize, to be able to type LESS.
> 
> In Perl 5, I really hate
> 
> for ($object) {
> $_->method(...);
> $_->method(...);
> $_->method(...);
> }
> 
> And the Perl 6 equivalent until your revelation,
> 
> given $object {
> .method(...);
> .method(...);
> .method(...);
> }
> 
> was the perfect solution. Killing off a useful and much used idiom even
> before the first release is quite an accomplishment.
> 
> Disallowing .method here means a huge step back in time. Back to
> $_.method or $object.method.
> 
> 
> Juerd
> -- 
> http://convolution.nl/maak_juerd_blij.html
> http://convolution.nl/make_juerd_happy.html 
> http://convolution.nl/gajigu_juerd_n.html

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: uhm, no, I think I'll sit this one out..: neeyah!



pgpL6XkyQ00ZQ.pgp
Description: PGP signature

Re: WTF? - Re: method calls on $self

[Aankhen]

On 7/12/05, Juerd <[EMAIL PROTECTED]> wrote:
> [snip]
> Disallowing .method here means a huge step back in time. Back to
> $_.method or $object.method.
> [snip]

I agree with what is being said here.  `.method` is a great way to
eliminate a lot of repetitive, tedious typing.  Surely there is a
viable alternative that doesn't involve outlawing it?

Aankhen

What do use and require evaluate to?

[Ingo Blechschmidt]

Hi,   
   
what do use and require evaluate to?  
  
S06 suggests it's probably some kind of Module object:   
  The result of a use statement is a (compile-time) object that also has   
  an .assuming method, allowing the user to bind parameters in all the   
  module's subroutines/methods/etc. simultaneously:   
 
  (use IO::Logging).assuming(logfile => ".log")   
   
We could make (use Foo) evaluate to the class object Foo,   
allowing:   
   
my $foo = (use Foo).new(...);   
   
Alternatively, we could go the Perl 5 way and return the   
last thing evaluated in Foo.pm (which might be a Module   
object, assuming that module Foo {...} evaluates to Foo).   
   
   
What do successive uses of use and require evaluate to?   
Perl 5 is inconsistent:   
   
$ cat > Foo.pm   
package Foo; 42;   
$ perl -we 'warn require Foo; warn require Foo'   
42 at -e line 1.   
1 at -e line 1.   
   
I'd like Perl 6's use and require to return the same thing.   
   
   
In Perl 5, %INC maps the partial path names of the modules   
loaded to their absolute ones. What should the keys and values   
of %*INC be in Perl 6?   
   
   
--Ingo   
   
--
Linux, the choice of a GNU | self-reference, n. - See self-reference 
generation on a dual AMD   |
Athlon!|

Re: MML dispatch

[Mark Reed]

On 2005-07-11 23:46, "Damian Conway" <[EMAIL PROTECTED]> wrote:
> 3. Work out the Manhattan distance from the argument list to each
>variant's parameter list.

OK, sorry if I missed this in an earlier discussion.  For purposes of
calculating this Manhattan distance, I gather that we're treating lists of N
arguments/parameters as points in N-space.  I further assume that the
monoaxial distance between a parameter coördinate and the corresponding
argument coördinate - the distance between two types, where the types are
known to be assignment-compatible - is the number of inheritance steps
between them?

And one more dumb question: why is it that the L[1] metric is superior to
the L[2] metric for this purpose?

Re: MML dispatch

[TSa (Thomas Sandlaß)]

Mark Reed wrote:

And one more dumb question: why is it that the L[1] metric is superior to
the L[2] metric for this purpose?


I am also interested in the rational behind the approach to manage MMD
my means of a metric instead of a partial order on the types.
Metric is a geometric concept which in my eyes doesn't fit type
theory.

I would join Luke and recommend 'pure' MMD. That is there has to
be exactly one target that is most specific on all positions relevant
for the dispatch. In particular do I dislike the the property of a
metric that several smaller mismatches can be compensated by a good match.
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[TSa (Thomas Sandlaß)]

Damian Conway wrote:

This is a much less dwimmy solution than Yuval's or Luke's, but it has the
advantage that those eight steps reduce to eight words:

Unique least-inherited most-specialized match, or default


Do I read this correctly as dispatching partly in the class hierarchy
and partly in the type hierarchy? Or do you mean with 'least-inherited'
most specific non-where type and with 'most-specialized' the strictest
where clause? To me these two concepts are the same if you think of the
does operator as a predicate:

multi sub foo ($x where { $x.does(Num) }) {...}

beeing the same as

multi sub foo (Num $x) {...}
--
TSa (Thomas Sandlaß)

Re: How to write a self.pm (Re: method calls on $self)

[TSa (Thomas Sandlaß)]

Autrijus Tang wrote:

The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set.  It is not trivial, because this should work:

sub baz (&c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure

But this needs to fail:

sub baz (&c) { c(1) }
method foo { baz { .bar } } # $_ is bound in inner closure


I might still not understand topic, $_ or lexical vars in general.
But why does the fact that &c is called with a parameter
in the second case and without one in the first example make a
difference? Isn't $_ always coming in out of band? So .bar is always
invoked on the invocant of &foo if we think that there is an implicit
$_ := $?SELF before the call to &baz in &foo.  And I hope the binding
of $_ to $?SELF is a read-only binding!
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[Mark Reed]

On 2005-07-12 12:22, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]>
wrote:
> I am also interested in the rationale behind the approach to manage MMD
> my means of a metric instead of a partial order on the types.
> Metric is a geometric concept which in my eyes doesn't fit type
> theory. 

The geometric interpretation does bring us into somewhat philosophical
territory. Not that that's anything new on this list. :)

Let me try a concrete example.  Suppose that class Answer has subclasses
Animal, Vegetable, and Mineral, with respective subclasses Dog, Potato, and
Diamond.  There are two methods named foo in scope, neither overriding the
other.  One is declared to take (Animal, Vegetable, Mineral), the other
(Dog, Potato, Answer).  Assuming the obvious memberships, which method
should foo(Snoopy, Mr_PotatoHead, HopeDiamond) call?  And more importantly,
why do you feel that is the right answer?
 
According to Damian's metric, we have distances of 0+0+2=2 and 1+1+1=3, so
(Dog, Potato, Answer) is "closer" and would get called.  

Re: What do use and require evaluate to?

[Gaal Yahas]

On Tue, Jul 12, 2005 at 12:15:30PM +, Ingo Blechschmidt wrote:
> In Perl 5, %INC maps the partial path names of the modules   
> loaded to their absolute ones. What should the keys and values   
> of %*INC be in Perl 6?   

Conceptually, the Perl 5 %INC maps from what to which. It also imposes
a coupling with the filesystem which makes things like require $module
awkward. The hook mechanism in values breaks consistency, unless you
think of string values as shorthand for sub { slurp "path" }.

I propose to throw away the filesystem coupling, and map from a more
general name of the bit of code we are requiring to a more general
description of which instance of it we actually got. Once modules return
interesting values, it might be useful to keep a copy of that value
somewhere on the value side of %*INC: or else turn it inside out and
stipulate that a standard field in the Module object is where you got
this particular module. Probably, %*INC values should be weak references.

On the key side, I think we should allow more than just strings.
`use Bar` and `require Bar` invoke the module loader on a
ModuleName.new("Bar"). Passing a straight string performs this promotion
automatically. Path separators and '.pm' need never seen outside the
module loader. You can also ask to use/require a File or a URI, but
those requests are only honored if you have appropriate entries in the
module search path. In the case of URIs we could allow, for example,
only modules from a particular domain or even under a particular path.

Examples:

%*INC = (
 # weak references
ModuleName.new("Bar") => Module.new(name=> "Bar",
version => "0.0.7",
author  => "BarCom",
path=> "/usr/lib/perl6/Bar.pm",
loaded_classes =>
 (::Bar, ::Bar::Internals),
   ),

URI.new("http://codeIZus.com/perl/randommodule.cgi";) =>
 Module.new(name=> "Acme::emcA", ...),

$an_open_file => ...
);

@*INC = ("/usr/local/lib/perl6",
 URI.new("http://codeIZus.com/perl/";),
 URI.new("http://";), # this would mean allow loading code from ANYWHERE.
);

-- 
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/

Re: MML dispatch

[TSa (Thomas Sandlaß)]

Mark Reed wrote:

On 2005-07-12 12:22, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]>
wrote:


I am also interested in the rationale behind the approach to manage MMD
my means of a metric instead of a partial order on the types.
Metric is a geometric concept which in my eyes doesn't fit type
theory. 



The geometric interpretation does bring us into somewhat philosophical
territory. Not that that's anything new on this list. :)

Let me try a concrete example.  Suppose that class Answer has subclasses
Animal, Vegetable, and Mineral, with respective subclasses Dog, Potato, and
Diamond.  There are two methods named foo in scope, neither overriding the
other.  One is declared to take (Animal, Vegetable, Mineral), the other
(Dog, Potato, Answer).  Assuming the obvious memberships, which method
should foo(Snoopy, Mr_PotatoHead, HopeDiamond) call?  And more importantly,
why do you feel that is the right answer?
 
According to Damian's metric, we have distances of 0+0+2=2 and 1+1+1=3, so
(Dog, Potato, Answer) is "closer" and would get called.  


Uhh, both targets are applicable but none is more specific on all
positions. I would like this to be an "ambiguous dispatch" error.

Actually it's a pitty, that the multi method call syntax isn't as
rich as the single method call syntax where we have .?method, .+method
and .*method. Something like (Snoopy, Mr_PotatoHead, HopeDiamond).*foo
doesn't exist, right? Or is it foo.*(Snoopy, Mr_PotatoHead, HopeDiamond)?
--
TSa (Thomas Sandlaß)

Re: MML dispatch

[Larry Wall]

On Tue, Jul 12, 2005 at 08:13:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Actually it's a pitty, that the multi method call syntax isn't as
: rich as the single method call syntax where we have .?method, .+method
: and .*method. Something like (Snoopy, Mr_PotatoHead, HopeDiamond).*foo
: doesn't exist, right? Or is it foo.*(Snoopy, Mr_PotatoHead, HopeDiamond)?

It doesn't seem to make much practical sense.  Multimethods are
generally written to be exclusive of ancestral methods.  Ordinary
methods are generally written to be cumulative with ancestral methods.

Larry

Re: What do use and require evaluate to?

[Larry Wall]

On Tue, Jul 12, 2005 at 12:15:30PM +, Ingo Blechschmidt wrote:
: Hi,   
:
: what do use and require evaluate to?  
:   
: S06 suggests it's probably some kind of Module object:   
:   The result of a use statement is a (compile-time) object that also has   
:   an .assuming method, allowing the user to bind parameters in all the   
:   module's subroutines/methods/etc. simultaneously:   
:  
:   (use IO::Logging).assuming(logfile => ".log")   
:
: We could make (use Foo) evaluate to the class object Foo,   
: allowing:   
:
: my $foo = (use Foo).new(...);   

I don't think it's wise to presume a magical binding between the package
name and the file name in this case.

: Alternatively, we could go the Perl 5 way and return the   
: last thing evaluated in Foo.pm (which might be a Module   
: object, assuming that module Foo {...} evaluates to Foo).   

That works for me.  I would note that when you say

module Foo;
...

it is equivalent to

module Foo {
...
}

so the first form does in fact return the module as the last (and only)
statement in the file.  Presumbaly one can override this with an
explicit return.

: What do successive uses of use and require evaluate to?   
: Perl 5 is inconsistent:   
:
: $ cat > Foo.pm   
: package Foo; 42;   
: $ perl -we 'warn require Foo; warn require Foo'   
: 42 at -e line 1.   
: 1 at -e line 1.   
:
: I'd like Perl 6's use and require to return the same thing.   

They will.  It'll be the "last thing", as defined above to usually
mean "the whole thing".  In the case of separate compilation this
may actually be a proxy or stub for the module or class that is just
smart enough to manage the interface to the module/class without
necessarily knowing the implementation.  (This does imply that
used modules must be compiled no later than "use" time, since we
can't know what the module exports without compiling it.)

: In Perl 5, %INC maps the partial path names of the modules   
: loaded to their absolute ones. What should the keys and values   
: of %*INC be in Perl 6?   

It's not clear that Perl 6 will use the same search strategy for
modules, so there may not even be a %INC, or if there is, there's no
guarantee what the keys and values will really be. This has not yet
been specified.  But searching a path of directories is certainly
one thing that slows down Perl 5 startup times.  Whether or not the
Perl 6 library system is implemented using a database or flat files,
the search for a module matching various criteria will likely be in
some kind of index rather than doing probes on the bare filesystem.
There might well be a %INC, but its value might well be that very
package and/or proxy object we were discussing above, and what file
it came from might just be part of its metadata.  Also, if the key
of %INC is the short name of a module, than it really has to be
kept per lexical scope, since different lexical scopes are allowed
to have different mappings from short names to long, so that we
can have dependencies on two different versions of the same module
simultaneously (to the extent allowed by shared resources).

In short, Perl 5 code that assumes too much knowledge about %INC
will have to be recoded to work under Perl 6.

Larry

Re: Raw bytes in perl6

[Larry Wall]

On Tue, Jul 12, 2005 at 04:53:49AM -, David Formosa (aka ? the Platypus) 
wrote:
: How do we intend to manipulate raw binary in Perl6?  Perl5's use
: bytes; pragma is rather poor (forcing all strings to be raw in its
: scope or requiring do {use bytes; ...} type tricks to deal with them)
: and now Perl6 has real typing perhaps it would be more usefull to have
: a bytestring type (or and octect string type) that doesn't get
: utf8ed.

I've said that string types will be allowed to specify a minimum and
maximum abstraction level.  Byte strings merely specify a maximum
abstraction level of bytes, and then any code that looks at it as
codepoints, graphemes, or characters will only see values in the
range of 0..255, and any attempt to store a character larger than
255 into such a string will fail.

On the other extreme we can have abstract string types that encapsulate
their representation, so that you're allowed to deal with them as
graphemes or characters, but not get at their "true" representation,
so you can't tell whether they're stored in UTF-8, UTF-32, UTF-EBCDIC,
ASN.1, ISO-2022-jp, or Morse Code.

As for naming string types, perhaps the main Str type can be parameterized.

my ::bitstr ::= Str of bit;
my ::bytestr ::= Str of uint8;
my ::codestr ::= Str of Code;

On the other hand, if the basic Str type is unwilling to take on the
burden of being parameterized, we could generate all our funny string
types by mapping a string name to an array declaration.

my Str $foo is Array of byte;

or some such.  But maybe we can make Str of byte mean that by way
of shorthand.

Larry

Re: User-defined infix subs/methods?

[Larry Wall]

On Tue, Jul 12, 2005 at 05:27:48PM +0800, Autrijus Tang wrote:
: On Sat, Jul 09, 2005 at 03:58:45PM -0700, Larry Wall wrote:
: > It should take a little more effort to mess with the minds of
: > unsuspecting modules, so maybe the standard syntax is cloned out of
: > *STANDARD_PERL_6 or some such scary package name.  It's the default for
: > starting all require-like Perl 6 parses.
: 
: Note that this requirement is already satisfied, under the "separate
: compilation doctrine" in the hackathon notes.
: 
: Each compilation unit needs to be compiled without any information to
: the symbols in the caller environment.  It may export symbols, but may
: not silently make use of caller's symbols, which naturally includes
: user-defined operators.

Good, I'd forgotten about that.  Which means that it's even harder
for someone to compile a module in a "strange" dialect, since they'd
essentially have to write their own version of "use" that forces
recompilation ("reuse", if you will).  And the harder we make it to
write "reuse", the better.

Larry

Re: Hackathon notes

[Larry Wall]

On Thu, Jul 07, 2005 at 06:37:58PM +0800, Autrijus Tang wrote:
: * A closure form of `but` is desugared into a `do given` block that
:   eliminates the need of returning $_ explicitly.  So those two forms
:   are equivalent:
: 
: my $foo = Cls.new but {
: .attr = 1;
: };
: 
: my $foo = do given Cls.new {
: .attr = 1;
: $_;
: };

I just noticed that our rewrite doesn't quite work unless you rewrite
every "when" clause in the first form to also return $_, since "when"
blocks would escape past the return of the $_.  Any form of "leave"
could have the same problem.  I think the proper semantics of "but"
are that it ignores any return value however generated and pretends
the topic was returned.  In fact, the original closure should probably
be evaluated in void context.  So it's doing something more complicated
like:

my $foo = do given Cls.new {
given $_ {
.attr = 1;
}
$_;
}
};

But hey, that just makes the monkey-but sugar seem all the sweeter.  :P

Larry

Re: Raw bytes in perl6

[Yuval Kogman]

On Tue, Jul 12, 2005 at 13:55:56 -0700, Larry Wall wrote:

> On the other hand, if the basic Str type is unwilling to take on the
> burden of being parameterized, we could generate all our funny string
> types by mapping a string name to an array declaration.
> 
> my Str $foo is Array of byte;
> 
> or some such.  But maybe we can make Str of byte mean that by way
> of shorthand

If this means that the string role, composed with the array role is
just a way to apply a bunch of really cool operations (rules,
substringing, composition, conversion) onto a stream of things that
know to do the Char role, can we have monads too? ;-)

Seriously though, haskell's way of treating strings as lists make
strings useful in a totally different way than perl5 makes them
useful, and I'd like to have both.

Perhaps the most interesting aspect of the string-is-a-list mindset
is that Parsec can parse any list of crap into any structured crap.
It's only affinity towards real strings and characters is the
builtin library of useful rules.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me has realultimatepower.net: neeyah



pgp54WMN4RUfZ.pgp
Description: PGP signature

Re: DBI v2 - The Plan and How You Can Help

[Sam Vilain]

Dean Arnold wrote:

RE: LOBs and "SQL Parse Trees": having recently implemented
LOB support for a JDBC driver (and soon for a DBD), I can assure
you that SQL parse trees are unneeded to support them. For databases


Great!

Perhaps you can shed some light on how to do it for this, then.

SQL command;

  INSERT INTO FOO (?, ?, ?, ?);

Column 3 is a BYTEA column in Pg and needs special peppering to work.

or this;

  SELECT
 *
  FROM
 FOO
  WHERE
 SOME_DATE_COLUMN > ?

SOME_DATE_COLUMN is the database native date type.  On Oracle you'll
need to convert the ? to a 'TO_DATE(?)'.

Sam.

Re: How to write a self.pm (Re: method calls on $self)

[Larry Wall]

On Tue, Jul 12, 2005 at 12:36:23PM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
: > On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: > : On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: > : The obvious thought is to have yet another magical, $^H like flag, to
: > : denote the current dialect.  If it is set, then the parser can emit
: > : .method as $_.method, instead of $?IMPLICIT_INVOCANT.method.
: > 
: > The parser always emits .method as $_.method under any dialect, or
: > fails.  What has changed is whether $_ sometimes means the invocant.
: 
: But the compiler needs to trigger ambiguity resolution -- i.e. check
: for $?SELF agreement with $_ -- when it sees $?IMPLICIT_INVOCANT.
: 
: No need to do that if it sees $_.method.  So they need to be different.

Well, another approach is to treat .method as invariably $_.method,
and catch the problem at the attempt to rebind $_.  Thomas seems to
think it should already be doing that.  Of course, that would make it
impossible to use given or for inside a method at all...

So the other approach is to give up on compile-time checks and say
that $?IMPLICIT_INVOCANT.method in a method's lexical scope (and
in the absence of "use self") turns into

($_ =:= $?SELF ?? $_.method :: fail "Phooey")

: > In any event, SMD methods always have a first argument, so you're never
: > in doubt at that point.  And since .bar always means $_.bar, I don't
: > think you really have a problem here that's any harder than you already
: > had with $_.
: 
: The problem here is for the compiler to detect whether $_ agrees
: with $?SELF, when it sees $?IMPLICIT_INVOCANT.  If they agree,
: $?IMPLICIT_INVOCANT gets replaced by $_; otherwise it is an error.
: 
: Consider this construct:
: 
: method foo {
:   $_ := $something_else if rand(2)>1;
:   .bar;
: }
: 
: That's one case where it's not possible to detect at compile time,
: so it needs to silently let .bar go thru as $_.bar.

Though Thomas's constant binding notion would presumably catch that.
But then we're getting into the "noalias" zone that Dennis Ritchie hates.
On the other hand, I can see lots of uses for variables that may
not be rebound, at least in terms of reassuring the optimizer that
Weird Things Can't Happen.

: > : Clearly we need a way to statically determine &statement:
: > : and &statement: will always assign at least one argument to
: > : its block argument.  Without that, the compile-time analysis mandated by
: > : Larry is infeasible.
: > 
: > I think you can assume that "given" and "for" always bind at least one
: > argument.  In particular, a "for" that binds 0 arguments will never
: > progress, plus you can recognize it:
: 
: But what in "given" and "for" signify that?  I do not want to special
: case based on function names, and &statement: may be rebound
: to something else.

I understand the desire for generality, but that road also leads to
error messages that are completely opaque to naive users, who are
pretty accurate in their view that features like "given" and "for"
will Stay Put in the normal course of events.  Many of the most useful
diagnostics in Perl 5 are the ones that are guessing based on common
usage patterns.  Users can't do much with messages that when deciphered
come out to mean something like "you called a function passing as
its first argument another function whose first argument's declared
type allows it to be optionally bound to $_ but if we actually try to
make use of that we'll get some ambiguity further on down the road,
and that's bad."  They'd much rather chuck the generality and have
"You can't say .foo inside "given" where the topic could be either $_
or the method's invocant."  Or in the absense of that just blow up
at run time.

Of course, I'm just restating your problem here...

: How does that something else signify that it will
: at least bind at least one argument to its code argument?  Via the
: signature of the code argument, i.e. the  in &code?
: 
: sub statement: (Any $topic, &code) { ... }

Maybe something like:

sub statement: (Any $topic, *&code:(Any is topic)) { ... }

: If so, what is the signature of "for"?  I can't seem to write it down.

Good question.  I suppose the signature wants to guarantee minimum arity
of 1 somehow.  Maybe

sub statement: (Lazy [EMAIL PROTECTED], *&code:(Any is topic, *)) { 
... }

or some such.  But whether the outer function is actually functioning
as a topicalizer would still depend on the innards of your function.
Hmm.  We might settle for declaring such functions with a special trait
that indicates that they are *intended* to function as topicializers.
And then maybe the compiler could just depend on those declarations
for its static analysis:

sub statement: (Any $topic, *&code:(Any)) is topicalizer { ... }

Other that that we rely on the run-time check.  (Which hopefully common
code analysis can factor out multiple copies of

Re: Raw bytes in perl6

[Yuval Kogman]

On Wed, Jul 13, 2005 at 00:46:49 +0300, Yuval Kogman wrote:

> Perhaps the most interesting aspect of the string-is-a-list mindset
> is that Parsec can parse any list of crap into any structured crap.
> It's only affinity towards real strings and characters is the
> builtin library of useful rules.

By the way, a nice use case for using the rules engine could be
"parsing" a stream of SAX events into a structure... XML::Simple in
perl6 could be really as simple as it sounds =)

Can anyone see this being retrofitted on top of current rules
semantics? How does PGE relate to this?

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /methinks long and hard, and runs away: neeyah!!!



pgpKi1qsGxwFw.pgp
Description: PGP signature

Re: Raw bytes in perl6

[Sam Vilain]

Yuval Kogman wrote:

By the way, a nice use case for using the rules engine could be
"parsing" a stream of SAX events into a structure... XML::Simple in
perl6 could be really as simple as it sounds =)
Can anyone see this being retrofitted on top of current rules
semantics? How does PGE relate to this?


Yes, in fact SGML DTDs, once reduced to compact forms such as in;

http://search.cpan.org/src/SAMV/Perldoc-0.13/t/09-scottish.t

End up looking surprisingly similar to rules.

Sam.

Perl 6 Summary for 2005-07-05 through 2005-07-12

[Matt Fowles]

Perl 6 Summary for 2005-07-05 through 2005-07-12
All~

Welcome to another summary from the frog house. A house so green it can
be seen from outerspace (according to google earth).

  Perl 6 Compiler
   Building Pugs Workaround
Sam Vilain posted a useful work around to the error "error: field
`_crypt_struct' has incomplete type" which occurs on some systems.
Fortunately, Salvador Ortiz Garcia found a fix.





   Pugs, Pirate. Pirate, Pugs.
Autrijus began plotting with the Pirate folks. Thoughts include unifying
PIL and PAST or possibly retargeting PIL to PAST. Perhaps the result
should be a more nautical dog... maybe schipperke.



   Implicit Invocants and Pain
Larry (as will be summarized later) ruled that " ./method " was gone. he
further ruled that " .method " would pitch fits at either compile or run
time if " $_ =:= $?SELF " was false. Autrijus found this quite difficult
to implement. Talk continues, my instincts tell me that this too will
pass, although Larry assures us that it is absolutely permanent for at
least a week.



  Parrot
   Key Question
Klass-Jan Stol found that using a assigning a floating point value to a
key and then using it make parrot segfault. Warnock applies.



   Parrot Copyrights
Allison Randal hinted that The Perl Foundation has almost finished
hammering out some legal stuff and there will soon be sweeping changes
throughout the repository addressing copyright issues.



   Character Classes in Globs
Will Coleda noted that Tcl would pass more tests if PGE supported
characters classes in globs. Patrick, unable to resist the siren call of
passing tests, implemented it.



   Amber for Parrot
Roger Browne announced that he had succeed in extracting viable DNA from
a Parrot encased in amber since the Jurasic age. Either that or he
release Amber version 0.2.2... not sure which.



   Leo's Branch
Leo has created a branch in SVN (branches/leo-ctx5) of his work
implementing the new calling conventions. This led to some discussion of
how to deal with optional arguments.





   Leo's Branch Meets mod_parrot
Jeff Horwitz posted some observations and troubles he was having with
Leo's branch of new calling conventions. Leo warned that the branch was
still young, but would gladly take test cases.



   Leo's Branch Meets PGE
After the initial discussion of optional parameter, Patrick updated the
leo_ctx5 branch of PGE to the new calling conventions. All tests pass.



   Get onto the Bus
Matt Diephouse found a Bus Error when running
languages/tcl/examples/bench.tcl. Warnock applies.



   MinGW Patch Resurrection
François Perrad resurected a patch from mid June with a set of action
items. Warnock applies.



   Scared Parrots Like Scheme
Joh Lenz posted an announcement that he had an alpha version of Chicken
(a Scheme to C compiler) backending to Parrot. Leo provided answers to
some of his questions.



   Bytecode vs PMCs
Matt Diephouse posted a list of questions about the place of PMCs. Some
of the core tradeoffs include: maintability, portability, optimization,
duplicate implementations, and security.



   make svnclean
Leo pointed out that make svnclean got removed, but that he found it
useful. Chip suggested that it be renamed make svnclobber, as it does
more than just clean.



   pmc2c.pl Bug
Nicholas Clark found a bug in the shortcut to avoid writing a pmc dump
file. Warnock applies.



   Define "cache"
Nicholas Clark suggested that it was probably not wise to #define
"cache". So they removed it.



   Parrots Getting Smarter
Leo pointed out that at least one parrot understood the concept of zero,
putting it some distance ahead of romans when it comes to math. Once the
Parrots start to grow opposable thumbs, I will welcome our new Parrot
overlords.



   Leo's Branch Meets Exceptions
Leo posted two suggestions for how the new calling conventions could
interact with Exceptions. Autrijus liked the one that unifies exception
handlers with the rest of calls and returns.



   Control Flow Graph Bugs
Curtis Rawls noted what he thought might be a bug in the
compute_dominators function. Leo confirmed that it was likely a bug.
Later he posted a note saying he was working on a new implementation for
some of the CFG algorithms. He asked for a hand, 

Re: Perl 6 Summary for 2005-07-05 through 2005-07-12

[Damian Conway]

Matt Fowles summarized:


   Method Call on Invocant
Now " ./method "is gone, and " .method " only works when " $_ =:= $?SELF ".


Important qualification:

  Within a method or submethod, C<.method> only works when C<$_ =:= $?SELF>.
  

C<.method> is perfectly legal on *any* topic anywhere that $?SELF doesn't exist.

Damian