This started by trying out S12:1910:

Day.enums.invert{3}  # (same thing)

Since .invert returns a list of Pairs, indexing it with {3} currently fails.

This could be a typo: what could have been meant was:

Day.enums.invert[3]  # (same thing)

or:

Day.enums.invert.hash{3}  # (same thing)

but it is generally felt that doing a .hash on an .invert list will lose information if two or more keys have the same value. And therefore not a good thing to propagate in a spec.

Please see below for the discussion of earlier today:

[20:53:27] this I think is a typo in the spec (S12:1910)
[20:53:41] rn: my enum Day ; say Day.enums.invert{3}
[20:53:44] <+camelia> rakudo 88f9c9: OUTPUT«postcircumfix:<{ }> not defined for type List␤ in method gist at src/gen/CORE.setting:10022␤ in method gist at src/gen/CORE.setting:893␤ in sub say at src/gen/CORE.setting:10917␤ in block at /tmp/aIctujKlzU:1␤␤»
[20:53:44] <+camelia> ..niecza v24-37-gf9c8fc2: OUTPUT«Unhandled exception: Cannot use hash access on an object of type List␤ at line 0 (ExitRunloop @ 0) ␤ at /home/p6eval/niecza/lib/CORE.setting line 352 (Any.at_key @ 9) ␤ at line 0 (ExitRunloop @ 0) ␤ at /tmp/teIKosjtpS line 1 (mainli…
[20:53:48] also, having 3 ~~ Day feels wrongish to me, since 3 is an Int and Int !~~ Day
[20:53:52] rn: my enum Day ; say Day.enums.invert[3]
[20:53:53] 3 is an Int, and Day is Int, but I don't have to have 3 being a Day.
[20:53:54] <+camelia> rakudo 88f9c9, niecza v24-37-gf9c8fc2: OUTPUT«3 => "Thu"␤»
[20:54:36] especially as (and this is perhaps a convincing point), declaring the enum effectively inserts Day between 3 and Int, which... feels weird, conceptually.
[20:55:32] heh, there's probably some category-theoretical theorem somewhere saying "don't do that, it'll lead to tears" :)
[20:55:52] let's assume there is one and fix the spec. :) :) :)
[20:56:53] not quite a +1, but no objections either ;)
[20:57:06] and I'm still curious to hear what TimToady has to say.
[20:57:25] (which might well be "screw category theory, we want this for reasons A, B and especially C")
[20:58:27] so: "Day.enums.invert{3}" doesn't work, but is in the spec, "Day.enums.invert[3]" works as expected
[20:58:59] r: my %h; say %h.invert.^name
[20:59:00] <+camelia> rakudo 88f9c9: OUTPUT«List␤»
[20:59:11] lizmat: .invert{3} looks weird.
[20:59:21] it's a List...
[20:59:22] that was my feeling as well
[20:59:24] indeed
[20:59:29] rn: my enum Day ; say Day.enums.invert.hash{3}
[20:59:31] <+camelia> rakudo 88f9c9, niecza v24-37-gf9c8fc2: OUTPUT«Thu␤»
[20:59:47] but the fact that it's a list may be the issue?
[20:59:53] .invert is returning a list of Pairs
[21:00:02] no, that's according to spec
[21:00:08] indeed
[21:00:38] lizmat will fix spec with s/{3}/[3]/ ?
[21:00:41] there's been some mumbling that a list of Pairs should be able to act like a hash.
[21:00:45] lizmat: +1
[21:00:59] jnthn does some mumbling about that idea :)
[21:01:02] i.e., that it would be able to understand .{ }
[21:01:11] pmichaud: I hope that remains a mumbling.
[21:01:15] .{ } on an array is reserved for custom indexing schems, no?
[21:01:20] yeah.
[21:01:31] wouldn't .invert be a form of "custom indexing scheme", though?
[21:01:53] pmichaud: it's a list because there can be duplicate keys.
[21:01:55] If it is, it produces a bit more than a nrmal List... :)
[21:02:21] masak: yes, I know, but .{ } on such a List could "handle" duplicate keys somehow
[21:02:36] /o
[21:02:48] I'm merely point out that .{ } on List is a defined behavior.
[21:02:52] *pointing
[21:02:56] yes, I agree.
[21:02:57] (in S09)
[21:03:06] I'm just uncomfortable even going down that road :)
[21:03:13] and thus enum.invert could produce the results listed in the spec.
[21:03:18] s/even going/even imagining going/
[21:03:35] I'd be wary of putting .[3] into the spec.
[21:04:00] Yes, it works in the example just given, but that's something of an artifact of how the enum is constructed and/or .pairs is being produced.
[21:05:08] PacoAir (~[email protected]) left IRC. (Quit: PacoAir)
[21:05:29] maybe I should make an issue out of this?
[21:05:37] PacoAir (~[email protected]) joined the channel.
[21:06:08] kurahaupo (~[email protected]) left IRC. (Ping timeout: 252 seconds)
[21:06:23] rn: my enum Day ( :Mon(1), 'Tue', 'Wed', 'Thu' ); say Day.enums.invert.[3]
[21:06:25] <+camelia> rakudo 88f9c9, niecza v24-37-gf9c8fc2: OUTPUT«4 => "Thu"␤»
[21:06:53] rn: my enum Day ( :Mon(1), 'Tue', 'Wed', 'Thu' ); say Day.enums.invert.[3]; say Thu;
[21:06:56] <+camelia> rakudo 88f9c9, niecza v24-37-gf9c8fc2: OUTPUT«4 => "Thu"␤Thu␤»
[21:07:09] rn: my enum Day ( :Mon(1), 'Tue', 'Wed', 'Thu' ); say Day.enums.invert.[3]; say +Thu;
[21:07:11] <+camelia> rakudo 88f9c9, niecza v24-37-gf9c8fc2: OUTPUT«4 => "Thu"␤4␤»
[21:07:30] note that .[3] doesn't give the enum with value 3 (which would be Wed)
[21:09:28] that's because the enums start at 1
[21:09:42] the list starts at 0
[21:10:18] the list that "invert" returns
[21:11:07] <moritz_> but enums can start at any value, and indeed they don't need to be continuous at all
[21:11:57] so you're saying the error in the spec is the missing .hash ?
[21:12:54] moritz_ hasn't followed the discussion closely enough to tell
[21:13:00] moritz_ is now known as moritz
[21:13:40] lizmat: yeah.
[21:13:56] lizmat: though .hash isn't what we recommend either after an .invert
[21:14:09] lizmat: (because that gives last-entry-wins behavior)
[21:14:22] lizmat: we recommend pushing the result onto another hash.
[21:14:29] but in the case of an enum, you never have that problem
[21:14:35] troo
[21:14:54] ...unless you do
[21:15:08] so is there a reason why .invert on a hash doesn't return a Bag?
[21:15:22] rn: my enum Ex ( :Foo(1), 'Bar', :Baz(1) ); say Ex.enums
[21:15:24] <+camelia> niecza v24-37-gf9c8fc2: OUTPUT«EnumMap.new(...)␤»
[21:15:24] <+camelia> ..rakudo 88f9c9: OUTPUT«("Foo" => 1, "Bar" => 2, "Baz" => 1).hash␤»
[21:15:40] yes, bags count, but you're not (always) interested in the count
[21:15:49] true
[21:16:13] and you really want inverted Pairs, and a Bag doesn't give you that.
[21:16:28] lizmat: as you see, duplicate enum values are OK, at least according to the implementations.
[21:16:40] lizmat: which means .invert can have duplicate keys.
[21:16:44] indeed
[21:17:16] feels more and more like an issue that requires TimToady's attention, no?
[21:19:18] aye
[21:20:44] lizmat++ # teasing out issues that require TimToady's attention

Originally opened as https://rt.perl.org/rt3/Ticket/Display.html?id=58290

Subject:    <prior> not implemented in rules in Rakudo
Date:   Sat, 23 Aug 2008 11:26:49 +0200
To: [email protected]
From:   "Carl M?sak" <[email protected]>
To match whatever the prior successful regex matched, use:

/ <prior> /

r30466:
$ ./perl6 -e 'my $s = "hello"; say $s ~~ /ll/; say $s ~~ /ll/' # works
ll
ll
$ ./perl6 -e 'my $s = "hello"; say $s ~~ /ll/; say $s ~~ / <prior> /'
# not implemented
ll
Unable to find regex 'prior'
Null PMC access in invoke()
[...]

This feature request is perhaps more accurately classified as
pertaining to PGE. Please re-tag as needed.

Subject:    Re: [perl #58290] <prior> not implemented in rules in Rakudo
Date:   Sat, 23 Aug 2008 08:16:43 -0500
To: [email protected]
From:   "Patrick R. Michaud" <[email protected]>
On Sat, Aug 23, 2008 at 02:27:10AM -0700, Carl M?sak wrote:
> To match whatever the prior successful regex matched, use:
> 
> / <prior> /
> 
> r30466:
> $ ./perl6 -e 'my $s = "hello"; say $s ~~ /ll/; say $s ~~ /ll/' # works
> ll
> ll
> $ ./perl6 -e 'my $s = "hello"; say $s ~~ /ll/; say $s ~~ / <prior> /'
> # not implemented
> ll
> Unable to find regex 'prior'
> Null PMC access in invoke()
> [...]
> 
> This feature request is perhaps more accurately classified as
> pertaining to PGE. Please re-tag as needed.

...correct -- C<< <prior> >> is not yet implemented. I'm not
certain if it belongs in PGE or in Rakudo... I'm guessing that
<prior> needs to refer to the "prior successful regex" in a
statement-level context, as opposed to a regex context. For
example, if we interpret S05 literally then in the regex

/ <foo> <prior> /

it's pretty clear that C<< <foo> >> is the prior successful regex 
matched, and I think that's not what is intended by C<< <prior> >>.
(If it is what is intended, then C<< <prior> >> becomes much
simpler. :-)

Pm

RT-Send-CC: [email protected]

I've changed this ticket to indicate that it's waiting on spec
clarification as to the exact meaning of <prior> in regexes.

Pm

Should TOP (or any other grammar regex) be considered to have implied $-anchors when invoked from .parse? (See RT #77022.) Example:

     grammar B { regex TOP { b } };
     say B.parse('bcd');                # failed match?

See also discussion at http://irclog.perlgeek.de/perl6/2013-03-06#i_6556613 .

Pm

General question: Suppose I have two lazy Lists @x and @y, and
want to create a new (still lazy) List consisting of the
elements of @x followed by the elements of @y. What's the canonical
form for doing that?

(The underlying purpose of this question is to better clarify the desired characteristics of flattening.)

Possible short answer: Is this the realm of C<.plan>?

@x.plan(@y)    # lazily add elements of @y to the end of @x

Specific example: Suppose I define lists @x and @y as follows:

my @x := (1,2) xx 3;
my @y := (3,4) xx 5;

For this, assume each is as lazy as possible. As Rakudo currently
models things, @x is a List that lazily) contains three Parcels,
while @y is a List that lazily contains five Parcels.

What's the canonical way of creating a List consisting of
the Parcels in @x followed by the Parcels in @y, preserving laziness
and without any intermediate Lists or Parcels surrounding the elements?

As mentioned above, if C<.plan> is the canonical answer to this
problem, I'm probably fine with that and will continue exploring
List refactors based on that answer.

If it's easier or you want to avoid memorializing speculative
answers into the Github issue ticket, feel free to propose
or discuss possible answers for this in the #perl6 channel.
I'll then transcribe results of those discussions into the ticket
as appropriate.

Thanks,

Pm

I propose to rename .exists to .exists_at_key, and .delete to .delete_at_key, because they are really internal methods, not to be used in non-system oriented code. I propose I will do the work for this. This will be done in the following steps:

1. create .exists_at_key in every class where need, as a dup of .exists
2. modify all core code to use .exists_at_key
3. modify tests using .exists to use :exists, or to use .exists_at_key if :exists is not possible
4. add warning to .exists that it should be replaced with :exists.

*wait one month

1. remove .exists from every class it exists.

Do the same in parallel for .delete.

Part of a recent dialogue.

http://irclog.perlgeek.de/perl6/2013-06-20#i_7226826
18:21 TimToady I don't mind something like .exists and .delete as internal methods, but they're more in the category of at_key and at_pos, not something that should be used much in Userland
18:22 so maybe a rename to exists_at_key and such
18:22 masak TimToady: this will break a lot of code.
18:22 masak a lot of code.
18:22 TimToady but all of those internals are subject to renegotiation as soon as S09 starts getting implemented
18:22 :exists is supposed to be S09-proof
18:23 we can't guarantee that for .exists
18:23 not without an explicit mapping of multidimensional args to single dimensional...
18:24 TimToady we know we have subscripts, and we know that we want to delete and test existence using subscript notation; the rest is still unspecced
18:26 TimToady what does this turn into: my Things @things[3,3,]; @things[1;2;$min..$max]:delete
18:27 TimToady er, my Things @things[3;3;]; @things[1;2;$min..$max]:delete
18:27 TimToady s'posed to use ; consistently...
18:28 TimToady currently .exists only knows about single keys, afaik
18:29 TimToady we'd need a .exists that knows about LoLs, where each sublist can be lazy
18:29 the :exists form is more straightforward as soon as you get out of single dimensions
18:53 lizmat TimToady: I like the .exists_at_key idea, since .exists currently is really an at_key cut short
18:54 TimToady but again, what's a "key" look like when you add slicing and multidimensionality?
18:55 * TimToady isn't sure
18:55 lizmat If necessary, I can do this rename of .exists internally + test-suite
18:56 I agree with your argument about S09, :exists is the way to do this, as it will easily allow you to specify on which slice you want things to be applied
18:57 .exists should only handle a single key (as in perl 5), and to make it an "internal" method, rename it to ".exists_at_key"

http://irclog.perlgeek.de/perl6/2012-07-03#i_5779999

13:09 <hoelzro> can you junction types? ex. has Str|Int $.str-or-int?
13:09 <moritz> std: my Str|Int $foo
13:09 <p6eval> std fd2647b: OUTPUT«===SORRY!===?Multiple prefix constraints not yet supported at /tmp/cqnj_WxWXJ line 1:?------> my Str?|Int 
               $foo?Malformed my at /tmp/cqnj_WxWXJ line 1:?------> my Str?|Int $foo?    expecting any of:?      multi_declar…
13:09 -!- JimmyZ_ [[email protected]] has quit [Read error: Connection reset by peer]
13:09 -!- JimmyZ__ is now known as JimmyZ_
13:09 <moritz> so, "no"
13:09 <hoelzro> =(
13:10 <moritz> with "not yet supported", STD.pm means "not a goal for 6.0"
13:10 <hoelzro> ok
13:10 <pmichaud> S02 says you can, btw.
13:10 <pmichaud> Anywhere you can use a single type you can use a set of types, for convenience
13:10 <pmichaud> specifiable as if it were an "or" junction:
13:10 <pmichaud> my Int|Str $error = $val;              # can assign if $val~~Int or $val~~Str
13:10 <pmichaud> S02:1754
13:10 <pmichaud> that's possibly a fossil.
13:10 <moritz> I'm pretty sure that's fossil
13:10 <masak> fossil.
13:10 <hoelzro> does Rakudo support it, though?
13:11 <masak> we do that with subtypes nowadays.

Pm

We need clarification for current intent of http://perlcabal.org/syn/S12.html#Abstract_vs_Concrete_types in the context of the discussion starting at http://irclog.perlgeek.de/perl6/2011-12-08#i_4808300 .

This ties into the ongoing discussion about the correct handling of Failure.

Need a ruling as to whether this should be part of the spec, or if the tests need re-writing:

S03-metaops/zip.t
S03-operators/range-int.t
S03-sequence/arity0.t
S03-sequence/basic.t
S03-sequence/nonnumeric.t
S04-statements/gather.t

Does numifying or stringifying a type object
produce an immediate 'warn' or a Failure? What's the
expected result from:

my $x;
my $y = +$x;
say 'alive';
say $y;

Is the warning generated at the point of assignment to $y
or at the point where $y is used?

Pm

The zen slice on hashes is currently implemented as:

multi method postcircumfix:<{ }>() { self }

I think it should be implemented as:

multi method postcircumfix:<{ }>() { self.values }

to make it inline with %hash{*}. This would make it consistent with the zen slice of arrays.

And it would make it inline with S03:5161, which states: "The empty C<[]> and C<.[]> postfix operators are interpreted as a zero-dimensional subscript returning the entire array, not as a one-dimensional null slice returning no elements. Likewise for C<{}> and C<.{}> on hashes, as well as the C<< <> >>, C<< .<> >>, C<«»>, and C<.«»> constant and interpolating slice subscripting forms."

So I ran a spectest with %h{} returning the values of the hash, just as %h{*}, and the following spectests failed:

t/spec/S02-literals/hash-interpolation.t (Wstat: 0 Tests: 10 Failed: 2)
Failed tests: 5-6
t/spec/S02-literals/misc-interpolation.t (Wstat: 0 Tests: 46 Failed: 1)
Failed test: 4
t/spec/S02-literals/quoting.rakudo (Wstat: 0 Tests: 162 Failed: 1)
Failed test: 124
t/spec/S02-types/hash.t (Wstat: 256 Tests: 22 Failed: 0)
Non-zero exit status: 1
Parse errors: Bad plan. You planned 81 tests but ran 22.

The last one because it was trying to do a sort on *.value, which of course doesn't work on Ints. So from a spec testing point of view, this would be easily fixed.

However, the general feeling on #perl6 was, that the current implementation was the Right Way To Do It. Hence this issue, as the feeling on #perl6 was that the spec should be adapted, rather than the implementation. Which, by the way, is done the same (wrong) way in Niecza.

So far I have assumed that Inf, -Infand NaN are of type Num. Hoever S02 says in the section on Immutable Types:

Int         Perl integer (allows Inf/NaN, arbitrary precision, etc.)

Which opens up the question: what exactly is the type of Inf etc.? If it's Num, an Int can't hold it. If it's an Int, a Num can't hold it. If it's a separate type, that should be specced explicitly.

Previously, the Set (etc) constructors, given a list would act as each if item in the list had been passed individually to the constructor, and so on recursively. Hashes, Sets, etc would do the same with their keys, Pairs with their key.

Current behavior (NYI anywhere) is any object passed to the Set constructor is stored in the Set as that object. This allows Sets of Sets, Sets of Hashes, Sets of IO, Sets of Any, whatever. To get something like the old behavior, you use the .Set coercion method instead.

But as I understand it, that "something like" is very important. In particular, my impression is that these new coercion methods do not recurse like the old constructors did. Specifically:

 set(set(1, 3), set(2, 4))

previously created a Set equivalent to set(1, 2, 3, 4), because we recursed into the keys of each Set. Now it creates a Set with two Sets in it. I'm thinking

 (set(1, 3), set(2, 4)).Set

should probably also return a Set with two Sets in it. (Please let me know if this assumption is wrong!) What about

(1, 2, 3, [3, 5, 6]).Set

-- is that a Set with four elements, one of which is an Array? Likewise, how about

(a => 10).Set
(3..10).Set
(1, 2, 3, 3 => 10).Set
(1, 2, 3, 3..10).Set
(1, 2, 3, %hash).Set
{ a => 3, b => 2000 }.Set

You can ask all the same questions again with Bag, KeySet, and KeyBag. I presume that

(a => 3, b => 2000).Bag

produces a Bag with 3 a's and 2000 b's. It frankly strikes me as bizarre that there is no longer a spec way to create that with a direct Bag constructor. (Incidentally, this means Bag.perl must return strings of the form (mumble).Bag.)

Originally opened as https://rt.perl.org/rt3/Ticket/Display.html?id=72944

Subject:    [BUG] No-one really knows what happens when a &fail is called from within a regex
Date:   Fri, 19 Feb 2010 15:04:31 +0100
From:   Carl Mäsak <[email protected]>


<pausenclown> rakudo: "123" ~~ / <[ a..z ]> { fail "ugh" } /; say $!
<p6eval> rakudo 3704a2: OUTPUT«Mu()␤»
<pausenclown> mmh
<masak> pausenclown: that's a bug, you figure?
<masak> pausenclown: want to submit it to RT?
<pmichaud> ...why is that a bug?
<pausenclown> i don't know it's a bug or not.
<masak> pausenclown: the pmichaud reply seems to imply it's not :)
<masak> so, where *would* the 'ugh' end up?
<pmichaud> we never reach the 'ugh'
<masak> oh!
<masak> of course. :P
<pausenclown> rakudo: "123" ~~ / [ <[ a..z ]> || { fail "ugh" } ] /; say $!
<p6eval> rakudo 3704a2: OUTPUT«Mu()␤»
<pmichaud> okay, that's more of a bug :)
<masak> pausenclown: shall you or I submit it?
<pmichaud> ooc, what *should* happen there?
<pausenclown> I'm just toying around
<masak> pausenclown++
<masak> pausenclown: still. it's a new discovery.
<pmichaud> does fail set $! ?
<masak> not that I know.
<pausenclown> The Exexgesis says it should.
<pmichaud> heh
<pmichaud> Exegesis tend to be waaaaay out of date.
<masak> indeed.
<pausenclown> That they tell me now
<masak> pmichaud: where, according to you, would the 'ugh' end up?
<pmichaud> masak: I have no idea, actually, thus my question :)
<moritz_> I've asked TimToady where parsing error message (like from
fail or from ~ ) end up
<moritz_> and so far I haven't got an understandable answer
<pausenclown> rakudo: "123" ~~ / [ <[ a..z ]> || { fail "ugh" } ] /; say $/
<p6eval> rakudo 3704a2: ( no output )
<jnthn> fail is like a return.
<jnthn> afaik
<pmichaud> what jnthn++ said.
<pmichaud> fail returns an object that throws an exception when it's used.
<jnthn> Given we're only in a closure, it probably causes us to fall
out of the entire regex.
* masak considers all the ambient confusion a bug and submits that
<pmichaud> actually, I think we might fall out of the surrounding sub.
<jnthn> Well, other question: is an anonymous regex and a named regex different?
<pmichaud> because a regex is more like a block than a sub in this case.
<jnthn> Yeah
<jnthn> Probably fall from surrounding sub here.
<pmichaud> that might be the case... but I'm not certain of that either. :)
<jnthn> Whether if that'd been a regex { ... } though...
<pausenclown> "The call to fail causes the match to fail at that
point, and sets an associated error message that would subsequently
appear in the $! error variable (and which would also be accessible as
part of $0)."
<pausenclown> http://dev.perl.org/perl6/doc/design/exe/E05.html
<jnthn> Oh
<jnthn> It begins with an E
<pmichaud> E05 also says...
<jnthn> ...a lot of other out of date stuff.
<jnthn> ;-)
<pmichaud> [Update: Please note that this was written several years ago, and
<pmichaud> a number of things have changed since then. Rather than changing
<pmichaud> the original document, we'll be inserting "Update" notes like this
<pmichaud> one to tell you where the design has since evolved. (For the better,
<pmichaud> we hope). In any event, for the latest Perl 6 design (or
to figure out
<pmichaud> any cryptic remarks below) you should read the Synopses,
which are kept
<pmichaud> very much more up-to-date than either the Apocalypses or Exegeses.]

Consider this ticket closable when the questions "Where does the 'ugh'
end up?" and "Is the behavior of &fail inside an anonymous regex
different from the behavior of &fail inside a named regex?" have been
answered.

S05:1132 says

And
    ms/<element>+ % ',' /
allows whitespace after each comma but nowhere else.

Is it the whitespace between the % and the ',' that enables the whitespace after each comma, or is it the whitespace following the comma?

If the latter, how does one get the above to match whitespace after the final element (but not after each element)?

Pm

There was socket behavior change between Rakudo 2012.11 and 2012.12.

Previously .read(2048) returned 2048 bytes if available, currently it returns 512 (one chunk).
If chunk is smaller than $limit - for example .read(2) - then previous and current version returns 2 bytes.

So param changed its meaning from "desired amount of bytes" to "no more than bytes". That led to discussion about which one is correct. Spec says

Reads and returns $bytes bytes from the handle

while IRC discussion disagree

<sorear> bbkr: you're supposed to keep calling .read until either it returns zero or you have all the bytes
 <bbkr> sorear, what is the point of length argument then?
 <sorear> bbkr: 256 seems a little buggy but in general, packet size limits will prevent you from getting all the data at once, and Berkeley sockets systems will return partial data rather than wait for future packets
 <sorear> bbkr: allows you to set an upper limit on the amount to read
...
<bbkr> so is it spec bug (the param means upper limit), or rakudo bug ?
 <sorear> bbkr: my hubris is telling me the spec is wrong and sockets should always follow a Berkeley-esque interface

If current spec is correct then it's Rakudo bug.

The -use- command in Perl (6) indicates which file must be loaded, without there being a guarantee that there is actually anything with that name inside it.

This is fine.

However, now that we have the capability (in spec) of having multiple versions of a module (class / package / grammar / etc). residing in memory at the same time, and imports are lexical, so we will be doing "use Foo" far more often than before, we need to look deeper at what "use Module" actually means.

Assume we have a file AAAAA.pm that contains:

module AAAAA { sub a is export { say "a" } }
module BBBBB { sub b is export { say "b" } }

This file is loaded into memory with:

use A:name;

After that the 2 modules exist at the same UNIT level: one under the synonym of "A", and the other with its longname "BBBBB". And all subs (from both modules) marked "is export" are imported. So currently you can not alias another top level module in a -use- statement.

If sometime later in another lexical scope the code say:

import BBBBB;

would Perl 6 need to be able to import from that module, even though in that scope it had not been loaded with "use"?

Alternately, would:

import AAAAA;

work as well, even though the "use" was aliassing the module to "A"? And if that would be possible, shouldn't we allow the full From/Auth/Version selection process on "import" as well?

I guess the whole problem comes from modules specifying their LFAV (longname, from, auth, version) in the module statement, whereas the selection on which version of a module to load, is done at the file (UNIT) level.

One way to solve this, would be to disallow more than one module (class, etc) at the UNIT level. Please note that this would not affect modules embedded in other modules, as these are not visible from the outside anyway, even though they can add to the export list of the outer module. Then we would be sure that the constraint in "use" would be correctly applied to the right module.

We will find other situations, in which the discrepancy between a file and a module in memory, may cause problems. Enforcing having only one module at UNIT level in a file, would make things simpler.

Would be nice if we could discuss and resolve this at YAPC::NA as well!

Originally posted here:

https://rt.perl.org/rt3/Ticket/Display.html?id=62068

e.g. what should:

my $x = /<digit>+/; say $x.perl

display?

.classify and .categorize are specced as returning a Hash (S32/Containers:156|191), but are currently returning a Parcel of pairs. And the tests are checking for this.

So either the implementation is wrong, or the spec is wrong. I would assume the implementation is wrong.

Additionally, it would seem that one should be able to specify the "keytype" and "of" of the Hash that is being created. I've added these named parameters to .classify and .categorize in the implementation already. If that is a good idea, then this should also be specced. If not, then a simple revert of the associated commits will be done by me

A few minutes of skimming and grepping didn't find any specification for (Cool $x as Int), just coercion of return values in S02.

Either it needs some love in S06, or I need a better grep, erm, better ack :-)

<masak> "C<:timezone> is a callable object that takes a C<DateTime> to convert and a C<Bool> that specifies the 
        direction of the conversion: to UTC if true, from UTC if false."
<masak> two things. first: huh?

I actually read this completely wrong the first time. I thought it said that the object should be both a callable and a Bool at the same time. But no; it says that the callable expects two positional parameters.

<masak> second: does this feel like a poor man's enum to someone else?
<masak> the C<Bool> thing.
<moritz> we already have a fitting enum, no?
<moritz> nr: say 'a' cmp 'b'
<p6eval> rakudo 87ad7c, niecza v24-26-g713c785: OUTPUT«Increase␤»
<masak> moritz: no, Increase is not fitting, because this enum is meant to convey "from UTC" or "to UTC", ether of 
        which may be either increasing or decreasing depending on which side of Greenwich you happen to be.

Still, an enumeration should be easy enough to create for this. Its two values could be called fromUTC and toUTC.

S03/Comparison semantics/ is very vague about what infix:<cmp> does if its two arguments are of different types. It says:

The C<cmp> is just like the C<eqv> above except that
instead of returning C<Bool::False> or C<Bool::True> values it always
returns C<Order::Increase>, C<Order::Same>, or C<Order::Decrease>
(which numerify to -1, 0, or +1).

And the "above" refers to

For components of your value
that are mutable, however, rather than comparing object identity using
C<===>, the C<eqv> operator tests whether the canonical representation
of both subvalues would be identical if we took a snapshot of them

right now and compared those (now-immutable) snapshots using C<===>

So it seems that some unspecified canonical representation is used, which means from the user perspective, the output is essentially random. I doubt that's really what we want. Any ideas for how to improve it?

This is probably a spec fossil needing updating...

S05:1277 has a line that reads:

 / [ @cmds[0] | @cmds[1] | @cmds[2] | ... ] /

but STD.pm6 treats array subscripts as [...] expressions

15:20 <pmichaud> std: my @cmds;     / [ @cmds[0] | @cmds[1] | @cmds[2] | ... ] /
15:20 <camelia> std b33d8e0: OUTPUT«Potential difficulties:␤  Apparent subscript will be treated as regex at /tmp/G7whgTIAPx line 1:␤------> my 
                @cmds;     / [ @cmds⏏[0] | @cmds[1] | @cmds[2] | ... ] /␤  [0] appears to be an old-school character class; please use <[0]> if 
                you␤    mean…

I suspect from other discussion that S05 needs to be updated with the correct syntax for matching against elements of an array. See also http://irclog.perlgeek.de/perl6/2013-02-23#i_6490881 and http://irclog.perlgeek.de/perl6/2013-05-06#i_7024563 .

Pm

found the idea here: http://rosettacode.org/wiki/Anonymous_recursion#PicoLisp

Working on borrowing IO::Path for Niecza, I've come up with a few questions.

• Say we've got

  my $p = IO::Path.new(:basename("4th.pl"), :directory("."), :volume(""))

What should $p be? The spec says "Stringification returns the path (volume, directory and base name joined together) as a string", which to me would naively suggest ./4th.pl. But Rakudo and Roast seem to think it should be just 4th.pl. That's reasonable, I'm just curious what the official rules for this should be.

• S32-io/dir.t has a test which does

  my @files = dir();
  @files.grep('t');

Should that's trying to smartmatch an IO::Path and a Str. Should that work?

I will add more things here as they come up...

Enums evaluate to expected strings in Str context and to expected ints in Int/Num context, but the Bool context is surprising. Consider the following from IRC (09/25/2012):

15:01 < sirrobert> r: enum E <A B C>;  for (E::A, E::B, E::C) { say $^a ?? "yep" !! "nope" }
15:01 <+p6eval> rakudo 16f22b: OUTPUT«nope␤yep␤yep␤»
15:01 < sirrobert> I find that *very* unexpected ... am I missing anything?
15:01 < sirrobert> (I think it's because the first one is getting evaluated as 0 because it's the first one)
15:02 < sirrobert> r: enum E <A B>; say so E::A; say so E::B;
15:02 <+p6eval> rakudo 16f22b: OUTPUT«False␤True␤»
15:03 < sirrobert> r: enum E <A B>; say E::A; say E::B;
15:03 <+p6eval> rakudo 16f22b: OUTPUT«A␤B␤»
15:03 < sorear> sirrobert: spec oversight, I'd say
15:03 < sirrobert> I think in bool context it should be True (or 0E0), and in Int context it should be 0;
15:03 < sorear> enums are specced to inherit from Int, and they don't have spec bool behavior
15:03 < sorear> so they inherit Int's bool behavior

This came up because I tested for the truthiness of an object property:

enum E <A B C>;
class A {
  has $.type;
  method something { 
    return $.type ?? "YES" !! "NO";
  }
}

my $a = A.new: type => E::A;

say $a.something;  # NO

A workaround is to test against whether the property is defined, but the behavior as it exists is surprising to me.

Originally entered by Dave Whipp as https://rt.perl.org/rt3/Ticket/Display.html?id=76602

I was looking at colomon's Vector.pm in github, and noticed that
Vector::length is defined as { sqrt( self dot self ) }. This is
obviously incorrect for complex numbers: it should be { sqrt( self dot
conjugate self ) } (for some syntax of "conjugate")

I can't just add the method to the Complex class, because then the
Vector code would fail ("method not found") for all non-complex
numeric types (for which conjugation is an identity operation).

Following the "forgiveness > permission" principle, I just removed the sprintf 'm' modifier (for formating Complex numbers) from S32-Str.pod, because it seems too irregular with respect to other sprintf-formatting codes. For example, there's disagreement about the type of modifier that should be used for formatting Rats (see http://irclog.perlgeek.de/perl6/2012-07-04#i_5784979).

In a larger sense, the format codes in 'sprintf' strike me as wanting a significant redesign for Perl 6, analogous to how Perl 6 has redesigned regex syntax. Simply layering new (somewhat ad-hoc) conversion specifiers onto the existing sprintf codes feels like the wrong approach; we should come up with a more regularized (and therefore teachable) syntax.

I do feel it makes sense to keep 'sprintf' around for now, albeit with its more traditional conversion specifications. If we do end up adding new modifiers, let's at least mark them "conjectural" until we have sufficient use cases and implementations to be comfortable that they should remain.

Pm

Just wanting to make sure we cover the bases on ?-quantifiers...

Consider an expression like:

'1a2b345e' ~~ / [ (\d) (<[a..z]>)? ]+ /

Clearly $0 and $1 will both be lists of Match objects because of the indirect + quantifier, and $0 will have five elements.

Will $1 end up with three elements (the Match objects for 'a', 'b', and 'e'),
five elements (Match for 'a', Match for 'b', Nil, Nil, and Match for 'e'),
or some other result?

Pm

Now that we can have multiple versions of the same module live in memory at the same time, we need to consider what to do in certain edge cases, which I think are not specced yet. And if they will not be specced, we need to decide how we're going to implement this in rakudo.

1 . multiple matching modules installed

What if there is more than one module installed that matches the given constraint(s)? Should it pick the first it finds while walking the @inc directories? Or should it warn that it found more than one match and use the first? Should it use the one that matches the closest (similar to MMD) and only complain if it cannot reach a decision? If so, what does it mean that one installed module matches closer than another? Or something else?

2 . second -use- larger range than first -use-

Suppose we have a "use Foo:version<v1.1.0>" which has loaded version 1.1.0 successfully. Then we get to a "use Foo:version<v1..^v2>", which is a wider range than the initial load of the module. There are a number of possibilities:

a. it becomes a noop, because there is already a Foo loaded that matches the version range specification.

b. it goes out to see whether there is another Foo module installed that more closely matches the version specification (whatever that means). And if it finds one, do the same checks as in 1.

Have I forgotten anything here? Could we get a resolution about this at the YAPC::NA Perl 6 hackathon?

What's the result of something like...?

 my $x = [<a b c d>];  'a b c d' ~~ / $x /;

Is $x treated like a scalar, in which case the entire Array is stringified and matched, or is $x treated like an alternation of elements from the array?

Contrast with:

my @x = <a b c d>;   'a b c d' ~~ / @x /;

In this case, we know that it's an alternation of matches.

Pm

Originally raised on https://rt.perl.org/rt3/Ticket/Display.html?id=83720

is there a method that pulls out .re and .im as a list
.reals
that's so misnamed
what PerlJam said.

• masak considers getting a #perl6 badge "API naming curmudgeon"
  rakudo: say (1+2i).reals.fmt("%7.3f")
  rakudo cad076: OUTPUT« 1.000 2.000␤»
  wtf, .reals exists?!
  <\TimToady> it should obviously be named .reim
• masak submits rakudobug
  masak: yeah, I thought he was joking too
  masak++
  whoever named that function, come talk with me at the end of the day. :)

But neither .reals nor .reim in the specs. Need to pick one or the other (or none) before this can be sorted in rakudo.

What should be the result of the following...?

say 'abcd'.match( /./, :pos(1), :global);

Should it:

1. return only the one match that is anchored at position 1,
2. return all matches, anchoring only the first one, or
3. return the match anchored at position 1, and all subsequent matches anchored to the previous match?

Similar considerations may hold for the :nth and :x modifiers.

Thanks!

Pm

Gist:
$object.clone() does not respect the listyness of attributes. When calling .clone(list_attr=>[$value]) the resulting list_attr is a list containing a list. When calling .clone(:list_attr($value)) the resulting list_attr is a list, as desired.

Gist, for reals: https://gist.github.com/samuraisam/5819387/44d63480908601244ea8bb09e28e0ecd32d117db

Relevant IRC Log

[18:08:03] <ssutch>  so, .clone works if i use the :arg(a,b,c) syntax
[18:08:11] <ssutch>  but not if use arg=>[a,b,c]
[18:08:15] <timotimo>    r: class Bob { has @.foo; }; Bob.new(:foo([1, 2, 3])).clone(:foo([1, 2, 3])).perl.say;
[18:08:16] <+camelia>    rakudo b2072f: OUTPUT«Bob.new(foo => Array.new([1, 2, 3]))␤»
[18:08:23] <timotimo>    oh, look!
[18:08:28] <ssutch>  yep
[18:08:32] <timotimo>    r: class Bob { has @.foo; }; Bob.new(:foo([1, 2, 3])).clone(:foo(1, 2, 3)).perl.say;
[18:08:32] <+camelia>    rakudo b2072f: OUTPUT«Bob.new(foo => Array.new(1, 2, 3))␤»
[18:08:48] <timotimo>    clone doesn't seem to know about the listyness of @.options
[18:09:48] <timotimo>    there's no test in the test suite that would cover it and there's no mention of how it should behave in the specs
[18:10:08] <timotimo>    so ... specbug?

In the specs it says, that the leftmost 'all' or 'none' junction will be autothreaded before the first 'one' or 'any' junction. There is no word on named parameters. Will the "leftmost"ness be determined by the caller?

foo(:var_a(1&2), :var_b("foo"&"bar"));
foo(:var_b("foo"&"bar"), :var_a(1&2));

Will those result in different expansions?

The current spec at S11:363 indicates that version/auth information of a class/module/grammar/role should be specified in the statement, e.g.

class Dog:authcpan:JRANDOM:ver<1.2.1>;

However, its counterpart:

use Dog:authcpan:JRANDOM:ver<1.2.1>;

applies to a file, therefore a UNIT, and to all code residing in that file, regardless of what is in there. In other words: -use- is just a way of smartfinding a file to load the code of.

I've therefore come to the conclusion that we need to make this more generic, and that we should have a way to identify the unit, rather than anything inside it.

I therefore propose to remove all auth/ver related information from class/module/grammar and the like, and create a new statement "unit":

unit Dog:authcpan:JRANDOM:ver<1.2.1>;

Only one -unit- statement would be valid per file. And it would be used by packagers / installers to let the system know what it is.

It should probably only be legal when reading from a file, although I could see uses for "eval" as well.

I think this would make things a lot clearer than the current specification.

The first full example in ch7 of the PIR book (containing a .sub 'main') doesn't work as is, error message class "[" "Foo" "]" found. I guess it misses a $P0 = newclass 'Foo'

With that fixed, it gets a bit further and then dies with get_iter() not implemented in class 'Foo', probably caused by the say args

Raised by the bug at https://rt.perl.org/rt3/Ticket/Display.html?id=78324

17:04 < moritz_> rakudo: say ~(64,32,16 ...^ Rat)
17:05 <+p6eval> rakudo 37eafa: OUTPUT«64 32 16␤»
17:05 < masak> eh?
17:05 < moritz_> it doesn't re-coerce to int
17:05 < moritz_> it calculates 8 as 1/2 * 16
17:05 < moritz_> which is a Rat

21:54 < [Coke]> r: say ~(64,32,16 ...^ Rat)
21:54 <+camelia> rakudo 8a0859: OUTPUT«64 32 16␤»
21:54 < TimToady> 16/2 is a Rat :)
21:56 < TimToady> n: say ~(64,32,16 ...^ Rat)
21:56 <+camelia> niecza v24-51-g009f999: OUTPUT«64 32 16␤»
21:56 < [Coke]> TimToady: that was the concensus, yes. Would you say that's
operating as intended, or should it be smarter?
21:56 < TimToady> well, the question is whether a Rat should auto-coerce itself
to an Int if it can
21:57 < TimToady> I don't know that we have any consensus on that

http://perlcabal.org/syn/S32/Numeric.html#Real

Documentation for round() function says that

Functions that round to a particular precision may easily be created by priming:
constant &roundcents ::= &round.assuming(:scale(1/100));

But scale is no longer a named param

 perl6 -e 'Real.^find_method("round").signature.say'
:(Real : $scale = { ... }, Mu *%_)

S03 says

Unary hyper operators always produce a hash or array of exactly the
same I<declared> shape as the single argument.  If the item is not
declared with a shape, only the top dimension is mapped, equivalent
to a normal C<.map> method.  

And later says

Hyper operators are defined recursively on nested arrays, so:

    -« [[1, 2], 3]               #    [-«[1, 2], -«3]
                                 # == [[-1, -2], -3]

which is in direct contradiction to the earlier statement.
Which one is true?

The Set operators and their Texan variants like (-) are misisng from S03, and currently we don't really know what precedence they should have (junctive?)

According to the spec at S06:3298, confirmed more or less at S04:1639, you can only specify a list (positionals) for creating a hash.

However, hash() is currently implemented as allowing any mix of Positionals and Named parameters to create a hash. rakudo/rakudo#156 makes the API of hash() consistent with Hash.new.

But apparently, this feels wrong: http://irclog.perlgeek.de/perl6/2013-05-20#i_7094884 .

So maybe the Spec should change on this. And should we find another way of creating "typed hashes" ?

Nom currently has a problem which IMHO is in big parts a spec issue. Here it comes.

Since no separate literals for native types are specced, a literal like 123 in is polymorphic in rakudo, and can be used both as Int or int, depending on compile-time context.

Unfortunately that means that an expression like 0x7FFFFFFF * 0x7FFFFFFF will overflow on a machine with 32 bit ints, because the compiler picks the infix:<*>(int, int) candidates, which overflows (as it is allowed to).

I can see several possible solutions:

• spec some separate way to write int vs. Int literals
• assume that literals are always Int, and only allow coercion when assigning to an int-typed variable (but would make things like my int $x = 2; $x * 5 less efficient)
• require constant folding in Int space when operators only operate on literals, and only make the result of the constant folding polymorphic
• allow the overflow, even if it's suprising to the user.

At the YAPC::NA 2013 hackathon, there was discussion of making Cool.eval and eval(...) act more like macros, so they can be detected at compile time and pessimized appropriately.

It was also suggested that they become all-caps ( EVAL and .EVAL), since like MONKEY_TYPING they represent operations that are "special" and perhaps denote extra attention from programmers due to their side effects (some perhaps unwanted, such as security vulnerabilities).

Pm

There are several special variables like %*ENV, $*PID, %*SIG, $*PROGRAM_NAME which from the outside of a UNIX process affect the whole program, but inside of Perl 6 they are scoped dynamically.

So, what happens when such a dynamic variable is redefined? Does the new variable loose its special association with the process?
Consider

my @list := gather loop {
    take my $*PROGRAM_NAME = 'a'..'z'.roll(5)
}
.say for @list;

(in Perl 5, $0 is assignable and changes the program name as reported by ps aux, and I expect the same to be true for Perl 6).

Does the program name change every single time @list is being reified?
If yes, how could that be implemented in an efficient manner that doesn't affect all control flow?
If not, what's the point of having those variables dynamically scoped?

Documentation of assuming use substr with named params in example.

&textfrom := &substr.assuming(str=>$text, len=>Inf);

However current substr signature accepts only positional params

Expected: :(Cool $s, $pos, $chars?)

spec$ ack ucfirst
S02-bits.pod
4027:Use curlies with the appropriate function instead: C<"{ucfirst $word}">.

S29-functions.pod
791:ucfirst, unpack

S05-regex.pod
254:    ucfirst(lc())

S32-setting-library/Str.pod
116:Note, there is no longer any C<ucfirst> function because its semantics are not useful under Unicode.

So three references to the function as if it still exists, and one that says that it doesn't. Fixing this issue means resolving the inconsistency.

It should be added that the vibes in #perl6 were less than pleased about &ucfirst having gone away for the reasons specified:

<moritz> masak: S32 is the newer one
<masak> yes.
<masak> that said, I think &titlecase is a poor substitute for &ucfirst, and I don't understand what's so useless about &ucfirst.
<masak> but the spec specs and I oblige.
<moritz> but I don't buy the "not useful under Unicode semantics" either
<moritz> there are still many, many cases where even an ASCII-Only ucfirst can be useful
<moritz> even if it's just for compatibility with all the other "legacy" systems out there :-)
<jnthn> This feels like a pragmatism fail at first glance. :/
* moritz hopes we can change TimToady's mind
<masak> but I'm still submitting that rakudobug, because that's what the spec says right now.
<moritz> please also submit a specbug
<masak> ok.
<masak> submitting bugs, now that I can do ;)

S11/"Runtime Importation" talks about allowing both module names and file names, but it does not specify how the compiler (or rather the runtime) should figure out whether a given variable should be taken as a module name (to be looked up in @*INC) or as a file name.

Perl 5's approach of always assuming a file name if it's not a bare package name is too limiting IMHO, it leads to needless (and buggy) reimplementations of module locating code.

My best idea so far is to create a second keyword, 'require-file', which always interprets its first argument as a file name.
An idea I like less, but which might work for many cases, is to treat the presence of a dot in the string as an indicator that it's a file/path, not a module name.
Better ideas are welcome too.

Original RT ticket 117829:

[23:55:42] rn: class A { }; my $a= A.new( foo => 1 ); $a # shouldn't this complain about trying to initialize a non-existing attribute?
[23:55:44] <+camelia> rakudo 802574, niecza v24-37-gf9c8fc2: ( no output )

This came up during my work in the masakism class

Followup discussion:
[23:26:34] wrt to 117829: perhaps this should at least be activated during tests?
[23:27:15] so that "new" complaints about excess named parameters?
[23:27:33] census (435335b7@gateway/web/freenode/ip.67.83.53.183) left IRC. (Ping timeout: 245 seconds)
[23:28:11] n: class Foo { has $.bar }; my Foo $a .= new( bar => 1, baz => 2 )
[23:28:12] <+camelia> niecza v24-37-gf9c8fc2: OUTPUT«Potential difficulties:␤ $a is declared but not used at /tmp/bY2D_twm2f line 1:␤------&gt; �[32mclass Foo { has $.bar }; my Foo �[33m⏏�[31m$a .= new( bar => 1, baz => 2 )�[0m␤␤»
[23:28:24] n: class Foo { has $.bar }; my Foo $a .= new( bar => 1, baz => 2 ); $a
[23:28:26] <+camelia> niecza v24-37-gf9c8fc2: ( no output )
[23:28:46] hmmm.. I seem to recall Niecza complaining about excess named parameters
[23:28:54] rn: say :foo
[23:28:56] <+camelia> niecza v24-37-gf9c8fc2: OUTPUT«Unhandled exception: Excess arguments to gistcat, unused named foo␤ at /home/p6eval/niecza/lib/CORE.setting line 0 (gistcat @ 1) ␤ at /home/p6eval/niecza/lib/CORE.setting line 1366 (say @ 7) ␤ at /tmp/luJiMs62qw line 1 (mainline @ 3) ␤ at /home/p6eval/…
[23:28:57] <+camelia> ..rakudo c66c42: OUTPUT«␤»
[23:29:04] I guess not always
[23:29:05] #117829 should probably not be an RT ticket, because it's not a Rakudo bug, as far as I know.
[23:29:14] yeah, it's a specbug.
[23:29:19] well, not even a specbug.
[23:29:30] rakudo is performing as specced.
[23:29:33] It's not automatically a bug. It's a request to reconsider an aspect of the design.
[23:29:38] right.
[23:29:42] indeed
[23:29:43] Anyway, part of keeping RT to a sane size is not having such things in it.
[23:29:58] so where would this live then?
[23:30:02] http://github.com/perl6/specs/issues
[23:30:05] (We used to have some [spec] tickets there, but they got moved to GitHub issues in the spec repo)
[23:30:31] tgt (~[email protected]) joined the channel.
[23:30:31] skids (~[email protected]) left IRC. (Ping timeout: 264 seconds)
[23:30:35] I'm looking at the Mu.new and Mu.BUILD code to see how hard it would be to manage.
[23:31:08] (then by all means close it in RT, I'll create in issue in spec)
[23:31:13] an
[23:32:09] pmichaud: Trouble is knowing when to complain.
[23:32:25] I would think it'd have to be at the end of BUILDALL
[23:32:41] if anything in %attrinit didn't get used, then complain about it.
[23:33:06] (I agree it's potentially a lot of checking and overhead)
[23:33:23] Yeah :(
[23:33:26] indeed. It wouldn't make things faster
[23:33:31] And it's a hot path.
[23:33:38] agree with that
[23:33:48] The code is already, um, interesting 'cus of things I did to try and cope with that.
[23:33:50] therefore I was more thinking about a compile time only
[23:33:57] check
[23:34:13] you don't know what is being .newed at compile time, though.
[23:34:20] We don't tend to do analysis of any methody stuff at compile time.
[23:34:31] Because it's too late bound / overridable.
[23:35:08] We go wild on stuff in lexical scopes after CHECK time, but method calls are more, "can't touch this".
[23:35:11] my Foo $obj = (Bool.pick ?? Foo !! Bar).new( @Args )
[23:36:00] I was more thinking about the case of my Foo $obj .= new( foo => 1, bar => 2 )
[23:36:11] where bar is not an attribute
[23:36:24] so, only in a declaration.
[23:36:30] But what if there's a new that knows what to do with it, or a BUILD that knows how to process those things?
[23:36:44] indeed...
[23:36:53] so, only in a declaration for a class that hasn't overridden .new, .BUILD, .BUILDALL, or .bless :-)
[23:37:03] or .create
[23:37:04] I was thinking of a pragma that would lexically wrap .new ?
[23:37:08] er, .CREATE
[23:37:19] Lex...what? It's a method. :)
[23:37:44] wrap the candidate(s) ?
[23:38:29] you can .wrap methods, no?
[23:38:33] Wrapping is (a) not that cheap already, and (b) frustrates optimizations.
[23:38:56] I see it more as a "use diagnostics" type of thing
[23:39:03] lizmat: You can. You can wrap subs, but you have to put a "use soft" pragma in place. In return, the compiler will refuse to do any inlining.
[23:39:07] to be used when you're willing to pay the price
[23:39:31] whatever checking we're going to do, really ought to be in the build process directly. It could be something that is activated only by a lexical pragma.
[23:39:39] nod
[23:39:41] (at a penalty, of course)
[23:40:11] indeed...
[23:40:22] I mean, there's nothing that is stopping you writing a role, sticking it in a module and applying it to your classes. The role provides an alternative new or BUILD or whatever that gives the semantics you wish.
[23:40:24] anyway, it's worth filing a spec ticket for.
[23:40:50] which is what I will do… and then the RT ticket can be closed or deleted or whatever :-)
[23:40:58] Then if you want a "do it to all classes I declare in this scope", just write a meta-class override that adds the role by default to any class declaration :)
[23:41:15] "just write a meta-class override"
[23:41:16] All the ingredients should be there for such a pragma to be written in Perl 6 already. :)
[23:41:37] :-D
[23:41:50] jnthn: indeed, and it would be something I could put on my list
[23:41:52] ;-)
[23:41:57] tgt (~[email protected]) left IRC. (Quit: Computer has gone to sleep.)
[23:42:28] pmichaud: Well, Grammar::Tracer "just" does that ;)
[23:43:34] lizmat: Well, it also allows prototyping this out of core, meaning if it works out Totally Awesome there's a concrete thing to play with and consider spec'ing.
[23:43:47] indeed :-)

Pulled from https://rt.perl.org/rt3/Ticket/Display.html?id=58922

Subject:        .perl for self-referent structures
Date:   Tue, 16 Sep 2008 17:17:27 +0200
To:     [email protected]
From:   "Carl M�sak" <[email protected]>
Download (untitled) [text/plain 631b]
Calling .perl on a self-referent structure makes Rakudo r31152 hang.

$ ./perl6 -e 'my @a = (1); @a[0] := @a; @a.perl'

<masak> pmichaud: what about @a[0] := @a ?
<pmichaud> masak: I don't know about that one. :-)
[...]
<masak> :)
[...]
<pmichaud> part of me thinks that ends up with a self-referential structure
<masak> I hope so
<masak> that seems to be what's happening in at least one case in
Rakudo right now
<masak> question is, should .perl be able to handle that, and if so, how?
<moritz_> masak: it should
<moritz_> perhaps it should emit something like 'do { my @x = (...);
@x[0] := @x; @x }'
* masak submits rakudobug

#       Fri Nov 07 15:01:43 2008         pmichaud - Correspondence added                 [Reply] [Comment]
RT-Send-CC:     [email protected]
Download (untitled) [text/plain 193b]
I'm going to mark this ticket as stalled until we have a good idea of
how self-referent structures should be handled in the output, either
through the spec itself or the spectests.

Thanks!

Pm

Currently, no behavior is defined for .classify and .categorize on infinite lists. It would seem to me that they should fail, just like .push and .pop to on infinite lists.

Propose to adapt the spec to state that they won't work on infinite lists. For now, I have already adapted the implementation to fail on infinite lists.