This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html
Set by lizmat on 8 June 2022.
01:47 frost joined 02:36 frost left 04:34 gfldex left, discord-raku-bot left 06:18 elcaro left 08:47 frost joined 10:58 discord-raku-bot joined 11:42 gfldex joined 12:42 jgaz joined 13:11 otpv joined, otpv left 14:12 frost left
masukomi thanks <@724421839924756480> that's.... kinda nasty. I figured i must be missing something obvious since that's a problem that has been _well known_ for a _very_ long time now in other languages. I don't think any newb could be expected to come up with that =my %foo = do { ... }= workaround. 14:24
thanks <@724421839924756480> that's.... kinda nasty. I figured i must be missing something obvious since that's a problem that has been _well known_ for a _very_ long time now in other languages. I don't think any newb could be expected to come up with that `my %foo = do { ... }` workaround.
elcaro Yeah, in one sense it's a little ugly, in another sense it's pretty cool that imports are lexical, and it's consistent with how the language works, but yeah, I with `is export` did what my module does by default. 14:31
People wanting the current behaviour could still do `is export(:DEFAULT)`. Funnily enough, this is the behaviour Damian Conway opted for when he wrote `Perl6::Export` for Perl
Yeah, in one sense it's a little ugly, in another sense it's pretty cool that imports are lexical, and it's consistent with how the language works, but yeah, I wish `is export` did what my module does by default.
People wanting the current behaviour could still do `is export(:DEFAULT)`. Funnily enough, this is the behaviour Damian Conway opted for when he wrote `Perl6::Export` for Perl
14:36 jgaz left
masukomi the `my &foo = do { ... }` hack makes me wonder if it'd be possible to write a module that was used to import other modules, figure out what methods & classes they provided, and then... exported _those_ instead of the originals. like `use-prefixed Some::Module, "my-prefix"` 14:39
the `my &foo = do { ... }` hack makes me wonder if it'd be possible to write a module that was used to import other modules, figure out what methods & classes they provided, make prefixed versions and then... exported _those_ instead of the originals. like `use-prefixed Some::Module, "my-prefix"` 14:44
Nemokosch I mean... you do know that exports _can_ have a symbol assigned to them, for importing them one-by-one?
just to make sure
masukomi sure, but that doesn't solve the problem if i need the `color` method from 2 packages. 14:45
elcaro Possibly you could query the Stash, but it might depend on how the module is structioned
Nemokosch I'm pretty sure it does
masukomi how so?
my newbish understanding was that the symbol was just for easily specifying groups of things to import, not that it changed how you called them. 14:46
Nemokosch well, it's a pair, with a key and a value, so I'd assume if you specify the value, that's where the imported thing will end up
tbh I don't use this a lot
elcaro Well, again, it's easy if the subs are `our` scoped.
Given this module
```
unit module Foo;
our sub foo is export { 'foo' }
our sub bar is export { 'bar' }
our sub baz is export { 'baz' }
```
You could do this in the importing code
```
use Foo;
say Foo::.keys
```
Which would output `(EXPORT &bar &foo &baz)`
Nemokosch but it came up a few weeks ago 14:47
elcaro There might be a better way, but I've used Stash lookup inside modules to dynamically generate exports before
I wrote a blog post years ago (my aforementioned "complaining at length" about implicit exports) that has some useful info around Exports. 14:49
0racle.info/articles/exportation_exploration
Like I said, it's years old, so might be some errors
I rarely have time to update my blog these days, but I think I at least updated most "Perl 6" references to "Raku" 14:50
masukomi so, ignoring the fact that many modules don't use `our` ... if `module Foo` and `module Bar` both had an `our sub thingy is export {...}` then you did `use Foo` and `use Bar` .... what happens if i call `thingy` in the code that imported it. Would it blow up? 14:51
so, ignoring the fact that many modules don't use `our` ... if `module Foo` and `module Bar` both had an `our sub thingy is export {...}` then you did `use Foo` and `use Bar` .... what happens if i call `thingy` in the code that imported it? Would it blow up?
elcaro If they both export `thingy`, yes, it will blow up at compile time, pretty sure
Kaiepi `use Bar` should error over a symbol collision
elcaro yeah, just confirmed, compile time error 14:52
Rog Thereā€™s some way to rename symbols to get around that isnā€™t there? 14:53
Or am I misremembering
Rename on import, that is
Obviously if you changed the module it would fix it
elcaro I posted a snippet earlier, the `my &foo := do { use &Foo; &thingy }` trick
I posted a snippet earlier, the `my &foo := do { use Foo; &thingy }` trick
Rog Ah, very nice 14:54
masukomi the key problem i'm concerned with is 2 modules that i don't control that are "normal" but coincidentally overlap and haven't done anything special that'd mitigate this.
i like the workaround, but ... i mean, it's a gross hack no-one should have to do.
Rog Agree
I am wondering if there are some adverbs to control that behavior
Maybe it shouldnā€™t blow up unless you actually try to call something with a naming conflict 14:55
Nemokosch I still wonder 14:58
elcaro The whole exports/compunits thing is mostly black-magic to me. Maybe it's possibly to change this behaviour with an Env var, but it's probably not easy, and there's probably more important things the small set of core developers are working on, so I've learned to accept it.
Nemokosch :bar is a pair
what is the point of it being a pair, if you cannot specify where you want your import to end up?
masukomi > Maybe it shouldnā€™t blow up unless you actually try to call something with a naming conflict 15:00
that feels like something that you'd want to be able to make a call about if it failed at runtime or compile time. i can see good arguments for both.
elcaro I think I know where your headed... keep scrolling
Nemokosch like you know
named function arguments
elcaro Like... this?
I was just playing around... but it proves this functionality is possible 15:02
Nemokosch yeah, I got to this 15:04
Rog Great demonstration
Would be nice to see that functionality integrated into the core language
Or something similar
Youā€™d want the ā€œsimpleā€ option still 15:05
Nemokosch so this relies on your particular EXPORT sub provided?
masukomi yeah, that was the problem i kept hitting... it relies on the library you're importing having taken special meausers. 15:06
yeah, that was the problem i kept hitting... it relies on the library you're importing having taken special measures.
elcaro yeah, the &EXPORT receives that list, and I just iterate through it
Nemokosch okay, then the situation is a bit worse than I initially thought xD
elcaro haha
masukomi i feel like we could almost get around this is we could somehow `use Foo :nothing` have it compile, but have it not let you invoke anything without the `Foo::` prefix
Nemokosch not only the default is dubious but there is no elegant built-in way to make it right
masukomi the `use Foo qx(bar);` is so close as it does it for all methods _except_ the one specified 15:08
Nemokosch now that you mentioned Python
does Python break away from this value resolution vs namespace resolution schizophrenia completely?
elcaro Dubious, yes. Deal breaker, not so much. I reiterate that Raku has a small _volunteer_ dev team. 15:11
I wrote that blog post years ago in mild hope that the community would rally around the idea of fixing import/export while the language was relatively young. That didn't happen, and I didn't push for change. The language had other more important deficiencies at the time.
Importantly, there are viable workarounds.. with the only issue being that the are "ugly". Maybe RakuAST will allow syntax transformations to help make the work arounds less "ugly".
Nemokosch Look, there are pros and cons and we could go on for days. The reason I'm still here is that I value the pros over the cons. 15:12
elcaro exactly
masukomi ok poking in the repl. given this: 15:13
```
unit module Foo;
sub bar() is export { say 'bar' }
sub baz() is export { say 'baz' }
```
what's happening when i do `use Foo < >;` Was hoping i'd be able to call `Foo::bar()` but i can't and i can't call `bar()` either.
Nemokosch However, I still have to say that sometimes, I found that the _willingness to do the right thing_ is the biggest wall in front of the right thing 15:14
elcaro you want to do `our sub ...` to be able to call `Foo::bar()`
Nemokosch some things would have been either dead simple or at least reasonably simple to fix, if the approximately 3 people who know the implementation didn't insist that the behavior is understandable xD 15:15
masukomi well that feels... silly. Kinda assumed you'd be able to call `Foo::bar()` by default (even without my weird invocation).
hey, that kinda works! 15:16
```
[0] > use lib '.'; use Foo < >;
Nil
[1] > Foo::bar();
bar
[1] > bar()
===SORRY!=== Error while compiling:
Undeclared routine:
bar used at line 1. Did you mean 'VAR', 'bag'?
```
Nemokosch when this came up a couple of weeks ago, I phrased this as "`our` doesn't mean private to package but public to package"
elcaro yeah I can see... there might be some way to dig into the guys of `Foo` and get access to unexported lexicals, but I'm not aware of one right now. 15:17
Nemokosch and that brought me inner peace xd
elcaro yeah I can see... there might be some way to dig into the guts of `Foo` and get access to unexported lexicals, but I'm not aware of one right now.
masukomi i like the `use Foo < >` hack, but it's dependent upon people using `our` which doesn't seem to be common. 15:18
i like the `use Foo < >`; hack, but it's dependent upon people using `our` which doesn't seem to be common.
i like the `use Foo < >;` hack, but it's dependent upon people using `our` which doesn't seem to be common.
Nemokosch I have the feeling that it's not even known enough that `our` does this
elcaro well, the good news on that front is it can be added without breaking much... so start submitting PR's šŸ˜€
Nemokosch what does use Foo do in that example? 15:19
masukomi > when this came up a couple of weeks ago, I phrased this as "our doesn't mean private to package but public to package"
that.... is non-obvous, and helpful. thanks.
elcaro it's actually not a bad idea
masukomi yeah, just... that's gonna be a LOT of PRs šŸ˜‰
under the covers? i have no idea. In practice... makes it so that you're forced to use the fully qualified name it seems. 15:20
Nemokosch does it not work without? 15:21
masukomi correct. if i `use Foo < >;` i can only invoke `bar` via `Foo::bar` BUT it only works if i've done `our sub bar() is export {...}` 15:22
correct. if i `use Foo < >;` i can only invoke `bar` via `Foo::bar` BUT it only works if i've done `our sub bar() is export {...}`. Without the `our` it doesn't work so... not a general solution.
Nemokosch okay, next experiment 15:23
what if you don't use `is export`, only `our`?
masukomi no difference.. i added `our sub fum() { say 'fum' }` and it worked just like `our sub bar() is export { say 'bar' }` 15:25
Nemokosch "superglobal"
for managing imports, there is also raku.land/zef:lizmat/from 15:27
15:34 Nemokosch joined
masukomi i think it might be possible to hack that to support prefixing. 15:37
i think it might be possible to hack that to support prefixing.... like combine it with <@724421839924756480> 's `my &foo...` hack.
Nemokosch > # use Foo, but don't import anything
is this essentially what you'd like to see?
masukomi well, yes, but the problem is i can't actually call `Foo::bar` after that. Not sure what exactly it's doing.
``` 15:39
[0] > use lib '.'; use from "Foo";
Nil
[1] > Foo::bar();
Could not find symbol '&bar' in 'GLOBAL::Foo'
in block <unit> at <unknown file> line 1
```
<--- currently attempting to satisfy PR feedback at work so only half able to focus on understanding liz's module with my newb raku understanding.
elcaro I figured this was possible, and of course lizmat's already done it. 15:51
Sleepy, time for bed. G'night
Nemokosch land down under? 15:52
good night
masukomi thanks for the education <@724421839924756480>
elcaro You're welcome. 15:53
15:55 Nemokosch left 16:33 Kaiepi left 16:34 Kaiepi joined 17:14 razetime joined 17:20 razetime left
tbrowder why don't you folks put those thoughts into a detailed Rakudo issue? 19:58
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/08/29/2022-35-reworkout/ 20:05
22:45 archenoth left 23:03 deadmarshal left 23:05 Guest10 joined
Guest10 help 23:05
i am looking for a healer 23:06
23:10 Guest10 left 23:28 archenoth joined 23:49 deadmarshal joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!