Re: S05 question
On Tue, Dec 07, 2004 at 12:11:18PM -0700, Patrick R. Michaud wrote: : I'm reviewing the updated S05 (2 Dec 2004) and ran across this : in the "Hypothetical Variables" section: : : # Pairs of repeated captures can be bound to hashes: : : / % := [ () = (\N+) ]* / : : Actually, I see three captures there, so should this instead read...? : : / % := [ («ident») = (\N+) ]* / Probably--that was the intent. Or maybe that style of capture ignores rule captures. (If we do allow rule captures, we have to worry about setting up a hash that is indexed by object rather than by string, which seems not terribly useful for grammar reductions.) Or maybe if there are more than two captures in the brackets, the first becomes the key and the rest of them become a list value, in which case 's $/ could be the first element and \N+ the second. But somehow I expect that when someone writes () they probably usually meant («foo»). On the other hand, it's an interesting idiom if you really mean that you want the key to be the text value of the match, and the value to be the object value of the match. : Or is it that hypotheticals only bind to things captured by parens? : If so, it might need clarification (or perhaps I'm overlooking the part : that makes it clear). No, I think you just found a blind spot in the design. : A similar question arises a bit later, with : : And this puts a list of lists: : : / $ := [ () = (\N+) ]* / : : Is the capture part of the list of lists that goes into $? Wasn't intended to be. I think I just missed changing it to «ident» in the GBS. Larry
Re: Lexical scope of parametric declaration blocks
Ashley Winters writes:
> In S12, I see examples like:
>
> role Pet[Type $petfood = TableScraps] {
> method feed (::($petfood) $food) {...}
> }
>
> I assume that means lexicals declared as part of a parametric
> specialization declaration block thingy are only visible within that
> scope, like a formal subroutine parameter list?
Well, "like" is a pretty strong word, but it turns out not to be strong
enough in this case. It *is* a formal parameter list. It just isn't on
a sub.
The brackets are there to be visually distinctive. We like declarations
to look different from statements, and we like to know when we're
messing with parametric types.
> If so, are there things allowed (or disallowed) in type parameter
> lists vs. sub parameter lists?
Hmm... not that I can think of right off the bat.
> If [] is enforcing long-name generation or something simple like that,
> could I cheat and make it imply multi on my functions if I use it?
>
> sub foo[Int $x: Pair ?$y] {...}
> sub foo[Pair $x, Pair $y] {...}
>
> Would that be valid/mean anything?
I don't think you can do that. The brackets are kind of like C++'s
templates, but not really. Since Perl is dynamic, they're not really
saying anything is compile-time or anything like that. The brackets are
just like the parentheses, except you use them with types.
The big issue about these things that needs to be hashed out is type
equivalence. When are two parameterized types the same one? When their
arguments are exactly the same? What if the arguments don't know what
equality is? What if you have multiple signatures for usability, but
they map to the same logical type.
Luke
Re: specifying the key Type for a Hash
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Dec 2004 00:39:08 -0800, Brent 'Dax' Royal-Gordon
> > my Patient @byid[Int $id] {
> > select_patients("SELECT * FROM patients WHERE patientid = ?",
> > $id)[0];
> > }
> > multi my Patient %byname{String $last} {
> > select_patients(
> > "SELECT * FROM patients WHERE lastname = ?",
> > $last, $first
> > );
> > }
> > multi my Patient %byname{String $last, String $first} {
> > select_patients(
> > "SELECT * FROM patients WHERE lastname = ? AND firstname = ?",
> > $last, $first
> > );
> > }
> >
> > ...
> > }
>
> for @byid -> $patient { ... }
> for %byname.kv -> $key, $value { ... }
Point. Maybe you just have to make all objects handled through this
method multi, though, and provide an empty-arguments variant:
multi my Patient @byid[] {
return select_patients("SELECT * FROM patients");
}
If the underlying code returns lazy lists, this can be a fairly
efficient way to do things.
The usefulness of this might be limited to providing several views an
underlying data (as above), but if you're doing something much more
complicated, chances are you really ought to use a class and an C.
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)
Re: Perl 6 Summary for 2004-11-29 through 2004-12-06
On Dec 6, 2004, at 6:27 PM, Matt Fowles wrote: getters and setters John Siracusa wanted to know if Perl 6 would allow one to expose a member variable to the outside world, but then later intercept assignments to it without actually having to switch to using getters and setters in all of the code that uses the variable. The answer: yes, yes you can. And I would consider this a huge improvement over Perl 5's otherwise useful lvalue-able subs. Cheers, David
Lexical scope of parametric declaration blocks
In S12, I see examples like:
role Pet[Type $petfood = TableScraps] {
method feed (::($petfood) $food) {...}
}
I assume that means lexicals declared as part of a parametric
specialization declaration block thingy are only visible within that
scope, like a formal subroutine parameter list?
If so, are there things allowed (or disallowed) in type parameter
lists vs. sub parameter lists?
If [] is enforcing long-name generation or something simple like that,
could I cheat and make it imply multi on my functions if I use it?
sub foo[Int $x: Pair ?$y] {...}
sub foo[Pair $x, Pair $y] {...}
Would that be valid/mean anything?
Okay, that enough curiosity for today. :)
Thanks,
Ashley Winters
Re: pull & put (Was: Angle quotes and pointy brackets)
On Mon, 06 Dec 2004 12:22:22 GMT, Smylers <[EMAIL PROTECTED]> wrote: David Green writes: I guess we could always use prepend/append, pull/pop. No! C and C are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Yeah. C and C are old and glorious ones (asm comes to mind), and C is too (even DOS .bat files used it, AFAIR), and it's a one of the most used perl5 CORE:: ops (it's more common than other three) .. And I like to shift :) the only doubtful word for me is unshift. Althought I would be pretty happy if we leave it as is, C is nice and short. but please don't swap meanings of old ops! if old push suddenly would try to unshift something, it could bring some perl5 programmers to hospital.
S05 question
I'm reviewing the updated S05 (2 Dec 2004) and ran across this in the "Hypothetical Variables" section: # Pairs of repeated captures can be bound to hashes: / % := [ () = (\N+) ]* / Actually, I see three captures there, so should this instead read...? / % := [ («ident») = (\N+) ]* / Or is it that hypotheticals only bind to things captured by parens? If so, it might need clarification (or perhaps I'm overlooking the part that makes it clear). A similar question arises a bit later, with And this puts a list of lists: / $ := [ () = (\N+) ]* / Is the capture part of the list of lists that goes into $? Pm
Is object representation "per class" or "per object"?
According to S12, it is possible to supply the object layout to bless(), like so: $object = $class.bless(:CREATE[:repr] :k1($v1) :k2($v2)) But in the section "Introspection", "layout" is a class trait. Does this mean that classes have a default layout that can be overriden for individual objects? If the answer is "yes", what is the reason that somebody would want to have some objects of the same class as P6Opaque and others as PyDict? I can imagine needing to be able to *convert* from one layout to another, but then the converted object appears to me to belong to a different class (probably in a different language) and then layout should perhaps be an adverb for something like convert() or cast()*, instead of for bless(). Another reason for saying that the object laid out differently is a different class is that if for whatever reason you want some object either as P6Opaque or PyDict then you may also want both representations simultaneously, effectively requiring "two objects". What am I missing? A good example of the need of overriding the default class layout will suffice... --abhijit * maybe not even then, because we'd be saying $current_obj.cast($otherclass), and $otherclass would know it's own layout. Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: specifying the key Type for a Hash
On Tue, 7 Dec 2004 00:39:08 -0800, Brent 'Dax' Royal-Gordon
<[EMAIL PROTECTED]> wrote:
> Larry Wall <[EMAIL PROTECTED]> wrote:
> > Also says maybe you could attach a block to a hash or array to
> > define what subscripting does. Hmm.
>
> That's...wow.
>
> class Patient {
> my DBI::Connection $db;
>
> my Patient @byid[Int $id] {
> select_patients("SELECT * FROM patients WHERE patientid = ?", $id)[0];
> }
> multi my Patient %byname{String $last} {
> select_patients(
> "SELECT * FROM patients WHERE lastname = ?",
> $last, $first
> );
> }
> multi my Patient %byname{String $last, String $first} {
> select_patients(
> "SELECT * FROM patients WHERE lastname = ? AND firstname = ?",
> $last, $first
> );
> }
>
> ...
> }
for @byid -> $patient { ... }
for %byname.kv -> $key, $value { ... }
???
--
matt diephouse
http://matt.diephouse.com
Pleasing some of the people all of the time
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Wall) wrote: >On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote: >[snip] >: I like that. >: I like that even better. [etc.] >Um. You're so very...easy to please... I guess I'm okay with that... =) But you'll notice we didn't hit anything I liked best of all. Maybe I should rank my responses on a scale from 1 to 10. Of course, it's all about psychology: complaining about the stuff I don't like only buys it increased mind-share, whereas you can catch more flies with honey... -David "doesn't actually want to catch flies, yuck... time to rethink this strategy" Green
Re: specifying the key Type for a Hash
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Luke Palmer) wrote:
>David Green writes:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Larry Wall) wrote:
> > >Maybe type parameters are just subscripts? [...]
> > >my Fight %fight does key{Dog;Cat};
> > I like that.
>
>Yeah, me too. Except I'm having trouble seeing how key is a role. It's
>not adding anything into a hash; it's changing it. Maybe I just don't
>quite grok roles yet.
I definitely don't, but from my approximate understanding, couldn't we
look at the "Role" of hash as giving you methods for FETCH, STORE,
EXISTS, etc.? And "my %hash does key{Str}" is a shorthand for "my %hash
does Hasherdabery :key(Str)" (or whatever the correct version would
be)?And the mere appearance of a % -- "my %hash" -- is shorterhand
for telling Perl you want your variable to play the Role of an ordinary
unaccessorised hash.
This notion was reinforced by Larry's suggesting that you could supply
code (instead of just a type) to define the keys and values; to me that
sounds like old-fashioned tying in Role's clothing. (But that's
glossing over a lot of details, some of which may actually be important.)
> > >Well, there's always "domain" and "range", if we want to be
> > >mathematical.
>[...]
>What you want here is "domain" and "codomain". Which leads me to
>believe that you don't want either.
Hm. Well, if you want to get picky, yes, the "range" should be the set
of *all* values mapped to from the domain, and it's unlikely that your
hash contains every possible Str [or whatever] as a value. But if we're
being that picky, it's also unlikely that every possible Str is a key,
either, unless you want to say they map onto 'non-existent' values (not
to be confused with undefined values). But a hash isn't a function
anyway, pickily speaking, because your hash can change (its domain or
its range), so at best it represents a set of functions. And what we're
actually specifying is some sort of metadomain and metarange.
Or we could just say we don't want to be that picky anyway. =)
-David "why we wouldn't want to is beyond me, nit-picking is fun!" Green
Re: specifying the key Type for a Hash
Larry Wall <[EMAIL PROTECTED]> wrote:
> Also says maybe you could attach a block to a hash or array to
> define what subscripting does. Hmm.
That's...wow.
class Patient {
my DBI::Connection $db;
my Patient @byid[Int $id] {
select_patients("SELECT * FROM patients WHERE patientid = ?", $id)[0];
}
multi my Patient %byname{String $last} {
select_patients(
"SELECT * FROM patients WHERE lastname = ?",
$last, $first
);
}
multi my Patient %byname{String $last, String $first} {
select_patients(
"SELECT * FROM patients WHERE lastname = ? AND firstname = ?",
$last, $first
);
}
...
}
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)
Re: iterators and functions (and lists)
Larry Wall wrote: On Sun, Dec 05, 2004 at 12:05:46AM +, Matthew Walton wrote: : I'm sorry, but from a C++ background, overriding postcircumfix:<( )> : feels far more natural to me than setting 'is default' on some method. That only works for disambiguation if you know which .() to call in the first place. It seems likely that that .() maps straight to MMD and doesn't look for a singly dispatched .() at all. But maybe I'm just not understanding this. No, that makes sense. What you're talking about already sounds suspiciously like Aspect Oriented Programming. I wouldn't know, I've never looked into it. Perhaps I should... Any foo() can return a list. That list can be a Lazy list. So the ordinary return can say: return 0...; to return an infinite list, or even return 0..., 0...; to return a surreal list. Either of those may be bound to an array as its "generator of missing values". Assignment sort of implies copying, but I'm just saying that the copier could also be smart at least about infinities or indefinities (ohh, a cool new word), even if it flattens everything else. That would be good. It would be nice to be able to copy infinite lists without having to flatten them first. An object can play the Undef role. Or maybe undef can play Ref role. In any event, since a string is an object, the answer is "Yes, but an unthrown Exception object that can stringify would be better..." I'll take either for now. I suspect an unthrown Exception will turn out to be the better solution, as it sounds much more useful. Except that I'm not quite sure how you'd notice it - I assume unthrown Exceptions would be expected to return false in Boolean context? Next thing you'll be telling me is that all this partially evaluated code shouldn't have any side effects. :-) Well of course it shouldn't. Confining all actions which have side effects to the IO monad makes it much easier to reason about programs and their behaviour. Although I suspect anybody who tries to reason about something written in idiomatic Perl deserves the headache they're going to get. That doesn't mean I don't find Perl to be immensely fun to work with though. I believe Perl 6 will be even more immensely fun.
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Austin Hastings wrote:
I'll guess that you're pointing at
.:send_one($_);
Which supposedly uses "topic" to resolve .:send_one into $this.send_one.
If that works, then I'm happy -- I like being able to control topic and
$_ differently. But if C changes topic, then what?
OUTER::.:send_one($_);
Yuck.
I believe it needs to be
method send ($self: [EMAIL PROTECTED]) {
$self.:send_one("BEGIN");
for @data {
$self.:send_one($_);
}
$self.:send_one("END");
}
While that works (I think it works anyway), its debatable if it's nice
or not. The first and last calls to .:send_one shouldn't need the $self,
but I put it there because if you use the $self inside the for in a
method that short, it's nice and clear to have it outside it as well.
I suspect the original example expands the for loop into the equivalent of:
for @data -> $item {
$item.:send_one($item);
}
And it doesn't take a $larry to figure out that this isn't going to make
the compiler very happy, as it's most likely a violation of class access
control, I would have thought.
So Luke, am I right?
