RE: atomicness and \n
On Tue, 2002-09-03 at 23:57, Luke Palmer wrote: On Tue, 3 Sep 2002, Brent Dax wrote: How can you be sure that roundascii is implemented as a character class, as opposed to (say) an alternation? What's the difference? :) Neglecting internals, semantically what Iis the difference? One *possible* semantic difference is a guaranteed matching order. Nothing (historically) has ever really dictated that character classes must match left-to-right, as alternation does. That's mainly because character classes have always been of a uniform width, in which case it is only going to match one thing and one thing only. Whether that will be an issue with variable-width characters in a class is largely going to rely on the semantics that are dictated. -- Bryan C. Warnock bwarnock(gtemail.net|raba.com)
Re: Multimethod Dispatch
David Wheeler wrote: Ah, yes, the same thing exists in Java. I remember, now. I thought Java only has over loading? Over loading is what C++ has. It is not the same as multi-dispatch. The trouble with over loading is that the compiler uses static (compile-time) type information to select the over loaded method. This can create subtle bugs when people try to re-use code by sub-classing. - Ken
Re: Multimethod Dispatch
From: Ken Fox [EMAIL PROTECTED] Over loading is what C++ has. It is not the same as multi-dispatch. The trouble with over loading is that the compiler uses static (compile-time) type information to select the over loaded method. This can create subtle bugs when people try to re-use code by sub-classing. So, just to clarify, does that mean that multi-dispatch is (by definition) a run-time thing, and overloading is (by def) a compile time thing? -Miko mail2web - Check your email from the web at http://mail2web.com/ .
RE: atomicness and \n
On 4 Sep 2002 at 0:22, Aaron Sherman wrote: On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: None, I think. Of course, if we ignore internals, there's no difference bewteen that and rx /roundascii | 1 | 7/. Then, why is there a C+? Why not make it C|? $foo = rx/ a|b|[cde]|f / Because it's good to have MTOWTDI. (= More than one way to do it) -- Markus Laire 'malaire' [EMAIL PROTECTED]
RE: Argument aliasing for subs
From: Peter Behroozi [EMAIL PROTECTED]
Has anyone considered a syntax for allowing
subroutines to have many different names for
the same argument? For example, in CGI.pm, many
methods support the -override parameter but
can also accept the alias of -force:
Yes. See the thread starting at
http:[EMAIL PROTECTED]/msg09551.html . The
end result was that Damian liked the idea and leans towards a syntax like
this:
sub load_data (
$filename_tainted is named('filename'),
$version_input is named('version','ver') //= 1)
{...}
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Multimethod Dispatch
At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: From: Ken Fox [EMAIL PROTECTED] Over loading is what C++ has. It is not the same as multi-dispatch. The trouble with over loading is that the compiler uses static (compile-time) type information to select the over loaded method. This can create subtle bugs when people try to re-use code by sub-classing. So, just to clarify, does that mean that multi-dispatch is (by definition) a run-time thing, and overloading is (by def) a compile time thing? No. They can be both compile time things or runtime things, depending on the characteristics of the language. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote: No. They can be both compile time things or runtime things, depending on the characteristics of the language. So if it's compile-time for a given language, how is it different from the Java concept of overloading? And will Perl 6 do it at compile-time or at run-time? Thanks, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Perl 6 parser, built in rules, etc.
It seems to me that what I mostly do is wave my arms about my head with a concern and then stay silent whenever praise is required. Everyone - consider yourselves praised :-) On to the concern (which I am fairly confident someone will obviate). I've never touched the Perl internals (and P5P should be thankful of that) so I'm not sure how much the parser changes. I worry that, since the rules that the Perl 6 grammer uses to parse the language are exposed to the users, that we could be forced to have an ever growing Perl 6 grammer to keep bakcwards compatability. If a reorganization of the parser ever occured, the language level rules would need to be maintained so that a) lexically scoped grammer changes do not break and b) those rules which are useful to all different kinds of parsing tasks (such as parsing quoted constructs) are still there for those programs which will inevitably use them. How are we planning on dealing with this, or do the implementers consider it a non issue? It seems to me that we are forced to do it (meaning the parser) right and cleanly the first time, which is a reasonable but heavy burden. -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Multimethod Dispatch
At 7:31 AM -0700 9/4/02, David Wheeler wrote: On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote: No. They can be both compile time things or runtime things, depending on the characteristics of the language. So if it's compile-time for a given language, how is it different from the Java concept of overloading? It probably isn't, though I'm unfamiliar enough with Java to say for sure. And will Perl 6 do it at compile-time or at run-time? Runtime. There's no way we could do it at compile-time--too much uncertainty. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 6 parser, built in rules, etc.
On Wed, 4 Sep 2002, Erik Steven Harrison wrote: How are we planning on dealing with this, or do the implementers consider it a non issue? Well, to me this is a non-Yet issue, but a very real issue. I'm hoping that when Perl 6 goes 1.0, the grammar will have seen a lot of testing, and will be in some sort of final form. To me a language's grammar, once defined, shouldn't do a lot of changing, internally or otherwise. When was the last time C's grammar changed? Or even gcc's implementation of it? Of course, before 1.0 the grammar will likely undergo some major tweaking, fixing, and refactoring. It seems reasonable to expect people who do grammar mods before then to keep up with changes. /s
Re: Perl 6 parser, built in rules, etc.
-- On Wed, 4 Sep 2002 07:45:37 Sean O'Rourke obviated: To me a language's grammar, once defined, shouldn't do a lot of changing, internally or otherwise. When was the last time C's grammar changed? Or even gcc's implementation of it? Granted . . .mostly. Were talking about Perl, the language designed to evolve. How much did the Perl grammer (even if there was no definitive one in the Perl 6 lex-on-the-fly sense) change between Perl 1 and Perl 5? Perl 5 and Perl 5.8? I think the answer to the first question (which I suspect is a lot) point to perhaps a different issue - how much do we expect Perl to change after this rewrite, and how are we accomodating Perl's inevitable evolution? The answer to the second question (which I think is probably a little, but some) is more to the point here. Parsing small or experimental features (vstrings and subroutine attricute come to mind) will probably cause changes to the parser. I'd like to keep the potential to introduce such features without breaking existing code. All that said, perhaps there is a solution. I'm not much of a Python programmer, but as I understand it Python offers an internal module called 'future' which holds features planned for inclusion in the next stable release. The idea here is that old code gets a chance to refactor in anticipation of language changes while still bringing new features into the language. Code which uses those features simply imports from the future modules. Hugo is working on the perl6ish pragma which already brings the concept to Perl. Perhaps a Perl 6 pragma can control these feature inclusions to help protect code which accesses the parser? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
User-defined character classes and repeat counts
On Wed, 2002-09-04 at 00:22, Aaron Sherman wrote:
Then, why is there a C+? Why not make it C|?
$foo = rx/ a|b|[cde]|f /
This brings to mind a few big things that have been batting around in my
head about user-defined rules for a while now These things fall out
nicely from A5, I think, but correct me if there's some reason I'm wrong
on that.
It would be nice to be able to flag a rule as being either a pure
character class or a generic rule. At the very least this lets the
compiler issue clearer errors, perhaps earlier. Something like:
rule abc :cc { [abc] }
Perhaps the engine could even try to coerce non-character classes so
that this would work (not that this simple example would happen, but if
you're working with a rule-chain it might be useful):
rule abc :cc { a | b | c }
Along that line, inline closures can do quite a bit, but it would be
nice if they could be used as counts (instead of the more painful
process of controlling backtracking via commit. Let's assume that C
={...} is used this way. Here's an example of its use:
/[\x0d\x0a]={ .count == 1 || (.count == 2 .atom eq \x0d\x0a) }/
Now that's a very expensive way to say C/\x0d\x0a|\x0d|\x0a/, but a
much more complicated count might make it worth-while. I'm assuming the
following things:
C.count is method on the state object that would return the number of
repetitions of the preceding atom have been tried
C.atom is the preceding atom as it would appear if backtracking
stopped now.
The return value of a count closure is boolean.
So, for example here are some translations of existing operators:
+ ={.count 0}
* ={1}
*? ={1}?
8 ={.count == 8}# No optimization possible!
? ={.count 2}
Again, it would be nice to be able to flag these to the compiler in a
rule:
rule thrice :count { ={.count 4} }
/ athrice? /
Note that the C? would cause the thrice count-rule to be matched
non-greedily because the regex parser knows that it's a count, not a
generic rule.
Re: Multimethod Dispatch
Just some thoughts (and an idea): I have found the whole context thing in Perl5 easier to understand when I regard it as overloading based on the return type. We all know that languages like C, C++ and Java throw a compile-time error if two function definitions differ in their return type only. Perl does something close to return type overloading with many of its builtin functions. At least, that's the impression you get from the outside (and I have never looked inside, so excuse my lack of knowledge about the Perl5 internals ;-) ) Now my suggestion: Couldn't context sensivity in Perl6 be implemented by extending multi-method dispatch to include return types? That could be generalized and would allow things like: my PNG $png = PNG.new(images/img0001.png); my JPEG $jpeg = $png.convert(); my GIF $gif = $png.convert(); Of course you could have convertToJPEG() and convertToPNG(), but that's the whole point of overloading and multimethod dispatch, isn't it? The usual list context / scalar context distinction would of course still be possible. It's just about _extending_ context sensivity. [Comments | Suggestions | Criticism] welcome.
Re: Perl 6 parser, built in rules, etc.
At 8:03 AM -0700 9/4/02, Erik Steven Harrison wrote: -- On Wed, 4 Sep 2002 07:45:37 Sean O'Rourke obviated: To me a language's grammar, once defined, shouldn't do a lot of changing, internally or otherwise. When was the last time C's grammar changed? Or even gcc's implementation of it? Granted . . .mostly. Were talking about Perl, the language designed to evolve. How much did the Perl grammer (even if there was no definitive one in the Perl 6 lex-on-the-fly sense) change between Perl 1 and Perl 5? Perl 5 and Perl 5.8? Perl's grammar didn't change much between 5.00 and 5.8. Once we ship the final grammar, we'll maintain it in a backward-compatible way, and document the places you can count on it to wedge in changes. Then we maintain it as long as Larry says so. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod Dispatch
The specific definitions of these terms vary from language to language. In Java, for instance, a method is said to be overloaded and/or overridden. An overloaded method is actually two or more methods with the same name but differing numbers/types of parameters (which Java calls the signature of the method). I believe this is what has been referred to as multimethod dispatch on this thread. An overridden method is two methods with the same name AND type signature in two different classes, where one class is a subclass of the other. The child class's method is said to override the parent class's implementation. The similarity of names is a little confusing, but the distinction between the two mechanisms is important. When an overridden method is called, the actual implementation that gets executed depends on the RUNTIME type of the INVOCANT. When an overloaded method is called, the implementation that is executed depends on the COMPILE-TIME type of the PARAMETERS. Many folks get bitten trying to use overloaded methods as if the implementation were chosen based on on run-time type information. But that's all off-topic. Back to Perl6, although it seems that we won't find out the details of Perl6 O-O until Apoc 12 comes out. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- grasshopotomaus: A creature that can leap to tremendous heights . . . once.
RE: atomicness and \n
On Wed, 2002-09-04 at 09:55, Markus Laire wrote: On 4 Sep 2002 at 0:22, Aaron Sherman wrote: On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: None, I think. Of course, if we ignore internals, there's no difference bewteen that and rx /roundascii | 1 | 7/. Then, why is there a C+? Why not make it C|? $foo = rx/ a|b|[cde]|f / Because it's good to have MTOWTDI. (= More than one way to do it) But, there isn't. There's only one way to indicate character-class unions, and that's C+. If we had C+ and C| as synonyms, I'd be ok with that, though I'd only tell people about C| to avoid the confusion (mind if we call you Bruce?)
Re: User-defined character classes and repeat counts
Aaron Sherman wrote:
So, for example here are some translations of existing operators:
+ ={.count 0}
* ={1}
*?={1}?
8 ={.count == 8}# No optimization possible!
Could it be done this way?:
c:=(.)* ( c == 8 )
Surely inefficient, but it works right (I think). Would there be a more
efficient way to do it within the existing system?
It's easy to do non-greedy, too. Just slap a question mark on the end of
that star.
Luke
Re: Hypothetical variables and scope
Ken Fox wrote:
/ $x := (gr\w+) /vs/ (gr\w+) { let $x = $1 } /
Shouldn't they both use C := ?
They should. The second version is a typo. It should be:
/ (gr\w+) { let $x := $1 } /
Depends on what you want. The $x := in the rule binds the
first match to $x -- it does not copy the value. The $x =
in the code block copies the value of the first match. You
can use either binding or assignment in the code block.
But not with the Clet keyword. That requires binding.
Both of them will be undone during backtracking. It's more
efficient to bind, but the copy guarantees changes to $x and $1
are independent.
This is not what Larry has said previously. He said that only
binding can be used with Clet variables and that only Clet
variable assignments are undone on backtracking.
Damian
Re: atomicness and \n
Jonathan Scott Duff wrote: How can you be sure that roundascii is implemented as a character class instead of being some other arbitrary rule? An answer is that perl should know how these things are implemented and if you try arithmetic on something that's not a character class, it should carp appropriately. Another answer might be that roundascii+[17] is actually syntactically illegal and you MUST perform character class arithmetic as [abc]+[def]. Somehow I prefer the former to the latter. It will definitely be the former, since we have to support named character classes like alpha, digit, printable, etc. Damian
Re: Argument aliasing for subs
Peter Behroozi wrote:
Has anyone considered a syntax for allowing subroutines to have many
different names for the same argument?
If it were allowed, it would probably be done via properties instead:
sub hidden (str $name, int $force, int $override is aka($force)) { ... }
Damian
Re: Argument aliasing for subs
From: Damian Conway [EMAIL PROTECTED]
If it were allowed, it would probably be done
via properties instead:
sub hidden (str $name, int $force, int $override is aka($force))
{ ... }
Would the following be simpler...?
sub hidden (str $name, int $force is aka($override))
{ ... }
Damian's statement says to me that there is an argument named $force, and
another argument named $override which is also known as $force... that
sounds conflicting. The revised statement simply says that there's an
argument named $force and it is also known as $override.
BTW, the aka thing is cool. It could be complementary to is named:
# can't use force_tainted as argument:
sub hidden (int $force_tainted is named($force))
# can use force_tainted as argument:
sub hidden (int $force_tainted is aka($force))
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Argument aliasing for subs
From: Damian Conway [EMAIL PROTECTED]
If it were allowed, it would probably be done
via properties instead:
sub hidden (str $name, int $force, int $override is aka($force))
{ ... }
How does this method affect the non-parameter-based calling scheme? It
looks like it is possible to use three arguments in the call to
hidden(). While this doesn't matter for this case, it might if another
named argument was tacked on to the end, like this:
sub hidden (str $name, int $force, int $override is aka($force),
int $pretty_print);
print hidden('name',1,1); #-- What does this do?
I think that the slight modification of Damian's original solution is
the best:
sub hidden (str $name, int $force is aka('override')) { ... }
Then there is no question that override is Just Another Name for
force (eliminating weird things like $force is aka(@override)), the
problem of argument order in normal sub calls goes away, and there is a
happy minimum of extra syntax.
By the way, thanks for pointing out the original discussion; I haven't
been on the list long enough to have known that it existed.
Peter Behroozi
Re: User-defined character classes and repeat counts
On Wed, 2002-09-04 at 12:41, Luke Palmer wrote:
Aaron Sherman wrote:
So, for example here are some translations of existing operators:
+ ={.count 0}
* ={1}
*? ={1}?
8 ={.count == 8}# No optimization possible!
Could it be done this way?:
c:=(.)* ( c == 8 )
Surely inefficient, but it works right (I think). Would there be a more
efficient way to do it within the existing system?
It's easy to do non-greedy, too. Just slap a question mark on the end of
that star.
What you suggest is just a special-case of what I'm suggesting, so I
agree :)
Adding the syntax of C ={...} just gives you the ability to do
this for arbitrary expressions without saving the results (unless you
want to).
Re: Hypothetical variables and scope
On Wed, Sep 04, 2002 at 11:27:46AM +, Damian Conway wrote:
This is not what Larry has said previously. He said that only
binding can be used with Clet variables and that only Clet
variable assignments are undone on backtracking.
It seems odd to require two syntactic elements to achieve one semantic.
And actually, after looking at A5, that's not what Larry wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
After this pattern, $x will be set to the ending position of
$1--but only if the pattern succeeds. If it fails, $x is
restored to undef when the closure is backtracked
I don't see any binding there, just letting.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Hypothetical variables and scope
On Wed, 2002-09-04 at 14:38, Jonathan Scott Duff wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
After this pattern, $x will be set to the ending position of
$1--but only if the pattern succeeds. If it fails, $x is
restored to undef when the closure is backtracked
I don't see any binding there, just letting.
I think the confusion here is that let is creating a binding, but the
binding is between the named variable (e.g. C$x) and the storage in
the result object (e.g. C$0.{x}). What C$0.{x} is is kind of beside
the point. It may be a binding as in:
... {let $x := $1} ...
or a stand-alone value as in:
... {let $x = $1 + 100} ...
Does this make sense? As I understand it, the let statement is
translated to something like this:
... { $self.{x} = sub {$1 + 100}; $x := $self.{x} } ...
Which will then be evaluated and the result substituted:
$0.{x} = $0.{x}.();
once backtracking is complete to avoid evaluating C$1 + 100 before a
final understanding of what C$1 contains is reached.
Is that roughly correct?
Defaulting params (reprise)
It was settled a while ago that sub arguments would be defaulted like this:
sub load_data ($version / /=1) {...}
(The space between / and / is on purpose, my emailer has problems if they
are together) I and a few others had issues with the slash-slash-equals
thing, but were unable to persuade Damian, Larry, et al to change. I'd
like to make one more proposal for defaulting. Damian seems to like
properties for arguments, how 'bout this construct:
sub load_data ( $version is default(1) ) {...}
It's clean, fits the existing syntax, and immediately understandable.
Thoughts?
-Miko
--
If you reprise the songs, we'll reprise the jokes. - George S. Kaufman
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Hypothetical variables and scope
On Wed, 2002-09-04 at 07:28, Damian Conway wrote:
Aaron Sherman wrote:
Hmm... I had not thought of the copy aspect. Certainly, the code version
is more flexible. You could define C$x above as anything. For example:
/ (gr\w+) {let $x = Gr_Thing.new($1)} /
The binding version is just a simple, fast version of one special case,
no?
No. It's the *only* way to set hypotheticals. Of course, you *can* always
do:
/ (gr\w+) { $x = Gr_Thing.new($1)} /
You chopped off some context. The discussion was about
/ $x := (gr\w+) /vs/ (gr\w+) { let $x := $1 } /
Not hypotheticals in particular. So, the question was is binding C$x
to C$1 via the former statement the same as binding C$x to C$1 via
the latter. I the replied that the former was in fact doable using the
latter syntax, but was more efficient (no closure to execute) while not
offering the flexibility of something like:
/ (gr\w+) {let $x = Gr_Thing.new($1)} /
I think you were saying the same thing as I was (e.g. that you could
only assign a hypothetical to a complex value this way).
Re: Defaulting params (reprise)
On Wed, Sep 04, 2002 at 04:01:50PM -0400, [EMAIL PROTECTED] wrote:
It was settled a while ago that sub arguments would be defaulted like this:
sub load_data ($version / /=1) {...}
(The space between / and / is on purpose, my emailer has problems if they
are together) I and a few others had issues with the slash-slash-equals
thing, but were unable to persuade Damian, Larry, et al to change.
Hopefully those problems had nothing to do with you MUA ;-)
I'd like to make one more proposal for defaulting. Damian seems to
like properties for arguments, how 'bout this construct:
sub load_data ( $version is default(1) ) {...}
It's clean, fits the existing syntax, and immediately understandable.
Thoughts?
So, how would you write the equivalent to this:
$foo //= $a // $b // $c;
Or are you proposing to *only* replace //=? Or are you proposing to
*only* replace //= in subroutine declarations?
What issues did you have with //=? It seems clear and concise to me.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Defaulting params (reprise)
From: Jonathan Scott Duff [EMAIL PROTECTED] Or are you proposing to *only* replace //=? Or are you proposing to *only* replace //= in subroutine declarations? Only augment //= in subroutine declarations, //= would also work. What issues did you have with //=? It seems clear and concise to me. I love the //= operator, but in the context of sub declarations it's confusing as the *only* way to default an argument. I still think = makes sense as an argument defaulter... but that issue's been settled for now and I'm not advancing it again. :-) -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Defaulting params (reprise)
On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote: Only augment //= in subroutine declarations, //= would also work. I love the //= operator, but in the context of sub declarations it's confusing as the *only* way to default an argument. Oh. You want default() to be synonymous with //= but only in subroutine declarations. That seems a tad odd. Why not make it synonymous everywhere? my $foo is default(23); # same as ... my $foo //= 23; -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Defaulting params (reprise)
From: Jonathan Scott Duff [EMAIL PROTECTED]
Oh. You want default() to be synonymous with //= but only in
subroutine declarations. That seems a tad odd. Why not make it
synonymous everywhere?
my $foo is default(23); # same as ...
my $foo //= 23;
Well, for is default to DWIM in a function call, it would almost have to
not DWIM outside a function call. Why? Well, the concept (as seen through
my too-human eyes) would be that the function arguments would be created
and populated something like this: 1) create the variable 2) if the
argument is sent, set the value of the variable using the sent value 3)
else set the value using the default property.
OK, that makes sense so far, but outside of a function call, I'm not sure
where it would be decided that the variable was never set, and so it would
never get the default value. Yes, is default could populate the variable
as soon as it is created, but that seems wasteful.
Is there a general rule that a property must make sense in all contexts?
If Perl6 has the is named property for sub arguments, does that mean that
it must also make sense outside a function...
my $foo is named('bar');
(Hmm, maybe it does... you could have two variables aliased to each other.
OK, bad example. Work with me here.)
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Argument aliasing for subs
[EMAIL PROTECTED] wrote:
sub hidden (str $name, int $force, int $override is aka($force))
{ ... }
Would the following be simpler...?
sub hidden (str $name, int $force is aka($override))
{ ... }
Yeah, that's what I meant.
Sorry. I've travelled 14,000 miles and given 93 hours of
presentations in the last 18 days. [Note to self: no more
posting whilst semi-conscious!!!]
%-)
BTW, the aka thing is cool. It could be complementary to is named:
# can't use force_tainted as argument:
sub hidden (int $force_tainted is named($force))
# can use force_tainted as argument:
sub hidden (int $force_tainted is aka($force))
Yes, that was the idea. :-)
Damian
Hypotheticals again
The thread on hypotheticals has caused me to reread that section of A5 a few times now and a couple of paragraphs bother me the more I read them. I'll just quote the parts that bother me: ... If a regex sets a hypothetical variable that was declared with either my or our beforehand, then the regex modifies that lexical or package variable, and let is purely a run-time operation. On the other hand, if the variable is not pre-declared, it's actually stored in the regex state object. In this case, the let also serves to declare the variable as lexically scoped to the rest of the regex, in addition to its run-time action. ... So, each time I use a hypothetical, I have to be concious of which variables are currently in scope? Perl can't help be with this task because how does it know if I meant to hypothetically clobber that lexical or store something in the match object. This is only really a problem if you expect let variables to always show up in the match object and sometimes they don't. So why not make it so that let also always causes these variables to appear in the match object? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Hypothetical variables and scope
Jonathan Scott Duff wrote:
It seems odd to require two syntactic elements to achieve one semantic.
And actually, after looking at A5, that's not what Larry wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
A typo, I believe. He has been very consistent in discussions that
hypothetical bind, rather than assigning.
Perhaps he's changed his mind since, but I haven't heard anything to that
effect.
Damian
Re: Defaulting params (reprise)
On Wed, Sep 04, 2002 at 05:06:32PM -0400, [EMAIL PROTECTED] wrote: Is there a general rule that a property must make sense in all contexts? Nah, I was just being distracted by work and not thinking clearly about your default() proposal. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Hypotheticals again
In a message dated Wed, 4 Sep 2002, Jonathan Scott Duff writes: The thread on hypotheticals has caused me to reread that section of A5 a few times now and a couple of paragraphs bother me the more I read them. I'll just quote the parts that bother me: ... If a regex sets a hypothetical variable that was declared with either my or our beforehand, then the regex modifies that lexical or package variable, and let is purely a run-time operation. On the other hand, if the variable is not pre-declared, it's actually stored in the regex state object. In this case, the let also serves to declare the variable as lexically scoped to the rest of the regex, in addition to its run-time action. ... So, each time I use a hypothetical, I have to be concious of which variables are currently in scope? Perl can't help be with this task because how does it know if I meant to hypothetically clobber that lexical or store something in the match object. This is only really a problem if you expect let variables to always show up in the match object and sometimes they don't. So why not make it so that let also always causes these variables to appear in the match object? It should. I think everyone has been proceeding under the assumption that they are. If you use a variable name already defined, then you set both the match object's attribute of the same name (minus the sigil if sigil is '$') *and* the external variable. Trey
Re: Multimethod Dispatch
Dan Sugalski wrote: Dan, can you explain what multimethod dispatch is? Damian can explain it better than I can, I thought you did a great job! However, anyone who wants to know more about multiple dispatch might also like to read: http://www.samag.com/documents/s=1274/sam05010010/ Damian
Re: Hypotheticals again
Trey Harris wrote:
So, each time I use a hypothetical, I have to be concious of which
variables are currently in scope? Perl can't help be with this task
because how does it know if I meant to hypothetically clobber that
lexical or store something in the match object. This is only really a
problem if you expect let variables to always show up in the match
object and sometimes they don't. So why not make it so that let
also always causes these variables to appear in the match object?
It should. I think everyone has been proceeding under the assumption that
they are. If you use a variable name already defined, then you set both
the match object's attribute of the same name (minus the sigil if sigil is
'$') *and* the external variable.
That's what I'd like to see too. Indeed, I'd like to see the scalars
turn up in C$o{'$name_with_dollar} as well. TMTOPTSI [*]
Damian
[*] There's More Than One Place To Store It. ;-)
Re: Defaulting params (reprise)
On Wed, Sep 04, 2002 at 03:48:41PM -0500, Jonathan Scott Duff wrote: On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote: Only augment //= in subroutine declarations, //= would also work. I love the //= operator, but in the context of sub declarations it's confusing as the *only* way to default an argument. Oh. You want default() to be synonymous with //= but only in subroutine declarations. That seems a tad odd. Why not make it synonymous everywhere? my $foo is default(23); # same as ... my $foo //= 23; I dont see what's that meant to be achieving. Surely It's always 23. andrew -- Cancer: (June 22 - July 22) You will soon be exposed to the most rocking music ever, but due to your unrockable nature, you will remain profoundly unrocked.
Re: Defaulting params (reprise)
In a message dated Wed, 4 Sep 2002, Andrew Wilson writes: On Wed, Sep 04, 2002 at 03:48:41PM -0500, Jonathan Scott Duff wrote: On Wed, Sep 04, 2002 at 04:43:25PM -0400, [EMAIL PROTECTED] wrote: Only augment //= in subroutine declarations, //= would also work. I love the //= operator, but in the context of sub declarations it's confusing as the *only* way to default an argument. Oh. You want default() to be synonymous with //= but only in subroutine declarations. That seems a tad odd. Why not make it synonymous everywhere? my $foo is default(23); # same as ... my $foo //= 23; I dont see what's that meant to be achieving. Surely It's always 23. A more practical application would be: my $foo; # Code which might or might not set $foo... $foo //= 23; # or $foo is default(23); In such a case, the Cis default just looks plain odd to me. Properties are meant to be out-of-band information; miko's suggestion would have this property setting the *value* of the variable. Weird. C//= seems perfectly reasonable to me. Trey
Re: Hypotheticals again
On Wed, Sep 04, 2002 at 10:34:23PM +, Damian Conway wrote:
Trey Harris wrote:
It should. I think everyone has been proceeding under the assumption that
they are. If you use a variable name already defined, then you set both
the match object's attribute of the same name (minus the sigil if sigil is
'$') *and* the external variable.
That's what I'd like to see too. Indeed, I'd like to see the scalars
turn up in C$o{'$name_with_dollar} as well. TMTOPTSI [*]
Oh good. Me too. I hadn't been proceeding under any assumptions if I
could help it, but that's only because everytime I think I understand
the new perl6isms someone throws a kink in my understanding. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Hypothetical variables and scope
On Wed, Sep 04, 2002 at 10:25:39PM +, Damian Conway wrote:
Jonathan Scott Duff wrote:
It seems odd to require two syntactic elements to achieve one semantic.
And actually, after looking at A5, that's not what Larry wrote:
my $x;
/ (\S*) { let $x = .pos } \s* foo /
A typo, I believe. He has been very consistent in discussions that
hypothetical bind, rather than assigning.
This continues to make no sense to me. The hypotheticality of a
variable seems quite orthogonal to what you do with it (bind, assign,
whatever). Why should these two things be intimate? And if they are,
does that mean that these:
/ (\S*) { let $x = .pos } \s* foo /
/ (\S*) { let $x; ... $x = .pos } \s* foo /
throw some sort of exception or error? That could be surprising if
the ellipses are really some long bit of code. (Why is that scalar
different from any other scalar? Because it's hypothetical. Suddenly
we've a new class of variable that people have to be aware of)
Anyway, I like the semantics described by Ken Fox earlier. (And, in
fact, that's what I thought happened until just recently :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: User-defined character classes and repeat counts
Again, it would be nice to be able to flag these to the compiler in a
rule:
rule thrice :count { ={.count 4} }
/ athrice? /
Note that the C? would cause the thrice count-rule to be matched
non-greedily because the regex parser knows that it's a count, not a
generic rule.
Going off on a tangent here, is there some deep and meaningful reason
why we're still using C? as a non-greedy multiplier suffix? I only
ask because one of the biggest sticking points with C? in my Perl
students is that it means two pretty completely different things,
depending on whether a multiplier comes before it or not.
A5 solved the dual-meaning of C^ nicely, by dumping the syntax for
character classes.
If we're redefining the regex grammar so that different things don't
look too similar (one of Larry's philiophical points in A5), isn't the
dual meaning of C? another one that ought to be dealt with? It's not
like the non-greedy suffix is something that is deeply ingrained in
(non-Perl) regex culture.
I'm not suggesting syntax for a revised non-greediness operator. It'd
probably include a colon and thus disqualify itself according to Larry's
Law of Language Design. But it'd have to reflect good Huffman coding.
(Besides, this'd nicely help solve one aspect of what Aaron's bringing up
in the quoted message above.)
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
We just ride with the wind, and we'll drive through the rain. We don't know
where we'll get to, or if we'll get back again. - _Blown by the Wind_, Alan
Parsons
Re: regex args and interpolation
David Whipp wrote:
But can I use a non-constant date?
You didn't show us the iso_date rule.
Obviously we could put the onus on the module writer to write super-flexible
rules/grammars. But will there be an easy way to force interpolative context
onto this type of regex-valued subroutine arg?
With this rule you need literal numbers:
rule iso_date { $year:=(\d{4}) -
$month:=(\d{2}) -
$day:=(\d{2}) }
This rule is more flexible:
rule iso_date { (Perl.term) - { let $year := eval $1 }
(Perl.term) - { let $month := eval $2 }
(Perl.term) { let $day := eval $3 }
($year =~ /^\d{4}$/
$month =~ /^\d{2}$/
$day =~ /^\d{2}$/) }
The eval is very restrictive though -- it forces the terms to
have values at compile time and breaks lexical scoping. (Unless
eval can play games with %MY and somehow evaluate in the
caller's scope. Maybe caller.{MY}.eval?)
We can tidy that up a little with another rule:
rule value { Perl.term
{ let $0 := caller(2).{MY}.eval($term) } }
rule iso_date { $year:=value -
$month:=value -
$day:=value
($year =~ /^\d{4}$/
$month =~ /^\d{2}$/
$day =~ /^\d{2}$/) }
There's still the compile-time value problem though.
What is really needed is something that converts the date syntax
to normal Perl code:
rule iso_date { (Perl.term) -
(Perl.term) -
(Perl.term)
{ use grammar Perl::AbstractSyntax;
$0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }
This rule just generates code -- the $0 return result is spliced
into the syntax tree at compile time. All the valid value checking
is done at run-time in the Date object constructor. (Or maybe at
compile time if the compiler can figure out there aren't any
side-effects and the object is serializable. But that's a whole
different thread.) It's very efficient because it only parses the
source code once. All the compiler optimizations (like constant
folding) get applied to your special syntax. But you're writing
Parrot macros (IMCC on steroids maybe?) and not Perl!
Another approach is to delay the final parse until run-time. In
this case, the compiler runs the rule over the input source
code and records the matched text, but without running any of the
code blocks. When the sub is called at run-time, the matched text
is parsed by the rule again, but this time with the code blocks
enabled. The second rule above (using eval) would work fine this
way (as long as the %MY games are possible). The down-side to
this approach is that you have lots of string evals happening
at run-time.
Maybe all of these techniques will be possible?
rule x is macro { ... }
rule y is delayed { ... }
rule z is syntax { ... }
- Ken
Re: Argument aliasing for subs
Somewhere, in another thread . . .
Dr. Claw wrote . . .
sub hidden (str $name, int $force is aka($override))
{ ... }
Yeah, that's what I meant.
Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem is to apply a
property. And is the is/but distinction still around?
Since but's proposal I've not seen any use of it, and
the distinction between a compile time and run time
property was somewhat hazy to me anyway, so I can't be
sure that it's dead or just of rare use.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
First crack at Builtins.p6m
Ok, so without knowing what the XS-replacement will look like and
without knowing what we're doing with filehandle-functions (is tell()
staying or does it get removed in favor of $fh.tell()) and a whole lot
of other stuff it's impossible to translate all of the Perl 5 functions
to Perl 6. However, what I've done is take a quick stab at creating at
least function signatures for everything that was in perlfunc and
implemented some of the functions that do not require any external junk
(e.g. reverse).
Some questions came up while I was doing this. Questions that came up a
lot, I put in comments at the front of the file. Other comments are
in-line and are marked with XXX for easy searching.
Anything that I think will be handled by internals or by the pre-coded
functions that are currently in parrot/languages/perl6/P6C/Builtins.pm,
I marked with INTERNAL for easy searching.
Please don't expect this to compile. It probably has typos and certainly
has masses of undefined class names (e.g. IO::Socket). It's really just
here to help me understand what I don't understand and to get some
questions on the table.
I'll keep updating this as more information about XS, filehandles, etc
become clear. There are also some functions (like split) that will
require my going over A5 with a fine-toothed comb before I proceed.
# Builtin functions
# XXX - This marker is used all over to indicate potential problems and
# quesitons about how Perl 6 works.
#
# High-level questions:
#
# When declaring:
# sub foo($a, $b) {...}
# and
# sub foo($a, *@rest) { ... }
# What is the correct order, and/or is this even valid? I need to know,
# given the way I did sort and reverse in order to handle exploded
# argument lists and arrays efficiently.
#
# What is happening to the IO functions? Do they just go away to be
# subsumed by the appropriate IO:: classes?
#
# Generally need to know how the interface ot libc will work, so
# that all of this junk can be implemented.
#
# Do I need to array is rw? I would think not
# An EMACS helper macro
# (defalias 'perl6-mockup (read-kbd-macro
# C-a sub SPC M-d C-y ( C-e ) SPC { SPC UNIMP(\ C-y \) SPC }))
sub UNIMP($func) { die $0: Unimplemented: $func }
sub NEVER($func) { die $0: $func makes no sense in Perl 6 }
# Math
sub abs($num is int){ return $num=0 ?? $num :: -$num }
sub accept($new is IO::Socket, $gen is IO::Socket){ UNIMP(accept) }
sub alarm($seconds is int){ UNIMP(alarm) }
sub atan2($y is number, $x is number) { UNIMP(atan2) }
sub bind($socket is IO::Socket, $name) { UNIMP(bind) }
sub binmode($fh is IO::Handle, $disc //= ':raw'){ UNIMP(binmode) }
sub bless($ref, $name //= undef){ NEVER(bless) }
sub caller($expr //= undef){ UNIMP(caller) }
sub chdir($path //= $ENV{HOME}){ UNIMP(chdir) }
sub chmod($mode is int, *@paths){
for paths - $_ {
UNIMP(chmod $mode, $_)
}
# XXX - Return value?
}
sub chomp($string is rw){
my $irs = $ {/};
if defined $irs {
if $irs.isa(Object) {
return undef;
} elsif $irs.length == 0 {
$string =~ s/ \n+ $ //;
return $0;
} else {
$string =~ s/{[$irs]}+$//;
return $0;
}
}
}
sub chomp() { UNIMP(chomp(LIST)) }
sub chomp(*@strings is rw) { UNIMP(chomp(LIST)) }
sub chop($string is rw) { UNIMP(chop) }
sub chop() { UNIMP(chop) }
sub chop(*@strings) { UNIMP(chop) }
sub chown($uid is int, $gid is int, *@files) {
for files - $_ {
UNIMP(chown $uid, $gid, $_);
}
# XXX Return value?
}
sub chr($num is int //= $_){ return pack 'C', $num } # XXX Not UNICODE
sub chroot($path //= $_){ UNIMP(chroot) }
sub close($fh is IO::Handle //= XXX_defaulthandle) { UNIMP(close) }
sub closedir($dh is IO::DirHandle) { UNIMP(closedir) }
sub connect($socket is IO:Socket, $name) { UNIMP(connect) }
sub cos($num is number //= $_) { UNIMP(cos) }
sub acos($num is number //= $_) { atan2( sqrt(1 - ($num ** 2)), $num ) }
sub tan($num is number //= $_) { return sin($num) / cos($num) }
sub cos($num is number //= $_) { UNIMP(cos) }
sub crypt($plaintext, $salt) { UNIMP(crypt) }
sub dbmclose(%hash) { NEVER(dbmclose) }
sub dbmopen(%hash, $dbname, $mask) { NEVER(dbmopen) }
# INTERNAL defined
# INTERNAL delete
# INTERNAL die
# INTERNAL do
sub dump($label //= $_) { NEVER(dump) }
# INTERNAL each
sub eof($fh is IO::Handle //= XXX_defaulthandle) { UNIMP(eof) }
sub eval(code) {
warn Perl 6 uses try for blocks;
return try(code);
}
# INTERNAL eval(string)
sub exec($program, *@args) { UNIMP(exec) } # XXX exec $prog $argv0, $argv1...
# INTERNAL exists
# INTERNAL exit
sub exp($num is number //= $_) { UNIMP(exp) }
sub fcntl($fh is IO::Handle, $func, $scalar) { UNIMP(fcntl) }
sub fileno($fh is IO::Handle //= XXX_defaulthandle) { UNIMP(fileno) }
sub flock($fh is IO::Handle, $operation) { UNIMP(flock) }
sub fork() {
Re: First crack at Builtins.p6m
Oh, BTW: Lest anyone think I'm spamming p6l for no reason, I sent the Builtins.p6m to p6l instead of p6i because I consider this a document, not code. When some of the questions get ironed out about the language, then I will talk to p6i about next steps.
Re: Argument aliasing for subs
sub hidden (str $name, int $force is aka($override))
{ ... }
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?
sub hidden (str $name, int $force := $override)
{ . . .}
While less verbose, it's actually more legible to me,
in that the prototype (we still calling it that?)
get's less visual clutter.
In a related note, even if the 'is aka($am, $are,
$also_known_as) = 'Electric Mayhem')' syntax get's
establsihed will the alising trick still work? Or are
we stepping on the Perl 6 rule against leaking lexical
scopes?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
RE: First crack at Builtins.p6m
Aaron Sherman:
# Ok, so without knowing what the XS-replacement will look like
# and without knowing what we're doing with
# filehandle-functions (is tell() staying or does it get
# removed in favor of $fh.tell()) and a whole lot of other
I think that sort of thing is going. IIRC, the only built-in I/O thingy
that's staying is open().
# stuff it's impossible to translate all of the Perl 5
# functions to Perl 6. However, what I've done is take a quick
# stab at creating at least function signatures for everything
# that was in perlfunc and implemented some of the functions
# that do not require any external junk (e.g. reverse).
The one thing I notice all over the place is:
sub abs($num is int){ return $num=0 ?? $num :: -$num }
^
I believe that should be (int $num).
push @newlist, $_ if code(); # XXX - How does code get
$_?
It should be Ccode($_). A closure that receives one argument and
doesn't have a signature gets that argument put into $_.
Overall, things look roughly correct. Well done.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator.
--Damian Conway
