The following is an attempt to put a number of Perl6 concepts into
practice, in order to see how useful and intuitive they actually are.
Complex numbers come in two representations: rectilinear coordinates
and polar coordinates:
class complexRectilinear {
has $.x, $.y;
method infix:+ ($a is c
Luke Palmer wrote:
> Just some initial thoughts and syntax issues. I'll come back to it on
> the conceptual side a little later.
I'm looking forward to it.
> Jonathan Lang wrote:
> > method coerce:complexPolar () returns complexPolar {
> > return new comp
Doug McNutt wrote:
> As for complex operations which have multiple results I think a principle
> value approach makes more sense than a list. It's well established for the
> inverse trigonometric functions. Leave RootOf( ) to Maple and Mathematica.
In the hypothetical module that I'm describing, t
Luke Palmer wrote:
> Recently, I believe we decided that {} should, as a special case, be
> an empty hash rather than a do-nothing code, because that's more
> common.
>
> However, what do we do about:
>
>while $x-- && some_condition($x) {}
>
> Here, while is being passed a hash, not a do-nothin
Luke Palmer wrote:
> Whatever solution we end up with for Junctions, Larry wants it to
> support this:
>
> if $x == 1 | 2 | 3 {...}
>
> And I'm almost sure that I agree with him. It's too bad, because
> except for that little "detail", fmap was looking pretty darn nice for
> junctions.
Not re
I think there might be a discrepency between S3 and S4.
S3:
> In order to support parallel iteration over multiple arrays,
> Perl 6 has a zip function that builds tuples of the elements of
> two or more arrays.
>
> for zip(@names; @codes) -> [$name, $zip] {
> print "Name: $name; Zip
Instead of
multi sub *infix:<~>(ArabicStr $s1, ArabicStr $s2) {...}
multi sub *infix:<~>(Str $s1, ArabicStr $s2) {...}
multi sub *infix:<~>(ArabicStr $s1, Str $s2) {...}
could you say
multi sub *infix:<~>(ArabicStr $s1, ArabicStr | Str $s2) | (Str
$s1, ArabicStr $s2) {...}
or so
Luke Palmer wrote:
> Of course, this was introduced for a reason:
>
> sub min($x,$y) {
> $x <= $y ?? $x !! $y
> }
> sub min2($x, $y) {
> if $x <= $y { return $x }
> if $x > $y { return $y }
> }
>
> In the presence of junctions, these two functions are not equ
Rob Kinyon wrote:
> To me, this implies that junctions don't have a complete definition.
> Either they're ordered or they're not. Either I can put them in a <=
> expression and it makes sense or I can't. If it makes sense, then that
> implies that if $x <= $y is true, then $x > $y is false. Otherwi
Me no follow. Please use smaller words?
--
Jonathan "Dataweaver" Lang
Dave Whipp wrote:
>An Int is Enumerable: each value that is an Int has well defined succ
>and pred values. Conversely, a Real does not -- and so arguably should
>not support the ++ and -- operators. Amonst other differences, a
>Range[Real] is an infinite set, whereas a Range[Int] has a finite
>card
Luke Palmer wrote:
> That's good, because that's what it does. A "range object" in list
> context expands into a list, but in scalar context it is there for
> smart-matching purposes:
>
> 3.5 ~~ 3..4 # true
> 4 ~~ 3..^4 # false
>
> etc.
>
> The only remaining problem is that we have n
Larry Wall wrote:
> On Thu, Jan 12, 2006 at 08:29:29PM +, Luke Palmer wrote:
> : The only remaining problem is that we have no syntax for ...3, which
> : doesn't make sense as a list, but does make sense as a range.
>
> Well, it could be a lazy list that you only ever pop, I suppose.
> In any e
Audrey Tang wrote:
> Assuming "num" uses the underlying floating point semantic (which may
> turn 0/0 into NaN without raising exception), what should the default
> "Num" do on these forms?
>
> 0/0
> 0*Inf
> Inf/Inf
> Inf-Inf
> 0**0
> Inf**0
>
Mark Reed wrote:
> Perl6 "".split(/whatever/) is equivalent to split(/whatever/,"") in Perl5.
I'm hoping that the perl 5 syntax will still be valid in perl 6.
--
Jonathan "Dataweaver" Lang
task. In this case,
you don't need to know _anything_ about a Hobbit, yet. By the time
you _do_ need to know something about it (such as how to form a mental
image of one), the script will presumably have given you the
neccessary information. If not, you're likely to say something like
"what's a Hobbit?"
a.k.a. "forward referencing". :)
--
Jonathan Lang
ean, not what I say" only carries so far.
That said, I very rarely set $/, so this aspect of 'say' doesn't
really affect me.
--
Jonathan Lang
Consider "my Dog $spot". From the Perl6-to-English Dictionary:
Dog: a dog.
$spot: the dog that is named Spot.
^Dog: the concept of a dog.
Am I understanding things correctly?
If so, here's what I'd expect: a dog can bark, or Spot can bark; but
the concept of a dog cannot bark:
can Dog "b
Stevan Little wrote:
> Yes, that is correct, because:
>
> Dog.isa(Dog) # true
> $spot.isa(Dog) # true
> ^Dog.isa(Dog) # false
>
> In fact ^Dog isa MetaClass (or Class whatever you want to call it).
>
> At least that is how I see/understand it.
OK. To help me get a better idea about what's goin
Stevan Little wrote:
> Jonathan Lang wrote:
> > OK. To help me get a better idea about what's going on here, what
> > sorts of attributes and methods would ^Dog have?
>
> Well, a metaclass describes the behaviors and attributes of a class,
> and ^Dog is an *instance*
Stevan Little wrote:
> Jonathan Lang wrote:
> > OK; apparently, what I meant when I asked "what methods and attributes
> > does ^Dog have?" is what you're talking about when you speak of which
> > methods ^Dog will respond to. To me, an object has whatever me
Thomas Sandlass wrote:
> > > or maybe
> > >
> > > method Dog.bark () { ... }
> >
> > Yes that works too.
>
> Shouldn't that read Dog::bark? Why the dot?
Because I'm not 100% with the proper syntax of things. The intent was
to add a bark() method to Dog during runtime.
--
Jonathan "Dataweaver"
Piers Cawley wrote:
> And backwhacking braces in generated code is *not* a pretty solution
> to my eyes. I'd *like* to be able to have a quasiquoting environment
> along the lines of lisp's backquote (though I'm not sure about the
> unquoting syntax):
Let me see if I understand this correctly: Ins
Brad Bowman wrote:
> Jonathan Lang wrote:
> > Let me see if I understand this correctly: Instead of interpolation
> > being enabled by default with backwhacks selectively disabling it, you
> > want something where interpolation is disabled by default with
> > "anti-
Brad Bowman wrote:
> I don't like the idea of sharing the adverb between escaping and
> force-interpolating since stacking other adverbs can turn q into qq
> and vice-versa. That's a minor quibble though.
And a reasonable one as well. I was trying to minimize the
proliferation of adverbs, but I
If you're going to have versions of sqrt in S29 that deal with Complex
numbers, you ought to do likewise with a number of other functions:
multi sub abs (: Complex ?$x = $CALLER::_ ) returns Num
should return the magnitude of a complex number. abs($x) :=
$x.magnitude, or whatever the appropriat
to junction: just place the
math function in a junctive function ("any", "all", etc.). This makes
it easy to distinguish between "sqrt($x)" (which returns the principle
value) and "any sqrt($x)" (which returns a disjunction of every
possible result): more flexible and more readable than trying for
implicit junctional return values.
--
Jonathan Lang
Doug McNutt wrote:
> Jonathan Lang wrote:
> >Technically, the result set is one element (the principle value),
> >since a mathematical function - by definition - produces a single
> >result for any given input.
>
> Please be careful of "definitions"
Larry Wall wrote:
> A multi sub presents only an MMD interface, while a multi method presents
> both MMD and SMD interfaces. In this case, there's not much point in the
> SMD inteface since .. used as infix is always going to call the MMD interface.
So:
multi method : MMD and SMD
multi sub: M
Stevan Little wrote:
> Jonathan Lang wrote:
> > Can subs be declared within classes? Can methods be declared without
> > classes?
>
> I would say "yes".
>
> Having subs inside classes makes creating small utility functions
> easier. You could also use
Stevan Little wrote:
> Jonathan Lang wrote:
> > Steven Little wrote:
> > > $object does unattached_method;
> > > ^Object does unattached_method;
> >
> > (Wouldn't that be "^$object does unattached_method;"?)
>
> No, I am attaching the m
Damian Conway wrote:
> One might argue that it would be more useful to return a result object whose
> boolean value is the success or failure, whose numeric and string values are
> the number of files *un*changed, and whose list value is the list of those
> *un*changed files.
>
> Then you could wri
Mark Overmeer wrote:
> * Larry Wall ([EMAIL PROTECTED]) [060327 01:07]:
> > On Sun, Mar 26, 2006 at 02:40:03PM -0800, Larry Wall wrote:
> > : On the original question, I see it more as a junctional issue.
> > : Assuming we have only chmod($,$), this sould autothread:
> > :
> > : unless chmod MO
-effects are involved? Or provide adverbs for the junctive
functions that can be used to change their short-circuiting behavior.
Or both.
--
Jonathan Lang
Given perl6's use of unicode as a basis, could we get "curly quotes",
both single and double, to do the same things that straight quotes do?
That is: "text" does the same thing as "text", and 'text' does the
same thing as 'text'. Other than "looks neat", why do this? Because
curly-quotes come in
Will perl6 Sets include set negation and/or a universal set? In
effect, an internal flag that says, "this set contains every possible
element _except_ the ones listed"?
--
Jonathan "Dataweaver" Lang
Larry Wall wrote:
> On Tue, Apr 04, 2006 at 11:02:55AM -0700, Jonathan Lang wrote:
> : Will perl6 Sets include set negation and/or a universal set? In
> : effect, an internal flag that says, "this set contains every possible
> : element _except_ the ones listed"?
>
>
Larry Wall wrote:
> You're confusing the map with the territory. We're trying to decide
> *how* Junctions are like Sets, not defining them into two different
> universes. I'm saying that all() is the Junction tha is most like
> a Set. A none() Junction can be viewed as the specification for an
>
next dot.
$x#.[].foo();
$x.#.[]foo();
$x#. ..foo();
$x.#. .foo();
would all become
$x.foo();
The third form would be legal, if a bit illegible.
--
Jonathan Lang
om "long dot is a special
case"? Though having the "long dot" as a special case of the
"delimited comment" concept, rather than being a "raw special case",
is more acceptable to my mind.
--
Jonathan Lang
Larry Wall wrote:
> I really prefer the form where .#() looks like a no-op method call,
> and can provide the visual dot for a postfix extender.
Although inline and multiline comments are very likely to be used in
situations where method calls simply aren't appropriate:
.#(+---+
| Hello! |
latter emphasizes the "you can strip
it out without harming the surrounding code" aspect. IMHO, the latter
is the more important point to emphasize - especially since the former
brings so much baggage with it.
And I suspect that the confusion between # and #."" would be minor,
_especially_ with syntax highlighters and the like in common use.
--
Jonathan Lang
How do you define new adverbs, and how does a subroutine go about
accessing them?
--
Jonathan Lang
Larry Wall wrote:
> Jonathan Lang wrote:
> : How do you define new adverbs, and how does a subroutine go about
> : accessing them?
>
> Adverbs are just optional named parameters. Most of the magic is in
> the call syntax.
Ah. So every part of a Capture Object has an alt
Larry Wall wrote:
> You might have to write that
>
>@list ==> $foo.act :bar('baz');
>
> I think or the colon on the method would be taken as starting a list.
> I dunno, depends on whether .act: is considered a "longest token",
> I guess. I could argue it the other way as well, and :bar is a lo
Damian Conway wrote:
Juerd wrote:
> Audrey cleverly suggested that changing the second character would also
> work, and that has many more glyphs available. So she came up with
>
>> and propose ".:" as a solution
> $xyzzy.:foo();
> $fooz. :foo();
> $foo. :foo();
This would make the
ill work, but so would
$foo._:foo()
$fa.__:foo()
$and_a_long_one_I_still_want_to_align._
__:foo()
$etc._:foo()
...and the latter five would be the recommended way of doing it.
--
Jonathan Lang
[1] This is a nod to TIMTOWTDI; technically, one could be as
r
foo()
$etc\..foo()
--
Jonathan Lang
, and returns a lazy list of the results.
There would be a default knowledge base, meaning that you wouldn't
have to explicitly state which knowledge base you're using every time
you declare a fact or make a query.
--
Jonathan Lang
How does an atomic block differ from one in which all variables are
implicitly hypotheticalized? I'm thinking that a "retry" exit
statement may be redundant; instead, why not just go with the existing
mechanisms for successful vs. failed block termination, with the minor
modification that when an
Larry Wall wrote:
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you potentially
have the ability to virtualize time to see if there's a way to order
the locks in virtual time such that they still make sense. Then you
jus
Is there anything that you can do with a sub (first parameter being
some sort of object) that you cannot do with a method? Frex, given:
multi method my_method($invocant:);
would
&topical_call := &my_method.assuming :invocant<$_>;
be legal?
--
Jonathan "Dataweaver" Lang
David Green wrote:
I think I understand it... (my only quibble with the syntax is that
=== and eqv look like spin-offs of == and eq, but I don't know what
to suggest instead (we're running short of combinations of = and : !))
Agreed.
So there are three basic kinds of comparison: whether the v
Yuval Kogman wrote:
Jonathan Lang wrote:
> Apparently, there are _four_ basic kinds of comparison: the ones
> mentioned above, and == (I believe that eq works enough like == that
> whatever can be said about one in relation to ===, =:=, or eqv can be
> said about the other).
Dave Whipp wrote:
Darren Duncan wrote:
> Assuming that all elements of $a and $b are themselves immutable to all
> levels of recursion, === then does a full deep copy like eqv. If at any
> level we get a mutable object, then at that point it turns into =:= (a
> trivial case) and stops.
( 1,
I accidently sent this directly to Richard. Sorry about that, folks...
-- Forwarded message --
From: Jonathan Lang <[EMAIL PROTECTED]>
Date: Aug 29, 2006 1:24 PM
Subject: Re: Classes / roles as sets / subsets
To: Richard Hainsworth <[EMAIL PROTECTED]>
Richard Hain
Mark Stosberg wrote:
Sometimes I use 'given' blocks to set a value. To save repeating myself
on the right hand side of the given block, I found I kept want to do this:
my $foo = given { }
...and have whatever value that was returned from when {} or default {}
populate $foo.
Isn't it still th
Joe Gottman wrote:
Since a FIRST block gets called at loop initialization time, it seems to me
that it would be useful to have a block closure trait, RESUME, that gets
called at the beginning of every loop iteration except the first. Thus, at
the beginning of each loop iteration either FIRST or R
Luke Palmer wrote:
On 8/31/06, Juerd <[EMAIL PROTECTED]> wrote:
> Still, though, How would you specify :g? It doesn't make a lot of sense
> on rx// -- just like you can't use it with qr// in Perl 5.
It is a good point that it doesn't belong on the regex. Perhaps:
$foo.subst(/bar/, "baz", :
Smylers wrote:
Damian Conway writes:
> I don't object in principle to renaming "grep" to something more self
> explanatory (except for the further loss of backwards compatability
> and historical Unix reference...though that didn't stop us with
> "switch" vs "given" ;-)
But while C had precedenc
Jonathan Scott Duff wrote:
On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote:
> Jonathan Lang schrieb:
> > IMHO, syntax should be left alone until a compelling reason to change
> > it is found. While I think it would be nice to have a more intuitive
> > name fo
Larry Wall wrote:
Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as "grep". My second choice is "select", which to me is
: more descriptive than "filter"; it also readily suggests an antonym of
: "reject" to do a "grep -v" (cf. "if !" vs "unl
[EMAIL PROTECTED] wrote:
I envision a select, reject, and partition, where
@a.partition($foo)
Returns the logical equivalent of
[EMAIL PROTECTED]($foo), @a.select($foo)]
But only executes $foo once per item. In fact. I'd expect partition
to be the base op and select and reject to be defined
Larry Wall wrote:
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
Fact: We're currently going
How would I construct a capture literal that has both an invocant and
at least one positional argument? How do I distinguish this from a
capture literal that has no invocant and at least two positional
arguments?
Gut instinct: if the first parameter in a list is delimited from the
rest using a c
Two questions:
1. How would the capture sigil affect the use of capture objects as
replacements for perl5's references?
2. With the introduction of the capture sigil, would it be worthwhile
to allow someone to specify a signature as a capture object's 'type'?
That is:
my :(Dog: Str $name, Nu
Larry Wall wrote:
Jonathan Lang wrote:
: Two questions:
:
: 1. How would the capture sigil affect the use of capture objects as
: replacements for perl5's references?
I don't see how it would have any effect at all, unless the P5 ref happened
to be to a typeglob, or had both arra
Larry Wall wrote:
: This would mean that the rules for capturing are as follows:
:
: * Capturing something in scalar context: If it is a pair, it is
: captured as a named argument; otherwise, it is captured as the
: invocant.
:
: * Capturing something in list context: Pairs are captured as named
Larry Wall wrote:
You don't need to use | to store a capture any more than you need @ to
store an array. Just as
$x = @b;
@$x;
gives you the original array,
Huh. I'm not used to this happening. So what would the following
code do, and why?
my @b = ('foo', 'bar');
my $x = @b;
Aaron Sherman wrote:
IMHO most of the confusion here goes away if capture variables ONLY
store parameter-list-like captures, and any other kind of capture
should, IMHO, permute itself into such a structure if you try to store
it into one. That way, their use is carefully constrained to the places
Minor nitpick:
Any types used will constrain multis to explicitly matching those types
or compatible types, so:
our Int proto max(Seq @seq, *%adverbs) {...}
Would not allow for a max multi that returned a string (probably not a
good idea).
IIRC, perl 6 doesn't pay attention to the le
Aaron Sherman wrote:
TSa wrote:
> Miroslav Silovic wrote:
>> package Foo does FooMultiPrototypes {
>> ...
>> }
>
> I like this idea because it makes roles the central bearer of type
> information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example,
Aaron Sherman wrote:
Jonathan Lang wrote:
> Actually, it's a promise made by a package (not a class) to meet the
> specification given by a role (which can, and in this case probably
> does, reside in a separate file - quite likely one heavily laced with
> POD).
That's a
Trey Harris wrote:
One thing that occurs to me: following this "contract" or "promise"
analogy, what does C<...> mean in a role or class?
Unless I've missed somewhere in the Synopses that explicates C<...>
differently in this context, yada-yada-yada is just code that "complains
bitterly (by call
Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
uses 'module' to refer to 'a perl 5-or-earlier module', and uses
'package' to refer to the perl 6-or-later equivalent.
Aaron Sherman wrote:
Details:
Larry has said that programming by contract is one of the many paradigms
that
Mark J. Reed wrote:
Jonathan Lang wrote:
> Terminology issue: IIRC (and please correct me if I'm wrong), Perl 6
> uses 'module' to refer to 'a perl 5-or-earlier module', and uses
> 'package' to refer to the perl 6-or-later equivalent.
Other way arou
Larry Wall wrote:
but only if self.HOW does Hash.
And here I thought you were a responsible, law-abiding citizen... :P
--
Jonathan "Dataweaver" Lang
My understanding is that "does" will prevent coercion. In particular,
it is erroneous to say that 'Str does Num' or that 'Num does Str'.
If you say 'Foo does Bar', what this means is that anything Bar can
do, Foo can do, too. As such, any routine that asks for a Bar can
just as easily be given
Jonathan Scott Duff wrote:
I hope you're way off the mark. Automatic coercion was one of the
annoyances I remember from C++. Debugging becomes more difficult when
you have to not only chase down things that are a Foo, but anything
you've compiled that might know how to turn itself into a Foo.
O
Brad Bowman wrote:
Hi,
Did you mean to go off list?
No, I didn't.
Jonathan Lang wrote:
> Brad Bowman wrote:
>> Does the "class GenSquare does GenEqual does GenPointMixin" line imply
>> an ordering of class composition?
>
> No. This was a conscious des
Stevan Little wrote:
Brad Bowman wrote:
> How does a Role require that the target class implement a method (or
> do another Role)?
IIRC, it simply needs to provide a method stub, like so:
method bar { ... }
This will tell the class composer that this method must be created
before everything is
Twice now in the last week or so, I've run across suggestions to the
effect of including syntax that forbids otherwise valid code from
being used. First was during the discussion about coming up with a
way to program by contract, where the poster suggested that a means of
saying "any declaration
jerry gay wrote:
Jonathan Lang wrote:
> I'm not used to programming styles where a programmer intentionally
> and explicitly forbids the use of otherwise perfectly legal code. Is
> there really a market for this sort of thing?
use strict;
Hmm... granted. But that does tend t
Dave Whipp wrote:
Smylers wrote:
>>use strict;
>
> That's different: it's _you_ that's forbidding things that are otherwise
> legal in your code; you can choose whether to do it or not.
Which suggests that the people wanting to specify the restrictions are
actually asking for a way to specify ad
Dave Whipp wrote:
Or we could view it purely in terms of the design of the core "strict"
and "warnings" modules: is it better to implement them as centralised
rulesets, or as a distributed mechanism by which "core" modules can
register module-specific strictures/warnings/diagnostics.
Question:
Trey Harris wrote:
It sounds like the assumption thus far has been that the existance of
roles imply that abstract classes are disallowed, so you'd write:
role Dog { method bark { ... } #[ ... ] }
class Pug does Dog { method bark { .vocalize($.barkNoise) } }
S12 says: "Classes are primari
chromatic wrote:
jesse wrote:
> Ok. So, I think what you're saying is that it's not a matter of "don't let
> people write libraries that add strictures to code that uses those modules"
> but a matter of "perl should always give you enough rope to turn off any
> stricture imposed on you by externa
What if I import two modules, both of which export a 'foo' method?
IMHO, it would be nice if this sort of situation was resolved in a
manner similar to how role composition occurs: call such a conflict a
fatal error, and provide an easy technique for eliminating such
conflicts. One such techniqu
TSa wrote:
I'm not familiar with the next METHOD syntax.
It's simple: if a multi method says "next METHOD;" then execution of
the current method gets aborted, and the next MMD candidate is tried;
it uses the same parameters that the current method used, and it
returns its value to the current m
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?
--
Jonathan "Dataweaver" Lang
S5 says:
There is no /e evaluation modifier on substitutions; instead use:
s/pattern/{ doit() }/
Instead of /ee say:
s/pattern/{ eval doit() }/
In my perl5 code, I would occasionally take advantage of the "pairs of
brackets" quoting mechanism to do something along the lines of:
It's been indicated that several regex modifiers that are found in
Perl5 are gone. That's all well and good, unless you're using the
Perl5 modifier to port code to perl6. What happens if you're trying
to port in a regex that made use of one of the now-obsolete modifiers?
Bear in mind that there
Larry Wall wrote:
On Sat, Oct 07, 2006 at 03:28:04PM -0700, Jonathan Lang wrote:
: It's been indicated that several regex modifiers that are found in
: Perl5 are gone. That's all well and good, unless you're using the
: Perl5 modifier to port code to perl6. What happens if you
Larry Wall wrote:
Jonathan Lang wrote:
: Translating this to perl 6, I'm hoping that perl6 is smart enough to let me
: say:
:
:s(pattern) { doit() }
Well, the () are illegal without intervening whitespace because that
makes s() a function call, but we'll leave that alone.
Th
Larry Wall wrote:
As a unary lazy prefix, you could even just say
s[pattern] doit();
Of course, then people will wonder why
.subst(/pattern/, doit())
doesn't work.
Another possibility: make it work. Add a "delayed" parameter trait
that causes evaluation of that trait to be postpone
Jonathan Lang wrote:
Another possibility: make it work. Add a "delayed" parameter trait...
...although "lazy" might be a better name for it. :)
--
Jonathan "Dataweaver" Lang
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 routi
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 --
The only thing that I'd like to see changed would be to allow a more
flexible syntax for formatting codes - in particular, I'd rather use
something analogous to the 'embedded comments' described in S02,
replacing the leading # with an appropriate capital letter (as defined
by Unicode) and insistin
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 p
1 - 100 of 354 matches
Mail list logo
