🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
aruniecrisps i wonder what i'm doing wrong then 🤔 if i can get it to properly parse raku files into an AST then a good chunk of our work is done already @lizmat 00:03
cdn.discordapp.com/attachments/633...34307&
_grenzo what was the command that produced that error? 01:40
nvm I see it right at the top 01:42
and is Moneys in your include paths? 01:43
aruniecrisps it's not, but it shouldn't matter, what i'm trying to do is just get the AST 02:11
[Coke] the use has to run code. 02:13
_grenzo you're trying to turn the string 'use Moneys' into it's AST representation?
[Coke] try 'use Test' instead, that one's built in 02:14
m: dd "use Test".AST 02:15
camelia use Test
[Coke] m: say "use Test".AST
camelia RakuAST::StatementList.new(
RakuAST::Statement::Use.new(
module-name => RakuAST::Name.from-identifier("Test")
)
)
[Coke] (sorry, dd not as helpful with AST) 02:16
aruniecrisps Hmmm, well in that case it looks like it's got error handling built in then
lizmat aruniecrisps because a "use" statement can change the grammar, and thus parsing of code, the module *is* actually loaded at compile time 10:50
and if it cannot, then will fail
m: use v6.e.PREVIEW; say RakuAST::Statement::Use.new(module-name => RakuAST::Name.from-identifier("Bar")) 10:52
camelia RakuAST::Statement::Use.new(
module-name => RakuAST::Name.from-identifier("Bar")
)
lizmat aruniecrisps this does not happen if you programmatically create the AST for a "use Bar"
m: use v6.e.PREVIEW; say RakuAST::Statement::Use.new(module-name => RakuAST::Name.from-identifier("Bar")).EVAL 10:53
camelia Could not find Bar in:
/home/camelia/.raku
/home/camelia/rakudo-m-inst-1/share/perl6/site
/home/camelia/rakudo-m-inst-1/share/perl6/vendor
/home/camelia/rakudo-m-inst-1/share/perl6/core
CompUnit::Repository::AbsolutePath<…
lizmat unless you .EVAL it of course, and the module can not be foud
*found
tbrowder__ lizmat: any thoughts on feasability of autochecking for allowable subroutine named args? 12:08
sub f(:$bar --> Hash | bar) is export {..} 12:11
lizmat tbrowder__: not sure I follow 12:12
tbrowder__ in tha sub i'm defining the allowable named args. if a caller uses anything else it would cause an exception. 12:14
lizmat m: sub a(:$a, :$b) { }; a(:c)
camelia Unexpected named argument 'c' passed
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat it's only on methods that unexpected named arguments are slurped into %_ 12:15
tbrowder__ funny but in my code i swear i see named args a didn't expect being ignored 12:16
lizmat m: my method a() { }; dd &a.signature # note that the sigature of a method always has an implicit *%_
camelia :(Mu: *%_)
lizmat m: my sub a() { }; dd &a.signature # as opposed to subs 12:17
camelia :()
tbrowder__ i'll keep an eye out
lizmat should only happen with methods, not subs
unless the sub as an explicit *%_ in its signature
*has
tbrowder__ so subs was my prob, unexpected named arg being ignore. so, for my simple mind, what is the solution? 12:19
lizmat provide a piece of code that shows the problem, so we can fix it ?
tbrowder__ ok, will do, thanks 12:20
lizmat specifically an --ll-exception stack trace
tbrowder__ ah, my bad, it was a method. that's been around a while. i remember it haunting me a few years back. 12:34
lizmat *phew* :-) 12:35
the only way to disallow unexpected nameds in a method is to do something like: die "unexpected nameds: %_.keys()" if %_; 12:36
tbrowder__ so in a method i think you got me to check that % to see if was empty or something. does that sound right?
lizmat yes :-) but %_ rather than % :-) 12:37
tbrowder__ cool, thank you!!
Voldenet if you need this kind of behavior better is to use a subroutine instead 13:02
m: class :: { x() { } }.x(:thing); 13:03
camelia ===SORRY!=== Error while compiling <tmp>
Unexpected block in infix position (missing statement control word before the expression?)
at <tmp>:1
------> class :: { x()⏏ { } }.x(:thing);
expecting any of:
infix
Voldenet m: class :: { method x() { } }.x(:thing);
camelia ( no output )
Voldenet m: sub x { }; class :: { }.&x(:thing);
camelia Too many positionals passed; expected 0 arguments but got 1
in sub x at <tmp> line 1
in block <unit> at <tmp> line 1
Voldenet m: sub x { }; class :: { }.&x();
camelia Too many positionals passed; expected 0 arguments but got 1
in sub x at <tmp> line 1
in block <unit> at <tmp> line 1
Voldenet m: class X { method x() { } }; sub x(X $x){}; X.&x(); 13:04
camelia ( no output )
Voldenet m: class X { method x() { } }; sub x(X $x){}; X.&x(:y); 13:05
camelia Unexpected named argument 'y' passed
in sub x at <tmp> line 1
in block <unit> at <tmp> line 1
tbrowder__ Voldenet: good point, but my use case is a bit different. It can very likely be designed better, but that's where I am for now. 13:09
Voldenet I wish methods didn't accept arbitrary named arguments 13:11
tbrowder__ i try to get design help here when i can, but too often jump in without that life preserver
Voldenet consider StrictNamedArguments package 13:13
tbrowder__ i also, but i think that has to be because of some Rake internal magic that requires it.
i will do that.
Voldenet it's runtime exception, but better than nothing 13:14
tbrowder__ wow, looks pretty slick. so, if i understand correctly, all i have to do use yr pkg and in my class add trait "is strict" to all my added methods? 13:24
lizmat It's El_Che's package, actually 13:25
but the approach comes at a price, an extra layer of indirection :-(
the proper approach would be to *not* install the slurpy *%_ in the signature of the method 13:26
tried that years ago, and it would fail somewhere deep in the bowels, because the core assumes there's a *%_ in the signature of each method 13:27
maybe I should revisit that approach :-)
or someone else should :-)
tbrowder__ oops, a tip of the hat to nxadm aka El_Che
lizmat: that would surely ease signature documentation! i get lost in that cave 13:31
and i
and in enums. although i got practical enums tamed a little more in my update to the Date::Event pkg 13:33
librasteve Voldenet: I was interested in your point about named args and looked up the rationale for this from the design docs... 13:59
=head1 Interface Consistency By default, all methods and submethods that do not declare an explicit C<*%> parameter will get an implicit C<*%_> parameter declared for them whether they like it or not. In other words, all methods allow unexpected named arguments, so that C<nextsame> semantics work consistently. If you mark a class "C<is hidden>", it hides the current class from "C<nextsame>" semantics, and
incidentally suppresses the autogeneration of C<*%_> parameters. Methods on hidden classes may still be called as C<$obj.NameOfHiddenClass::yourmethod>. A similar effect can be achieved from the derived class by saying C<hides Base> instead of C<is Base>.
github.com/Raku/old-design-docs/bl...bjects.pod L:2264 14:00
anyway it seems that the consistency of nextsame is to blame (I guess to chain args through) ... this kinda makes sense to me as a design trade off (and has ways to turn off the behaviour such as 'is hidden' which I never came across before). so you may not like this particular design choice ... but it wasn't just arbitrary 14:02
Voldenet Huh
m: class :: { }.&x(:thing);
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
x used at line 1
Voldenet m: class :: { method x() { } }.x(:thing); 14:03
camelia ( no output )
Voldenet m: class :: is hidden { method x() { } }.x(:thing);
camelia Unexpected named argument 'thing' passed
in method x at <tmp> line 1
in block <unit> at <tmp> line 1
Voldenet That is useful to know
librasteve yeah I was surprised that 'is hidden' and 'hides' made it to the implementaiton (and the docs too!)
lizmat looks like "is hidden" is not really documented :-( 14:10
librasteve well its documented a bit docs.raku.org/routine/hides (but not searchable) tbh this is kind of a master class feature 15:09
lizmat in any case, the different method signatures appear to be a side-effect 15:12
librasteve of the despatch semantics? 15:13
Voldenet Implicit *%_ is the implementation detail of nextsame, when you throw in "hidden/hides" to the mix it becomes weird 15:32
m: class A is hidden { method x(:$p) { say $p } }; class B is A { method x() { say "foo"; nextsame } }.x(:p);
camelia foo
Voldenet m: class A { method x(:$p) { say $p } }; class B hides A { method x() { say "foo"; nextsame } }.x(:p);
camelia foo
Voldenet m: class A { method x(:$p) { say $p } }; class B is A { method x() { say "foo"; nextsame } }.x(:p);
camelia foo
True
Voldenet oh, and 15:35
m: class A { method x(:$p) { say $p } }; class B is A is hidden { method x() { say "foo"; nextsame } }.x(:p);
camelia Unexpected named argument 'p' passed
in method x at <tmp> line 1
in block <unit> at <tmp> line 1
librasteve weird? yes! ... to be fair it does what is says on the tin (although I would be a bit upset to see class B is A is hidden in production code!) ... I can imagine some use cases ... for example if you are refactoring together some "grandparent" classes from which you would like to inherit, but many of the method names conflict (or are externally provided or you cannot guarantee no conflict down the line) so you 16:15
want to mask them 100% ... but you want to use normal parent-child nextsame semantics in your stuff ... bit of a strech I know
lizmat another disadvantage is that "is hidden" affects *all* methods in the class 17:30
which may be too coarse-grained for you 17:31
SmokeMachine just for curiosity, I've used the ChatGPT to generate a new Pod6 for may Configuration module based on the original one, and I think that did it very good: github.com/FCO/Configuration 18:46
lizmat SmokeMachine: the boilerplate: use Configuration::Node; and does Configuration::Node 18:50
could also be handled by the EXPORT, by mixing in the Connfiguration::Node role into the given class 18:51
the mixin would still be done at compile time 18:52
SmokeMachine but the clas does not necessarily need to does that role
lizmat "To define your application's configuration structure, create a Raku class that does the Configuration::Node role. This class will specify the fields and default values for your configuration." 18:53
SmokeMachine I'm still deciding if it makes sense to change that...
lizmat appears to say otherwise ?
SmokeMachine Thanks, I'll change that
It seems I was wrong... and the root class needs to be a Node... I think I'll follow your suggestion... 18:55
antononcube @SmokeMachine Did you use ChatGPT via Raku? 19:08
SmokeMachine no... :(
(but I was writing a module to play with with the assistent api at some point...) 19:09
antononcube The OpenAI's Assistant functionalities seem to "unfinished" at the moment. Same with their LLM functions. 19:10
Granted, they honestly say those are in Beta-stage.
As for making Raku configurations using LLMs -- that can be done either via Raku LLM-functions or with a Question Answers System (QAS). 19:12
Well, QAS, might be too involved. But definitely LLM examples based generation should applicable, 19:13
SmokeMachine When I was doing that my only intention was to play with that API... 19:23
antononcube I understand. I tried out the assistant framework for work project using their Python package. 19:24
It is does not always work. Or, more precisely, it does not adhere to expectations. (Not just mine, also implied from the documentation.) 19:25
SmokeMachine lizmat: is it better now? github.com/FCO/Configuration 19:50
lizmat much better, except the first example in the README still uses the old boilerplate ? 19:53
SmokeMachine yes, but it explains you can avoid adding the role... 19:54
with the 2nd example
make sense? 19:55
lizmat why would you need to add the role "manually" ever ? 19:58
antononcube @SmokeMachine I think you should spell out a few use cases in the "Configuration" README.
lizmat that feels like an exception to me
SmokeMachine if you are going to have more than one layer you may need to `use` that... for example: github.com/FCO/Configuration/blob/...ig.rakumod 19:59
lizmat I'm not sure I follow 20:01
SmokeMachine antononcube: I think that's a great idea... but I confess I'm failing to think into some examples
lizmat: I think you are right... (again)
lizmat ak& 20:03
SmokeMachine antononcube: do you have any idea? 20:07
antononcube @SmokeMachine I was thinking configurations of LLMs. 20:22
@SmokeMachine See the LLM configurations here: raku.land/zef:antononcube/LLM::Fun...igurations 20:23
@SmokeMachine But I might be misunderstanding what "Configuration" is about. Is it about setting up attributes in data classes / objects? Why not just use hash maps? 20:33
SmokeMachine antononcube: because Configuration creates builders that can type check your configuration while you are writing it and returns to your program an immutable (if you defined your config class that way). And it also can return to your program a Supply that emits new configuration objects every time the configuration changes 20:39
SmokeMachine it makes it impossible to someone have invisible typos on configuration files and also makes it programable, so, you can for example have loops to define many attributes... 20:41
antononcube: for example, here we have an example of a program using cro and Configuration to configure host and port for the cro server. if that's running and the configuration file changes, it automaticaly restart the cro server with the new port: github.com/FCO/Configuration/tree/...amples/cro 20:46
make sense? 20:48
antononcube @SmokeMachine I will study the example tonight. 21:50
SmokeMachine antononcube: please, let me know your thoughts/suggestions 22:41