Trying to write a oo :method that isn't automatically inserted in a namespace.
I'm working on http://rt.perl.org/rt3/Ticket/Display.html?id=48631 I've added parsing of :namespace to imcc, now I'm trying to figure out what I'm suppose to do differently when :namespace is present in a methods prototype. I thought I was suppose to add the :method to a namespace, but that seems to already work. I must be missing something, an example test case would be helpful. The following code finds the method 't' in the 'GOOBER' namespace and successfully prints: YES HELLO I thought that :method subs were not suppose to be accessible from the namespace. Kevin .namespace ['GOOBER' ] .sub t :method print self print \n .end .namespace ['LOOSER' ] .sub main :main find_global $P0, 'GOOBER', 't' $I0 = defined $P0 unless $I0 goto no print Yes\n $P0(HELLO) goto end no: print No\n end: .end
Re: [perl #48735] [DEPRECATED] :: in PIR identifiers
Klaas-Jan Stol via RT wrote: On Sun Dec 16 21:11:34 2007, coke wrote: From PDD 19: NOTE: The use of C:: in identifiers is deprecated. what exactly does this mean? In Lua, I started to replace (see r23367) : [ 'Lua::io' ] by [ 'Lua'; 'io' ] François I take it that :: can still appear in typenames, as in PAST::Op, but not, for instance like so: .local int some::var Is that it?
Re: Concerns about {...code...}
On Thu, Dec 20, 2007 at 03:24:30PM -0800, Michael G Schwern wrote:
: Jonathan Scott Duff wrote:
: On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote:
: I think the issue is that bare vars don't interpolate anymore, but
: they still have sigils of their own, so adding to the default interp
: syntax is too noisy: ${$var} is not really much improvement over
: ${\(expr)}.
:
: That's not quite accurate. Scalars interpolate as they always have, but
: aggregates need to be followed their respective bracketing construct
: (e.g., My array contains these items: @array[])
:
: The only issues that I see from the original email are:
: 1. interpolating scalars but not code
: 2. having to be more careful about what type of string you're using
:
: Adriano answered #1 I think: $yaml = Q:!c{ $key: 42 };
:
: For the second one, if you're really just worried about how prevalent {}
: appear in double-quotish strings, perhaps @Larry could be persuaded to
: make them non-interpolative by default. (i.e., the adverb would be
: required to make them interpolate)
:
: That pretty much sums up my concern.
Well, it's certainly a concern that we thought about a lot when
designing the interpolation originally, so I rather suspect I'm highly
unlikely to change my mind on this one. I've done (and read) a fair
amount of pugs programming since then, and while I can see that from a
Perl 5 perspective it looks like a problem, the situation doesn't arise
so often in practice, and when it does, it almost always results in
a compile-time error (which is a good thing). Perl 6 balances a lot
of subtle issues differently than Perl 5 does, and these all factor into
whether closures should interpolate by default or not. More on that
below.
But I will make one general remark at the start, which is that we
want Perl 6 programmer to look at curlies differently than Perl 5
programmers do. In Perl 5, curlies were overloaded many different
ways, and rarely did they mean a closure by themselves. In Perl 6,
it's almost always the case that bare curlies indicate a closure of
some sort throughout the rest of the language. So the visual and
psychological import of seeing and typing curlies is intentionally
weighted rather differently. Curlies are Perl 6's lambda. Whenever
the user sees curlies, we want them to stop and think. Even the
curlies used by the built in control operators are real lambdas
in the abstract, unlike in P5 where they are just hardwired in the
grammar. Bare curlies in regex are now special too.
(Going the other way, you'll note that, in various other spots where
P5 uses curlies such as in \x{...} or $x{foo}, P6 prefers things like
\x[...] or $xfoo instead, to avoid the visual implication of code.)
: The gyrations to turn off interpolating code... it's nice to know that exists
: but not something I want to ever have to remember or type or even consider my
: quoting context.
In general, I would never use negative form myself. I'd be much more
likely to use qs// than qq:!c//. But since the negative adverbial
forms are already available, it seems better to go ahead and provide
them to work as expected, even if they inspire occasional nausea.
As for the Q base form, it's not really there so much for end-use,
but to provide the bare form from which all other quotes and quote-like
forms are constructed, including forms like rx//. Most user-defined
quotes should just be variants of q//. Or just use bare '' quotes,
since it's still possible to interpolate using \qq[$foo]. This is
huffmanly suitable for quoting large stretches of code that need only
occasional interpolations.
: Interpolate vs not interpolate is enough, I have more
: important things to worry about while coding. [1]
And, in fact, this can be taken as an argument for making closures
interpolate consistently in double quotes, if they interpolate at all.
To the first approximation, double quotes do all interpolations
and single quotes do none (ignoring backslashes). Positioning the
double quote semantics somewhere in the middle of the spectrum just
means you have to memorize which sequences interpolate by default
and which don't. And we're trying to avoid the need for the user to
memorize arbitrary lists.
: Non-interpolative by default... well I don't exactly want the feature to go
: away either. [2] I can see its uses [3] and it potentially eliminates some
: otherwise convoluted bits of code. And again, I don't want to be thinking
: about flipping interpolation features on and off for each string. Even qs//
: is more than I want to consider. [4]
In general, if you're interpolating a bunch of strings similarly,
you want to think about factoring that out. One of the reasons
we're reserving backticks for users is so they can use them for
any specialty quotes, not just for qqx//.
: Code execution in a string is a very powerful thing, so it's not the sort of
: thing one wants to accidentally trigger. Because it's
Re: Concerns about {...code...}
On 12/21/07 5:54 AM, Larry Wall wrote: To you and me, the fact that there are single quotes means there's something there to hide. But other people think the other way and see double quotes as indicating there's something to interpolate. I think PBP comes down on that side, but to me, single quotes are a little harder to see. And maybe there's some bias from seeing double quotes used non-interpolatively in American English. FWIW, my reasoning in this area is based on Laziness: single quotes mean I don't have to scan the string looking for interpolated stuff when reading code. Double quotes mean I do, and I'm annoyed at the waste of time when I scan and find nothing. Why didn't this guy just use singles here? It's (mildly) misleading. (There are obviously edge cases, even in Perl 5, but even naive adherence to this guideline is a good first approximation, with a second look only required in the rarest of cases.) -John
Re: [perl #48735] [DEPRECATED] :: in PIR identifiers
Klaas-Jan Stol via RT wrote: On Sun Dec 16 21:11:34 2007, coke wrote: From PDD 19: NOTE: The use of C:: in identifiers is deprecated. what exactly does this mean? I take it that :: can still appear in typenames, as in PAST::Op Yes, that's still fine. In fact, any character that can be represented in any character set that Parrot supports is valid in string names. but not, for instance like so: local int some::var Is that it? Yes, it's deprecated in bare identifiers. The '::' was added as a special case for Perl identifiers, so we either had to add special cases for all the languages, or just declare that if you want a sub, class, etc. with interesting characters you need to give it a string name. The second option makes more sense, as the set of languages that run on Parrot is open-ended, and the bare identifiers aren't accessible to user-level code anyway. Allison
Re: Concerns about {...code...}
On Dec 21, 2007 8:53 AM, John Siracusa [EMAIL PROTECTED] wrote: FWIW, my reasoning in this area is based on Laziness: single quotes mean I don't have to scan the string looking for interpolated stuff when reading code. Double quotes mean I do, and I'm annoyed at the waste of time when I scan and find nothing. Why didn't this guy just use singles here? It's (mildly) misleading. +1, as the kids these days say. I use singles by default for literal strings. I switch to doubles when I need to interpolate, or for text containing apostrophes (though it would be more consistent to use q[...] in the latter case. I use qq and qw all the time, but rarely q for some reason). The single-quoted string literal has become such a habit that I frequently make mistakes in other C-like languages that use the two types of quotation marks to make the character/string distinction. -- Mark J. Reed [EMAIL PROTECTED]
Re: [perl #48735] [DEPRECATED] :: in PIR identifiers
François Perrad wrote: In Lua, I started to replace (see r23367) : [ 'Lua::io' ] by [ 'Lua'; 'io' ] Also a good change. This gains you the benefits of true hierarchical namespaces, and means that different languages that use different characters as class name separators can use your classes. Allison
Re: [perl #48631] [RFE] oo - allow :method to also enter sub in namespace
Patrick R. Michaud wrote: Optional string parameter to C:namespace : Anytime there's a namespace or class parameter, I think we have to consider the possibility of a keyed argument, since the general case is that namespaces are given by keys, not strings. Ah, you're reading :namespace as supplying a full namespace, not just the string name of the sub to use in the namespace. Hmmm... well, others are likely to read it the same way (as some sort of inline export functionality). So maybe :namespace isn't the best name for the feature. Allison
Re: Trying to write a oo :method that isn't automatically inserted in a namespace.
On Fri, Dec 21, 2007 at 01:30:42AM -0700, Kevin Tew wrote: I'm working on http://rt.perl.org/rt3/Ticket/Display.html?id=48631 I've added parsing of :namespace to imcc, now I'm trying to figure out what I'm suppose to do differently when :namespace is present in a methods prototype. I thought I was suppose to add the :method to a namespace, but that seems to already work. Hmm, you seem to be right. I could've sworn that I ran into problems that indicated that :methods weren't automatically going into the namespace, even as recently as last week, but now I can't seem to reproduce the problem. I think I must have misinterpreted some problem in the past as being due to a missing namespace entry, when it may have been something else. (Looking in the wrong namespace comes to mind.) So, it looks like Parrot already does what I need as its current default behavior. My apologies for sending you on a false errand, and you have my gratitude for helping to resolve it so quickly. Pm
Re: Concerns about {...code...}
On Dec 21, 2007, at 5:54 , Larry Wall wrote: On Thu, Dec 20, 2007 at 03:24:30PM -0800, Michael G Schwern wrote: : Jonathan Scott Duff wrote: : [1] Note, I'm the sort of person that uses until I have a reason otherwise. Well, me too, but P6 just provides a different set of reasons. :) To you and me, the fact that there are single quotes means there's something there to hide. But other people think the other way and see double quotes as indicating there's something to interpolate. I think PBP comes down on that side, but to me, single quotes are a FWIW, as a sysadmin who's learned (sometimes the hard way) that paranoia is good when coding, I tend to use single quotes in Perl (and shell) code unless I specifically want interpolation to happen. Also, I come down on the side of generic interpolation should be a little harder to enable: either with a more complex interpolation syntax (although your arguments for simple braces have merit) or a quoting adverb which defaults off. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: [perl #48631] [RFE] oo - allow :method to also enter sub in namespace
Kevin Tew started investigating this ticket, and he discovered that :method subs are already being placed as entries in the namespace by default, which is the behavior I was looking for. So, the issue turns out to be a non-issue (for me at least), unless we decide to make it one. Apologies for the false alarm. I'm not sure what led me to believe that :method subs weren't going into the namespace, as I can't reproduce the problem now. We can either rename this ticket as provide a way for :method to not appear as namespace entry, or we can just close the ticket. I'm in favor of the latter for now. Pm
Re: Trying to write a oo :method that isn't automatically inserted in a namespace.
On Fri, Dec 21, 2007 at 01:30:42AM -0700, Kevin Tew wrote: I've added parsing of :namespace to imcc, now I'm trying to figure out what I'm suppose to do differently when :namespace is present in a methods prototype. I thought I was suppose to add the :method to a namespace, but that seems to already work. The relevant code is the 'set_pmc_keyed_str' vtable function in src/pmc/namespace.pmc. After inserting a method or vtable override, it used to skip the rest of the routine and so not insert the namespace entry. Not sure when the code changed, but it doesn't particularly matter. What the code should do is note that the namespace entry was inserted as a method or vtable override, maybe by setting an integer flag, and then at line 289 check the flag and return if it's true. (It can't just return immediately, because some entries are both vtable overrides and methods.) I think I must have misinterpreted some problem in the past as being due to a missing namespace entry, when it may have been something else. (Looking in the wrong namespace comes to mind.) So, it looks like Parrot already does what I need as its current default behavior. It was set that way in the past, which may have caused an earlier problem. But, if you don't actually need the feature now, we won't add the flag. Allison
Re: Trying to write a oo :method that isn't automatically inserted in a namespace.
Kevin Tew wrote: :method subs should not be added to the namespace unless they have a :namespace flag. Yes. So we should fix set_pmc_keyed_str to not add :methods unless the :namespace flag is present. Sort of. The thing is, 'set_pmc_keyed_str' isn't just storing subs in the namespace, it's also storing methods in the class. (Because everything defined with '.sub' calls 'set_pmc_keyed_str'.) So, lines 180-288 of 'set_pmc_keyed_str' are responsible for determining if a sub element should be stored somewhere besides the namespace, and lines 290 onward actually store the sub (or variable) in the namespace. The whole 'set_pmc_keyed_str' vtable function should be refactored out into a series of helper routines. But, refactored or not, what it effectively has to do is: [...] note that the namespace entry was inserted as a method or vtable override, maybe by setting an integer flag, and then at line 289 check the flag and return if it's true. (It can't just return immediately, because some entries are both vtable overrides and methods.) The places where you would currently want to set an I don't belong in the namespace flag are lines 199, 217, 242, and 270. (Those are vtable override, method, NCI method, and multi method, respectively.) Allison
Re: Trying to write a oo :method that isn't automatically inserted in a namespace.
Yeah, I spent an hour trying to figure out how 'set_pmc_keyed_str' vtable function in src/pmc/namespace.pmc precluded :methods from the namespace before I tested it and found out that it didn't. What do we want the final behavior to be? I'm going to take a guess, correct me as needed. :method subs should not be added to the namespace unless they have a :namespace flag. So we should fix set_pmc_keyed_str to not add :methods unless the :namespace flag is present. Kevin Allison Randal wrote: On Fri, Dec 21, 2007 at 01:30:42AM -0700, Kevin Tew wrote: I've added parsing of :namespace to imcc, now I'm trying to figure out what I'm suppose to do differently when :namespace is present in a methods prototype. I thought I was suppose to add the :method to a namespace, but that seems to already work. The relevant code is the 'set_pmc_keyed_str' vtable function in src/pmc/namespace.pmc. After inserting a method or vtable override, it used to skip the rest of the routine and so not insert the namespace entry. Not sure when the code changed, but it doesn't particularly matter. What the code should do is note that the namespace entry was inserted as a method or vtable override, maybe by setting an integer flag, and then at line 289 check the flag and return if it's true. (It can't just return immediately, because some entries are both vtable overrides and methods.) I think I must have misinterpreted some problem in the past as being due to a missing namespace entry, when it may have been something else. (Looking in the wrong namespace comes to mind.) So, it looks like Parrot already does what I need as its current default behavior. It was set that way in the past, which may have caused an earlier problem. But, if you don't actually need the feature now, we won't add the flag. Allison
Re: [perl #48735] [DEPRECATED] :: in PIR identifiers
On Dec 21, 2007 8:50 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: On Dec 21, 2007 3:53 PM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol via RT wrote: On Sun Dec 16 21:11:34 2007, coke wrote: From PDD 19: NOTE: The use of C:: in identifiers is deprecated. what exactly does this mean? I take it that :: can still appear in typenames, as in PAST::Op Yes, that's still fine. In fact, any character that can be represented in any character set that Parrot supports is valid in string names. but not, for instance like so: local int some::var Is that it? Yes, it's deprecated in bare identifiers. The '::' was added as a special case for Perl identifiers, so we either had to add special cases for all the languages, or just declare that if you want a sub, class, etc. with interesting characters you need to give it a string name. there are some tests that explicitly use this feature; don't remember which ones, but I found some yesterday. I guess these tests can be removed (as their sole purpose is to test something that's going to be removed) so, shall I remove those tests? yes, as long as that's what they're testing. that's a normal part of deprecation. ~jerry
Factoring Arguments
I'm thinking aloud here, so please bear with me.
A number of languages have a with ... construct that's intended to
cut down on repetitive typing, by factoring the invocant out of every
method call. Perl 6 also has this, in the form of given ...:
given $foo.bar.baz {
.dothis();
.dothat();
.doanother();
}
(same as)
$foo.bar.baz.dothis();
$foo.bar.baz.dothat();
$foo.bar.baz.doanother();
I'm wondering if something similar could be done for optional
arguments - something along the lines of within the following block,
assign value V to argument X of routine R by default. This would
allow for a similar factoring out of repetitive flags. So instead
of:
say qq:!c ... { ... } ...;
say qq:!c ... { ... } ...;
say qq:!c ... { ... } ...;
and so on, you might do something like:
with qq :(c = false) {
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
Or maybe it could be a pragma (which, by definition, lasts only until
the end of the current scope):
{
use defaults { qq = :!c }
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
The core concept here is to allow the programmer to easily change the
default behavior of a routine within a given scope so that he doesn't
have to repeatedly override the default behavior every time it comes
up.
--
Is this reasonable, or is this too much of a corner case to be worth the effort?
--
Jonathan Dataweaver Lang
Re: [perl #48735] [DEPRECATED] :: in PIR identifiers
On Dec 21, 2007 3:53 PM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol via RT wrote: On Sun Dec 16 21:11:34 2007, coke wrote: From PDD 19: NOTE: The use of C:: in identifiers is deprecated. what exactly does this mean? I take it that :: can still appear in typenames, as in PAST::Op Yes, that's still fine. In fact, any character that can be represented in any character set that Parrot supports is valid in string names. but not, for instance like so: local int some::var Is that it? Yes, it's deprecated in bare identifiers. The '::' was added as a special case for Perl identifiers, so we either had to add special cases for all the languages, or just declare that if you want a sub, class, etc. with interesting characters you need to give it a string name. there are some tests that explicitly use this feature; don't remember which ones, but I found some yesterday. I guess these tests can be removed (as their sole purpose is to test something that's going to be removed) so, shall I remove those tests? kjs The second option makes more sense, as the set of languages that run on Parrot is open-ended, and the bare identifiers aren't accessible to user-level code anyway. Allison
Re: Factoring Arguments
On Fri, Dec 21, 2007 at 08:41:54AM -0800, Jonathan Lang wrote:
and so on, you might do something like:
with qq :(c = false) {
I think this can be done with normal currying, something like
temp circumfix: := quote:qq.assuming(:!c);
-ryan
[perl #49001] [PROPOSAL][DOCS] Change word compilation_unit into something else (like sub)
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #49001] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49001 IMCC's top level non-terminal rule looks something like: program: compilation_unit | compilation_units compilation_unit compilation_unit: sub | /* other stuff like HLL ... */ pmichaud wondered what actually /is/ a compilation unit. In the classic C.S. sense, it's a file, or string that results in one block that is evaluated (in PCT at least, I guess Perl too? don't know, I'm not a perl programmer). . This is different from IMCC and its docs, where a compilation unit seems to refer to individual subs. In order to prevent confusion, I propose to stick to the classic sense, and replace compilation_unit with some other word (jsut stick to sub). IMCCs docs should then be updated accordingly. (and source, which is kinda a lot of work, but let's just forget about that for now) kjs
writing mod_perl6 in perl 6
This just went up in my blog, but I think it's interesting enough to post
to the list as well.
-jeff
One of the goals of the mod_parrot project is to provide the
infrastructure for running the Perl 6 version of mod_perl, a.k.a.
mod_perl6. I've already demonstrated that mod_perl6 works, so that goal is
slowly being achieved. Many thanks to Patrick Michaud, Jerry Gay, and
everyone else who has worked on the Parrot implementation of Perl 6.
Another lesser known goal of mod_parrot is to allow the high level
language (HLL) layers to be written in the HLL itself. That is to say,
write mod_perl6 in Perl 6. Up to this point, mod_parrot has five HLL
layers (PIR, NQP, Perl6, PHP/Plumhead, Perl1/Punie), all written in
Parrot's native PIR. However, yesterday, with some help from Patrick, I
was able to port mod_perl6 from PIR to pure Perl 6!
As an example, here is a very bare-bones mod_perl6 (DISCLAIMER: string
interpolation in namespaces doesn't actually work yet):
module ModParrot::HLL::perl6;
our %loaded_modules;
# load a Perl 6 handler module
sub load($module)
{
unless (%loaded_modules{$module}) {
use $handler;
%loaded_modules{$module} = 1;
}
}
# call a Perl 6 response handler
sub handler($name)
{
my $r = Apache::RequestRec.new();
load($name);
my $status = ::($name)::handler($r);
$status;
}
# call a Perl 6 authentication handler
sub authen_handler($name)
{
my $r = Apache::RequestRec.new();
load($name);
my $status = ::($name)::handler($r);
$status;
}
When calling a Perl 6 handler, mod_parrot loads this module and calls the
individual handler routines according to the Apache configuration. It also
provides the interface to Apache, including the Apache::RequestRec class
needed by mod_perl6. Everything else it leaves to the Perl 6 compiler.
You might think this code doesn't actually do much, and that's the point.
It's really just a simple thunking layer between mod_parrot and your
handlers, enforcing the rules of the mod_perl6 implementation. For
example, in mod_perl, an Apache::RequestRec object is passed to all
response handlers. This layer is responsible for making sure that happens.
As the Perl 6 compiler matures and mod_parrot adds more functionality,
this version of mod_perl6 will inevitably change. But what you see above
will remain at its core -- loading Perl 6 modules, juggling arguments, and
passing control to handler subroutines. And the fact that it's pure Perl 6
will enable scores of Perl programmers to hack on it without having to
know anything about Parrot or C programming. Take that, XS.
Re: Concerns about {...code...}
On Fri, Dec 21, 2007 at 08:59:02AM -0500, Mark J. Reed wrote: : The single-quoted string literal has become such a habit that I frequently : make mistakes in other C-like languages that use the two types of quotation : marks to make the character/string distinction. Yeah, it might be my C background that biases me the other way too. I guess when I'm reading someone else's double-quoted string I don't really feel like I need to check whether it interpolates; it just chunks into a psychological unit that *could* interpolate if it wants to, and I note any obvious literal text and go on from there. I don't feel compelled to analyze the string in depth unless I need to. For someone who is somewhere on the autistic spectrum, I'm pretty good at ignoring details. I understand others may not be so lucky. :) Larry
Re: writing mod_perl6 in perl 6
On Dec 21, 2007, at 10:50 AM, Jeff Horwitz wrote: This just went up in my blog, but I think it's interesting enough to post to the list as well. URL? I'll post it to Mechanix. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Factoring Arguments
A number of languages have a with ... construct that's intended to cut down on repetitive typing, I hope I will be excused for dragging in the indecency, but it might be worth looking at the concepts COBOL used to mitigate its verbosity, (e.g. types defined in a structure that get inherited by lower levels, unless specifically over-ridden). Those who will not learn from history are bound to repeat it, and a lot of o-o concepts give me an unpleasant sense of deja vu. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: Concerns about {...code...}
Larry Wall wrote: As for the Q base form, it's not really there so much for end-use, For an operator not intended for end use, it has a remarkable low Huffman rank...
Re: Concerns about {...code...}
On Dec 21, 2007 4:51 PM, Dave Whipp [EMAIL PROTECTED] wrote: Larry Wall wrote: As for the Q base form, it's not really there so much for end-use, For an operator not intended for end use, it has a remarkable low Huffman rank... But since it will be combined with adverbs like my $str = Q :b :s /Hello $name\n/; it needs to be short. Q is just one part of a larger expression that is meant to be taken as a whole.
Re: Concerns about {...code...}
Chas. Owens wrote: On Dec 21, 2007 4:51 PM, Dave Whipp [EMAIL PROTECTED] wrote: Larry Wall wrote: As for the Q base form, it's not really there so much for end-use, For an operator not intended for end use, it has a remarkable low Huffman rank... But since it will be combined with adverbs like my $str = Q :b :s /Hello $name\n/; it needs to be short. Q is just one part of a larger expression that is meant to be taken as a whole. That misses the point of Huffman coding. It is not the length of the overall expression that determines the score: it is the relative frequency with which it will appear in perl6 programs. If the construct is used only rarely then it should have a longer name, and people using it would be well advised to use the long form of the adverbs when they do so -- increasing the overall length of the expression still further as an aid to readability of the rarely used operator. If it will be frequently used then it of course deserves the short name.
Re: Concerns about {...code...}
Dave Whipp wrote: If the construct is used only rarely then it should have a longer name, Actually, Huffman coding implies that if the construct is used regularly then it should have a short name. It does not mandate a long name for rare constructs; it merely says that if a given short name is suitable for both a common construct and a rare construct, the common construct should get it. If there's no such conflict, there's no reason not to give the short name to a rarely used construct. -- Jonathan Dataweaver Lang
Re: Factoring Arguments
Ryan Richter wrote:
Jonathan Lang wrote:
and so on, you might do something like:
with qq :(c = false) {
I think this can be done with normal currying, something like
temp circumfix: := quote:qq.assuming(:!c);
That handles the specific example that I had in mind, but does so in a
rather brittle way. First, the programmer is forced to use
double-quotes to make use of the currying; he cannot switch to another
quoting character if one of the strings that he's dealing with has a
number of double-quote characters in it. This being a
quoting-specific issue, it should be no surprise that it comes with a
quoting-specific solution, e.g., use 'qs' instead of 'qq:!c') - but
that still leaves you with having to prefix every string in the target
scope: cqs ... instead of c ... . Still, that isn't my main
concern here.
There's no way that I know of to override the currying: every
.assuming that you use removes one parameter from the signature (if I
understand currying correctly). This means that you don't get to set
assumed values for three different parameters at the start of the
block and then override just one of them for a single use of the
function in the middle of the block. This concern could probably be
addressed if currying doesn't remove arguments from a signature, but
instead forces them to be optional and assigns default values to them;
but this can lead to its own problems, such as what happens when you
curry the second of three required positional parameters.
What I was thinking of would be somewhat more modest: it would be a
variation on the currying mechanic, but would only apply to optional
parameters. It wouldn't remove them from the signature at all; it
would merely change the default values assigned to them.
--
Jonathan Dataweaver Lang
Re: Concerns about {...code...}
On Fri, Dec 21, 2007 at 01:51:19PM -0800, Dave Whipp wrote: Larry Wall wrote: As for the Q base form, it's not really there so much for end-use, For an operator not intended for end use, it has a remarkable low Huffman rank... That's because some end-users will want to use Q anyway. I figured the shift key requirement was sufficient Huffman coding... :-) Larry
Re: Factoring Arguments
Ryan Richter skribis 2007-12-21 11:52 (-0500):
On Fri, Dec 21, 2007 at 08:41:54AM -0800, Jonathan Lang wrote:
and so on, you might do something like:
with qq :(c = false) {
I think this can be done with normal currying, something like
temp circumfix: := quote:qq.assuming(:!c);
Hm, would the following work?
given quote:qq.assuming(:!c) - circumfix: {
...
}
--
Met vriendelijke groet, Kind regards, Korajn salutojn,
Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: Factoring Arguments
On Fri, Dec 21, 2007 at 08:41:54AM -0800, Jonathan Lang wrote:
: I'm wondering if something similar could be done for optional
: arguments - something along the lines of within the following block,
: assign value V to argument X of routine R by default. This would
: allow for a similar factoring out of repetitive flags. So instead
: of:
:
: say qq:!c ... { ... } ...;
: say qq:!c ... { ... } ...;
: say qq:!c ... { ... } ...;
:
: and so on, you might do something like:
:
: with qq :(c = false) {
: say ... { ... } ...;
: say ... { ... } ...;
: say ... { ... } ...;
: }
Hmm, well, qq isn't really a function, it's actually the name of
a sublanguage, as parsed by a macro.
: Or maybe it could be a pragma (which, by definition, lasts only until
: the end of the current scope):
:
: {
: use defaults { qq = :!c }
: say ... { ... } ...;
: say ... { ... } ...;
: say ... { ... } ...;
: }
I like to name pragmas by the construct they're controlling, so if
we took that approach, I'd probably make it something like:
{
use qq ':!c';
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
: The core concept here is to allow the programmer to easily change the
: default behavior of a routine within a given scope so that he doesn't
: have to repeatedly override the default behavior every time it comes
: up.
:
: --
:
: Is this reasonable, or is this too much of a corner case to be worth the
effort?
Well, sure, but there's really no effort required at all, given you can
already do it (in theory) with:
{
my macro quote: { 'qq:!c' }
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
Actually, the my is a bit redundant there; syntax changes from
macros are always lexically scoped. That includes imports of macros,
so if you made a module that contained:
my macro quote: is export(:DEFAULT) { 'qq:!c' }
then you could use it like this:
{
use Schwernlich;
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
and it would be a lexically scoped language hack. With a slight
generalization it's the use qq pragma above. Welcome to Perl 6. :)
Larry
Re: Status of docs/embed.pod and Parrot::Embed?
On Mon, Dec 10, 2007 at 04:37:31PM +0200, Allison Randal wrote: Tim Bunce wrote: I meant docs/pdds/draft/pdd10_embedding.pod I could trying hacking on it to at least mention all the functions in embed.h with a few words on each. I'd be fumbling in the dark mostly but it would at least push the document along for others to review later. This was a partial first draft written by chromatic. The extending/embedding PDD's aren't on the core list of milestones, so I don't have a specific date when I'm planning to work on it. It probably makes the most sense to repeat the group drafting strategy we're using with the PIR PDD. You and others can help pull together the draft PDD, and I'll review/revise/approve it as it reaches a relatively solid state. We can also also talk back and forth about ideas on the mailing list as it solidifies. There are two parts of the group drafting task: documenting how the system works now, and documenting how you would like it to work. Documenting the functions in embed.h is a great place to start. At the moment, chromatic or I would start exactly where you'll be starting: sitting down with the code, extracting a list of current functions/features, and at the same time keeping an eye out for missing features, misfeatures, or other places in need of improvement. So, if you or others are willing to take a first stab at it, it would be enormously helpful. (It's also a great way to gain experience with parrot.) Sounds good. I added a tool to check the coverage of the embed.h API: $ perl tools/check_embed_coverage.pl ../../include/parrot/embed.h Embed.xs 20 out of 25 Parrot_* functions in ../../include/parrot/embed.h not used in Embed.xs: Parrot_clear_debug Parrot_clear_flag Parrot_clear_trace Parrot_debug Parrot_disassemble Parrot_exit Parrot_init_stacktop Parrot_run_native Parrot_runcode Parrot_set_config_hash Parrot_set_debug Parrot_set_flag Parrot_set_run_core Parrot_set_trace Parrot_setup_argv Parrot_setup_opt Parrot_setwarnings Parrot_test_debug Parrot_test_flag Parrot_test_trace I'd appreciate some guidance on what interfaces are most stable / least likely to change / most useful so I can prioritise my time. Similarly it may help Jeff prioritise work on PDD10 as more spec detail would help me write some tests. Meanwhile there's some housekeeping I can be getting on with. Like fixing the broken Makefile.PL (seems best to make it a wrapper for the working Build.PL) Actually, what we'd like to do is eliminate the Module::Build dependency, and integrate the build process for Parrot::Embed into Parrot's build process (which is all Makefiles). chromatic wrote Parrot::Embed as an independent CPAN module, but with the need to always have a version of Parrot::Embed that's compatible with the version of Parrot you have installed, we'll ship them together. (It may also be dual-life'd on CPAN, that's one of the open design questions.) So should I just delete the Build related files? Tim.
Re: Concerns about {...code...}
John Siracusa wrote: On 12/21/07 5:54 AM, Larry Wall wrote: To you and me, the fact that there are single quotes means there's something there to hide. But other people think the other way and see double quotes as indicating there's something to interpolate. I think PBP comes down on that side, but to me, single quotes are a little harder to see. And maybe there's some bias from seeing double quotes used non-interpolatively in American English. FWIW, my reasoning in this area is based on Laziness: single quotes mean I don't have to scan the string looking for interpolated stuff when reading code. Double quotes mean I do, and I'm annoyed at the waste of time when I scan and find nothing. Why didn't this guy just use singles here? It's (mildly) misleading. (There are obviously edge cases, even in Perl 5, but even naive adherence to this guideline is a good first approximation, with a second look only required in the rarest of cases.) Normally I'd go on the side of the reader and say yes, when writing code you should be picky about what quotes you use. But in this case I find that, on the writing side, I find it a common annoyance when I chuck a variable into a string and then only realize afterwards that it's not interpolating. On the reading side, I find visually scanning for $ in strings easy and I guess I assume everyone else does, too. -- We do what we must because we can. For the good of all of us, Except the ones who are dead. -- Jonathan Coulton, Still Alive
[perl #48971] Parrot build failure no such instruction: `trap'
On Thu Dec 20 21:34:41 2007, [EMAIL PROTECTED] wrote: On a PPC with OSX 10.5.1 I didn't know you could run 10.5.1 on PPC; I thought it only worked on x86. Could you attach the output from 'perl -V'? It may help us diagnose this problem better. Thank you very much.
Re: Concerns about {...code...}
Michael G Schwern skribis 2007-12-21 19:21 (-0800): Normally I'd go on the side of the reader and say yes, when writing code you should be picky about what quotes you use. But in this case I find that, on the writing side, I find it a common annoyance when I chuck a variable into a string and then only realize afterwards that it's not interpolating. On the reading side, I find visually scanning for $ in strings easy and I guess I assume everyone else does, too. Just to add nothing to the discussion: I find double quotes without interpolation annoying, but only when I'm reading code without syntax highlighting. Whenever I read code with syntax highlighting that makes the interpolated variables stand out, it's no issue at all. I tend to write first, and then change them to '' when getting close to releasing the code. Unpaid non-opensource code usually stays at ... My excuse is growing up with BASIC. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker [EMAIL PROTECTED] http://juerd.nl/sig Convolution: ICT solutions and consultancy [EMAIL PROTECTED]
Re: Concerns about {...code...}
Larry Wall wrote:
But I will make one general remark at the start, which is that we
want Perl 6 programmer to look at curlies differently than Perl 5
programmers do. In Perl 5, curlies were overloaded many different
ways, and rarely did they mean a closure by themselves. In Perl 6,
it's almost always the case that bare curlies indicate a closure of
some sort throughout the rest of the language. So the visual and
psychological import of seeing and typing curlies is intentionally
weighted rather differently. Curlies are Perl 6's lambda. Whenever
the user sees curlies, we want them to stop and think. Even the
curlies used by the built in control operators are real lambdas
in the abstract, unlike in P5 where they are just hardwired in the
grammar. Bare curlies in regex are now special too.
All this makes me happy and more willing to accept interpolative curlies. I
was rapidly hooked on Ruby's ability to easily pass blocks into methods and
want to see more user ability to play with blocks.
And after looking a bit more into how Perl 6 does interpolation I see a lot
has changed. So I'll drink it all in some more.
: Code execution in a string is a very powerful thing, so it's not the sort of
: thing one wants to accidentally trigger. Because it's using a common,
: innocent construct, this strikes me as being all too easy to trigger
: accidentally and unknowingly.
:
: $ pugs -wle 'sub key() { 42 } sub value() { 23 } say { key: value }'
: 23
:
: Whoops.
Seems like you had to work pretty hard to contrive an example
that would parse. P6 is much pickier about random code than P5 is.
FWIW that naturally occurred to me and I was surprised when it parsed without
error. But I've been doing a lot of YAML lately.
As a last resort, you can even redefine how double quotes work.
All is fair if you predeclare. But I think some people would
construe that as antisocial.
Every time someone responds to a Perl 6 language concern with just change the
grammar I silently scream inside. ;)
--
Life is like a sewer - what you get out of it depends on what you put into it.
- Tom Lehrer
