Re: S5: substitutions
Larry Wall wrote: On Sat, Oct 07, 2006 at 07:49:48PM -0700, Jonathan Lang wrote: : Another possibility: make it work. Add a delayed parameter trait : that causes evaluation of that trait to be postponed until the first : time that the parameter actually gets used in the routine. If it : never gets used, then it never gets evaluated. I could see uses for : this outside of the narrow scope of implementing substitutions. Tell me how you plan to do MMD on a value you don't have yet. MMD is based on types, not values; and you don't neccessarily have to evaluate something in order to know its type. Also, you don't neccessarily need every argument in order to do MMD: if there's a semi-colon in any of the candidates' signatures prior to the argument in question, MMD stands a decent chance of selecting a candidate before the question of its type comes up. Worst case scenario (a Code object without a return type being compared to a non-Code parameter), you can treat the argument's type as Any, and let the method redispatch once the type is known, if it's appropriate to do so. That said, the real problem here is figuring out what to do if some candidates ask for a given parameter to be lazily evaluated and others don't. It would probably be best to restrict the lazy evaluation option to the prototype's parameters, so that it always applies across the board. -- Consider this as another option: instead of a parameter trait, apply a trait to the method prototype. With this trait in play, all parameter evaluations are postponed as long as possible. If the first candidate needs only the first two parameters to test its viability, only evaluate the first two parameters before testing it. If the dispatch succeeds, the other parameters remain unevaluated until they actually get used in the body. If all of the two-parameter candidates fail, evaluate the next batch of parameters and go from there. This approach doesn't guarantee that a given parameter won't be evaluated before its first appearance within the routine; but it does remove the guarantee that it will be. -- In the case of subst, there's an additional wrinkle: you can't always evaluate the expression without making reference to the pattern's Match object, which won't be known until the pattern is applied to the invocant. In particular, closures that refer to $0, $1, etc. will only work properly if called by the method itself, and only after $0, $1, etc. have been set. All things considered, the best solution for subst might be to treat the timing of quote evaluation in a manner analogous to regex evaluation. -- Jonathan Dataweaver Lang
Re: S5: substitutions
Jonathan Lang writes:
Translating this to perl 6, I'm hoping that perl6 is smart enough to
let me say:
s(pattern) { doit() }
Instead of
s(pattern) { { doit() } }
That special case is nasty if you don't know about it -- you
inadvertently execute as code something which you just expected to be a
string. Not a good trap to have in the language.
Smylers
S5: substitutions
Smylers wrote:
Jonathan Lang writes:
Translating this to perl 6, I'm hoping that perl6 is smart enough to
let me say:
s(pattern) { doit() }
Instead of
s(pattern) { { doit() } }
That special case is nasty if you don't know about it -- you
inadvertently execute as code something which you just expected to be a
string. Not a good trap to have in the language.
If you expected it to be a string, why did you use curly braces?
While I'm completely on board with the idea that _pattern_ delimiters
shouldn't affect the _pattern's_ semantics, the second half of the
search-and-replace syntax isn't a pattern. Conceptually, it's either
a string or an expression that returns a string.
Larry pretty much summed up what I'm looking for in this regard -
change the s/// syntax so that it has two distinctive forms:
s/pattern/string/
(where '/' can be replaced by any valid non-bracketing delimiter, and
string is always evaluated as an interpolated string)
or
s[pattern] expression
(where '[' and ']' can be replaced by any valid pair of bracketing
delimiters, and expression is evaluated as a perl6 expression)
--
Jonathan Dataweaver Lang
Re: S5: substitutions
Jonathan Lang writes:
Smylers wrote:
Jonathan Lang writes:
Translating this to perl 6, I'm hoping that perl6 is smart enough
to let me say:
s(pattern) { doit() }
Instead of
s(pattern) { { doit() } }
That special case is nasty if you don't know about it -- you
inadvertently execute as code something which you just expected to
be a string. Not a good trap to have in the language.
If you expected it to be a string, why did you use curly braces?
Because it isn't possible to learn of all Perl (5 or 6) in one go. And
in general you learn rules before exceptions to rules.
In general in Perl the replacement part of a substitution is a string,
one that takes interpolation like double-quoted strings do.
In general in Perl if the default delimiter for something is
inconvenient you can pick a different delimiter -- this includes
patterns, and also strings. And if you pick any sort of brackets for
your delimiters then they match -- which is handy, cos it means that
they can still be used even if the string inside contains some of those
brackets.
So it's quite possible for somebody to have picked up all the above, and
have got used to using Cqq[long string] or Cqq{long string} when he
wishes to quote long strings. The form with braces has the advantage
that they are relatively uncommon in text (and HTML, and SQL, and many
other typically encountered long strings).
At which point if he wants to do substitution with slashes in at least
one of the pattern or the replacement text (perhaps it's a URL or a
filename) then he's likely to pick some other arbitrary characters for
doing the quoting. And braces seem as likely to be picked as anything
else. Unless he specifically knows about an exception there's no reason
not to pick them.
I refer simply to Perl above. The above situation could just as
easily arise (or already have arisen) in Perl 5 -- in which case the
programmer's expectations would've been met and the code interpreted
fine. Your proposal would make that no longer the case in Perl 6.
And, apart from people learning Perl fresh, there's also a large number
of existing Perl 5 programmers who also won't be expecting this
exception.
Yes, Perl 6 isn't supposed to be compatible with Perl 5, and obviously a
Perl 5 coder is going to have to learn lots of new things anyway. But
usually they are significantly different, or the old way of doing things
will be a syntax error. This is a situation where the old syntax
continues to work but does something quite different.
That's unfortunate, but probably liveable with in general. But in this
particular case the particular behaviour involves _executing as Perl
code something which the programmer never intended to be code in the
first place_. That's crazily dangerous.
It's like having a Perl 5 to Perl 6 translator that randomly sticks
eval statements in front of some of your double-quoted strings.
While I'm completely on board with the idea that _pattern_ delimiters
shouldn't affect the _pattern's_ semantics, the second half of the
search-and-replace syntax isn't a pattern. Conceptually, it's either
a string or an expression that returns a string.
Sure. Or rather, it's a string (but braces inside strings can be used
to embed expressions in them).
To be consistent your proposal should also suggest that these become
equivalent:
* { function() }
* qq[ {function() }]
* qq{ function() }
* eval function()
and, naturally, that these no longer are:
* string
* qq[string]
* qq{string}
And if braces are special as delimiters for Cqq consistency would say
they should be for Cq as well -- effectively just another way of
spelling Ceval, but one that doesn't stand out so much.
Smylers
Re: S5: substitutions
Smylers schreef: in this particular case the particular behaviour involves _executing as Perl code something which the programmer never intended to be code in the first place_. That's crazily dangerous. I wouldn't mind eval() to be off by default, so to have to put a use eval in every block that needs it. -- Affijn, Ruud Gewoon is een tijger.
Re: Synposis 26 - Documentation [alpha draft]
I liked it. Just one nit, near the end: You can also preconfigure Lformatting codes|#Formatting codes, by naming them with a pair of angles as a suffix. For example: =comment Always allow E codes in any (implicit or explicit) V code... =config V :allowE =comment All code to be italiciized... ^^ =config C :formattedI Note that, even though the code is named using single-angles, the preconfiguration applies regardless of the actual delimiters used on subsequent instances of the code. s/italiciized/italicized/ in the marked place. -- Customer Waiter, waiter! There's a fly in my soup! Waiter That's not a bug, it's a feature. http://surreal.istic.org/ It sounded right in my head.
Recursing? hypers
S03 says that hypers recurse into subarrays. That's a nice and useful feature, but that not-recursing is even more useful. Especially given that many objects will probably does Array, you want to be explicit about recursion. S03 doesn't give a way to avoid recursion. I suggested on #perl6 that standard hypers do not recurse, and a new operator: double hypers. These are the same, but they do recurse. From my point of view, hypers should operate on lists, not arrays. Recursive hypers would work on arrays because arrays are single element lists. Audrey agreed. It would probably be useful to allow combinations of recursive and non-recursive hypers. »+«# do not dive into arrays »»+«« # do dive into arrays, on both sides »+«« # dive into arrays only on the RHS »»+« # same, but LHS 42, 15 »+ 1 # 43, 16 ( 42, 15 ) »+ 1 # 43, 16 [ 42, 15 ] »+ 1 # 2 [ 42, 15 ] »»+ 1 # [ 43, 16 ] The ASCII variant is a bit big, but that's okay huffmanwise, IMO. Recursion can be a pretty big operation anyway. Being explicit about that is good. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: Synposis 26 - Documentation [alpha draft]
Damian Conway wrote: Delimited blocks are bounded by C=begin and C=end markers... ...Typenames that are entirely lowercase (for example: C=begin head1) or entirely uppercase (for example: C=begin SYNOPSIS) are reserved. I'm not a great fan of this concept of reservation when there is no mechanism for its enforcement (and this is perl...). Typical programmers ignore it, just as they ignore similar reservations of the type lower-case subroutine names are reserved. If use strict will flag an error for their use, then perhaps is reserved would become must be predeclared (imported via =use). Then any module will be able to add its own typenames, without needing some distinguishing this is a core module trait to enable the typename. Reservation then simply becomes a note to module authors, not part of the language specification.
Comments in qw// or qqw//
A long while back Damian said I should follow up on the subject of comments in qw// like constructs, and how useful they would be. So im following up. Juerd said this is the right place. If its not obvious why this would be nice: qw() is often used as a list constructor for things like options or hash elements, and it would be convenient to have a way to selectively comment out certain elements. In perl 5 you have to CP out the offending part and then stick it in a comment later on. Or hand hack a custom qw//, which for quick fixes, and stuff like that is a bit annoying. Cheers, Yves -- perl -Mre=debug -e /just|another|perl|hacker/
S5: substitutions
Smylers wrote:
Jonathan Lang writes:
If you expected it to be a string, why did you use curly braces?
Because it isn't possible to learn of all Perl (5 or 6) in one go. And
in general you learn rules before exceptions to rules.
Agreed.
In general in Perl the replacement part of a substitution is a string,
one that takes interpolation like double-quoted strings do.
Here's where I differ from you. In general, string literals are
delimited by quotes; pattern literals are delimited by forward
slashes; and closures (i.e., code literals) are delimited by curly
braces. And once you learn that other delimiters are possible for
patterns and strings, that knowledge comes with the added fact that in
order to use a non-standard delimiter, you have to preface it with a
short tag clearly identifying what is being delimited.
In general, you can use literals anywhere you can use variables, and
vice versa. There are two crucial exceptions to this, both of which
apply to the topic at hand: one is minor, and the other is major. The
minor exception is the pattern-matching macro, m//. This macro takes
a pattern literal and applies it as a match criterion to either the
current topic ($_) or whatever is attempting to match (via ~~). m//
_must_ take a pattern literal; it cannot take a variable containing a
Regex object. To do the latter, you have to embed the Regex object in
a pattern literal.
m// is a _minor_ exception because it can be viewed as being the
complement of rx// - both can be thought of as pattern literals, with
m// being a pattern literal that always attempts to create a Match
object and rx// being a pattern literal that always tries to create a
Regex object. Meanwhile, you have the .match method: unlike m//,
.match isn't choosy about where it gets its Regex object; it can come
from a pattern literal, as with m//; it can be passed in by means of a
variable; it can be composed on the spot by an expression; and so on.
The possibilities are endless.
The s/// macro is a Frankenstein Monster, stitched together from the
bodies of a pattern literal and an interpolating string literal and
infused with the spirit of a search-and-replace algorithm. Like the
m// macro, s/// can only work on literals, never on variables (unless,
as above, you embed them in literals). In addition, if you choose a
non-bracketing delimiter for the pattern literal, you _must_ use the
same delimiter for the string literal. (This is more of a handicap
than at first it seems: in general, different kinds of literals use
different delimiters. With s///, you're forced to use the same
delimiter for two different kinds of literals: a pattern and a
string.) Using bracketed delimiters for the pattern gets around this
problem, but you're still left with the fact that the delimiters for
the string no longer follow the common-sense rule of either
double-quotes or 'qq' followed by something else - no matter what
delimiters you apply here, the semantics remain the same - unlike
anywhere else that string literals are used. And short of embedding
them in the literal (notice a trend here?), you cannot apply any
modifiers to the string - only to the pattern or to the
search-and-replace algorithm. In this regard, the string literal is
the odd man out - s/// could be thought of as a pattern literal with
an auxiliary string literal attached to it, but not the other way
around.
There's nothing natural about this beastie; and if it wasn't so darn
useful, I'd advocate dropping it.
The .subst method bypasses _all_ of these problems, letting you use
distinct and independently modifiable literals for each of the pattern
and the string, or even letting you use a variable or expression to
supply the pattern (or string) in lieu of literals. On the downside,
the .subst syntax isn't nearly as streamlined as the s/// syntax. In
addition, there's the issue about delayed evaluation (or lack thereof)
of the string argument, currently being discussed.
In general in Perl if the default delimiter for something is
inconvenient you can pick a different delimiter -- this includes
patterns, and also strings. And if you pick any sort of brackets for
your delimiters then they match -- which is handy, cos it means that
they can still be used even if the string inside contains some of those
brackets.
As noted above, if you choose non-standard delimiters, you have to
explicitly tag them; and with the exception of s/// and tr///, a given
set of delimiters delimits one thing at a time. s/// and tr/// are
exceptions to the general rule.
So it's quite possible for somebody to have picked up all the above, and
have got used to using Cqq[long string] or Cqq{long string} when he
wishes to quote long strings. The form with braces has the advantage
that they are relatively uncommon in text (and HTML, and SQL, and many
other typically encountered long strings).
And he will be used to saying 'qq{long string}', as opposed to '{long
string}', when he expects the
Re: Comments in qw// or qqw//
demerphq skribis 2006-10-08 16:01 (+0200): If its not obvious why this would be nice: qw() is often used as a list constructor for things like options or hash elements, and it would be convenient to have a way to selectively comment out certain elements. In perl 5 you have to CP out the offending part and then stick it in a comment later on. Or hand hack a custom qw//, which for quick fixes, and stuff like that is a bit annoying. I think that this feature fits perfectly in qqw// or «», which is already dubbed shell-like. Every shell that I know lets you comment things. If # is special, you need a way to escape or quote it. qqw already provides this. I also believe that qqw is much more likely to be used for constructing hashes than qw, exactly because of the quoting feature. Shells require comments to be separated from other characters with whitespace. I think this is a good feature to steal. my %foo = « foo bar baz# And quux xyzzy# comments blah 42#15# go red #FF# here :) »; works like my %foo = ( foo = bar baz, # And quux = xyzzy,# comments blah = 42#15,# go red = #FF, # here ); but with much less punctuation and finger strain. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED] Ik vertrouw stemcomputers niet. Zie http://www.wijvertrouwenstemcomputersniet.nl/.
Re: Don't tell me what I can't do!
In a message dated Wed, 4 Oct 2006, Smylers writes:
Trey Harris writes:
I remember not so many years ago when there were a lot of modules
floating around that required you to do no strict of various flavors
in order to use them.
Really? How?
I wrote imprecisely. Not to use them in the sense of Cuse Package,
but use in the sense of make use of them as described in the perldoc's
synopsis--usually by dint of requiring undeclared package variables,
barewords, or symbolic refs. Alias is one example, there were others.
You could always work around, but the docs assumed you had strictures
turned off, so you were left to your own devices to determine what
internal implementation decision was leading to problems operating under
your level of stricture. (For example, a package that had string
constants defined as subroutines like Csub ERRCODE() { ERRCODE } would
behave differently than one that assumed barewords would work, but both
might use identical examples of Cmoose ERRCODE in their perldocs.)
I still run across modules that need no warnings. (I won't name
names, because some of their authors post to this list ;)
Again, I can't see how. If you use Cuse warnings in your program then
it is lexically scoped and only affects your code, not that of other
files you load in.
Again, I meant in code use, not in just loading--uninitialized value
warnings being the main culprit there.
C-w does affect all files, but that's one of the reasons why Cuse
warnings is an improvement over C-w, because it lets the author of
each bit of code have control over it.
Yes indeed.
Trey
[svn:perl6-synopsis] r12873 - doc/trunk/design/syn
Author: larry Date: Sun Oct 8 16:51:56 2006 New Revision: 12873 Modified: doc/trunk/design/syn/S02.pod Log: Allow Perl-consistent :foo and # policies within «...» Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podSun Oct 8 16:51:56 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 1 Oct 2006 + Last Modified: 8 Oct 2006 Number: 2 - Version: 74 + Version: 75 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -1462,6 +1462,15 @@ CPair notation is also recognized inside C«...» and such words are returned as CPair objects. +Colon pairs (but not arrow pairs) are recognized within double angles. +In addition, the double angles allow for comments beginning with C#. +These comments work exactly like ordinary comments in Perl code. +That is, C# at beginning of line is always a line-end comment, +otherwise a following bracket sequence implies an inline comment; +also, unlike in the shells, any literal C# must be quoted, even +ones without whitespace in front of them, but note that this comes +more or less for free with a colon pair like C :char#x263a . + =item * There is now a generalized adverbial form of Pair notation. The
Re: Re: class interface of roles
Jonathan~ On 10/7/06, Jonathan Lang [EMAIL PROTECTED] wrote: TSa wrote: Dispatch depends on a partial ordering of roles. Could someone please give me an example to illustrate what is meant by partial ordering here? Sets demonstrate partial ordering. Let denote the subset relation ship. If A B and B C, then A C for any A, B, and C. However, it is not necessarily the case that A B, or B A, or B == A for any particular A and B. Thus transitivity is preserved, but there is not a guarantee of comparability between elements. http://en.wikipedia.org/wiki/Partial_ordering Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
[svn:perl6-synopsis] r12874 - doc/trunk/design/syn
Author: larry Date: Sun Oct 8 22:34:45 2006 New Revision: 12874 Modified: doc/trunk/design/syn/S04.pod Log: Ordinary undef is not an undefined generator, only unthrown exceptions are. Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podSun Oct 8 22:34:45 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 19 Aug 2004 - Last Modified: 5 Oct 2006 + Last Modified: 8 Oct 2006 Number: 4 - Version: 42 + Version: 43 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -928,20 +928,19 @@ to false in a boolean context.) A list can have a defined length even if it contains undefined scalar values. A list is of undefined length only if it contains an undefined generator, which, happily, is -what is returned by the Cundef function when used in list context. +what is returned by the Cfail function when used in list context. So any Perl 6 function can say -return undef; +fail message; and not care about whether the function is being called in scalar or list context. To return an explicit scalar undef, you can always say -return item(undef); +return undef; Then in list context, you're returning a list of length 1, which is defined (much like in Perl 5). But generally you should be using -Cfail in such a case to return an exception object. Exception -objects also behave like undefined generators in list context. +Cfail in such a case to return an exception object. In any case, returning an unthrown exception is considered failure from the standpoint of Clet. Backtracking over a closure in a regex is also considered failure of the closure, which is how hypothetical
