🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
nine A trillion features in this language but a "protected" like access level is not one of them. Baffles me why we lack this super common OO feature 08:53
JimmyZhuo m: class A { has $.a is protected; } 08:56
camelia ===SORRY!=== Error while compiling <tmp>
Can't use unknown trait 'is' -> 'protected' in an attribute declaration.
at <tmp>:1
expecting any of:
rw
readonly
box_target
leading_docs
trailing_doc…
JimmyZhuo maybe nobody asked for it? 08:59
nine That's still as baffling. We have super obscure things like a flip-flop operator which in 33 years of programming I have needed a grand total of 0 times. But a basic OO feature that almost everyone has and that I could use all the time? Nope 09:03
JimmyZhuo thinks we can have such a trait 09:07
timo .o( raku can have little a java, as a treait ) 09:36
lizmat well, we have private methods and "trusts" docs.raku.org/language/typesystem#trait_trusts ? 10:11
I guess an "is protected" trait on an attribute would autogen a private method? 10:12
and then maybe an "is trusting" attribute on classes to allow all subclasses access to private methods ? 10:13
note that we also have "is implementation-detail" on methods 10:14
It isn't as strict as "is protected" appears to be, but still, plenty of ways to indicate possible capabilities? 10:15
nine ^^ 10:17
although I guess I would call the attribute trait "is private" to keep more in the Raku vocabulary 10:18
instead of "is protected"
JimmyZhuo wants 'switch' syntax 10:41
lizmat isn't that what "when" is ? 10:46
JimmyZhuo ah, I forgot given when 11:02
Geth roast: dff9bd2cbb | (Elizabeth Mattijsen)++ | S06-currying/positional.t
Remove test that would check implementation detail

The old implementation of .assuming would re-create the constant value in the signature of the generated Callable. In the new implementation, it will pass thru the nameless array that contained the value. However, to be able to pass it through, it needs a name to refer to, which is implementation dependent.
Rather than replace one implementation dependent test with another it feels like a better idea to remove this test.		 12:53
lizmat m: sub a(Positional[Int] $a) { }; dd &a.signature.params.head.type # all is good 13:06
camelia Int = Positional[Int]
lizmat m: sub a(Int @a) { }; dd &a.signature.params.head.type # should be "Int" because of the @ sigil 13:07
camelia Int = Positional[Int]
nine I thought Int @a literally means Positional[Int]? 13:08
lizmat it does 13:09
but we get one level of Positional too many if we combine it with a @ sigil
Geth rakudo/main: 8faa16a5db | (Stefan Seifert)++ | 3 files
RakuAST: generate tailor made attribute accessors

We can still improve the generated code by cutting out standard signature checks, but this at least fixes some problems with native types.
Fixes: my class C { has uint8 $.ff is rw }; say C.new.ff = 255		 13:10
rakudo/main: 3d651c2ef0 | (Stefan Seifert)++ | src/Raku/ast/variable-access.rakumod
RakuAST: throw compile time error when attribute alias is used outside method

Fixes: class Foo { has $a; say $a }
nine 1253
lizmat so I think that 'Parameter.type" needs to return Int in that case, or the .assuming logic needs to work around this
nine++
nine I think the burden is on assuming's part here. That type is correct. Positional[Int] *is* the type of that first param. Would be weird to ask a parameter for its type and get an answer that one then has to somehow combine with the parameter's name to get the actual answer to the initial question 13:12
lizmat ok, than I'll attack it from that end... although not really convinced yet :-) 13:13
fwiw, Parameter.raku has this beaut in it: 13:14
$type ~~ / .*? \[ <( .* )> \] $$/; 13:15
$raku ~= $/ ~ $modifier if $/;
nine When a typical user asks a Parameter for its type, they will want to know what kind of argument they may pass to this parameter. And in this case that is a Positional[Int]. It's hardly the typical use case to try to build a signature that looks similar.
lizmat m: sub a(::T $a, Positional[T] $b) { dd } # placeholder type ok 13:29
camelia ( no output )
lizmat m: sub a(Positional[::T] $a, T $b) { dd } # placeholder type not recognized :-(
camelia ===SORRY!=== Error while compiling <tmp>
No such symbol 'T'
at <tmp>:1
------> sub a(Positional[::T<HERE>] $a, T $b) { dd } # placeholder type
Geth rakudo/main: 8026638f7a | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: fix attributes bound in signatures accidentally becoming read-only
 13:33
rakudo/main: 1f958343b7 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: mark rw acessor methods as rw
nine 1257!
So that was why my initial support for binding attributes in signatures did not fix more spec tests
lizmat nice! 13:39
Geth rakudo/main: 79175d2c33 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: fix bogus error about required attribute needing to be marked required
 13:50
nine Holy cow another 3 down!
1260
jdv woohoo 14:04
[Coke] nine++ 14:34
Geth roast: 169ddf4749 | (Elizabeth Mattijsen)++ | S06-currying/positional.t
Further adjustments on .assuming tests

  - remove superstitious .item
  - remove tests currying Nil, these can never work
  - give defaults to hash arguments a sensible value: "%a = 2" doesn't work
  - move special data stuctures to where they are actually needed		 17:38
rakudo/main: 5 commits pushed by (Stefan Seifert)++ 19:24
nine 1261
jdv yes please 19:42
nine So, 84 spec tests before the finish line, I finally come across the deal breaker. 20:36
The one test that destroys the whole house of cards.
m: class A61354_1 { EVAL('method x { "OH HAI" }') }.x 20:37
camelia ( no output )
nine m: class A61354_1 { EVAL('method x { "OH HAI" }') }.x.say
camelia OH HAI
nine This is fundamentally incompatible with the way we stitch things together in RakuAST. To find the package to attach that method to, we ask the resolver for the nearest "package" attach target which would be the RakuAST::Package node representing that package. Alas there is none, because we're at runtime, and the AST is long gone. 20:41
patrickb How relevant is that capability? In principle the mop is very much capable to modify classes at runtime. So maybe we can live with forbidding this specific way of doing it? 21:16
RakuAST is happening on a version boundary anyways. So it's more than fair to clean up where it makes sense. 21:17
Or do I miss the point here?
nine The question is valid. Alas... 22:02
Geth rakudo/main: bb1737fc0e | (Stefan Seifert)++ | 3 files
RakuAST: fake attach target for adding methods to packages via EVAL

At runtime we won't have any AST nodes anymore. Thus if we're in an EVAL and there's a $?PACKAGE from outside, use a RakuAST::Declaration::External::Package as attach target. It pretends to be a RakuAST::Package just enough for attaching methods to work.
Fixes: class C { EVAL q[method a() { "hi" }] }; C.a.say
nine ...where there's a will, there's a way. With enough blunt force that is. 22:03

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!