Created
July 1, 2023 21:25
-
-
Save gfldex/b4178078a64f6752a5ba4a419dca4eac to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <html><body><div class='index'> | |
| <div class='entry'><a href="issues.html#374"><span class='number'>374</span></a> [open] <span class='title'>Errors should not be adhoc in core</span></div> | |
| <div class='entry'><a href="issues.html#370"><span class='number'>370</span></a> [open] <span class='title'>A way around "multi-level classification"</span></div> | |
| <div class='entry'><a href="issues.html#366"><span class='number'>366</span></a> [open] <span class='title'>`next`, `last`, `redo` shouldn't fall through subroutines</span></div> | |
| <div class='entry'><a href="issues.html#362"><span class='number'>362</span></a> [open] <span class='title'>Expand DEPRECATED functionality.</span></div> | |
| <div class='entry'><a href="issues.html#369"><span class='number'>369</span></a> [open] <span class='title'>Provide `sort` with `:k` adverb (returns ordinal index)</span></div> | |
| <div class='entry'><a href="issues.html#368"><span class='number'>368</span></a> [open] <span class='title'>LinkedIn does not recognize "Raku Developer" as a job title.</span></div> | |
| <div class='entry'><a href="issues.html#361"><span class='number'>361</span></a> [open] <span class='title'>`LEAVE` phaser fires when errorring in argument binding</span></div> | |
| <div class='entry'><a href="issues.html#367"><span class='number'>367</span></a> [open] <span class='title'>Add :k option to min and max</span></div> | |
| <div class='entry'><a href="issues.html#373"><span class='number'>373</span></a> [open] <span class='title'>Rakudoc in third-party modules and some related topics</span></div> | |
| <div class='entry'><a href="issues.html#358"><span class='number'>358</span></a> [open] <span class='title'>Request to deprecate untwigiled attributes </span></div> | |
| <div class='entry'><a href="issues.html#365"><span class='number'>365</span></a> [open] <span class='title'>Spectesting is a minefield</span></div> | |
| <div class='entry'><a href="issues.html#357"><span class='number'>357</span></a> [open] <span class='title'>Handling of non-breaking spaces when splitting to words</span></div> | |
| <div class='entry'><a href="issues.html#364"><span class='number'>364</span></a> [open] <span class='title'>Supply blocks may reorder flow of execution</span></div> | |
| <div class='entry'><a href="issues.html#372"><span class='number'>372</span></a> [open] <span class='title'>Are Captures value types or not?</span></div> | |
| <div class='entry'><a href="issues.html#363"><span class='number'>363</span></a> [closed] <span class='title'>Feature request: snip counterpart for Str</span></div> | |
| <div class='entry'><a href="issues.html#371"><span class='number'>371</span></a> [closed] <span class='title'>Trailing declarator docs semantics need to be revisited</span></div> | |
| <div class='entry'><a href="issues.html#355"><span class='number'>355</span></a> [open] <span class='title'>Choose some precise (or rough) way to "adopt" modules in the Raku Module Adoption center</span></div> | |
| <div class='entry'><a href="issues.html#351"><span class='number'>351</span></a> [open] <span class='title'>Deprecation of flatmap is foggy and debatable</span></div> | |
| <div class='entry'><a href="issues.html#347"><span class='number'>347</span></a> [open] <span class='title'>The Path to Raku, revisited</span></div> | |
| <div class='entry'><a href="issues.html#343"><span class='number'>343</span></a> [open] <span class='title'>When and by whom should changes in Rakudo be documented?</span></div> | |
| <div class='entry'><a href="issues.html#346"><span class='number'>346</span></a> [open] <span class='title'>Semantics of hyper metaoperators - direction, "dwimminess", dimensions, etc.</span></div> | |
| <div class='entry'><a href="issues.html#345"><span class='number'>345</span></a> [closed] <span class='title'>The semantics of >>.foo feel wrong and possibly need changing</span></div> | |
| <div class='entry'><a href="issues.html#354"><span class='number'>354</span></a> [open] <span class='title'>`min` is presumptuous (on empty iterables)</span></div> | |
| <div class='entry'><a href="issues.html#350"><span class='number'>350</span></a> [closed] <span class='title'>Smartmatching to S/// is not a bug but a feature</span></div> | |
| <div class='entry'><a href="issues.html#342"><span class='number'>342</span></a> [closed] <span class='title'>"Failure is Nil" and the anomalies this leads to</span></div> | |
| <div class='entry'><a href="issues.html#344"><span class='number'>344</span></a> [open] <span class='title'>Interoperability of numeric type objects</span></div> | |
| <div class='entry'><a href="issues.html#353"><span class='number'>353</span></a> [open] <span class='title'>Artistic License not a default on Github</span></div> | |
| <div class='entry'><a href="issues.html#349"><span class='number'>349</span></a> [open] <span class='title'>Raku / Perl 6 books - CCR measures and beyond</span></div> | |
| <div class='entry'><a href="issues.html#348"><span class='number'>348</span></a> [open] <span class='title'>What to do with https://twitter.com/raku_news ?</span></div> | |
| <div class='entry'><a href="issues.html#352"><span class='number'>352</span></a> [open] <span class='title'>Wanted: new Raku Infrastructure jack-of-all-trades</span></div> | |
| <div class='entry'><a href="issues.html#339"><span class='number'>339</span></a> [open] <span class='title'>Should the `handles` trait delegate by name or by code reference?</span></div> | |
| <div class='entry'><a href="issues.html#338"><span class='number'>338</span></a> [closed] <span class='title'>Include line numbers in Pod::Blocks</span></div> | |
| <div class='entry'><a href="issues.html#337"><span class='number'>337</span></a> [open] <span class='title'>Function return types should also tell about the used assignment/container</span></div> | |
| <div class='entry'><a href="issues.html#335"><span class='number'>335</span></a> [open] <span class='title'>Does -I Directory Order Affect Whether Modules are Recompiled?</span></div> | |
| <div class='entry'><a href="issues.html#330"><span class='number'>330</span></a> [open] <span class='title'>modules.raku.org should be deprecated</span></div> | |
| <div class='entry'><a href="issues.html#334"><span class='number'>334</span></a> [closed] <span class='title'>Class construction: should we reconsider our approach for performance?</span></div> | |
| <div class='entry'><a href="issues.html#336"><span class='number'>336</span></a> [open] <span class='title'>Alternate name for MONKEY pragmas</span></div> | |
| <div class='entry'><a href="issues.html#341"><span class='number'>341</span></a> [closed] <span class='title'>Rakudoc Delimited Block Comments</span></div> | |
| <div class='entry'><a href="issues.html#328"><span class='number'>328</span></a> [closed] <span class='title'>Adding head, skip, tail as subroutines</span></div> | |
| <div class='entry'><a href="issues.html#333"><span class='number'>333</span></a> [open] <span class='title'>Specify an implementation neutral method for extracting pod</span></div> | |
| <div class='entry'><a href="issues.html#340"><span class='number'>340</span></a> [open] <span class='title'>Dependency hell in Raku</span></div> | |
| <div class='entry'><a href="issues.html#327"><span class='number'>327</span></a> [open] <span class='title'>Inherit(aliz)ability and compos(aliz)ability are too ad-hoc</span></div> | |
| <div class='entry'><a href="issues.html#326"><span class='number'>326</span></a> [open] <span class='title'>`div` and `mod` don't convert to Int, unlike everything else</span></div> | |
| <div class='entry'><a href="issues.html#332"><span class='number'>332</span></a> [open] <span class='title'>POD6 consistency problems</span></div> | |
| <div class='entry'><a href="issues.html#324"><span class='number'>324</span></a> [closed] <span class='title'>Taking responsibility for Raku Documentation issues</span></div> | |
| <div class='entry'><a href="issues.html#317"><span class='number'>317</span></a> [open] <span class='title'>Uniform approach to distributing important messages about Raku</span></div> | |
| <div class='entry'><a href="issues.html#313"><span class='number'>313</span></a> [open] <span class='title'>"Tight or" precedence level of //, min, max operators</span></div> | |
| <div class='entry'><a href="issues.html#308"><span class='number'>308</span></a> [open] <span class='title'>More flexible Phasers</span></div> | |
| <div class='entry'><a href="issues.html#323"><span class='number'>323</span></a> [closed] <span class='title'>Our symbol resolution implementation is totally counter-thread-safe</span></div> | |
| <div class='entry'><a href="issues.html#316"><span class='number'>316</span></a> [closed] <span class='title'>Preparing the Raku Ecosystem for the Future</span></div> | |
| <div class='entry'><a href="issues.html#312"><span class='number'>312</span></a> [closed] <span class='title'>Wrong behavior is specced for classify method</span></div> | |
| <div class='entry'><a href="issues.html#311"><span class='number'>311</span></a> [closed] <span class='title'>Make Junction a value object.</span></div> | |
| <div class='entry'><a href="issues.html#321"><span class='number'>321</span></a> [closed] <span class='title'>Allow "bare" indexing terms in documentation</span></div> | |
| <div class='entry'><a href="issues.html#315"><span class='number'>315</span></a> [open] <span class='title'>Make grammars called from grammars more intuitive</span></div> | |
| <div class='entry'><a href="issues.html#307"><span class='number'>307</span></a> [open] <span class='title'>Destructuring assignment lhs has different semantics from the corresponding literal</span></div> | |
| <div class='entry'><a href="issues.html#309"><span class='number'>309</span></a> [open] <span class='title'>A Mechanism for Adding Hooks into CURI for Custom Installation Output</span></div> | |
| <div class='entry'><a href="issues.html#314"><span class='number'>314</span></a> [open] <span class='title'>Operator precedence/associativity API needed</span></div> | |
| <div class='entry'><a href="issues.html#319"><span class='number'>319</span></a> [open] <span class='title'>Junctions with comparisons - or why is != meta</span></div> | |
| <div class='entry'><a href="issues.html#306"><span class='number'>306</span></a> [open] <span class='title'>No easy way to inspect distributions</span></div> | |
| <div class='entry'><a href="issues.html#305"><span class='number'>305</span></a> [open] <span class='title'>Semi-predicate situation with `is required` and defaults on native attributes</span></div> | |
| <div class='entry'><a href="issues.html#304"><span class='number'>304</span></a> [open] <span class='title'>INIT blocks in module does not behave nicely</span></div> | |
| <div class='entry'><a href="issues.html#299"><span class='number'>299</span></a> [open] <span class='title'>Edge cases of nominalizable typeobjects interactions</span></div> | |
| <div class='entry'><a href="issues.html#295"><span class='number'>295</span></a> [closed] <span class='title'>Moving distributions between distribution backends "duplicates" them</span></div> | |
| <div class='entry'><a href="issues.html#303"><span class='number'>303</span></a> [open] <span class='title'>Signature parameter introspection for type smileys/signature modifiers</span></div> | |
| <div class='entry'><a href="issues.html#298"><span class='number'>298</span></a> [closed] <span class='title'>Consider renaming default branch from master to main</span></div> | |
| <div class='entry'><a href="issues.html#302"><span class='number'>302</span></a> [open] <span class='title'>API reconciliation between Blob/Buf, CArray, and native array</span></div> | |
| <div class='entry'><a href="issues.html#291"><span class='number'>291</span></a> [closed] <span class='title'>Scalar.WHICH semantics is incorrect</span></div> | |
| <div class='entry'><a href="issues.html#301"><span class='number'>301</span></a> [open] <span class='title'>Issues with the design of `assuming` method</span></div> | |
| <div class='entry'><a href="issues.html#290"><span class='number'>290</span></a> [open] <span class='title'>"assuming" is a big word</span></div> | |
| <div class='entry'><a href="issues.html#294"><span class='number'>294</span></a> [open] <span class='title'>Particular scopes of PseudoStash'es are not clear</span></div> | |
| <div class='entry'><a href="issues.html#297"><span class='number'>297</span></a> [closed] <span class='title'>"In general, the left side of `~~` should not be auto-threading"</span></div> | |
| <div class='entry'><a href="issues.html#286"><span class='number'>286</span></a> [open] <span class='title'>Separate Community Resource pages</span></div> | |
| <div class='entry'><a href="issues.html#285"><span class='number'>285</span></a> [open] <span class='title'>Datish should have a `.fmt` command and its formatter should be deprecated</span></div> | |
| <div class='entry'><a href="issues.html#284"><span class='number'>284</span></a> [open] <span class='title'>Terminal circumfix token should have (optionally) higher precedence</span></div> | |
| <div class='entry'><a href="issues.html#293"><span class='number'>293</span></a> [open] <span class='title'>Subtyping by augmentation is too ad-hoc</span></div> | |
| <div class='entry'><a href="issues.html#283"><span class='number'>283</span></a> [open] <span class='title'>There should be a (relatively easy) way to specify how to test for non-Raku dependencies</span></div> | |
| <div class='entry'><a href="issues.html#292"><span class='number'>292</span></a> [closed] <span class='title'>Priority of `let` and `temp` operators give them WAT behavior</span></div> | |
| <div class='entry'><a href="issues.html#288"><span class='number'>288</span></a> [open] <span class='title'>Perl5 support specced in roast is questionable</span></div> | |
| <div class='entry'><a href="issues.html#287"><span class='number'>287</span></a> [open] <span class='title'>HyperWhatever in subscripts</span></div> | |
| <div class='entry'><a href="issues.html#296"><span class='number'>296</span></a> [open] <span class='title'>&-sigiled terms an possibly other emergent "features"</span></div> | |
| <div class='entry'><a href="issues.html#282"><span class='number'>282</span></a> [open] <span class='title'>Proposal: q:thru/DELIM/ heredocs</span></div> | |
| <div class='entry'><a href="issues.html#277"><span class='number'>277</span></a> [open] <span class='title'>We (probably) need Rakudo specs</span></div> | |
| <div class='entry'><a href="issues.html#270"><span class='number'>270</span></a> [closed] <span class='title'>new Coercion protocol creates an opportunity for more ergonomic coercions </span></div> | |
| <div class='entry'><a href="issues.html#262"><span class='number'>262</span></a> [closed] <span class='title'>The Raku Conference</span></div> | |
| <div class='entry'><a href="issues.html#269"><span class='number'>269</span></a> [closed] <span class='title'>conf.raku.org DNS record</span></div> | |
| <div class='entry'><a href="issues.html#276"><span class='number'>276</span></a> [open] <span class='title'>:ignoremark is overzealous</span></div> | |
| <div class='entry'><a href="issues.html#280"><span class='number'>280</span></a> [closed] <span class='title'>Preserving / Accessing Raku IRC Log History</span></div> | |
| <div class='entry'><a href="issues.html#268"><span class='number'>268</span></a> [closed] <span class='title'>Clarify "On Behalf of Community"</span></div> | |
| <div class='entry'><a href="issues.html#275"><span class='number'>275</span></a> [closed] <span class='title'>Expressing the idea that a function successfully returned nothing is difficult </span></div> | |
| <div class='entry'><a href="issues.html#279"><span class='number'>279</span></a> [open] <span class='title'>No literal syntax for sparse arrays</span></div> | |
| <div class='entry'><a href="issues.html#263"><span class='number'>263</span></a> [closed] <span class='title'>The Raku Foundation</span></div> | |
| <div class='entry'><a href="issues.html#272"><span class='number'>272</span></a> [closed] <span class='title'>The PS-process' acceptance policy doesn't match reality</span></div> | |
| <div class='entry'><a href="issues.html#260"><span class='number'>260</span></a> [closed] <span class='title'>Provide a way to explicitly set arg0 when calling a program</span></div> | |
| <div class='entry'><a href="issues.html#278"><span class='number'>278</span></a> [open] <span class='title'>Coercer methods for parametrised roles</span></div> | |
| <div class='entry'><a href="issues.html#259"><span class='number'>259</span></a> [closed] <span class='title'>Method `reverse` on ranges should produce ranges</span></div> | |
| <div class='entry'><a href="issues.html#257"><span class='number'>257</span></a> [closed] <span class='title'>Subdomain for the Raku Course</span></div> | |
| <div class='entry'><a href="issues.html#252"><span class='number'>252</span></a> [open] <span class='title'>Documentation and the ecosystem</span></div> | |
| <div class='entry'><a href="issues.html#251"><span class='number'>251</span></a> [open] <span class='title'>Add a forum to support the Raku community and provide a searchable repository of Q&A</span></div> | |
| <div class='entry'><a href="issues.html#258"><span class='number'>258</span></a> [closed] <span class='title'>Independent CI server for Raku modules and infrastructure</span></div> | |
| <div class='entry'><a href="issues.html#250"><span class='number'>250</span></a> [closed] <span class='title'>Documentation search categories are not standardized</span></div> | |
| <div class='entry'><a href="issues.html#255"><span class='number'>255</span></a> [open] <span class='title'>`constant` for many identifiers in single declaration</span></div> | |
| <div class='entry'><a href="issues.html#249"><span class='number'>249</span></a> [open] <span class='title'>Make react return values</span></div> | |
| <div class='entry'><a href="issues.html#254"><span class='number'>254</span></a> [open] <span class='title'>Name (and release date) proposal for 6.e</span></div> | |
| <div class='entry'><a href="issues.html#253"><span class='number'>253</span></a> [open] <span class='title'>Rakudo releases (and probably zef too) need a long-term support strategy</span></div> | |
| <div class='entry'><a href="issues.html#248"><span class='number'>248</span></a> [open] <span class='title'>raku --doc should get a pager</span></div> | |
| <div class='entry'><a href="issues.html#244"><span class='number'>244</span></a> [closed] <span class='title'>How should modules/distributions be handled when severe security issues are discovered?</span></div> | |
| <div class='entry'><a href="issues.html#239"><span class='number'>239</span></a> [open] <span class='title'>Taking care of repos in the "perl6" organization</span></div> | |
| <div class='entry'><a href="issues.html#235"><span class='number'>235</span></a> [open] <span class='title'>What is the philosophy of the Raku language</span></div> | |
| <div class='entry'><a href="issues.html#234"><span class='number'>234</span></a> [open] <span class='title'>To what extent are resources part of the API of a distribution?</span></div> | |
| <div class='entry'><a href="issues.html#238"><span class='number'>238</span></a> [closed] <span class='title'>What action should be taken in response to AlexDaniel's behavior with other developers</span></div> | |
| <div class='entry'><a href="issues.html#247"><span class='number'>247</span></a> [closed] <span class='title'>Using a Pager for POD6</span></div> | |
| <div class='entry'><a href="issues.html#233"><span class='number'>233</span></a> [open] <span class='title'>IO::Path and Distribution::Resource share many methods</span></div> | |
| <div class='entry'><a href="issues.html#246"><span class='number'>246</span></a> [open] <span class='title'>There's no effective way to communicate something to all people with commit bits in the different Raku repos and organizations</span></div> | |
| <div class='entry'><a href="issues.html#243"><span class='number'>243</span></a> [open] <span class='title'>Raku lacks a generic way of handling backend constants (signals, protocol families, etc.)</span></div> | |
| <div class='entry'><a href="issues.html#241"><span class='number'>241</span></a> [closed] <span class='title'>Add codesections to «meta» reviewers</span></div> | |
| <div class='entry'><a href="issues.html#232"><span class='number'>232</span></a> [open] <span class='title'>Add a "community" label for issues that don't fit existing labels</span></div> | |
| <div class='entry'><a href="issues.html#245"><span class='number'>245</span></a> [open] <span class='title'>How should modules/distributions be handled when severe security issues are discovered?</span></div> | |
| <div class='entry'><a href="issues.html#231"><span class='number'>231</span></a> [open] <span class='title'>Add a Raku blog site as "blogs.raku.org"</span></div> | |
| <div class='entry'><a href="issues.html#240"><span class='number'>240</span></a> [open] <span class='title'>Manage GitHub (and other) organization secrets</span></div> | |
| <div class='entry'><a href="issues.html#237"><span class='number'>237</span></a> [open] <span class='title'>`language` `rakudo` `moarvm` labels have no dev responsible for them</span></div> | |
| <div class='entry'><a href="issues.html#227"><span class='number'>227</span></a> [closed] <span class='title'>Coercion reconsidered and unified</span></div> | |
| <div class='entry'><a href="issues.html#236"><span class='number'>236</span></a> [open] <span class='title'>META6 specification only exists "de facto"</span></div> | |
| <div class='entry'><a href="issues.html#230"><span class='number'>230</span></a> [closed] <span class='title'>rx:s/ / is considered a null regex</span></div> | |
| <div class='entry'><a href="issues.html#229"><span class='number'>229</span></a> [open] <span class='title'>Ecosystem name resolution security problem</span></div> | |
| <div class='entry'><a href="issues.html#228"><span class='number'>228</span></a> [open] <span class='title'>Coercing a string with a Roman numeral throws an error</span></div> | |
| <div class='entry'><a href="issues.html#226"><span class='number'>226</span></a> [closed] <span class='title'>META6.json perl key</span></div> | |
| <div class='entry'><a href="issues.html#225"><span class='number'>225</span></a> [open] <span class='title'>Extended identifiers- reserving :sym puzzles me</span></div> | |
| <div class='entry'><a href="issues.html#224"><span class='number'>224</span></a> [open] <span class='title'>Extended identifiers-why and where, exactly?</span></div> | |
| <div class='entry'><a href="issues.html#223"><span class='number'>223</span></a> [open] <span class='title'>Map parameterized vs Hash parameterized</span></div> | |
| <div class='entry'><a href="issues.html#218"><span class='number'>218</span></a> [open] <span class='title'>Destructuring infinite ranges and sequences</span></div> | |
| <div class='entry'><a href="issues.html#213"><span class='number'>213</span></a> [open] <span class='title'>Loading of custom setting logic is undefined</span></div> | |
| <div class='entry'><a href="issues.html#209"><span class='number'>209</span></a> [open] <span class='title'>Exponentiation with Rat or FatRat exponent results in Num</span></div> | |
| <div class='entry'><a href="issues.html#212"><span class='number'>212</span></a> [open] <span class='title'>pl6anet.org is a name that does not reflect Raku</span></div> | |
| <div class='entry'><a href="issues.html#211"><span class='number'>211</span></a> [open] <span class='title'>The behaviour of -I and 'use lib' can be confusing if there is a META6.json in play</span></div> | |
| <div class='entry'><a href="issues.html#217"><span class='number'>217</span></a> [open] <span class='title'>Uncertain status of tests in the roast</span></div> | |
| <div class='entry'><a href="issues.html#222"><span class='number'>222</span></a> [open] <span class='title'>Introspection for operator precedence, associativity</span></div> | |
| <div class='entry'><a href="issues.html#221"><span class='number'>221</span></a> [open] <span class='title'>.max on Iterables sorts on keys instead of values.</span></div> | |
| <div class='entry'><a href="issues.html#210"><span class='number'>210</span></a> [open] <span class='title'>The raku-community-modules organization and its problems. </span></div> | |
| <div class='entry'><a href="issues.html#208"><span class='number'>208</span></a> [open] <span class='title'>Could Raku benefit from a Flags type?</span></div> | |
| <div class='entry'><a href="issues.html#220"><span class='number'>220</span></a> [closed] <span class='title'>There should be a way of change the default class for sigiled attributes on custom classes</span></div> | |
| <div class='entry'><a href="issues.html#215"><span class='number'>215</span></a> [closed] <span class='title'>Do we need :desc named in Test routines?</span></div> | |
| <div class='entry'><a href="issues.html#207"><span class='number'>207</span></a> [open] <span class='title'>Raku needs a modern doc format that is familiar to most people</span></div> | |
| <div class='entry'><a href="issues.html#214"><span class='number'>214</span></a> [closed] <span class='title'>Allow overriding of compiler-handled operators</span></div> | |
| <div class='entry'><a href="issues.html#204"><span class='number'>204</span></a> [open] <span class='title'>[WIP] Some parts of Raku are improperly named</span></div> | |
| <div class='entry'><a href="issues.html#199"><span class='number'>199</span></a> [open] <span class='title'>More language revision related questions needs resolving.</span></div> | |
| <div class='entry'><a href="issues.html#195"><span class='number'>195</span></a> [open] <span class='title'>Use of literal named parameters syntax for multi-dispatching</span></div> | |
| <div class='entry'><a href="issues.html#194"><span class='number'>194</span></a> [closed] <span class='title'>Gist type objects as `Foo:U` rather than `(Foo)`</span></div> | |
| <div class='entry'><a href="issues.html#206"><span class='number'>206</span></a> [open] <span class='title'>Current Rakudo (possibly MoarVM as well) development process hinders releasing</span></div> | |
| <div class='entry'><a href="issues.html#203"><span class='number'>203</span></a> [open] <span class='title'>Managing the Raku project as it is Coming of Age</span></div> | |
| <div class='entry'><a href="issues.html#198"><span class='number'>198</span></a> [closed] <span class='title'>Should IO::Path.child default to :secure semantics</span></div> | |
| <div class='entry'><a href="issues.html#197"><span class='number'>197</span></a> [closed] <span class='title'>Writing BOMs for *all* utf16 encodings</span></div> | |
| <div class='entry'><a href="issues.html#196"><span class='number'>196</span></a> [closed] <span class='title'>Only allow IO::Path.open to create an IO::Handle</span></div> | |
| <div class='entry'><a href="issues.html#201"><span class='number'>201</span></a> [closed] <span class='title'>Calling vararg functions from NativeCall</span></div> | |
| <div class='entry'><a href="issues.html#200"><span class='number'>200</span></a> [closed] <span class='title'>The Problem Solving Process is not working</span></div> | |
| <div class='entry'><a href="issues.html#193"><span class='number'>193</span></a> [open] <span class='title'>Raku and/or Rakudo trademarks</span></div> | |
| <div class='entry'><a href="issues.html#190"><span class='number'>190</span></a> [closed] <span class='title'>.? behavior on signature mismatch: clarification of semantics</span></div> | |
| <div class='entry'><a href="issues.html#186"><span class='number'>186</span></a> [open] <span class='title'>Nativecall, native trait library usage rework</span></div> | |
| <div class='entry'><a href="issues.html#182"><span class='number'>182</span></a> [open] <span class='title'>What should be the size of `int`? (and other NativeCall type issues)</span></div> | |
| <div class='entry'><a href="issues.html#181"><span class='number'>181</span></a> [closed] <span class='title'>Should we allow directories as destinations for IO::Path.copy/move?</span></div> | |
| <div class='entry'><a href="issues.html#180"><span class='number'>180</span></a> [open] <span class='title'>A better MOP API for wrapper kinds could exist</span></div> | |
| <div class='entry'><a href="issues.html#179"><span class='number'>179</span></a> [closed] <span class='title'>Give Travis.com permission to access raku-community-modules repositories</span></div> | |
| <div class='entry'><a href="issues.html#189"><span class='number'>189</span></a> [closed] <span class='title'>Should we make short-id2class accessible?</span></div> | |
| <div class='entry'><a href="issues.html#188"><span class='number'>188</span></a> [closed] <span class='title'>Should we have a :todo named argument in test routines?</span></div> | |
| <div class='entry'><a href="issues.html#185"><span class='number'>185</span></a> [open] <span class='title'>A way to control Rat's behavior when it is running out of range for its denominator</span></div> | |
| <div class='entry'><a href="issues.html#191"><span class='number'>191</span></a> [closed] <span class='title'>Should Rakudo fail at compile time if it's possible?</span></div> | |
| <div class='entry'><a href="issues.html#184"><span class='number'>184</span></a> [closed] <span class='title'>Should ¿? and ¡! be an alternative to "" ?</span></div> | |
| <div class='entry'><a href="issues.html#187"><span class='number'>187</span></a> [open] <span class='title'>Use a grammar for command line options</span></div> | |
| <div class='entry'><a href="issues.html#177"><span class='number'>177</span></a> [open] <span class='title'>Making a signature accept a list of Pairs</span></div> | |
| <div class='entry'><a href="issues.html#173"><span class='number'>173</span></a> [closed] <span class='title'>Redesign Exceptions for subclassing</span></div> | |
| <div class='entry'><a href="issues.html#176"><span class='number'>176</span></a> [closed] <span class='title'>Rounding issues</span></div> | |
| <div class='entry'><a href="issues.html#175"><span class='number'>175</span></a> [closed] <span class='title'>"Sequence" means too many things in Raku</span></div> | |
| <div class='entry'><a href="issues.html#172"><span class='number'>172</span></a> [closed] <span class='title'>No easy way of getting the N highest/lowest items on a list</span></div> | |
| <div class='entry'><a href="issues.html#174"><span class='number'>174</span></a> [closed] <span class='title'>Attributes could use more support for reflection</span></div> | |
| <div class='entry'><a href="issues.html#183"><span class='number'>183</span></a> [closed] <span class='title'>What should unicode subscripts do? (and should they do anything at all?)</span></div> | |
| <div class='entry'><a href="issues.html#169"><span class='number'>169</span></a> [closed] <span class='title'>New public interfaces are often added without any chance for general consensus</span></div> | |
| <div class='entry'><a href="issues.html#164"><span class='number'>164</span></a> [closed] <span class='title'>$*CWD is an IO::Path, IO::Path.CWD is a Str</span></div> | |
| <div class='entry'><a href="issues.html#160"><span class='number'>160</span></a> [open] <span class='title'>Errors indexing past the end of a List</span></div> | |
| <div class='entry'><a href="issues.html#171"><span class='number'>171</span></a> [open] <span class='title'>printf padding and wide East Asian characters</span></div> | |
| <div class='entry'><a href="issues.html#163"><span class='number'>163</span></a> [closed] <span class='title'>Implement Adverb::Eject in core</span></div> | |
| <div class='entry'><a href="issues.html#168"><span class='number'>168</span></a> [open] <span class='title'>Abandoned modules, deceased authors, etc. (Raku Community Modules)</span></div> | |
| <div class='entry'><a href="issues.html#159"><span class='number'>159</span></a> [open] <span class='title'>The development experience around the generate-and-export pattern has shortcomings</span></div> | |
| <div class='entry'><a href="issues.html#167"><span class='number'>167</span></a> [open] <span class='title'>RAKUDOLIB destiny?</span></div> | |
| <div class='entry'><a href="issues.html#170"><span class='number'>170</span></a> [closed] <span class='title'>Provide better interface for dispatchers</span></div> | |
| <div class='entry'><a href="issues.html#162"><span class='number'>162</span></a> [closed] <span class='title'>Allow single-element Map/Hash to be treated as a Pair</span></div> | |
| <div class='entry'><a href="issues.html#158"><span class='number'>158</span></a> [open] <span class='title'>A new website for raku.org</span></div> | |
| <div class='entry'><a href="issues.html#166"><span class='number'>166</span></a> [closed] <span class='title'>qqx not picking up quotes in Windows 7</span></div> | |
| <div class='entry'><a href="issues.html#161"><span class='number'>161</span></a> [closed] <span class='title'>Should $foo ~~ Failure mark Failure in $foo as handled?</span></div> | |
| <div class='entry'><a href="issues.html#155"><span class='number'>155</span></a> [closed] <span class='title'>Routine doc pages need front matter</span></div> | |
| <div class='entry'><a href="issues.html#154"><span class='number'>154</span></a> [open] <span class='title'>uint's confused with int's</span></div> | |
| <div class='entry'><a href="issues.html#151"><span class='number'>151</span></a> [closed] <span class='title'>Visibility of dynamic symbols in async blocks</span></div> | |
| <div class='entry'><a href="issues.html#147"><span class='number'>147</span></a> [open] <span class='title'>SEO for the keyword "rakulang" seems poor</span></div> | |
| <div class='entry'><a href="issues.html#146"><span class='number'>146</span></a> [closed] <span class='title'>Expose nqp::findcclass and nqp::notfindclass functionality</span></div> | |
| <div class='entry'><a href="issues.html#145"><span class='number'>145</span></a> [closed] <span class='title'>Creating accessors for private attributes without adding them to the BUILDPLAN</span></div> | |
| <div class='entry'><a href="issues.html#157"><span class='number'>157</span></a> [open] <span class='title'>IO::Socket::INET's methods for socket creation may need reconsideration</span></div> | |
| <div class='entry'><a href="issues.html#153"><span class='number'>153</span></a> [closed] <span class='title'>RFE: REPL dependency check for Readline</span></div> | |
| <div class='entry'><a href="issues.html#152"><span class='number'>152</span></a> [open] <span class='title'>RFE: returns for multiple variables</span></div> | |
| <div class='entry'><a href="issues.html#143"><span class='number'>143</span></a> [closed] <span class='title'>Generalization of the "settings" concept</span></div> | |
| <div class='entry'><a href="issues.html#150"><span class='number'>150</span></a> [open] <span class='title'>Expmod returns a default value instead of erroring out on libtommath errors</span></div> | |
| <div class='entry'><a href="issues.html#149"><span class='number'>149</span></a> [open] <span class='title'>Routines could use more support for reflection</span></div> | |
| <div class='entry'><a href="issues.html#139"><span class='number'>139</span></a> [open] <span class='title'>perl6-users mailing list</span></div> | |
| <div class='entry'><a href="issues.html#142"><span class='number'>142</span></a> [closed] <span class='title'>export trait must operate with declared package name</span></div> | |
| <div class='entry'><a href="issues.html#138"><span class='number'>138</span></a> [closed] <span class='title'>What should `val()` support?</span></div> | |
| <div class='entry'><a href="issues.html#148"><span class='number'>148</span></a> [closed] <span class='title'>Add Str.(r)index(@needles)</span></div> | |
| <div class='entry'><a href="issues.html#141"><span class='number'>141</span></a> [open] <span class='title'>change the raku spec versioning</span></div> | |
| <div class='entry'><a href="issues.html#137"><span class='number'>137</span></a> [closed] <span class='title'>How to provide coercers for new types in higher language versions</span></div> | |
| <div class='entry'><a href="issues.html#134"><span class='number'>134</span></a> [closed] <span class='title'>Update or replace draft SoC/CCoC</span></div> | |
| <div class='entry'><a href="issues.html#144"><span class='number'>144</span></a> [closed] <span class='title'>Test Raku modules against different OS, Rakudo versions</span></div> | |
| <div class='entry'><a href="issues.html#135"><span class='number'>135</span></a> [closed] <span class='title'>Add Dict/Tuple to the core</span></div> | |
| <div class='entry'><a href="issues.html#133"><span class='number'>133</span></a> [open] <span class='title'>Remove P5 regexes from Raku</span></div> | |
| <div class='entry'><a href="issues.html#132"><span class='number'>132</span></a> [closed] <span class='title'>Release manager for Rakudo 2019.12 and onward</span></div> | |
| <div class='entry'><a href="issues.html#140"><span class='number'>140</span></a> [closed] <span class='title'>Logo issues and discussion</span></div> | |
| <div class='entry'><a href="issues.html#130"><span class='number'>130</span></a> [open] <span class='title'>"Path to Raku" is missing change of linux module namespaces</span></div> | |
| <div class='entry'><a href="issues.html#129"><span class='number'>129</span></a> [closed] <span class='title'>FQN method calls may need clarification</span></div> | |
| <div class='entry'><a href="issues.html#128"><span class='number'>128</span></a> [closed] <span class='title'>Implementation of importing of classes with composite names perhaps needs better consideration</span></div> | |
| <div class='entry'><a href="issues.html#127"><span class='number'>127</span></a> [open] <span class='title'>Dynamic symbols resolution via &DYNAMIC is potentially a problem in user code</span></div> | |
| <div class='entry'><a href="issues.html#131"><span class='number'>131</span></a> [closed] <span class='title'>Harassment by another member of the community</span></div> | |
| <div class='entry'><a href="issues.html#125"><span class='number'>125</span></a> [closed] <span class='title'>IO::Socket::INET and IO::Socket::Async need a redesign in v6.e</span></div> | |
| <div class='entry'><a href="issues.html#121"><span class='number'>121</span></a> [open] <span class='title'>Check MoarVM out using OSS-fuzz</span></div> | |
| <div class='entry'><a href="issues.html#120"><span class='number'>120</span></a> [open] <span class='title'>Wikipedia and Wikidata curation</span></div> | |
| <div class='entry'><a href="issues.html#124"><span class='number'>124</span></a> [closed] <span class='title'>What's exactly our stance regarding other Raku implementations?</span></div> | |
| <div class='entry'><a href="issues.html#117"><span class='number'>117</span></a> [open] <span class='title'>Creditcard for cloud services</span></div> | |
| <div class='entry'><a href="issues.html#112"><span class='number'>112</span></a> [closed] <span class='title'>Role concretization needs big improvements.</span></div> | |
| <div class='entry'><a href="issues.html#111"><span class='number'>111</span></a> [open] <span class='title'>Raku needs better ways to deal with network addresses</span></div> | |
| <div class='entry'><a href="issues.html#119"><span class='number'>119</span></a> [open] <span class='title'>Generic name for FALLBACK and CALL-ME</span></div> | |
| <div class='entry'><a href="issues.html#123"><span class='number'>123</span></a> [open] <span class='title'>`Supply.map` should respect the `Slip` semantics as `List.map` does</span></div> | |
| <div class='entry'><a href="issues.html#116"><span class='number'>116</span></a> [open] <span class='title'>Apply for AWS credit</span></div> | |
| <div class='entry'><a href="issues.html#122"><span class='number'>122</span></a> [open] <span class='title'>List should have `.do` method as Supply</span></div> | |
| <div class='entry'><a href="issues.html#118"><span class='number'>118</span></a> [closed] <span class='title'>Perl 6 to Raku timeframe</span></div> | |
| <div class='entry'><a href="issues.html#115"><span class='number'>115</span></a> [open] <span class='title'>Open a blog</span></div> | |
| <div class='entry'><a href="issues.html#110"><span class='number'>110</span></a> [closed] <span class='title'>FQN method call needs support for parameterized roles.</span></div> | |
| <div class='entry'><a href="issues.html#107"><span class='number'>107</span></a> [open] <span class='title'>Delegation does not handle multi-methods.</span></div> | |
| <div class='entry'><a href="issues.html#103"><span class='number'>103</span></a> [closed] <span class='title'>Roles, submethods, constructors, destructors.</span></div> | |
| <div class='entry'><a href="issues.html#106"><span class='number'>106</span></a> [closed] <span class='title'>Decision to be taken on Raku filename extensions.</span></div> | |
| <div class='entry'><a href="issues.html#113"><span class='number'>113</span></a> [closed] <span class='title'>0.0.gist returns "0" instead of "0.0" but 0.0.perl works as expected</span></div> | |
| <div class='entry'><a href="issues.html#102"><span class='number'>102</span></a> [closed] <span class='title'>Use of cmake for build subsystem</span></div> | |
| <div class='entry'><a href="issues.html#99"><span class='number'>99</span></a> [closed] <span class='title'>Unification of Array/List and Hash/Map behaviors.</span></div> | |
| <div class='entry'><a href="issues.html#108"><span class='number'>108</span></a> [closed] <span class='title'>New Raku file extensions</span></div> | |
| <div class='entry'><a href="issues.html#98"><span class='number'>98</span></a> [open] <span class='title'>Perl6 is missing the ability to store sub signatures for later use. Think Callbacks.</span></div> | |
| <div class='entry'><a href="issues.html#101"><span class='number'>101</span></a> [closed] <span class='title'>Perl 6, if renamed, needs new filename extensions</span></div> | |
| <div class='entry'><a href="issues.html#97"><span class='number'>97</span></a> [open] <span class='title'>Clean interpolation for enumerated character classes</span></div> | |
| <div class='entry'><a href="issues.html#95"><span class='number'>95</span></a> [open] <span class='title'>Alert system for core developers</span></div> | |
| <div class='entry'><a href="issues.html#94"><span class='number'>94</span></a> [closed] <span class='title'>Reconsider Rakudo build structure</span></div> | |
| <div class='entry'><a href="issues.html#96"><span class='number'>96</span></a> [open] <span class='title'>MoarVM Support of Callbacks in a Different Thread</span></div> | |
| <div class='entry'><a href="issues.html#93"><span class='number'>93</span></a> [open] <span class='title'>Specify documentation URLs</span></div> | |
| <div class='entry'><a href="issues.html#92"><span class='number'>92</span></a> [open] <span class='title'>there is no security process for receiving security critical bug reports</span></div> | |
| <div class='entry'><a href="issues.html#100"><span class='number'>100</span></a> [open] <span class='title'>stage0 is a binary blob, how can we do without it?</span></div> | |
| <div class='entry'><a href="issues.html#105"><span class='number'>105</span></a> [closed] <span class='title'>Ecosystem stability issues</span></div> | |
| <div class='entry'><a href="issues.html#104"><span class='number'>104</span></a> [closed] <span class='title'>A threat of full CORE duplication for each language revision</span></div> | |
| <div class='entry'><a href="issues.html#91"><span class='number'>91</span></a> [open] <span class='title'>.perl should be replaced with a pluggable system</span></div> | |
| <div class='entry'><a href="issues.html#85"><span class='number'>85</span></a> [open] <span class='title'>Update Travis configuration so that it does not compile Rakudo every single time.</span></div> | |
| <div class='entry'><a href="issues.html#77"><span class='number'>77</span></a> [open] <span class='title'>What's up with hyper/race semantics?</span></div> | |
| <div class='entry'><a href="issues.html#73"><span class='number'>73</span></a> [open] <span class='title'>Should IO::Handle instances be possible to construct using file descriptors?</span></div> | |
| <div class='entry'><a href="issues.html#72"><span class='number'>72</span></a> [closed] <span class='title'>Ecosystem: versioning issues</span></div> | |
| <div class='entry'><a href="issues.html#76"><span class='number'>76</span></a> [open] <span class='title'>Make Rakudo read from META6 modules with :ver<>, :auth<> and :api<></span></div> | |
| <div class='entry'><a href="issues.html#75"><span class='number'>75</span></a> [open] <span class='title'>Mechanism for Reusing Function Definitions in NativeCall</span></div> | |
| <div class='entry'><a href="issues.html#90"><span class='number'>90</span></a> [open] <span class='title'>Support for custom HOWs isn't generic enough</span></div> | |
| <div class='entry'><a href="issues.html#74"><span class='number'>74</span></a> [closed] <span class='title'>One more approach for EXPORT problems.</span></div> | |
| <div class='entry'><a href="issues.html#88"><span class='number'>88</span></a> [open] <span class='title'>Language versioning.</span></div> | |
| <div class='entry'><a href="issues.html#81"><span class='number'>81</span></a> [closed] <span class='title'>"Perl" in the name "Perl 6" is confusing and irritating</span></div> | |
| <div class='entry'><a href="issues.html#86"><span class='number'>86</span></a> [closed] <span class='title'>pl6anet.org will be discontinued breaking "Recent Blog Posts" on perl6.org</span></div> | |
| <div class='entry'><a href="issues.html#71"><span class='number'>71</span></a> [closed] <span class='title'>No way of having new versions of CORE classes for new language revisions</span></div> | |
| <div class='entry'><a href="issues.html#69"><span class='number'>69</span></a> [open] <span class='title'>Status of the POD6 implementation</span></div> | |
| <div class='entry'><a href="issues.html#68"><span class='number'>68</span></a> [open] <span class='title'>[WIP] perl6-infra overview</span></div> | |
| <div class='entry'><a href="issues.html#70"><span class='number'>70</span></a> [open] <span class='title'>Official release of Raku implementation</span></div> | |
| <div class='entry'><a href="issues.html#67"><span class='number'>67</span></a> [closed] <span class='title'>[WIP] Detrapping</span></div> | |
| <div class='entry'><a href="issues.html#66"><span class='number'>66</span></a> [open] <span class='title'>Status of NativeCall is unclear</span></div> | |
| <div class='entry'><a href="issues.html#80"><span class='number'>80</span></a> [closed] <span class='title'>Core class version syntax</span></div> | |
| <div class='entry'><a href="issues.html#78"><span class='number'>78</span></a> [closed] <span class='title'>Documentation principles for making translation easier</span></div> | |
| <div class='entry'><a href="issues.html#65"><span class='number'>65</span></a> [closed] <span class='title'>Issue templates for every label</span></div> | |
| <div class='entry'><a href="issues.html#61"><span class='number'>61</span></a> [closed] <span class='title'>Samemark breaks regional indicator symbols, should it be this way?</span></div> | |
| <div class='entry'><a href="issues.html#57"><span class='number'>57</span></a> [open] <span class='title'>X::MyModule::Foo or MyModule::X::Foo ?</span></div> | |
| <div class='entry'><a href="issues.html#53"><span class='number'>53</span></a> [open] <span class='title'>Changelogging takes too much time and effort</span></div> | |
| <div class='entry'><a href="issues.html#64"><span class='number'>64</span></a> [closed] <span class='title'>[WIP] Decluttering</span></div> | |
| <div class='entry'><a href="issues.html#60"><span class='number'>60</span></a> [open] <span class='title'>Running some scripts without any input sometimes leads users to believe that the program is hanging</span></div> | |
| <div class='entry'><a href="issues.html#52"><span class='number'>52</span></a> [closed] <span class='title'>rakudo.party</span></div> | |
| <div class='entry'><a href="issues.html#63"><span class='number'>63</span></a> [open] <span class='title'>Should `without` allow chaining?</span></div> | |
| <div class='entry'><a href="issues.html#51"><span class='number'>51</span></a> [closed] <span class='title'>read-bits/read-ubits on Int as well?</span></div> | |
| <div class='entry'><a href="issues.html#50"><span class='number'>50</span></a> [closed] <span class='title'>Ambiguity in slicing with Ranges / WhateverCodes</span></div> | |
| <div class='entry'><a href="issues.html#59"><span class='number'>59</span></a> [open] <span class='title'>Need a substitute for Perl 5 die with newline for raising end-user errors?</span></div> | |
| <div class='entry'><a href="issues.html#62"><span class='number'>62</span></a> [open] <span class='title'>What can and what cannot be changed in 6.c-errata?</span></div> | |
| <div class='entry'><a href="issues.html#49"><span class='number'>49</span></a> [closed] <span class='title'>rt.perl.org is shutting down</span></div> | |
| <div class='entry'><a href="issues.html#58"><span class='number'>58</span></a> [open] <span class='title'>Ambiguity in pseudo-package and package reaction on missing symbols.</span></div> | |
| <div class='entry'><a href="issues.html#44"><span class='number'>44</span></a> [closed] <span class='title'>%0 and &0 should probably be syntax errors</span></div> | |
| <div class='entry'><a href="issues.html#43"><span class='number'>43</span></a> [closed] <span class='title'>require with non-sigiled arguments</span></div> | |
| <div class='entry'><a href="issues.html#56"><span class='number'>56</span></a> [open] <span class='title'>Clarifying dual-licensing on the site</span></div> | |
| <div class='entry'><a href="issues.html#41"><span class='number'>41</span></a> [open] <span class='title'>`once` block can be executed more than once</span></div> | |
| <div class='entry'><a href="issues.html#55"><span class='number'>55</span></a> [open] <span class='title'>LCM (support Rat and fail on lossy coercion)</span></div> | |
| <div class='entry'><a href="issues.html#54"><span class='number'>54</span></a> [open] <span class='title'>Release process changes</span></div> | |
| <div class='entry'><a href="issues.html#40"><span class='number'>40</span></a> [open] <span class='title'>Please beware of eliminating (or changing) documented features</span></div> | |
| <div class='entry'><a href="issues.html#39"><span class='number'>39</span></a> [closed] <span class='title'>Ecosystem content, quality and fragmentation issues.</span></div> | |
| <div class='entry'><a href="issues.html#35"><span class='number'>35</span></a> [closed] <span class='title'>Helper function on SetHashes</span></div> | |
| <div class='entry'><a href="issues.html#34"><span class='number'>34</span></a> [closed] <span class='title'>The status of PREVIEW modifier.</span></div> | |
| <div class='entry'><a href="issues.html#38"><span class='number'>38</span></a> [closed] <span class='title'>Maybe Any:D.await should return self?</span></div> | |
| <div class='entry'><a href="issues.html#33"><span class='number'>33</span></a> [open] <span class='title'>Push access to repositories in perl6 organization</span></div> | |
| <div class='entry'><a href="issues.html#37"><span class='number'>37</span></a> [open] <span class='title'>Editor modes for Raku</span></div> | |
| <div class='entry'><a href="issues.html#32"><span class='number'>32</span></a> [open] <span class='title'>perl6-infra: Host the Blin Toaster</span></div> | |
| <div class='entry'><a href="issues.html#36"><span class='number'>36</span></a> [open] <span class='title'>Removed Syntactic Feature (-i flag for in-place file editing)</span></div> | |
| <div class='entry'><a href="issues.html#47"><span class='number'>47</span></a> [closed] <span class='title'>Metaop semantics with QuantHashes</span></div> | |
| <div class='entry'><a href="issues.html#46"><span class='number'>46</span></a> [closed] <span class='title'>Moving tickets between rakudo and problem-solving repos is impossible</span></div> | |
| <div class='entry'><a href="issues.html#45"><span class='number'>45</span></a> [open] <span class='title'>Ecosystem issues and a corresponding dev</span></div> | |
| <div class='entry'><a href="issues.html#31"><span class='number'>31</span></a> [closed] <span class='title'>Language revision dependent spectests: change the approach.</span></div> | |
| <div class='entry'><a href="issues.html#27"><span class='number'>27</span></a> [closed] <span class='title'>What are the intended semantics of <== and <<==</span></div> | |
| <div class='entry'><a href="issues.html#22"><span class='number'>22</span></a> [closed] <span class='title'>Defining custom coercions from extant types</span></div> | |
| <div class='entry'><a href="issues.html#18"><span class='number'>18</span></a> [open] <span class='title'>take single letter CLI options with one leading hyphen, such as `-lwc`</span></div> | |
| <div class='entry'><a href="issues.html#21"><span class='number'>21</span></a> [open] <span class='title'>Semantics of coercion type on an "rw" parameter</span></div> | |
| <div class='entry'><a href="issues.html#17"><span class='number'>17</span></a> [closed] <span class='title'>`infrastructure` label and a corresponding subject-matter expert</span></div> | |
| <div class='entry'><a href="issues.html#20"><span class='number'>20</span></a> [closed] <span class='title'>How should Proc::Async.new, run and shell call cmd.exe?</span></div> | |
| <div class='entry'><a href="issues.html#26"><span class='number'>26</span></a> [closed] <span class='title'>Ecosystem: should we strive for integration with MetaCPAN</span></div> | |
| <div class='entry'><a href="issues.html#16"><span class='number'>16</span></a> [closed] <span class='title'>Create .Buf/.Blob coercers on Cool</span></div> | |
| <div class='entry'><a href="issues.html#30"><span class='number'>30</span></a> [open] <span class='title'>perl6-infra: service: Password handling</span></div> | |
| <div class='entry'><a href="issues.html#15"><span class='number'>15</span></a> [closed] <span class='title'>Test issue</span></div> | |
| <div class='entry'><a href="issues.html#29"><span class='number'>29</span></a> [open] <span class='title'>perl6-infra: group of services: DNS hosting</span></div> | |
| <div class='entry'><a href="issues.html#25"><span class='number'>25</span></a> [closed] <span class='title'>The label "infrastructure" is misspelled</span></div> | |
| <div class='entry'><a href="issues.html#28"><span class='number'>28</span></a> [open] <span class='title'>perl6-infra: rules and guidelines</span></div> | |
| <div class='entry'><a href="issues.html#14"><span class='number'>14</span></a> [closed] <span class='title'>Please add me to list of reviewers</span></div> | |
| <div class='entry'><a href="issues.html#24"><span class='number'>24</span></a> [open] <span class='title'>where blocks vs sub signatures</span></div> | |
| <div class='entry'><a href="issues.html#9"><span class='number'>9</span></a> [open] <span class='title'>Issues with security and reliability of our infrastructure</span></div> | |
| <div class='entry'><a href="issues.html#13"><span class='number'>13</span></a> [open] <span class='title'>Specify rounding mode in CORE</span></div> | |
| <div class='entry'><a href="issues.html#19"><span class='number'>19</span></a> [open] <span class='title'>Metadata licenses should be required before adding new modules to ecosystem</span></div> | |
| <div class='entry'><a href="issues.html#11"><span class='number'>11</span></a> [closed] <span class='title'>sprintf is a mess</span></div> | |
| <div class='entry'><a href="issues.html#10"><span class='number'>10</span></a> [open] <span class='title'>Inconsistent handling of too-large array index between match variables and regular arrays</span></div> | |
| <div class='entry'><a href="issues.html#5"><span class='number'>5</span></a> [open] <span class='title'>There's a huge PR/issue deficit in the Rakudo repo</span></div> | |
| <div class='entry'><a href="issues.html#8"><span class='number'>8</span></a> [closed] <span class='title'>.WHEN</span></div> | |
| <div class='entry'><a href="issues.html#7"><span class='number'>7</span></a> [closed] <span class='title'>Add tony-o to the list of reviewers</span></div> | |
| <div class='entry'><a href="issues.html#6"><span class='number'>6</span></a> [open] <span class='title'>New named parameters to .classify</span></div> | |
| <div class='entry'><a href="issues.html#4"><span class='number'>4</span></a> [open] <span class='title'>Some useful math/statistics functions are missing</span></div> | |
| <div class='entry'><a href="issues.html#3"><span class='number'>3</span></a> [closed] <span class='title'>Inconsistensy of container descriptor default value type for nominalizable types.</span></div> | |
| <div class='entry'><a href="issues.html#1"><span class='number'>1</span></a> [closed] <span class='title'>No formally defined process for working on problems</span></div> | |
| </div></body></html> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| html { | |
| font-family: serif; | |
| font-size: 14pt; | |
| font-variant-ligatures: common-ligatures no-discretionary-ligatures no-historical-ligatures contextual; | |
| font-variant-numeric: oldstyle-nums; | |
| } | |
| body { | |
| margin-left: 3em; | |
| margin-right: 3em; | |
| } | |
| .issue > .body { | |
| margin-left: 2em; | |
| } | |
| .issue > .comment { | |
| margin-left: 2em; | |
| } | |
| .issue .header { | |
| font-size: 140%; | |
| background-color: #f0f0f0; | |
| } | |
| .issue > .comments { | |
| margin-left: 2em; | |
| } | |
| .issue .comment { | |
| padding-top: 1em; | |
| } | |
| .issue blockquote { | |
| border-left: .25em solid #a0a0a0; | |
| padding-left: 1em; | |
| } | |
This file has been truncated, but you can view the full file.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <html><head><style>html { | |
| font-family: serif; | |
| font-size: 14pt; | |
| font-variant-ligatures: common-ligatures no-discretionary-ligatures no-historical-ligatures contextual; | |
| font-variant-numeric: oldstyle-nums; | |
| } | |
| body { | |
| margin-left: 3em; | |
| margin-right: 3em; | |
| } | |
| .issue > .body { | |
| margin-left: 2em; | |
| } | |
| .issue > .comment { | |
| margin-left: 2em; | |
| } | |
| .issue .header { | |
| font-size: 140%; | |
| background-color: #f0f0f0; | |
| } | |
| .issue > .comments { | |
| margin-left: 2em; | |
| } | |
| .issue .comment { | |
| padding-top: 1em; | |
| } | |
| .issue blockquote { | |
| border-left: .25em solid #a0a0a0; | |
| padding-left: 1em; | |
| } | |
| </style><link rel='stylesheet' href='issues.css'/></head><body><div class='issue' id="374"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/374"><span class='number'>374</span></a> - <span class='title'>Errors should not be adhoc in core</span></div> | |
| <div class='author'>[open]<span class='author'>@alabamenhu</span> opend this issue at <time datetime="2023-06-26T21:58:03Z">2023-06-26 21:58</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Errors should not be <code>X::Adhoc</code> in core.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>Adhoc errors only inform their issues via a message, which may not be easily parseable. As well, per the documentation</p> | |
| <blockquote> | |
| <p>Note that young code will often be prototyped using X::AdHoc and then later be revised to use more specific subtypes of Exception. As such it is usually best not to explicitly rely on receiving an X::AdHoc – in many cases using the string returned by the .message method, which all Exceptions must have, is preferable.</p> | |
| </blockquote> | |
| <p>However, this is complicated by the fact that the string returned by <code>.message</code> is also potentially unreliable, as LTA errors may be changed, improved, with data points in the message potentially being reorded, adjusted, etc.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5f3hOo"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2023-06-26T22:11:24Z">2023-06-26 22:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>This is fairly simple (if laborious) thing to do. The main issue is determining what error classes are needed so we're not creating a bunch of one-off errors when we could combine them. Additionally, the <code>Exception</code>s created (and extant ones) should be updated to ensure that, in contrast to the documentation, any actionable information is contained in attributes which the <code>message</code> function uses to convert into plain English. This will also make handling a potential internationalization of error messages much easier.</p> | |
| <p>(I posted this in problem-solving because it's sort of a partially Raku, partially Rakudo issue. I'm happy to go start working on a large PR updating all the <code>Exception</code>, but would want consensus on how to go about it first)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f36Ax"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-27T00:02:21Z">2023-06-27 00:02</time> | |
| </div> | |
| <div class='body'> | |
| <p>I agree that it's both Raku and Rakudo issue at the same time. Changed the categorization of this problem accordingly.</p> | |
| <p>Solving this problem would involve not only updating Rakudo sources but adding tests to the roast. This is what's on the surface.</p> | |
| <p>Deeper goes the task of collecting the errors thrown using <code>nqp::die</code> throughout the sources of Rakudo and categorizing them.</p> | |
| <p>Another task is to see what could be done about the errors coming from NQP and, worse even, from VMs. These are adhocs by definition as currently there is no mechanism of mapping them into HLL classes.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f4u_E"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2023-06-27T03:22:29Z">2023-06-27 03:22</time> | |
| </div> | |
| <div class='body'> | |
| <p>Per something I noted in IRC, I think in updating the <code>Exception</code> base class, we should do something akin to</p> | |
| <pre><code>class Exception { | |
| method message { self.MESSAGE } | |
| method MESSAGE is implementation-detail { 'Exception of type ' ~ self.WHAT.^name } | |
| } | |
| </code></pre> | |
| <p>Each exception class would generate its message based on <code>MESSAGE</code> (name for an example only). This would enable an internationalization module to do <code>INIT Exception.^find_method('message').wrap()</code> and not need to wrap the dozens of exception classes' methods which is not performant.</p> | |
| <p>At the same time, in reworking them, I'd make a rule that all pertinent information goes in an attribution that makes logical sense to be used in a <code>grep</code>/<code>when</code> area. The message just joins them into a human readable version. A mostly good example of this is <code>X::Method::NotFound</code>, where the message <em>No such method 'foo' for invocant of type 'Bar'</em> is derived from the attributes <code>method</code> (=<em>foo</em>), <code>typename</code> (=<em>Bar</em>), and <code>private</code> (=<em>false</em>). It does however have a new one <code>addendum</code> that is basically an adhoc and could warrant some review in an <code>Exception</code> rework.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f_PCP"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-28T00:41:54Z">2023-06-28 00:41</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>This would enable an internationalization module to do <code>INIT Exception.^find_method('message').wrap()</code></p> | |
| </blockquote> | |
| <p>I already dislike it:</p> | |
| <ol> | |
| <li><code>wrap</code> is a hack</li> | |
| <li>one would have to do it for nearly every exception class with <code>message</code> and would have to follow any changes in the core</li> | |
| <li>it would be necessary to know the internal implementation of complex <code>message</code> methods where a bunch of other methods are involved – as in your example with <code>X::Method::NoFound</code></li> | |
| </ol> | |
| <p>Besides, what worries me is that composite messages may require different order of their parts in other languages.</p> | |
| <p>I think internationalization must be done in a totally different way at Raku core level.</p> | |
| <p>First of all, there must be some pluggable mechanism where forming of complex messages can be offloaded to external modules. For example, the core could provide defaults via <code>X::L10N::<LN></code> modules, where <code><LN></code> is a language code.</p> | |
| <p>Second, there must be a way of obtaining atomic translations for standard strings and it must work at VM level. At the Raku level it would then make sense to use <code>printf</code> instead of string concatenations to allow language-specific word ordering.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5gCJsr"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2023-06-28T10:43:47Z">2023-06-28 10:43</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>This would enable an internationalization module to do <code>INIT Exception.^find_method('message').wrap()</code></p> | |
| </blockquote> | |
| <p>I already dislike it:</p> | |
| <pre><code>1. `wrap` is a hack | |
| 2. one would have to do it for nearly every exception class with `message` and would have to follow any changes in the core | |
| 3. it would be necessary to know the internal implementation of complex `message` methods where a bunch of other methods are involved – as in your example with `X::Method::NoFound` | |
| </code></pre> | |
| <p>Besides, what worries me is that composite messages may require different order of their parts in other languages.</p> | |
| <p>I think internationalization must be done in a totally different way at Raku core level.</p> | |
| <p>First of all, there must be some pluggable mechanism where forming of complex messages can be offloaded to external modules. For example, the core could provide defaults via <code>X::L10N::<LN></code> modules, where <code><LN></code> is a language code.</p> | |
| <p>Second, there must be a way of obtaining atomic translations for standard strings and it must work at VM level. At the Raku level it would then make sense to use <code>printf</code> instead of string concatenations to allow language-specific word ordering.</p> | |
| </blockquote> | |
| <p>I just wonder if internationalized error messages should be something core handles. The idea of having a single <code>message</code> that farms out to individual <code>MESSAGE</code>s means only one wrap needs to be handled and has minimal extra overhead but a much easier implementation, but also pretty much says empatically "I'm not a part of core". If stuff is farmed out to a module, then complex messages can be handle pretty easily — frameworks are far more advanced today than the old <code>.po/.mo</code> standard. Do we consider the <code>Pod::To::</code> mechanism to be a part of Raku or Rakudo? I think that's a good model to follow. But that's probably a different problem solving issue (although certainly related — discussion of it sparked this issue).</p> | |
| <p>That said, the idea of including each piece of information (method, type, etc for <code>X::Method::NotFound</code>) would make rewriting complex messages much easier for such things. But the primary goal would be to allow better handling of errors. It's much easier to use <code>if .method eq 'foo'</code> or <code>if .type eq 'Bar'</code> on <code>X::Method::NotFound</code> than having to tease out that information based on the contents of <code>.message</code>. (I use <code>X::Method::NotFound</code> here as it's a good example of how to do things, but also of where work needs to be done — the <code>addendum</code>). If that's figure out, I think a lot more can be enabled.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5gMA-D"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-29T20:21:38Z">2023-06-29 20:21</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I just wonder if internationalized error messages should be something core handles.</p> | |
| </blockquote> | |
| <p>I think it should. It's not ought to do it all itself, but providing a pluggable API would be very beneficial.</p> | |
| <p>Besides, having the API would also allow third party code to use it for their needs too.</p> | |
| <p>And don't forget about VM where having a way of providing localized messages is needed too.</p> | |
| <blockquote> | |
| <p>means only one wrap needs to be handled</p> | |
| </blockquote> | |
| <p>Any <code>wrap</code> is rather a hack. It is OK and sometimes even really useful when it comes to well isolated, controllable cases. But when it is supposed to affect the entire ecosystem of a program it is barely acceptable.</p> | |
| <blockquote> | |
| <p>but also pretty much says empatically "I'm not a part of core".</p> | |
| </blockquote> | |
| <p>Does it really matter? Say, my typical <code>$LANG</code> is en_US.UTF-8, but if I set it to, say, uk_UA.UTF-8 and there would be no core support for it then installing something like <code>X::L10N::UA</code> (though, perhaps, more sensible name would be <code>uk_UA</code>) from the ecosystem makes it no less clear that it is not a core thing. But why should anybody care? As long as it doesn't break one's code. Either core or installed L10N modules would be auto-loaded by the core based on the locale making the process transparent to a user.</p> | |
| <blockquote> | |
| <p>frameworks are far more advanced today than the old <code>.po/.mo</code> standard.</p> | |
| </blockquote> | |
| <p>I don't propose the exact replica of .po/.mo. Pluggability can mean that roles or classes in a L10N module may override methods of the original exceptions. In a way this is a cleaner replacement for <code>wrap</code>.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="373"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/373"><span class='number'>373</span></a> - <span class='title'>Rakudoc in third-party modules and some related topics</span></div> | |
| <div class='author'>[open]<span class='author'>@vrurg</span> opend this issue at <time datetime="2023-06-21T01:02:36Z">2023-06-21 01:02</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>This is a meta-issue as it is about to cover a few topics I stumbled upon while writing docs for my last module. Perhaps it would make sense to spawn more specialized issues later, but for now it feels to me like having more sense in providing general overview of the situation.</p> | |
| <p>It is also to be noted that I've got an answer to at least one of my question, but it was part of an undocumented conversation. Therefore it'd be included here as well. Other answers could be lurking out there too, but they're not known to me.</p> | |
| <p>I would try to structure this from the perspective of a module developer, possibly not very experienced with documenting in Raku.</p> | |
| <h3>Where To Start?</h3> | |
| <p>Turns out we don't have a manual on how to write manuals. Something I'd rather expect to be part of module development section in the Raku documentation, or be linked to from the section. What I would like to see there is:</p> | |
| <ol> | |
| <li>Where to start in general, including such topics as recommended sections and styling in general</li> | |
| <li>How to organize the docs from distribution perspective: file locations, pros and cons of using dedicated .rakudoc, or inlining into .rakumod, etc.</li> | |
| <li>What tools to use.</li> | |
| </ol> | |
| <p>I'd say this all is better be a single piece since, as a rule, writing docs is the final stage of project development.</p> | |
| <h3>Docs In An Installed Distribution</h3> | |
| <p>Giving further development to the item 2 from from above, there are cases when having documentation inlined into a .rakumod is not considered a good idea. My own latest example is <code>LibXML::Class::Manual</code> which is not a module and better not be. Other cases may include documenting classes which are declared within a module but one wants them to be available for a documentation reading tool by their full names:</p> | |
| <pre><code class="language-raku">unit module Foo; | |
| class Bar {...} | |
| </code></pre> | |
| <p>And then:</p> | |
| <pre><code>$ rakudoc Foo::Bar | |
| </code></pre> | |
| <p>Our current Raku documentation states that .rakudoc are to be placed under <em>doc/</em> directory of distribution source tree. But the directory is never included into precompiled installation. Thus, <code>zef install Foo</code> and then wiping zef's cache would leave one with no access to these docs whatsoever.</p> | |
| <p>Though, for the clarity, even having the cache preserved is of little help because one has to know where is it located before using it. Moreover, if they don't know about the cache existence then it's not much different from not having it in first place.</p> | |
| <h3>The Reading Tool</h3> | |
| <p>For those coming from Perl background, having <code>rakudoc</code> is quite natural expectation. To be frank, I don't know what is the situation with documentation readers in other languages, but having one should be considered an advantage. From this point of view I tend to consider having the <code>rakudoc</code> as the standard.</p> | |
| <p>Either way, there is no alternative to it presently. But in its current form it is barely useful too.</p> | |
| <p>First of all, it requires a document to follow its demands with regard to the structure and it is very rigid in these demands. In particular, it has to be <code>=TITLE</code>, not <code>=head TITLE</code>, not <code>=head1 TITLE</code>. But then again, why <code>=TITLE</code> and <code>=SUBTITLE</code>, after all? My own preference is man-styled docs with <code>=NAME</code>, <code>=SYNOPSIS</code>, <code>=DESCRIPTION</code>, etc. In large due to keeping in mind that this how they should be used too.</p> | |
| <p>The other requirement is to have <code>:kind</code>, <code>:subkind</code>, and <code>:category</code> keys on <code>=begin pod</code> – but what are they? What for? Seems like this is something apparent to The Raku Documentation project participants, but they are an undocumented mystery to me.</p> | |
| <p>It is understandable that since <code>rakudoc</code> is not part of Rakudo and, apparently and definitely, of the Raku language, I cannot impose any requirements on it. But without an alternative implementing more democratic rules I'd have these question open. It is irrelevant to me wether they'd be answered by <code>rakudoc</code> or somebody picks up the task and implements a "competitor".</p> | |
| <p>And then, once again, access to .rakudoc in precompiled distros...</p> | |
| <h3>Tooling?</h3> | |
| <p>Having some kind of standard tool or tools to deal with documentation, starting from verifying it and all the way down to producing output formats and even publishing them – it's a dream. Let it be here, just in case...</p> | |
| <p>BTW, with RakuAST implementing this part would become more feasible.</p> | |
| <h3>TOC?</h3> | |
| <p>I'm not even certain as to what to ask about here. Some documents (the above mentioned manual, in particular) tend to grow big. Having TOC would help a lot in navigating them. Even if it's not clickable since having a document overview already eases search for necessary information.</p> | |
| <p>Some docs are so tiny that TOC in them would be an overkill.</p> | |
| <p>Having TOC as a part of Rakudoc standard seems to be an advantage. Making it available for opt-in/opt-out would be great too.</p> | |
| <h3>Rakudoc Cross-linking</h3> | |
| <p><code>L<></code> tag is giving more questions than answers. The first and the biggest problem is when it comes down to multi-format output (HTML, Markdown, etc.) where there could not only be different file extensions but even different directory structure – if there is any directories at all like when everything is thrown into a single PDF, for example. There is a real-life case of https://raku.land where links in READMEs are very fragile and often just do not work.</p> | |
| <p>What aspects of linking we can take as axioms?</p> | |
| <ul> | |
| <li>anchors (explicit or implicit)</li> | |
| <li>inter-document</li> | |
| <li>cross-document</li> | |
| <li>the already mentioned multi-format output with different file extensions and URI schemas</li> | |
| </ul> | |
| <p>A typical question of linking would look like: in a doc for module <code>Foo::Bar::Baz</code> I need to link to a paragraph in <code>Foo::Fubar</code> documentation so, that it would work in a local HTML; on a web page; on a version control service provider like GitHub, GitLab, whatever else is one's choice; etc.</p> | |
| <p>Perhaps this question doesn't have a comprehensive answer, but at the moment there is barely anything reliable but WWW URLs. Not even relative paths are sufficiently good for the task.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5fXS8N"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-21T01:38:30Z">2023-06-21 01:38</time> | |
| </div> | |
| <div class='body'> | |
| <p>My own two cents.</p> | |
| <p>First, about TOC. Best is to have <code>=toc</code> so one can chose where exactly they want to see it. This is best in cases when a kind of preface is required.</p> | |
| <p>Speaking of links, @finanalyst has mentioned during our last RSC meeting that we can introduce, say <code>:id</code> configuration key, making it possible to create reliable links. The problem in general for now is when we have, say <code>=head My Ideas</code> there is no way to link to it in a way that when it gets renamed to <code>=head Our Ideas</code> the old <code>L<></code> tags would still point out to the section.</p> | |
| <p>Another matter to cover is that limiting links with only certain kinds of Rakudoc elements (like headings) make it harder for both the writer and the reader: <em>"See section L<Our Ideas>, where you would find a list with an item of interest."</em> Nah!</p> | |
| <pre><code>Look at the method L<foo|#method-foo> down below. | |
| ... | |
| =begin item :id<method-foo> | |
| B<C<method foo(...)>> | |
| Hope you found what you're looking for here! | |
| =end item | |
| </code></pre> | |
| <p>Having <code>:id</code> available for any (or almost any) kind of Rakudoc block would be very beneficial for docs readability.</p> | |
| <p>Another point is cross-module/-document linking. Speaking of the <code>Foo::Bar::Baz</code> -> <code>Foo::Fubar</code> example, best if one can simply use <code>L<Foo::Fubar|#some-id></code> and the rest would be taken care of by the tools. Moreover, I'd make the pipe <code>|</code> optional and have it just as `L<a href="Foo::Fubar#some-id">Foo::Fubar#some-id</a> in this particular case. Others would still require the separator.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fXT0a"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-21T01:44:37Z">2023-06-21 01:44</time> | |
| </div> | |
| <div class='body'> | |
| <p>Having to always define <code>:id</code> for any potential anchor is too much. Therefore some rules of implicit anchor naming must be defined. But they have to be clear and standard for any output format. Whatever is eventually generated in the output, anchor name in Rakudoc would only depend on what Rakudoc itself states. So, one would know that <code>=head Our Ideas</code> can be referenced as <code>#our-ideas</code> at any time.</p> | |
| <p>It feels to me that these rules are to be coded in RakuAST parser. Tools would simply pick up what they're offered with. This should also simplify producing links for something like <code>L<Our Ideas></code> as the corresponding object would already have the target anchor name in it.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fdzFX"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-21T20:43:47Z">2023-06-21 20:43</time> | |
| </div> | |
| <div class='body'> | |
| <p>I gave a 10 min presentation to the Core summit about changes needed in Rakudoc. | |
| As a result of the 3hours of discussion, I have rewritten the Rakudoc document / specification, making it backwards compatible, but also explaining a lot more about certain features of Rakudoc (aka POD6), such as metadata, the difference between code-oriented Rakudoc and page-oriented Rakudoc, directives vs blocks, etc.</p> | |
| <p>A first draft of the Rakudoc document is currently being reviewed by @lizmat As soon as she is through, it will be sent for a BETA review to people who have been implementing Rakudoc in various ways. After the BETA review and incorporating changes, the document will be placed somewhere (as a Raku/Doc PR) for a wider community review. Also I will release a series of blogs about the changes to explain the rationale behind them.</p> | |
| <p>As to the requests above (this is not an exhaustive list of the revisions):</p> | |
| <ul> | |
| <li>An original unimplemented specification in S26 (the speculation about POD6) was <code>P<:toc></code> which would place a TOC where the author wanted. This will be a part of the revised Rakudoc. | |
| <ul> | |
| <li>There is a problem in that for a large project like Raku documentation the designer will want to place the ToC in a standard place, such as a sidebar.</li> | |
| </ul> | |
| </li> | |
| <li>The idea of an <code>:id<some-custom-anchor></code> will be in the Rakudoc revision, and will be applied to all blocks. | |
| <ul> | |
| <li>It is for the author to guarantee that the id is unique, a conflict is resolved by the browser or renderer.</li> | |
| <li>If a <code>=head</code> block exists, then it automatically generates an anchor (as mentioned above), which is guaranteed to be unique. However, a custom <code>:id</code> will also generate an anchor at the same place. This way a document author can create an easy to remember anchor for their own documents.</li> | |
| <li>The ability to add custom <strong>metadata</strong> already exists by using the <code>=for</code> directive. So if a <code>=head1 This is a header</code> exists and the id needs to be customised, then the new code will be:</li> | |
| </ul> | |
| </li> | |
| </ul> | |
| <pre><code>=for head1 :to<easy_anchor> | |
| This is a header | |
| </code></pre> | |
| <p>A compliant renderer will be expected to generate both the <code>this_is_a_header</code> and the <code>easy_anchor</code> anchors.</p> | |
| <ul> | |
| <li>The need for a way to link by Module was noted at the Core summit with a new schema for <code>L<></code> and <code>P<></code> markup, namely <code>mod://Some::Module</code>. The syntax will be included in the Rakudoc revision, but the semantics have yet to be fully nailed down. It will link to the rakuland site though.</li> | |
| <li>About the <code>:kind</code> <code>:subkind</code> metadata in Raku documentation files, this is a poorly documented feature of POD6. This data is used by the Renderer of the Raku documentation to compile cross document indexes and secondary files. Only some metadata is specified by the new Rakudoc revision, and if it is not in the specification, then it is ignored, unless a customised renderer is used.</li> | |
| <li>About how to create documentation, and ways to view any module's documentation, this is indeed a need. There is a part of the META6 specification that includes a 'doc' directory, but this not used or recognised yet.</li> | |
| </ul> | |
| <p>In addition, the move to RakuAST will change Rakudoc considerably. It will no longer need to be accessed via the $=pod mechanism, but will be primarily found using an <code>.AST</code> call on a file.</p> | |
| <p>Hopes this explains some of the progress that is on its way.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ffhhg"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-06-22T06:49:47Z">2023-06-22 06:49</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <ul> | |
| <li>The need for a way to link by Module was noted at the Core summit with a new schema for <code>L<></code> and <code>P<></code> markup, namely <code>mod://Some::Module</code>. The syntax will be included in the Rakudoc revision, but the semantics have yet to be fully nailed down. It will link to the rakuland site though.</li> | |
| </ul> | |
| </blockquote> | |
| <p>The specification shouldn't dictate, which platform module links are resolved to. Once raku.land has gained Rakudoc support it makes sense for docs.raku.org to link to raku.land (as that's currently the dominant platform). But other documentation providers should be free to link somewhere else. E.g. a command line documentation reader should try to resolve and display module links itself.</p> | |
| <p>@finanalyst I guess this is what you meant. But I wanted to be sure.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fgU8y"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-22T09:25:59Z">2023-06-22 09:25</time> | |
| </div> | |
| <div class='body'> | |
| <p>@patrickbkr yes, you're right about retaining a generic interface, but what I meant about 'the semantics have yet to be fully nailed down' is to work out how to do this. The reference to rakuland is more about an initial default. | |
| Because Rakudoc must be customisable, every renderer will have to be configurable in some way. I don't want to define how a renderer should be configured. | |
| However, by defining the behaviours of some blocks, say the way numbering works with <code>=head</code> and <code>=item</code>, Rakudoc is being specific about defaults, allowing Renderer developers to provide other behaviours. The <code>=config</code> directive to change behaviours. | |
| oO ( maybe we need to have a metadata option like :mod-prefix that by default is set to eg rakuland, then if a document writer wants a different behaviour, they could put</p> | |
| <pre><code>=config Markup-L mod-prefix 'https://another-site.eg/dist?' | |
| </code></pre> | |
| <p>) end of speculation | |
| Would this suit?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fgquZ"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-06-22T10:28:04Z">2023-06-22 10:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think documentation software will fall in one of several categories:</p> | |
| <ul> | |
| <li>Software to display the official Raku documentation which may contain links to ecosystem modules -> hard code raku.land or let the user decide via some configuration on the website</li> | |
| <li>Generic ecosystem module documentation viewers (raku.land, the rakudoc CLI tool) -> They should open links in their own interface.</li> | |
| <li>Software to create or display documentation potentially unrelated to Raku. (podlite?) -> Won't have module links.</li> | |
| <li>A company may have internal Raku code and documentation which they view in a private installation of e.g. raku.land. -> Configure that installation to resolve links to that private installation itself.</li> | |
| </ul> | |
| <p>Following the above categories I see two cases:</p> | |
| <ul> | |
| <li>the reader wants to change where such links go to (i.e. by setting some option in the viewer program / website)</li> | |
| <li>the software presenting the documentation decides</li> | |
| </ul> | |
| <p>@finanalyst Can you come up with an example where it would make sense for the mod-prefix to be specified in the documentation itself?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fiMMW"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-22T15:01:10Z">2023-06-22 15:01</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't think there must be any suggestion/defaults on the Rakudoc side as to where module links must point at. Neither implicit, by the standard; nor explicit by document creator. In the latter case there is always an option of inserting the link manually, as a URL, since it's about to be rigidly hardcoded anyway.</p> | |
| <p>This has to be 100% on the reader side.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fiUYu"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-22T15:21:00Z">2023-06-22 15:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>@vrurg I'm having difficulties reconciling your two comments:</p> | |
| <blockquote> | |
| <p>best if one can simply use L<a href="Foo::Fubar%7C#some-id">Foo::Fubar|#some-id</a> and the rest would be taken care of by the tools. Moreover, I'd make the pipe | optional and have it just as `LFoo::Fubar#some-id in this particular case</p> | |
| </blockquote> | |
| <p>and recently</p> | |
| <blockquote> | |
| <p>don't think there must be any suggestion/defaults on the Rakudoc side as to where module links must point at. Neither implicit, by the standard; nor explicit by document creator. In the latter case there is always an option of inserting the link manually, as a URL, since it's about to be rigidly hardcoded anyway.</p> | |
| </blockquote> | |
| <p>The original desire seemed to be that in some documentation an author could say eg</p> | |
| <pre><code>This to-json method is similar to the L<to-json method in JSON::Fast|mod://JSON::Fast#to-json> | |
| </code></pre> | |
| <p>The renderer would have default mechanism to find <code>JSON::Fast</code> and point at the documentation.</p> | |
| <p>Personally I don't like the suggestion purely because it leaves too much to the tooling, but I could see it would be useful.</p> | |
| <p>But if such a functionality is wanted, how should a Renderer operate to become compliant?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fibXH"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-22T15:37:29Z">2023-06-22 15:37</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The renderer would have default mechanism to find <code>JSON::Fast</code> and point at the documentation.</p> | |
| </blockquote> | |
| <p>I have combined the "renderer" and actual person-reader into a single term "reader". The point is that there is language side (the Rakudoc standard), the writer side (module/document author), and the "reader" side. Or, the other way around, "reader" is the one who reads Rakudoc sources.</p> | |
| <p>Not the best definitions, but OK for the purpose of defining where the final link is produced.</p> | |
| <blockquote> | |
| <p>Personally I don't like the suggestion purely because it leaves too much to the tooling, but I could see it would be useful.</p> | |
| </blockquote> | |
| <p>Dynamic or semi-dynamic things like URLs are better be left off to the tools. As much as we should do is to provide <em>recommendations</em>, but nothing more. Patrick has provided very good examples as to when the final URL can differ from our understanding of it. My other point would be that changing a standard is not a particularly fast paced process. Not to mention the need for the tools to update afterwards. But in case of a disastrous disappearance of the site, hardcoded in the standard, we better let tool developers to react as quick as they can.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fiqYK"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-22T16:00:31Z">2023-06-22 16:00</time> | |
| </div> | |
| <div class='body'> | |
| <p>The three terms are needed:</p> | |
| <ul> | |
| <li>reader - a human reading documentation about a module or functionality. The reader will want to use a method that is most convenient. There are three current useful methods: | |
| <ul> | |
| <li>HTML rendered pages (such as the Raku documentation suite), but also in pages rendered by Podlite.</li> | |
| <li>MarkDown rendered pages, eg. REAME.md</li> | |
| <li>An IDE, such as Comma</li> | |
| </ul> | |
| </li> | |
| <li>developer / document author - a human writing software or describing how to use software, which the reader will want to use. The writer uses Rakudoc, which is neutral about the output format.</li> | |
| <li>renderer - the software tool that converts Rakudoc instructions into a form useful to the reader. The renderer for the Raku documentation site is now <code>Raku::Pod::Render</code>.</li> | |
| </ul> | |
| <p>So the suggestion is to include in the standard for the minimum Rakudoc the schema for <code>L<></code> markup called <code>mod://</code>, in addition to the very common <code>https://</code>| <code>http://</code>. The aim is for <code>mod://</code> to be followed by the name of a Raku module.</p> | |
| <p>That part seems easy. The question is how to specify what a Rakudoc B<Renderer> should do when implementing that link? There may be multiple renderers (I am already planning a new renderer to work directly on RakuAST because <code>Raku::Pod::Render</code> works using <code>$=pod</code>).</p> | |
| <p>It seems to me that a default behaviour should be indicated in the Rakudoc documentation. This default can be changed in the future.</p> | |
| <p>However, this default can be changed / customised.</p> | |
| <p>I am <strong>ABSOLUTELY</strong> against hard-coded solutions. I wrote <code>Raku::Pod::Render</code> because <code>Pod::To::HTML</code> hard coded everything. The bits that are now put into Mustache templates were my first PRs to <code>Pod::To::HTML</code>.</p> | |
| <p>What I am trying to say is that even if there is maximum flexibility, there should be some reasonable defaults so that the first use of a Render can be as easy as possible for a new user.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ftQRO"> | |
| <div class='header'> | |
| <span class='author'>@ugexe</span> commented at <time datetime="2023-06-24T19:21:15Z">2023-06-24 19:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>Something to consider when trying to create a URI scheme for this is that users should be able to link to a specific version like <code>mod://JSON::Fast:ver<42>#to-json</code>. The <code><</code> and <code>></code> would make it annoying to embed in <code>L<></code>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ftRUS"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-24T19:43:34Z">2023-06-24 19:43</time> | |
| </div> | |
| <div class='body'> | |
| <p>That has a solution, one can use <code>L<<>></code> or <code>L«»</code>, unless you're referring to something else.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ftRXh"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-24T19:44:33Z">2023-06-24 19:44</time> | |
| </div> | |
| <div class='body'> | |
| <p>@ugexe the Rakudo grammar is actually good at handling this sort of bracing. | |
| For instance <code>C< L<> ></code> passes <code>L<></code> to the handler for C.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ftSz8"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-24T19:57:56Z">2023-06-24 19:57</time> | |
| </div> | |
| <div class='body'> | |
| <p>As long as the delimiters are balanced it'll work, unless the <code><></code> part is in the URL section(I don't know if that's a bug):</p> | |
| <pre><code class="language-raku">=begin pod | |
| L<mod://JSON::Fast:ver<42>#to-json> | |
| # Pod::FormattingCode.new(type => "L", meta => [], config => {}, contents => ["mod://JSON::Fast:ver<42>#to-json"]) | |
| L<test|mod://JSON::Fast:ver<42>#to-json> | |
| # Pod::FormattingCode.new(type => "L", meta => ["mod://JSON::Fast:ver<42"], config => {}, contents => ["test"]) | |
| L<<test|mod://JSON::Fast:ver<42>#to-json>> | |
| # Pod::FormattingCode.new(type => "L", meta => ["mod://JSON::Fast:ver<42>#to-json"], config => {}, contents => ["test"]) | |
| L«test|mod://JSON::Fast:ver<42>#to-json» | |
| # Pod::FormattingCode.new(type => "L", meta => ["mod://JSON::Fast:ver<42>#to-json"], config => {}, contents => ["test"]) | |
| =end pod | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ftUPu"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-24T20:19:13Z">2023-06-24 20:19</time> | |
| </div> | |
| <div class='body'> | |
| <p>@CIAvash Good catch. I would say the second case is a bug. | |
| Have you tried this with RakuAST?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ftV9W"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-24T20:33:25Z">2023-06-24 20:33</time> | |
| </div> | |
| <div class='body'> | |
| <p>@finanalyst no, not sure how to do that. I'm still on Rakudo 2023.04. That doesn't support RakuDoc, does it?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ftXCb"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-24T20:52:21Z">2023-06-24 20:52</time> | |
| </div> | |
| <div class='body'> | |
| <p>@CIAvash RakuAST for RakuDoc is very bleeding edge. | |
| Using your tests in a file called ttt.rakudoc, I get.</p> | |
| <pre><code>$ RAKUDO_RAKUAST=1 raku -e "'ttt.rakudoc'.IO.slurp.AST.say" | |
| RakuAST::StatementList.new( | |
| RakuAST::Doc::Block.new( | |
| type => "pod", | |
| paragraphs => ( | |
| RakuAST::Doc::Paragraph.new( | |
| RakuAST::Doc::Markup.new( | |
| letter => "L", | |
| opener => "<", | |
| closer => ">", | |
| atoms => ( | |
| "mod://JSON::Fast:ver", | |
| RakuAST::Doc::Markup.new( | |
| letter => "", | |
| opener => "<", | |
| closer => ">", | |
| atoms => ( | |
| "42", | |
| ) | |
| ), | |
| "#to-json", | |
| ) | |
| ), | |
| "\n\n" | |
| ), | |
| RakuAST::Doc::Paragraph.new( | |
| RakuAST::Doc::Markup.new( | |
| letter => "L", | |
| opener => "<", | |
| closer => ">", | |
| atoms => ( | |
| "test|mod://JSON::Fast:ver", | |
| RakuAST::Doc::Markup.new( | |
| letter => "", | |
| opener => "<", | |
| closer => ">", | |
| atoms => ( | |
| "42", | |
| ) | |
| ), | |
| "#to-json", | |
| ) | |
| ), | |
| "\n\n" | |
| ), | |
| RakuAST::Doc::Paragraph.new( | |
| RakuAST::Doc::Markup.new( | |
| letter => "L", | |
| opener => "<<", | |
| closer => ">>", | |
| atoms => ( | |
| "test", | |
| ), | |
| meta => ( | |
| "mod://JSON::Fast:ver<42>#to-json", | |
| ) | |
| ), | |
| "\n\n" | |
| ), | |
| RakuAST::Doc::Paragraph.new( | |
| RakuAST::Doc::Markup.new( | |
| letter => "L", | |
| opener => "«", | |
| closer => "»", | |
| atoms => ( | |
| "test", | |
| ), | |
| meta => ( | |
| "mod://JSON::Fast:ver<42>#to-json", | |
| ) | |
| ), | |
| "\n\n" | |
| ), | |
| ) | |
| ) | |
| ) | |
| </code></pre> | |
| <p>So @ugexe was correct: the inner <code><></code> causes problems.</p> | |
| <p>The interesting thing is that both of the first two cases in your example are wrong, the first one subtly. Rakudo is parsing the <code><></code> after the <code>ver</code> as a FormatCode with letter ''.</p> | |
| <p>Using <code><< >></code> as the bracketing pair yields the correct form (the url should be in the <code>meta</code> attribute.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ft9nv"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-25T05:50:30Z">2023-06-25 05:50</time> | |
| </div> | |
| <div class='body'> | |
| <p>@finanalyst hmm, don't know if that's a bug or not, but using multiple angle brackets or <code>«»</code> is safer for sure.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fuOC3"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-06-25T08:53:39Z">2023-06-25 08:53</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>So @ugexe was correct: the inner <> causes problems.</p> | |
| </blockquote> | |
| <p>It indeed causes issues in the legacy $=pod generation. Am looking into this.</p> | |
| <blockquote> | |
| <p>The interesting thing is that both of the first two cases in your example are wrong, the first one subtly. Rakudo is parsing the <> after the ver as a FormatCode with letter ''.</p> | |
| </blockquote> | |
| <p>The rules according to S26 are that <em>if</em> you use the same delimiter inside a markup as the "outer" markup, they <em>must</em> balance. The easiest way to implement this, was to handle the as "letterless" markup codes. A "letterless" markup code can always just be stringified. One could argue the parser should do that for you, but I'm a little in two minds about that, as it would remove potentially valuable information.</p> | |
| <blockquote> | |
| <p>Using << >> as the bracketing pair yields the correct form (the url should be in the meta attribute.</p> | |
| </blockquote> | |
| <p>Different delimiters mean that you can have unbalanced as well, as they are completely ignored in markup parsing.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fuZ0X"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-25T10:01:15Z">2023-06-25 10:01</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>A "letterless" markup code can always just be stringified. One could argue the parser should do that for you, but I'm a little in two minds about that, as it would remove potentially valuable information.</p> | |
| </blockquote> | |
| <p>If the parser doesn't stringify, then a RakuAST-oriented renderer needs to look for letterless MC. Then this needs to be documented. It could be useful if a renderer is looking to do something with <code>:var<></code>, <code>:auth<></code> or <code>:api<></code>. That seems a long way ahead.</p> | |
| <blockquote> | |
| <p>Different delimiters mean that you can have unbalanced as well, as they are completely ignored in markup parsing.</p> | |
| </blockquote> | |
| <p>But that would allow unbalanced delimiters. A note in documentation would indicate that if different delimiters are used, the parser will not pick up an imbalance.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fual7"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-06-25T10:08:15Z">2023-06-25 10:08</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>But that would allow unbalanced delimiters. A note in documentation would indicate that if different delimiters are used, the parser will not pick up an imbalance.</p> | |
| </blockquote> | |
| <p>Sometimes you need to allow for unbalanced delimiters. <code>C« < »</code> comes to mind.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fucgD"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-06-25T10:18:13Z">2023-06-25 10:18</time> | |
| </div> | |
| <div class='body'> | |
| <p>https://github.com/rakudo/rakudo/commit/e66bcd670c fixes the <code>L<test|mod://JSON::Fast:ver<42>#to-json></code> case.</p> | |
| <pre><code class="language-raku">RakuAST::Doc::Markup.new( | |
| letter => "L", | |
| opener => "<", | |
| closer => ">", | |
| atoms => ( | |
| "test", | |
| ), | |
| meta => ( | |
| "mod://JSON::Fast:ver<42>#to-json", | |
| ) | |
| ) | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fuyRF"> | |
| <div class='header'> | |
| <span class='author'>@ugexe</span> commented at <time datetime="2023-06-25T13:47:28Z">2023-06-25 13:47</time> | |
| </div> | |
| <div class='body'> | |
| <p>Some other things to consider that crossed my mind:</p> | |
| <p>Is this <code>mod://</code> string is meant to be an actual URI? If so I don't think we could use <code>:</code>, <code><</code>, or <code>></code> (among others) in the host portion of it. The <a href="https://en.wikipedia.org/wiki/File_URI_scheme">file URI scheme</a> solves a similar problem (that <code>/</code> can be contained in the first part -- i.e. the host) by starting the scheme with a triple slash ala <code>file:///</code> (thus e.g. <code>JSON::Fast</code> would end up in the path portion of the URI instead of host).</p> | |
| <p>Another other thing is that <code>:</code> <code><</code> <code>></code> would typically be URI encoded. This might not be a problem as most tooling can probably handle that conversion, but I do wonder if having the URI not parse-able by URI grammars in their initial form will lead to problems down the road. I'm not really sure there is a good solution for this, but it is worth being aware of.</p> | |
| <p>Third, while it doesn't map directly to raku syntax, it might be better to pass filters like we normally would with a URI, ala <code>mod:///Foo::Bar?version=1&api=2&auth="blorg"</code>. This also happens to solve some parts of the previous problem since we wouldn't be passing in <code><</code> and <code>></code>.</p> | |
| <p>Fourth, should we use a different prefix like <code>rakumod://</code>? That might make it easier to have something that would show up on e.g. https://en.wikipedia.org/wiki/List_of_URI_schemes since it wouldn't be using a super generic scheme <code>mod</code></p> | |
| <p>Finally, should this URI map to a distribution + module? For instance a distribution called <code>Net::HTTP</code> which provides a module <code>Net::HTTP::Get</code>: <code>rakumod:///Net::HTTP/Net::HTTP::GET?version=1&auth="github:ugexe"</code>. I.e. first path portion would be the distribution, the second path portion (which could be optional) would be something contained in that distribution.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fu0m-"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-25T14:17:06Z">2023-06-25 14:17</time> | |
| </div> | |
| <div class='body'> | |
| <p>It shouldn't be an actual URI, should it? Language implementation should create the RakuDoc data and then RakuDoc renderer should create the suitable link/whatever IMO.</p> | |
| <p>The old design docs mention <code>L<doc:Module::Name></code>: https://design.raku.org/S26.html#Links</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fu1sM"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-25T14:27:52Z">2023-06-25 14:27</time> | |
| </div> | |
| <div class='body'> | |
| <p>To respond to @ugexe , let me start with some initial ideas.</p> | |
| <p>The idea behind the <code>mod:</code> schema is to make it easier for a documentation writer to refer to a module without needing to know where the module is located.</p> | |
| <p>A link has two parts <code>L< 'the text shown in the documentation' | 'the meta data containing the link</code>>`. So when I say 'meta data', I mean the second bit.</p> | |
| <p>The metadata can already contain three schemas: <code>http://</code>, <code>https://</code>, <code>file://</code></p> | |
| <p>The original suggestion was to have quite a few more, but the one that seems to have usefulness is <code>toc:</code>, to which we are adding <code>index:</code>.</p> | |
| <p>The new schema requested was <code>mod:</code>, but <code>:rakumod</code> seems a better idea since I'm sure someone will want to reference a module in another language, which would increase complexity without much benefit.</p> | |
| <p>Since the idea is to make it easy to write and (read the raw Rakudoc), my feeling is that the <code>rakumod:</code> schema should be as close to the Raku standard idiom as possible.</p> | |
| <p>The question about the URI mapping is something I would call the 'semantics' of the schema (I'm probably technically wrong here). I would think that when a renderer creates the rendered version, for example an HTML <code><a></code> tab, it should create something like <code>Foo::Bar?version=1&api=2&auth="blorg"</code> from <code>L<< text | mod://Foo::Bar:ver<1>:api<2>:auth<blorg> >></code>.</p> | |
| <p>As to distribution / module parts, I think there is a question to be resolved. Where doe s the link to point at? Suppose we have a distribution <code>ExampleModule</code> structured as</p> | |
| <pre><code>ExampleModule/ | |
| docs/ | |
| README.rakudoc | |
| Moredetail.rakudoc | |
| lib/ | |
| ExampleModule.rakumod | |
| README.md | |
| </code></pre> | |
| <p>Now we have <code>L<looking at the Example module|rakumod://ExampleModule></code>, where does it reference? And an HTML URL is going to expect an HTML page to be served back.</p> | |
| <p>This indicates that a <code>Rakumod:</code> schema imposes an expectation on the site that is serving the link.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fu5SN"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2023-06-25T15:13:40Z">2023-06-25 15:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>Another point for rakumod: is that it's more self-documenting. It's crystal clear that the URI is identifying a Raku module.</p> | |
| <p>Since we want to use a URI to identify these modules, we must adhere to the URI syntax. Everything else would just put an unneeded burden on tool developers. As such a tool developer, I'd expect to be able to pass the actual link to a standard URI parser to get at the individual components (most of all the scheme to determine, how to link). The URI part after the initial <code>//</code> is the authority which is <code>[userinfo "@"] host [":" port]</code>. As we don't have that kind of information in rakumod links, it doesn't make sense to include the <code>//</code>. Thus a sensible URI would look like <code>rakumod:Foo::Bar</code></p> | |
| <p>As to the question of how to encode adverbs, I would suggest that we stick to URI syntax as @ugexe suggested: <code>rakumod:Foo::Bar?version=1&api=2&auth="blorg"</code>. The reasons are:</p> | |
| <ul> | |
| <li>Since tools will already use a URI parser for processing these links, getting the adverbs will be very straight forward, without having to parse the path part yet again.</li> | |
| <li>The <code>:version<1></code> syntax might be quite common, but it's by no means standard and by far not the only one. A benign alternative would be <code>:version(1)</code>, but syntactically it could also be <code>:version(1 + 2)</code> or really arbitrary code. I'm pretty sure we do not want to go down that route.</li> | |
| <li>If you argue, that the above is nonsense and we'd of course not allow full Raku syntax in these adverbs, then you'll have to answer how to e.g. quote <code>></code> characters contained in these fields (like auth <code>super>>fancy>>company</code>). The closer you stick to standard URI syntax, the more obvious the answers are.</li> | |
| <li>Even with <code>:version<1></code> you'll end up with the mentioned <code>> >></code> at the end of the link, which only makes it harder to read.</li> | |
| </ul> | |
| <p>Just a side node: technically, we don't want those links to be URIs, but IRIs instead. After all, we'll permit pretty much all of Unicode there as usual.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fu_GA"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-25T16:37:58Z">2023-06-25 16:37</time> | |
| </div> | |
| <div class='body'> | |
| <p>Maybe it's because I haven't been involved, but I still don't understand why the tools need to parse the <code>L<></code> link. Isn't it the job of Raku to provide the necessary and parsed data?</p> | |
| <p>For the dist/module linking, I think it needs to be standardized, so tools know what doc to show as the main document and in what order.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fvMn7"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-06-25T18:15:40Z">2023-06-25 18:15</time> | |
| </div> | |
| <div class='body'> | |
| <p>FWIW, in RakuAST, anything after the <code>|</code> in <code>L<></code> will appear in the <code>meta</code> attribute. That it didn't so far in some cases, was a bug and that has been fixed.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fvNYj"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-25T18:26:27Z">2023-06-25 18:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>Just to be clear, I mean maybe Raku should do more than extracting the link, also parse it and provide an object representing the dist/module, since Raku already supports that syntax.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fvNrU"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-25T18:32:13Z">2023-06-25 18:32</time> | |
| </div> | |
| <div class='body'> | |
| <p>@CIAvash Here's my take on your comment. (I hope I'm not stating the obvious)</p> | |
| <p>Rakudoc is a markup language that is quite neutral to the way a user will view the documentation. ('quite neutral' although it leans heavily to HTML).</p> | |
| <p>Rakudoc is eventually <strong>rendered</strong> to an output that the reader will view. So a Rakudoc <code>some text L<pointer|https://docs.raku.org/language/pod></code> will be output into HTML as</p> | |
| <pre><code>some text <a href="http://docs.raku.org/language/pod>pointer</a> | |
| </code></pre> | |
| <p>and into Markdown as</p> | |
| <pre><code>some text [pointer](http://docs.raku.org/language/pod) | |
| </code></pre> | |
| <p>and eventually into epub in an xhml version.</p> | |
| <p>Currently parses the Rakudoc into a <code>$=pod</code> tree as</p> | |
| <pre><code>[Pod::Block::Named.new(name => "pod", config => {}, contents => [Pod::Block::Para.new(config => {}, contents => ["some text ", Pod::FormattingCode.new(type => "L", meta => ["http://docs.raku.org/language/pod"], config => {}, contents => ["pointer"])])])] | |
| </code></pre> | |
| <p>It is the renderer that takes the pod block and turns it into html or markdown.</p> | |
| <p>In the future, it won't be a POD block, but an AST tree that is used by the Render. Here is the AST tree for the same file.</p> | |
| <pre><code>RakuAST::StatementList.new( | |
| RakuAST::Doc::Block.new( | |
| type => "pod", | |
| paragraphs => ( | |
| RakuAST::Doc::Paragraph.new( | |
| "some text ", | |
| RakuAST::Doc::Markup.new( | |
| letter => "L", | |
| opener => "«", | |
| closer => "»", | |
| atoms => ( | |
| "pointer", | |
| ), | |
| meta => ( | |
| "http://docs.raku.org/language/pod", | |
| ) | |
| ), | |
| "\n\n" | |
| ), | |
| ) | |
| ), | |
| ) | |
| </code></pre> | |
| <p>The current conversation is exactly about standardising the distribution / module order and what is intended by it.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fvQEB"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-25T19:05:07Z">2023-06-25 19:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>Yes, what I'm suggesting is that if Raku sees <code>L<rakumod:Some::Dist::Module:ver<1.0.0>></code> , it should generate more data in RakuDoc/RakuAST(if there won't be a pod block). So as an example:</p> | |
| <pre><code class="language-raku">RakuAST::StatementList.new( | |
| RakuAST::Doc::Block.new( | |
| type => "pod", | |
| paragraphs => ( | |
| RakuAST::Doc::Paragraph.new( | |
| "some text ", | |
| RakuAST::Doc::Markup.new( | |
| letter => "L", | |
| type => "module", # or something like that | |
| opener => "«", | |
| closer => "»", | |
| atoms => ( | |
| "Some::Dist::Module", | |
| ), | |
| meta => ( | |
| RakuAST::Doc::Module.new( | |
| dist => "Some::Dist", | |
| module => "Module", | |
| version => "1.0.0", | |
| ) | |
| ) | |
| ), | |
| "\n\n" | |
| ), | |
| ) | |
| ), | |
| ) | |
| </code></pre> | |
| <p>Again, just an example of what I mean.</p> | |
| <p>And maybe even something like <code>L<doc:language/pod></code> can be used to refer to official docs. (if their location is stable).</p> | |
| <p>And normal links continue to work as usual.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fvQSH"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-06-25T19:08:35Z">2023-06-25 19:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>Re: <code>RakuAST::Doc::Module</code>: it feels to me that this should be a more generally useful object, e.g. as a result of <code>use Some::Dist:ver<1.0.0></code>. So the name should probably not include the <code>::Doc</code> part.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fvQYk"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-25T19:10:42Z">2023-06-25 19:10</time> | |
| </div> | |
| <div class='body'> | |
| <p>Yeah, it was just for sake of example, I didn't want to emphasize on the naming.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fvQr5"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-25T19:17:25Z">2023-06-25 19:17</time> | |
| </div> | |
| <div class='body'> | |
| <p>@lizmat if I understand what you said, then <code>use Some::Distribution</code> and <code>L<xx|rakumod://Some::Distribution></code> could be more intimately linked. May be even get the data from the local installation???</p> | |
| <p>Also, for readability I prefer <code>rakumod://</code> to <code>rakumod:</code>. It is analogous to <code>file://</code> and <code>http://</code>. I accept that the <code>//</code> serve a purpose in <code>file:</code> etc, but I have never seen <code>http:</code> without a <code>http://</code></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fvVn0"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2023-06-25T19:57:44Z">2023-06-25 19:57</time> | |
| </div> | |
| <div class='body'> | |
| <p>That's because it doesn't make sense to use the HTTP protocol with something that isn't an HTTP server that's running on some host. So you will always find authority parts in HTTP URIs. You don't find them in mailto URIs like <code>mailto:foo@bar.org</code> or data URIs like <code>data:just%20a%20string</code>. You want it to be a URI? Then adhere to URI's syntax. Otherwise it is not a URI. If it just sorta, kinda looks like a URI, but really isn't, then it's just confusing.</p> | |
| <p>If the Raku parser is responsible for parsing that URI and turning it into some more capable object, then what is it supposed to do with e.g. https or file URIs?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fxE6T"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-26T05:58:08Z">2023-06-26 05:58</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>That's because it doesn't make sense to use the HTTP protocol with something that isn't an HTTP server that's running on some host. So you will always find authority parts in HTTP URIs. You don't find them in mailto URIs like <code>mailto:foo@bar.org</code> or data URIs like <code>data:just%20a%20string</code>. You want it to be a URI? Then adhere to URI's syntax. Otherwise it is not a URI. If it just sorta, kinda looks like a URI, but really isn't, then it's just confusing.</p> | |
| </blockquote> | |
| <p>I agree with the first part. I think it shouldn't be <code>rakumod://</code>, but I personally don't find <code>rakumod:</code> confusing.</p> | |
| <blockquote> | |
| <p>If the Raku parser is responsible for parsing that URI and turning it into some more capable object, then what is it supposed to do with e.g. https or file URIs?</p> | |
| </blockquote> | |
| <p>As I mentioned in my comment, they won't be treated specially, the URL will be what is inside <code>L<></code>.</p> | |
| <p>I think Raku should parse the <code>L<></code> link and create objects only when it's special. e.g. <code>rakumod:</code>, <code>rakudoc:</code> or maybe even <code>man:</code>(for manuals). And if that's not okay, maybe we should use a new code formatter for linking to documentations.</p> | |
| <p>But if others disagree with this approach, then what makes the most sense is using the URI scheme. Examples for that were given by @niner and @ugexe. another example I would add is the <a href="https://en.wikipedia.org/wiki/Magnet_URI_scheme">Magnet URI scheme</a>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fxmta"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-26T07:08:11Z">2023-06-26 07:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>One way of avoiding URI scheme and creating a new code formatter can be using <code>C<></code> inside <code>L<></code> to make it clear that we are linking to some code, but it may get verbose:</p> | |
| <pre><code class="language-raku">L<C<mod:Some::Dist:ver<1.0.0>>> | |
| L<C<mod:Some::Dist:ver<1.0.0>::Module::some_function()>> | |
| L<C<mod:Some::Dist:ver<1.0.0>::Class.some_method()>> | |
| L<C<mod:Some::Dist:ver<1.0.0>::Class.some_attribute>> | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fxtSm"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2023-06-26T07:26:41Z">2023-06-26 07:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>That's one way, but why add this complication? Links contain labels and URIs. That's easy to understand and will certainly match expectations set up by all other important formats like HTML and Markdown. URIs are the perfect way to express such links as after all they are Universal Resource Identifiers. They really can identify anything. Adding a special <code>rakumod</code> scheme is exactly how our use-case is meant to be handled by URIs. All that's really unclear is what syntax to use for those adverbs.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fxtuk"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-26T07:28:00Z">2023-06-26 07:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>For documentation ordering, I can only speak from my experience and the way I do it; I mostly put documentation inside the code, so based on that my suggestion would be:</p> | |
| <ol> | |
| <li>Look at the <code>docs</code> directory(if that's the new place to put the docs) and use the corresponding doc</li> | |
| <li>Use the README.rakudoc in <code>docs</code> directory(if the link points to the dist)</li> | |
| <li>Use doc from the Raku files(<code>.raku</code>, <code>.rakumod</code>)</li> | |
| <li>Use the README.md (or other readme files)</li> | |
| </ol> | |
| <p>One problem with this order, might be that developer used some documentation in the code, but the full documentation is in the README.md, …</p> | |
| <p>One way to solve this would be leaving it to the programmer to specify it, using the <code>=config</code> block.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fxz-V"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2023-06-26T07:42:11Z">2023-06-26 07:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>@niner I don't know, maybe you're right, but that syntax is more familiar to Raku programmers.</p> | |
| <p>Using URI scheme:</p> | |
| <pre><code class="language-raku">L<rakumod:Some::Dist?version="1.0.0"> | |
| L<rakumod:Some::Dist?version="1.0.0"&module=Module&function="some_function"> | |
| L<rakumod:Some::Dist?version="1.0.0"&class=Class&method="some_method"> | |
| L<rakumod:Some::Dist?version="1.0.0"&class=Class&attribute=some_attribute> | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f3KLY"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-26T21:34:41Z">2023-06-26 21:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>Having read through the thread, I'm somewhat baffled with a couple of things.</p> | |
| <p>First of all, I like the URI approach in general. BTW, speaking of <code>rakumod:</code> vs. <code>rakumod://</code> – this can be left out for a document writer to decide, which one is preferred for them. That's not a big deal, in my view.</p> | |
| <p>The use of standard URI arguments also appeals to me. But there is a fly in the ointment: are we going to support <code>:ver<1.0+></code>? If so then I'd hate having to remember to write it as <code>version="1.0%2B"</code> since even right now I'm not sure if the code is correct, even though I was looking for it only a couple of minutes ago.</p> | |
| <p>The other question is about the interpretation of the "host" part of URI. In <code>L<rakumod:Foo::Bar></code> – is it about a distribution, or is it about a module? <code>rakudist:Foo::Bar</code> is one solution, but multiplying schemes isn't the best of the best. I would propose the following order:</p> | |
| <ol> | |
| <li><code>rakumod:Foo::Bar</code> points to a module. If it is not part of the current distribution then we expect it to be possible to locate the distro in an index of some kind.</li> | |
| <li><code>rakumod:Foo::Bar?in="Foo"</code> to use distribution "Foo".</li> | |
| <li><code>rakumod:Foo?module="Foo::Bar"</code> is the same, but it may have different meaning in a very specific case.</li> | |
| <li><code>rakumod:Foo::Bar?dist</code> is for cases when a distribution a module of the same name and we want to be explicit about linking to the distro. Useful for, say, pointing out to a download page. 'dist' could be aliased 'distribution' for purists sake. ;)</li> | |
| </ol> | |
| <p>Speaking of the difference between 2 and 3, it could play a role for a rare but not impossible case when a module has versions different from those on the distribution. Since we do not prohibit such discrepancies then they are allowed. In this case <code>rakumod:Foo::Bar?in="Foo"&ver="1.0"</code> would be about <code>Foo::Bar:ver<1.0></code> in the distribution <code>Foo</code>. Apparently, <code>rakumod:Foo?module="Foo::Bar"&ver=1.2"</code> is a link to distribution <code>Foo:ver<1.2></code>.</p> | |
| <p>Speaking of the advantages of using URI-complient meta, the arguments not used to select module/distribution version can be bypassed to the final link. If translated into a URL the arguments would be submitted to a web server.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f3TBJ"> | |
| <div class='header'> | |
| <span class='author'>@ugexe</span> commented at <time datetime="2023-06-26T21:47:25Z">2023-06-26 21:47</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>are we going to support :ver<1.0+>?</p> | |
| </blockquote> | |
| <p>I wouldn't think so. There isn't really anything it could link to that makes a lot of sense.</p> | |
| <blockquote> | |
| <p>rakumod:Foo::Bar?in="Foo" to use distribution "Foo".</p> | |
| </blockquote> | |
| <p>The only issue here is that the distribution always exists, but modules may not. For instance: a distribution that provides all of its functionality / code inside of a <code>bin/myapp</code> file.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f3db2"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-26T21:58:31Z">2023-06-26 21:58</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>are we going to support :ver<1.0+>?</p> | |
| </blockquote> | |
| <p>I wouldn't think so. There isn't really anything it could link to that makes a lot of sense.</p> | |
| </blockquote> | |
| <p>Not exactly. Say, I have a dependency with the same version mask and would like to link to the same version. But considering what may go wrong here, I wouldn't mind if this feature remains missing.</p> | |
| <blockquote> | |
| <blockquote> | |
| <p>rakumod:Foo::Bar?in="Foo" to use distribution "Foo".</p> | |
| </blockquote> | |
| <p>The only issue here is that the distribution always exists, but modules may not. For instance: a distribution that provides all of its functionality / code inside of a <code>bin/myapp</code> file.</p> | |
| </blockquote> | |
| <p>Are links pointing to nowhere is a big surprise to you? ;) I tend to check as many links in my docs as possible. In the future we may get a linter for Rakudoc too.</p> | |
| <p>Either way, we talk about documentation, not modules themselves. <code>rakumod:Foo::Bar?in="Foo"</code> could eventually lead me to <code>doc/Foo/Bar.rakudoc</code>, or to a render of it.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f3pNZ"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-26T22:49:06Z">2023-06-26 22:49</time> | |
| </div> | |
| <div class='body'> | |
| <p>I am unclear what to think about the complex syntax for distributions and modules. I think that the links are not to modules themselves, but to documentation about the distribution / modules. Locations within a document are not necessarily the names of classes/roles/sub etc, but are anchors defined by <code>=head</code> or <code>X<></code> markup. A heading might be eg a <code>sub</code> name, but that is a writers choice.</p> | |
| <p>If a link is expected to resolve to an HTML page, then the actual page served will depend on the server site.</p> | |
| <p>@ugexe are you against the <code>+</code> in the <code>ver<2.1+></code> ? If documentation changes between versions, I can see the need for <code>ver<2.1></code>, but not for <code>+</code>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f33N7"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-26T23:50:53Z">2023-06-26 23:50</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I think that the links are not to modules themselves, but to documentation about the distribution / modules.</p> | |
| </blockquote> | |
| <p>You're right. But to resolve a link to a module we'd need to locate its distribution. This could be especially relevant for local offline documentation browsers when they'd need to search through local caches.</p> | |
| <p>The point about module version vs. distribution version could be especially confusing. <code>:api</code> versioning could serve even better example to get the point. Imagine a distribution <code>Foo</code> where <code>Foo::Bar</code> module provides very conservative API which version could lag behind distro's API. Say, there is something like <code>"api": "1.5",</code> in META6, but <code>module Foo::Bar:api<1.1>;</code>. In this case, having <code>use Foo::Bar:api<1.1>;</code> in one's sources would naturally translate into <code>L<rakumod:Foo::Bar?api="1.1"></code> in the docs. The developer wouldn't care in which <code>Foo</code> distribution version the destination page is found as long as it documents the requested API version.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5f4VLq"> | |
| <div class='header'> | |
| <span class='author'>@ugexe</span> commented at <time datetime="2023-06-27T02:14:59Z">2023-06-27 02:14</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>@ugexe are you against the + in the ver<2.1+> ?</p> | |
| </blockquote> | |
| <p>There is nothing inherently wrong with including it, but I do think it will increase the complexity quite a bit since it now implies tooling needs methods of resolving these types of queries in the same way raku would (i.e. use the same sort order). I suppose if such a link did exist I would expect it to go to the latest distribution that is greater than 2.1 (similar to requesting a document without a version at all probably implies the latest version)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5gJjX-"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-06-29T12:45:44Z">2023-06-29 12:45</time> | |
| </div> | |
| <div class='body'> | |
| <p>Rather than <code>rakumod:</code> perhaps it should be <code>rakudoc:</code> ? This would signal clearly that the link is to documentation, and not to code.</p> | |
| <p>It also implies that the documentation may be found in a <code>.rakudoc</code> or <code>.rakumod</code> file.</p> | |
| <p>It also means that the link is to sources written in <strong>Rakudoc</strong> and not just sources written in <strong>raku</strong>, which is possible because there are non-raku implementations of POD6 and hopefully of Rakudoc.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5gMBTn"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-06-29T20:22:55Z">2023-06-29 20:22</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Rather than <code>rakumod:</code> perhaps it should be <code>rakudoc:</code> ?</p> | |
| </blockquote> | |
| <p>Makes sense to me.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="372"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/372"><span class='number'>372</span></a> - <span class='title'>Are Captures value types or not?</span></div> | |
| <div class='author'>[open]<span class='author'>@lizmat</span> opend this issue at <time datetime="2023-06-20T08:47:59Z">2023-06-20 08:47</time></div> | |
| </div> | |
| <div class='body'> | |
| <p><code>Capture</code> instances are currently implemented as being a value type (basically since https://github.com/rakudo/rakudo/commit/c855a0f439 ).</p> | |
| <p>However, since https://github.com/Raku/old-issue-tracker/issues/4360 it has made elements of it mutable (if they were created with containers).</p> | |
| <p>If an element in a <code>Capture</code> is changed, it's associated <code>.WHICH</code> will also change. This violates the principle of immutability of value types.</p> | |
| <p>Making <code>Capture</code> instances immutable, breaks spectests. | |
| Making the <code>Capture</code> class an object type, also breaks spectests.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5fRUPO"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-06-20T08:50:54Z">2023-06-20 08:50</time> | |
| </div> | |
| <div class='body'> | |
| <p>Propose to:</p> | |
| <ul> | |
| <li>keep <code>Capture</code> being a value type</li> | |
| <li>disallow mutations in the object (remove <code>is raw</code> from <code>AT-POS</code> / <code>AT-KEY</code>)</li> | |
| <li>adapt spectests accordingly</li> | |
| </ul> | |
| <p>Ideally to be done with a language level check, but I think that will turn out to be pretty hard to do.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fRkwA"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2023-06-20T09:34:33Z">2023-06-20 09:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>The primary purpose of <code>Capture</code> in the language is to model an argument list, and arguments may be mutated by <code>is rw</code> parameters. For example, consider:</p> | |
| <pre><code>sub foo($p is rw) { | |
| $p++; | |
| } | |
| my $x = 1; | |
| my \c = \($x); | |
| foo(|c); | |
| say c; | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fRlVL"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-06-20T09:36:08Z">2023-06-20 09:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>@jnthn So then it shouldn't be a value type then?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fRszb"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2023-06-20T09:57:26Z">2023-06-20 09:57</time> | |
| </div> | |
| <div class='body'> | |
| <p>Correct, although it'd make sense for snapshot equality (<code>eqv</code>) to work.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="371"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/371"><span class='number'>371</span></a> - <span class='title'>Trailing declarator docs semantics need to be revisited</span></div> | |
| <div class='author'>[closed]<span class='author'>@lizmat</span> opend this issue at <time datetime="2023-05-18T10:43:30Z">2023-05-18 10:43</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>S26 states:</p> | |
| <blockquote> | |
| <p>Declarator blocks that start with C<#=> attach to the declarator declared at the start of the line immediately before them.</p> | |
| </blockquote> | |
| <p>Seems pretty clear cut, now doesn't it. However, the current implementation is way too lenient in attaching, and sometimes attaches to objects one might not expect. Some examples. Please note that all of these examples have been distilled from actual spectests! :-(</p> | |
| <pre><code class="language-raku">class A { | |
| has $.a; has $.b; #= trailing | |
| } | |
| </code></pre> | |
| <p>So, does the trailing doc attach to <code>$.a</code> or <code>$.b</code>? It attaches to <code>$.a</code>!</p> | |
| <pre><code class="language-raku">sub six(Str $param1, Str $param2) { | |
| #= trailing comment for six? | |
| } | |
| </code></pre> | |
| <p>So does this attach to the <code>sub six</code>? Or to <code>$param2</code>. It attaches to the sub, whereas <code>$param2</code> is the last object seen that can have declarator doc.</p> | |
| <pre><code class="language-raku">sub a { } | |
| ... many lines of code without declarable objects | |
| #= still attaches to &a | |
| </code></pre> | |
| <p>The trailing declarator can be <em>many</em> lines after the object it attaches to, if there's nothing declarable inbetween. This violates S26.</p> | |
| <p>Another example, where trailing docs are before the leading docs:</p> | |
| <pre><code class="language-raku">sub four {} | |
| #| before five | |
| #= after four | |
| sub five {} | |
| </code></pre> | |
| <p>I think this should at least be a worry, as this may indicate a mixup on leading/trailing doc, or a copy-pasto.</p> | |
| <p>And a more general issue, that could be considered a bug:</p> | |
| <pre><code class="language-raku">sub a { | |
| #= foo bar | |
| } | |
| </code></pre> | |
| <p>That actually attaches the trailing doc to <code>sub a</code>. But the object that lives in <code>$=pod</code>'s is <em>not</em> complete: its <code>WHEREFORE</code> is <code>Any</code>, <strong>unless</strong> you call <code>&a.WHY</code> after which it will be correct. But that's not very useful for rakudoc renderers, as it won't be able to see to what the pod applies to.</p> | |
| <p>I think we should have clearer rules on what the exact semantics are, and have more worries issued in situations where it would be unclear to which object a trailing doc should be attached to.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5ck2ap"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-05-18T14:38:04Z">2023-05-18 14:38</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <pre><code class="language-raku">sub six(Str $param1, Str $param2) { | |
| #= trailing comment for six? | |
| } | |
| </code></pre> | |
| <p>So does this attach to the sub six? Or to $param2. It attaches to the sub, whereas $param2 is the last object seen that can have declarator doc.</p> | |
| <pre><code></code></pre> | |
| </blockquote> | |
| <p>I think, unless we make it an error, attaching to the <code>sub</code> is sufficiently logical. The parameters belong to the signature's visual context, i.e. enclosed in parentheses, whereas the pod already belongs to the block context.</p> | |
| <p>But this is the only note I have. Because making this particular case an error would make better sense. As well as the other proposals too.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5c3fHu"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2023-05-22T21:37:09Z">2023-05-22 21:37</time> | |
| </div> | |
| <div class='body'> | |
| <p>For what it's worth, I've used the</p> | |
| <pre><code>sub foo($a, $b) { | |
| #= description of foo | |
| } | |
| </code></pre> | |
| <p>In some of my code. I would be genuinely surprised (akin to the <code>my $a; my $b; #= attaches to $a</code> issue) if it didn't. Justification can come from the idea that the declaration of the parameters occurs inside the signature, and so is opaque to the trailing comment which effectively only sees <code>sub foo(…) { … }</code> and thus attaches accordingly.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5c6Ndy"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-05-23T08:15:42Z">2023-05-23 08:15</time> | |
| </div> | |
| <div class='body'> | |
| <p>But that implies some kind of scoping and style semantics: would the trailing declarator doc also apply to the sub in this case?</p> | |
| <pre><code class="language-raku">sub foo( | |
| $a, | |
| $b | |
| ) { | |
| #= description of foo | |
| } | |
| </code></pre> | |
| <p>At the grammar level, there's no functional difference between the two. The only way to make the difference, is to start looking at line numbers. And that becomes very fragile very quickly.</p> | |
| <p>Another solution might be to deprecate trailing declarator doc altogether?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5fROQy"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-06-20T08:33:29Z">2023-06-20 08:33</time> | |
| </div> | |
| <div class='body'> | |
| <p>At the RSC it was decided that the <em>last</em> declarator seen, will be used for attaching trailing declarator doc.</p> | |
| <p>Also that the declarator doc needs to start on the same line as the declarator, or at the start of the line immediately after that. This has now been implemented in RakuAST, and spectests have been adapted accordingly.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5gCMW3"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2023-06-28T10:53:00Z">2023-06-28 10:53</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>At the RSC it was decided that the <em>last</em> declarator seen, will be used for attaching trailing declarator doc.</p> | |
| </blockquote> | |
| <p>Whelp, time for me to update a bunch of modules lol. But it's good that some standard has been set so it's clear how it will be handled.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="370"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/370"><span class='number'>370</span></a> - <span class='title'>A way around "multi-level classification"</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2023-04-22T00:50:28Z">2023-04-22 00:50</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>A sister issue of https://github.com/Raku/doc/issues/4293.</p> | |
| <p>The capability of multi-level classification is nice but sometimes, it would be good to really just use an <code>Iterable</code> as a key of a flat <code>Hash</code>. It seems too broad to lose all control of the otherwise default behavior by introducing <code>Iterable</code>s in the classification.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5agbNE"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-04-22T00:53:04Z">2023-04-22 00:53</time> | |
| </div> | |
| <div class='body'> | |
| <p>A couple of ideas:</p> | |
| <ul> | |
| <li>an "adverb" to control multi-level classification; either opt-in or opt-out</li> | |
| <li>draw a distinction using containers (or conceptually rather itemization)</li> | |
| <li>draw a distinction using <code>Slip</code>s</li> | |
| </ul> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="369"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/369"><span class='number'>369</span></a> - <span class='title'>Provide `sort` with `:k` adverb (returns ordinal index)</span></div> | |
| <div class='author'>[open]<span class='author'>@jubilatious1</span> opend this issue at <time datetime="2023-04-11T21:41:36Z">2023-04-11 21:41</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Similar to issue posted by @0rir (and comment by @0racle):</p> | |
| <h3>Provide <code>sort</code> with <code>:k</code> adverb (returns ordinal index)</h3> | |
| <p>Sometimes you don't need the values of a data structure returned in correct <code>sort</code> order--sometimes you just need the correct <code>order</code> (ordinal index) of those elements.</p> | |
| <p>In the R-programming language, you get two different functions to accomplish these tasks, <code>sort</code> and <code>order</code>:</p> | |
| <p>https://web.mit.edu/~r/current/lib/R/library/base/html/sort.html</p> | |
| <p>https://web.mit.edu/~r/current/lib/R/library/base/html/order.html</p> | |
| <p>Thx.</p> | |
| <hr /> | |
| <blockquote> | |
| <p>Putting my hand up as someone who has wanted <code>min</code>/<code>max</code> with <code>:k</code>.</p> | |
| <p>The ~~adverbs~~ named args should be similar to <code>first</code>, ie. <code>:v</code> just returns the value (default), <code>:k</code> returns the index, <code>:kv</code> returns a Seq of the index and value, and <code>:p</code> returns a Pair of the index and value.</p> | |
| </blockquote> | |
| <p><em>Originally posted by @0racle in https://github.com/Raku/problem-solving/issues/367#issuecomment-1499720683</em></p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5ZqDog"> | |
| <div class='header'> | |
| <span class='author'>@jubilatious1</span> commented at <time datetime="2023-04-11T22:15:24Z">2023-04-11 22:15</time> | |
| </div> | |
| <div class='body'> | |
| <p>Sampling/ordering code from the R-programming language, within the R-REPL:</p> | |
| <pre><code class="language-r">> samp1 <- sample(1:10, 10) | |
| > samp1 | |
| [1] 3 4 6 1 9 10 8 7 2 5 | |
| > order(samp1) | |
| [1] 4 9 1 2 10 3 8 7 5 6 | |
| > | |
| </code></pre> | |
| <p>Above, taking the <code>order()</code> of the <code>samp1</code> vector with the code <code>order(samp1)</code>:</p> | |
| <ul> | |
| <li> | |
| <p>Returns <code>4</code> in the first position, telling you that the lowest numeric value in <code>samp1</code> is in one-indexed position <code>4</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>1</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>9</code> in the second position, telling you that the second-lowest numeric value in <code>samp1</code> is in one-indexed position <code>9</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>2</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>1</code> in the third position, telling you that the third-lowest numeric value in <code>samp1</code> is in one-indexed position <code>1</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>3</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>2</code> in the fourth position, telling you that the fourth-lowest numeric value in <code>samp1</code> is in one-indexed position <code>2</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>4</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>10</code> in the fifth position, telling you that the fifth-lowest numeric value in <code>samp1</code> is in one-indexed position <code>10</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>5</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>3</code> in the sixth position, telling you that the sixth-lowest numeric value in <code>samp1</code> is in one-indexed position <code>3</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>6</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>8</code> in the seventh position, telling you that the seventh-lowest numeric value in <code>samp1</code> is in one-indexed position <code>8</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>7</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>7</code> in the eighth position, telling you that the eighth-lowest numeric value in <code>samp1</code> is in one-indexed position <code>7</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>8</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>5</code> in the ninth position, telling you that the ninth-lowest numeric value in <code>samp1</code> is in one-indexed position <code>5</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>9</code>).</p> | |
| </li> | |
| <li> | |
| <p>Returns <code>6</code> in the tenth position, telling you that the tenth-lowest numeric value in <code>samp1</code> is in one-indexed position <code>6</code> of the original <code>samp1</code> vector. (In this case, that value equals <code>10</code>).</p> | |
| </li> | |
| </ul> | |
| <hr /> | |
| <p>Meaning you can reorder the <code>samp1</code> vector ( <em><strong>or any other vector of identical length</strong></em>) based upon the index-output of <code>order(samp1)</code>:</p> | |
| <pre><code class="language-r">> samp1[order(samp1)] | |
| [1] 1 2 3 4 5 6 7 8 9 10 | |
| > | |
| </code></pre> | |
| <p>https://web.mit.edu/~r/current/lib/R/library/base/html/sort.html</p> | |
| <p>https://web.mit.edu/~r/current/lib/R/library/base/html/order.html</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ZqnJ4"> | |
| <div class='header'> | |
| <span class='author'>@0racle</span> commented at <time datetime="2023-04-12T00:42:38Z">2023-04-12 00:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>Since I was quoted, I also think this feature would be useful. Notably, APL - which Larry was influenced by - does not have a <em>Sort</em> primitive, but it does have a <em>Grade</em> primitive that does exactly this</p> | |
| <pre><code class="language-apl"> ⍋ 3 4 6 1 9 10 8 7 2 5 | |
| 4 9 1 2 10 3 8 7 5 6 | |
| </code></pre> | |
| <p>So in APL (and it's decedents) Grade is seen as a more fundamental primitive, from which you can derive Sort. All this is to say that this concept of Grade (or <em>Order</em>) is useful in other algorithms (not just sort), and while it's possible (<code>*.pairs.sort(*.value)».key</code> is one way), having a simple <code>:k</code> option would be nice.</p> | |
| <p>Of course, unlike APL and R, Raku's indices would be 0-based, such that <code>@xs.sort ≡ @xs[@xs.sort(:k)]</code>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ZtGL2"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-04-12T09:56:08Z">2023-04-12 09:56</time> | |
| </div> | |
| <div class='body'> | |
| <p>FWIW, if a sort is done with a Callable with a single positional argument, the list with indices basically already exists internally as part of the Schwartzian transform. So it looks to me that support for :k, :kv, :p could be easily derived by forcing a Schwarrtzian transform, and post-processing the indices list.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="368"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/368"><span class='number'>368</span></a> - <span class='title'>LinkedIn does not recognize "Raku Developer" as a job title.</span></div> | |
| <div class='author'>[open]<span class='author'>@bbkr</span> opend this issue at <time datetime="2023-04-01T14:38:19Z">2023-04-01 14:38</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>In LinkedIn when setting up "open to work" one has to choose job title. This title must be preselected - "Perl Developer" is present, but "Raku Developer" is nowhere to be found.</p> | |
| <p>It may be good idea to contact LinkedIn to add "Raku Developer" as an option.</p> | |
| <p>BTW: This issue is not about top search bar. This is about window where you set jobs that you are interested in.</p> | |
| </div> | |
| <div class='comments'> | |
| </div> | |
| </div> | |
| <div class='issue' id="367"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/367"><span class='number'>367</span></a> - <span class='title'>Add :k option to min and max</span></div> | |
| <div class='author'>[open]<span class='author'>@0rir</span> opend this issue at <time datetime="2023-03-27T21:32:30Z">2023-03-27 21:32</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>This is feature request for the addition of a <code>:k</code> option for appropriate types; <code>map</code> being the model.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5YmkSy"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-03-28T09:19:15Z">2023-03-28 09:19</time> | |
| </div> | |
| <div class='body'> | |
| <p>If I understand it correctly, you want it to produce the ordinal numbers of any matches?</p> | |
| <p>Could you give some code examples and expected result?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5YmnOg"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2023-03-28T09:27:47Z">2023-03-28 09:27</time> | |
| </div> | |
| <div class='body'> | |
| <p>I figure it's about the list case of <code>min</code>, so <code>[4,1,2,-6,10].min(:k)</code> would evaluate to <code>3</code>, the index of the minimum element. While it's not mentioned, I imagine <code>:kv</code> and <code>:p</code> are implied by this request too.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5YoYkV"> | |
| <div class='header'> | |
| <span class='author'>@0rir</span> commented at <time datetime="2023-03-28T14:16:37Z">2023-03-28 14:16</time> | |
| </div> | |
| <div class='body'> | |
| <p>@lizmat, @jnthn, you both are entirely correct in what you say. | |
| I would have done better to reference <code>@a.first( @a.min)</code> as <code>:end</code> is also applicable.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5YpYV6"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-03-28T16:26:13Z">2023-03-28 16:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>And I guess if there are multiple minimum / maximum values, it would produce multiple indices.</p> | |
| <p>@0rir I'm not sure how <code>:end</code> comes into play here?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5YpeI0"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2023-03-28T16:43:26Z">2023-03-28 16:43</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>And I guess if there are multiple minimum / maximum values, it would produce multiple indices.</p> | |
| </blockquote> | |
| <p>Only if <code>min</code>/<code>max</code> have an option to do that already; otherwise, I'd keep it consistent with the value result.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5YqrX4"> | |
| <div class='header'> | |
| <span class='author'>@0rir</span> commented at <time datetime="2023-03-28T20:58:13Z">2023-03-28 20:58</time> | |
| </div> | |
| <div class='body'> | |
| <p>My thinking was to keep the return to the value element, the index or both in a <code>Pair</code>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ZY-vr"> | |
| <div class='header'> | |
| <span class='author'>@0racle</span> commented at <time datetime="2023-04-06T22:47:19Z">2023-04-06 22:47</time> | |
| </div> | |
| <div class='body'> | |
| <p>Putting my hand up as someone who has wanted <code>min</code>/<code>max</code> with <code>:k</code>.</p> | |
| <p>The ~~adverbs~~ named args should be similar to <code>first</code>, ie. <code>:v</code> just returns the value (default), <code>:k</code> returns the index, <code>:kv</code> returns a Seq of the index and value, and <code>:p</code> returns a Pair of the index and value.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="366"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/366"><span class='number'>366</span></a> - <span class='title'>`next`, `last`, `redo` shouldn't fall through subroutines</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2023-03-08T11:18:36Z">2023-03-08 11:18</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Inspired by https://github.com/Raku/doc/issues/4255 because it seems like this is an unnecessary trap to work with.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>The <a href="https://design.raku.org/S04.html#The_Relationship_of_Lexical_and_Dynamic_Scopes">synopses actually do mention</a> the dynamic nature of a bare <code>next</code> (as opposed to a labelled <code>next</code>, for example) - however, this doesn't appear anywhere in <a href="https://github.com/Raku/roast/blob/master/S04-statements/next.t">the corresponding file of the specification</a>.</p> | |
| <p>In Raku, one can declare a <code>Block</code> that will act just like an actual inline block, including <code>next</code> behavior. <code>Sub</code>s have their own <code>return</code>. Implimentation differences aside (between <code>return</code> and <code>next</code> or <code>last</code>, that is), it really seems like a trap that <code>next</code> and the likes might implicitly have a broader scope of action than <code>return</code>, hence implicitly returning from a subroutine much "harder" than the actual <code>return</code> would.</p> | |
| <p>If somebody wants the fall-through behavior by default, chances are they don't need/want the tight <code>return</code> a <code>Sub</code> provides and they should really be thinking about using a <code>Block</code>. The code will also get clearer if a subroutine is really a lexical unit with the default control structures.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5XBiYk"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-03-08T11:29:14Z">2023-03-08 11:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>My proposal would be to keep control exceptions like the ones <code>next</code> and <code>last</code> create, inside <code>Sub</code>s, hence throwing a similar exception to a legitimately missing loop to iterate.</p> | |
| <p>If somebody prefers the former (perhaps unspecified?) behavior:</p> | |
| <ul> | |
| <li>they can specify a CONTROL phaser to pass it through anyway</li> | |
| <li>I don't know how you feel about pragmas but there could be one to set the behavior for one <code>Sub</code> or the whole <code>CompUnit</code>, for example</li> | |
| </ul> | |
| <p>The topic of performance also came up from @lizmat . My stance on that is (besides the general sentiment of "it's better to be right slowly than wrong quickly"): the implementation doesn't need to be fast <em>immediately</em>. Loads of control structure optimizations will be available with RakuAST - in fact, most of the time, we could say it at compile time if an invalid <code>next</code> is used in a subroutine, by traversing from the usage of <code>next</code> towards the root <code>Sub</code>. At the very least, we can omit special handling when it's clear that there are no such control statements, or they are clearly scoped in a loop inside the <code>Sub</code>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XCddJ"> | |
| <div class='header'> | |
| <span class='author'>@cfa</span> commented at <time datetime="2023-03-08T14:40:25Z">2023-03-08 14:40</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The <a href="https://design.raku.org/S04.html#The_Relationship_of_Lexical_and_Dynamic_Scopes">synopses actually do mention</a> the dynamic nature of a bare <code>next</code> (as opposed to a labelled <code>next</code>, for example) - however, this doesn't appear anywhere in <a href="https://github.com/Raku/roast/blob/master/S04-statements/next.t">the corresponding file of the specification</a>.</p> | |
| </blockquote> | |
| <p>See https://github.com/Raku/roast/blob/master/S04-statements/last.t#L31-L39 for <code>last</code>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XDPCH"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-03-08T16:33:15Z">2023-03-08 16:33</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>The <a href="https://design.raku.org/S04.html#The_Relationship_of_Lexical_and_Dynamic_Scopes">synopses actually do mention</a> the dynamic nature of a bare <code>next</code> (as opposed to a labelled <code>next</code>, for example) - however, this doesn't appear anywhere in <a href="https://github.com/Raku/roast/blob/master/S04-statements/next.t">the corresponding file of the specification</a>.</p> | |
| </blockquote> | |
| <p>See https://github.com/Raku/roast/blob/master/S04-statements/last.t#L31-L39 for <code>last</code>.</p> | |
| </blockquote> | |
| <p>I think this is the right place for design decisions anyway - so then the amendment woud be: introduce this in a new version, and modify the corresponding test.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XGChq"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2023-03-09T03:07:50Z">2023-03-09 03:07</time> | |
| </div> | |
| <div class='body'> | |
| <p>Hmm, my (tentative) thought is that the current behavior is reflects the correct design. A different way to phase this issue would be "<code>next</code>, <code>last</code>, and <code>redo</code> should have lexical scope rather than dynamic scope". But, phrased like that, I'm slightly inclined to disagree – it's very clear that <code>gather</code> is supposed to have dynamic scope, and <code>next</code>/<code>last</code>/<code>redo</code> "feel" similar enough to <code>gather</code> that I'm inclined to think that keeping their behavior consistent is the better design.</p> | |
| <p>On the other hand, lexical scope is more familiar to most programmers and I don't have <em>strong</em> feelings on the matter. So I'm certainly open to persuasion.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XJ0Mt"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-03-09T14:50:17Z">2023-03-09 14:50</time> | |
| </div> | |
| <div class='body'> | |
| <p>Just an example:</p> | |
| <pre><code class="language-raku">sub transform($v) { | |
| next if $v.contains("2"); | |
| "<$v>" | |
| } | |
| say (^20).map(&transform); | |
| </code></pre> | |
| <p>Even the <code>.map({...})</code> form is a good demonstration because the code block just cannot be in the same lexical scope where the iteration logic is located.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XJ12G"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2023-03-09T14:54:42Z">2023-03-09 14:54</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Even the <code>.map({...})</code> form is a good demonstration because the code block just cannot be in the same lexical scope where the iteration logic is located.</p> | |
| </blockquote> | |
| <p>Well, it <em>can</em>:</p> | |
| <pre><code class="language-raku">say (^20).map({ | |
| next if .contains("2"); | |
| "<$_>" | |
| }); | |
| </code></pre> | |
| <p>But, more generally, I agree that there are times when a dynamic scope to <code>next</code> is useful/clearer.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XJ2rG"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-03-09T14:56:50Z">2023-03-09 14:56</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Well, it <em>can</em>:</p> | |
| </blockquote> | |
| <p>You missed the point. The actual iterator logic is in <code>map</code> lexical scope, actually. :)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XMjOQ"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-03-09T22:20:39Z">2023-03-09 22:20</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Even the .map({...}) form is a good demonstration because the code block just cannot be in the same lexical scope where the iteration logic is located.</p> | |
| </blockquote> | |
| <p>The <code>.map({...})</code> form uses a <code>Block</code>, not a <code>Sub</code>. I'm not arguing against this behavior for a <code>Block</code> but a <code>Sub</code>. And consequently, that example looks like a good illustration of what I find confusing without any benefits.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XM_wS"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-03-10T00:17:27Z">2023-03-10 00:17</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>A different way to phase this issue would be "next, last, and redo should have lexical scope rather than dynamic scope"</p> | |
| </blockquote> | |
| <p>I don't think this reflects the <code>Block</code> vs <code>Sub</code> distinction. It's super useful and also fairly reasonable that a <code>Block</code> is transparent to all control structures. It could even look up all variables dynamically - I can imagine why that might be a bad idea but it could also make some sense. However, to have a subroutine that can be safely used as an independent unit of execution, is a different story.</p> | |
| <blockquote> | |
| <p>it's very clear that gather is supposed to have dynamic scope, and next/last/redo "feel" similar enough to gather that I'm inclined to think that keeping their behavior consistent is the better design.</p> | |
| </blockquote> | |
| <p>It seems to me that both statements can be challenged. I do think that <code>take</code> could also be taken as a cunning implicit callback and be subject to evalutation whether it's really worth it to let it slip through subroutines. However, let me point out that <code>take</code> does indeed have more of a callback interface that <code>next</code>, <code>last</code> and the likes don't have, and maybe for the better:</p> | |
| <pre><code class="language-raku">use v6.*; # To enforce next, last with return values | |
| gather for (1..10) { .take } # This is going to work | |
| (1..10).map: { .next } # This won't - has to use `next $_` | |
| (1..10).map: { .last } # This also won't - has to use `last $_` | |
| </code></pre> | |
| <p>Now, of course those control statements could be adopted to also have the OO-looking interface - which is also a modification that might interfere with existing code, and then we can still ask if it's really expressive or just confusing.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XNXcm"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2023-03-10T02:19:57Z">2023-03-10 02:19</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I'm not arguing against this behavior for a Block but a Sub.</p> | |
| </blockquote> | |
| <p>IMO having this behavior differ between Blocks and Subs would be <em>highly</em> confusing.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XNsig"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-03-10T03:42:43Z">2023-03-10 03:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>@2colours:</p> | |
| <blockquote> | |
| <p>The <code>.map({...})</code> form uses a <code>Block</code>, not a <code>Sub</code>. I'm not arguing against this behavior for a <code>Block</code> but a <code>Sub</code>. And consequently, that example looks like a good illustration of what I find confusing without any benefits.</p> | |
| </blockquote> | |
| <p>Are you sure about no benefits? I consider the <code>transform</code> sub from my example to be very beneficial as means of code clarification and organization. <code>.map(&transform)</code> (or <code>.map: &transform</code>) seems to be way more self-explanatory than using a block with all the same logic <code>transform</code> provides. Basically, the routine should've be named <code>transform-and-filter</code> for the full clarity of it.</p> | |
| <p>@codesections:</p> | |
| <blockquote> | |
| <p>IMO having this behavior differ between Blocks and Subs would be <em>highly</em> confusing.</p> | |
| </blockquote> | |
| <p>Not exactly. Think of <code>return</code> which is <code>routine</code>-scoped, so to say. The other point is that its semantics greatly differs from that of <code>next</code> and its "kins".</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XO6nV"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-03-10T09:35:48Z">2023-03-10 09:35</time> | |
| </div> | |
| <div class='body'> | |
| <p>Just to throw in another code example that could potentially confuse me:</p> | |
| <pre><code>for @lists -> $x { | |
| $x.map({ process($_); next if !$_ } | |
| } | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XSerm"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-03-10T20:57:05Z">2023-03-10 20:57</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>IMO having this behavior differ between Blocks and Subs would be highly confusing.</p> | |
| </blockquote> | |
| <p>Well, what can I say, I think this is <em>the whole point <code>Block</code>s exist in the first place</em> - to represent a piece of code with a scope that can be abstracted away while still providing inlining semantics. I can't see why this would be confusing - rather than <code>Sub</code> sometimes mimicking inlined behavior, by implicitly passing control flow back to the caller...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XS539"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-03-10T22:35:51Z">2023-03-10 22:35</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The other point is that its semantics greatly differs from that of next and its "kins".</p> | |
| </blockquote> | |
| <p>Well, does it? Are they not all pragmatisms over structural code, sort of jumps that are at least guaranteed to be tied to certain control structures? I would say <code>return</code> and <code>next</code> are much more alike than <code>take</code> and <code>next</code> - I wonder if <code>take</code> is considered a control statement to begin with, it's not obvious at least. By semantics, it's much more like a callback.</p> | |
| <p>Also, food for thought: <a href="https://design.raku.org/S04.html#The_Relationship_of_Lexical_and_Dynamic_Scopes">linked part of synopsis</a> also says <code>For instance, next with a label will prefer to exit a loop lexotically</code> - and this is present in the current workings as well. <code>next BAR</code> isn't going to fall through anything but a bare <code>next</code> will - does this inconsistency seem as good as it did back when this language was going to be the new Perl?<br /> | |
| Also, if one does want the fallback behavior for a subroutine, it could still be made explicit, right? I have mentioned the idea of a pragma but at the end of the day, I wouldn't oppose something like <code>next *</code> either. The asterisk even plays nice with the symbolics of dynamic behavior.</p> | |
| <blockquote> | |
| <p><code>.map(&transform)</code> (or <code>.map: &transform</code>) seems to be way more self-explanatory than using a block with all the same logic transform provides</p> | |
| </blockquote> | |
| <p>I'm afraid this is a "let's agree to disagree" situation - that seems to me like a misuse of a subroutine. To me, it breaks the expectations of a subroutine - the expectation that a successfully executed subroutine won't interfere with the code of the caller - after all, that's part of the reason why I abstracted it away with a subroutine and not a <code>Block</code>, right?<br /> | |
| It can actually lead to weird thoughts: what return value does that subroutine even have? After all, <code>next</code> is not a callback, and indeed it terminates the control flow of the subroutine in the first place. Indeed, it behaves like an exception, without looking like one.</p> | |
| <blockquote> | |
| <p>Just to throw in another code example that could potentially confuse me:</p> | |
| <pre><code>for @lists -> $x { | |
| $x.map({ process($_); next if !$_ } | |
| } | |
| </code></pre> | |
| </blockquote> | |
| <p>@patrickbkr Could you please elaborate? Because here the <code>for</code> loop seems superfluous. So far, I haven't seen anybody questioning that <code>map</code>˙implies a loop, therefore all possible uses would hook up there, if anywhere.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="365"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/365"><span class='number'>365</span></a> - <span class='title'>Spectesting is a minefield</span></div> | |
| <div class='author'>[open]<span class='author'>@lizmat</span> opend this issue at <time datetime="2023-02-07T11:39:46Z">2023-02-07 11:39</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Spectesting is a version minefield at the moment:</p> | |
| <pre><code>% rak '^use v6' t/spec --frequencies | |
| 1758:use v6; | |
| 30:use v6.c; | |
| 22:use v6.e.PREVIEW; | |
| 14:use v6.d; | |
| </code></pre> | |
| <p>A more precise:</p> | |
| <pre><code>% rak '{ "t/spec/$/" if .match(/^ <-[#]+[\S]>+ /) }' --/show-item-number t/spec/spectest.data | rak --files-from=- '^use v6' --frequencies | |
| 1332:use v6; | |
| 17:use v6.c; | |
| 14:use v6.e.PREVIEW; | |
| 9:use v6.d; | |
| </code></pre> | |
| <p>So this shows several issues that each may need a different problem solving issue.</p> | |
| <ol> | |
| <li> | |
| <p>there are <em>many</em> files in roast that are not actually being part of the spectest. Maybe these should be removed from roast or parked in a "archived" branch?</p> | |
| </li> | |
| <li> | |
| <p>The use of <code>use v6xxx</code> in test files. I think all of the <code>use v6</code> should be removed. They served a purpose in the days when there could be confusion with Perl, but nowadays that's not needed. And it's a potential problem.</p> | |
| </li> | |
| <li> | |
| <p>When we currently run a spectest, it is done with the <strong>CURRENT</strong> state of <code>v6.d</code>, which is <em>not</em> what the next version will be. We should have an easy way to run the spectests for a specific version of Raku, similar to what we're now doing with the RakuAST grammar (aka an environment variable)</p> | |
| </li> | |
| <li> | |
| <p>What the above doesn't show, is that roast is still using the old <code>.t</code> test extensions. I think these can and should be changed to use the new <code>.rakutest</code> extensions, as the 6.d release test files already live in a separate branch.</p> | |
| </li> | |
| </ol> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5UrUrl"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2023-02-07T11:46:42Z">2023-02-07 11:46</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Spectesting is a version minefield at the moment:</p> | |
| <pre><code>% rak '^use v6' t/spec --frequencies | |
| 1758:use v6; | |
| 30:use v6.c; | |
| 22:use v6.e.PREVIEW; | |
| 14:use v6.d; | |
| </code></pre> | |
| <p>A more precise:</p> | |
| <pre><code>% rak '{ "t/spec/$/" if .match(/^ <-[#]+[\S]>+ /) }' --/show-item-number t/spec/spectest.data | rak --files-from=- '^use v6' --frequencies | |
| 1332:use v6; | |
| 17:use v6.c; | |
| 14:use v6.e.PREVIEW; | |
| 9:use v6.d; | |
| </code></pre> | |
| <p>So this shows several issues that each may need a different problem solving issue.</p> | |
| <pre><code>1. there are _many_ files in roast that are not actually being part of the spectest. Maybe these should be removed from roast or parked in a "archived" branch? | |
| </code></pre> | |
| </blockquote> | |
| <p>Wasn't there a file that stated which ones were actually used?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Ur3hF"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-07T13:35:23Z">2023-02-07 13:35</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think there is a bit of confusion about <code>.t</code> extension being "legacy" or "simply stable" - lately it seems that it's more the former, in which case the last point seems simple and straightforward.</p> | |
| <p>For the rest of the questions, I would refer to our discussion at #raku-dev on IRC: a readable form of a test helper like "skip this file if the version doesn't match a certain criterion" would probably help a lot. If I understand right, it would also mitigate the situation of datatest.spec quite a bit: the files themselves could say what version they belong to, which seems like a sane default for spectesting.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UsboG"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-07T15:09:51Z">2023-02-07 15:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>Spectest must not be ran against a single version. Moreover, <em>each</em> test must have an explicit version. Not just <code>use v6</code> for which, I agree, there must be no place out there anymore. Otherwise, each particular test is designed for a particular language version. Vast majority of them are covering 6.c, apparently. It wouldn't be right to expect that something with no explicit <code>use v6.c</code>/<code>use v6.d</code> will continue to pass when 6.e becomes the default.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Us4Ga"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-07T16:22:01Z">2023-02-07 16:22</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think @vrurg made a good point, perhaps it would be more accurate to say: "one possible good point".</p> | |
| <p>What didn't seem to be clear in the short discussion on the IRC is how the two-dimensional nature of the question is solved:</p> | |
| <ul> | |
| <li>a spectest belongs to a set of versions of the language (I'm saying it this way because we need to account for deprecations and removals as well!)</li> | |
| <li>an actual compiler/runtime can implement and run different versions of the language</li> | |
| </ul> | |
| <p>So in theory, this could be an N:M situation - however, only those combinations make sense where the used runtime version is matched by the spectest, so it's much closer to a linear situation. It's worth thinking about the idea of @lizmat as well, namely that the used language version could be set directly, rather than always coming from the source.</p> | |
| <p>If I remember correctly, the topic of removal came up recently, as something that is "possible in theory but a hassle to actually achieve". Anyway, if there may be breaking changes (other than extensions) in the future, it would be good to at least give the specs the chance to describe that phenomenon.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Us5oL"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-07T16:26:08Z">2023-02-07 16:26</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <ul> | |
| <li>an actual compiler/runtime can implement and run different versions of the language</li> | |
| </ul> | |
| </blockquote> | |
| <p>What??? It does, mind me...</p> | |
| <p>For the rest of version-related stuff: that's why there are many individual files. Each one can test a specific aspect using a concrete <code>use v6.x</code> pragma. If something is deprecated in 6.e – test it in a 6.e compunit. Period.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UtHnJ"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-07T17:04:00Z">2023-02-07 17:04</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>What??? I does, mind me...</p> | |
| </blockquote> | |
| <p>Not sure what this even means but it's hard to imagine it was anything constructive...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UtXkJ"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-07T17:39:40Z">2023-02-07 17:39</time> | |
| </div> | |
| <div class='body'> | |
| <p>Anyway, what still seems to be missing: what about those spectests that <strong>aren't meant to be run, given a newer version, because their right outcome on the newer version is that they fail</strong>? Part of the reason I was trying to recite the "removal topic" (that apparently wasn't as interesting as the existence of compiler versions...) - if something is removed, the whole "language versions are scopes around each other" approach breaks down, or at least needs to be hacked. It would be good if at least the specification could deal with this situation in a clear way, period. And this is where both</p> | |
| <ul> | |
| <li>the separation of the spectest version and used runtime version</li> | |
| <li>and the "skip/fail/pass this test depending on language version in use" | |
| would turn relevant and useful.</li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UusvG"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-07T22:09:37Z">2023-02-07 22:09</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Not sure what this even means</p> | |
| </blockquote> | |
| <p>It was a mistype. "It does", not "I does".</p> | |
| <blockquote> | |
| <p>what about those spectests that aren't meant to be run, given a newer version, because their right outcome on the newer version is that they fail?</p> | |
| </blockquote> | |
| <p>Not sure I get you here, but they're supposed to be run with corresponding <code>use v6.x</code>. What is wrong about this statement?</p> | |
| <p>I wonder if you understand the meaning of <code>use v6.x</code> pragma.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UvUwx"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-08T00:22:59Z">2023-02-08 00:22</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I wonder if you understand the meaning of use v6.x pragma.</p> | |
| </blockquote> | |
| <p>As much as you explained during the 2021 conference, I guess.</p> | |
| <p>I'm starting to think that we have completely different interpretations of what a run of a spectest means, what the output is. Frankly, the way liz talked about it is much easier for me to relate to.</p> | |
| <p>As I'm taking right now, a "spectest a la vrurg" tests the compiler, regardless of language version, in one run: version c stuff is guaranteed to work in version c mode, version d stuff is guaranteed to work in version d mode and so on. This test treats "<em>introduced</em> in language version c (and may belong to others as well!)" as "belongs to language version c (and only that)". This can only be sound if it's postulated that all language versions MUST include all the previous versions, with a hard stop - otherwise how could we be sure that the same compiler running in e.g "d" mode can still pass tests introduced in language version "c"?</p> | |
| <p>Now, this sort of spectesting makes actual removal of functionality impossible because in order to implement the language version that removed, say, a dozen of public functions and two types, one would still need to implement those versions that introduced and contained them - or else it couldn't even pass the tests that you are proposing, in the first place.</p> | |
| <p>This doesn't follow from the semantics of "use v6.x" in theory, does it? This "language version hierarchy" is more a pragma than a specification demand, right? Okay, that's how it is done in Rakudo, and one wouldn't want to write the same tests for different language versions either, when most of the time there are just no changes - however, the latter is mitigated by a combination of what @lizmat and I proposed (i.e "version under test" coming from a compiler setting, and all tests individually can check the version if different behaviors are needed).</p> | |
| <p>PS: you could write a little longer than three lines, and please keep the bantering bits (like that "compiler versions, no shit" crap) for yourself.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UzFYF"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-08T14:23:29Z">2023-02-08 14:23</time> | |
| </div> | |
| <div class='body'> | |
| <p>I haven't read past "<x> version mode". Give yourself an answer what that does mean. Then think of backward compatibility we provide – and you'd be surprised! I just have nothing more to add here.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UzM8o"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-08T14:44:12Z">2023-02-08 14:44</time> | |
| </div> | |
| <div class='body'> | |
| <p>Thank you for the constructivity again - the only question at this point is who that "we" might be.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UzZx3"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2023-02-08T15:18:18Z">2023-02-08 15:18</time> | |
| </div> | |
| <div class='body'> | |
| <p>@vrurg there's actually one thing missing from the current spec test suite and the way we use it: | |
| Let's assume there is a test that tests that in Raku <code>1 + 1</code> is indeed 2. Since <code>&infix:sym<+></code> was already part of the first version, that test uses <code>use v6.c;</code>. There is however no test that ensures that this still holds in a comp unit that has a <code>use v6.d;</code> at the top. I.e. we only test that the intentional changes we make in later language versions are present, but don't test the negative: that there are no unintentional changes. Thus a compiler would be free to provide a working version of <code>+</code> in v6.c mode, but even completely remove it from 6.d.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UzfRH"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-08T15:27:23Z">2023-02-08 15:27</time> | |
| </div> | |
| <div class='body'> | |
| <p>What constructiveness do you expect? If I tell you that code written 7 years ago with <code>use v6.c</code> we expect to be ran today with, perhaps, just a couple of changes (some code rely on buggy behaviors), if that code used nothing beyond included into the roast back then or today – what would it mean to you? Let me guess, you knew about this paradigm.</p> | |
| <p>If we think further then it becomes clear that the compiler right now supports all language versions: 6.c, 6.d, and the upcoming 6.e. It means that one could <code>use</code> a <code>6.e</code> module from their <code>6.d</code> code and it will work. Perhaps not semantically (but it might happen even when the same language version compunits interact), but technically it will. So, all these language versions are in the compiler now.</p> | |
| <p>Then what is that <code>version mode</code> term means? Your statements are based on the term which has no meaning. How could I respond to something that's meaningless in its premise? The only thing which do make sense to me is a test for a language version. A test with <code>use 6.e</code> tests if something works for 6.e and nothing else. If I want to see that something works equally well for all language versions – I would take care to have the code ran under each version individually. It's just a technical matter and nothing else.</p> | |
| <p>The situation is like this: a compiler to claim full Raku support has to pass the roast and support all three language versions.</p> | |
| <p>If we speak about removal of tests then this is something separate and unrelated to versioning.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UzmKH"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-08T15:37:43Z">2023-02-08 15:37</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Thus a compiler would be free to provide a working version of <code>+</code> in v6.c mode, but even completely remove it from 6.d.</p> | |
| </blockquote> | |
| <p>Just about time! :) I've mentioned this case above. It's a pure technical matter of how to implement that kind of testing. For the moment the cleanest way is to <code>EVAL</code> from within individual test files, like, for example:</p> | |
| <pre><code class="language-raku">use v6.e; | |
| EVALFILE "./must-work-everywhere.t"; | |
| </code></pre> | |
| <p>Or to use <code>is-run</code> test. See, for example, <code>S11-modules/versioning.t</code>. I always wanted <code>EVAL</code> to let its compunit use own language version, but never got there due to lack of time.</p> | |
| <p>And, of course, the option of letting the compiler to use different <em>default</em> language version is on the table too.</p> | |
| <p>But then, again, these are pure technical matters of how to get a task solved. I don't see a problem here.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Uz_L7"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-08T16:38:59Z">2023-02-08 16:38</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The situation is like this: a compiler to claim full Raku support has to pass the roast and support all three language versions.</p> | |
| </blockquote> | |
| <p>YES, thank you very much, this is the <strong>presumption</strong> that I also mentioned, have you bothered to read the comment, rather than boasting with not having read it:</p> | |
| <blockquote> | |
| <p>This can only be sound if it's postulated that all language versions MUST include all the previous versions, with a hard stop</p> | |
| </blockquote> | |
| <p>Let's keep it simple: where is this interpretation of the specification written down, as normative? All Raku compilers should be able to run all Raku code ever written, no matter how obsolete? This sounds debatable - but more importantly, it's not obvious whatsoever. It should be written down at a visible place, rather than deducible from an upset one-liner response.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5U0F3l"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2023-02-08T16:57:40Z">2023-02-08 16:57</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>This can only be sound if it's postulated that all language versions MUST | |
| include all the previous versions, with a hard stop | |
| Let's keep it simple: where is this interpretation of the specification | |
| written down, as normative? All Raku compilers should be able to run all | |
| Raku code ever written, no matter how obsolete?</p> | |
| </blockquote> | |
| </blockquote> | |
| <p>I don't think this has ever been written down anywhere. The reason however is | |
| not that we didn't commit to it. Rather the opposite: maintaining eternal | |
| backwards compatibility is one of those values that sit so deep, that no one | |
| felt the need to codify it. It was pretty much a given, i.e. a common | |
| understanding and underlies many of the design principles. It's for example | |
| the reason why so many things are lexically scoped in Raku. It's one of the | |
| values we inherited from the Perl community. The only difference being that we | |
| tried to make maintaining that backwards compatibility less painful.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VCrCk"> | |
| <div class='header'> | |
| <span class='author'>@usev6</span> commented at <time datetime="2023-02-11T13:07:26Z">2023-02-11 13:07</time> | |
| </div> | |
| <div class='body'> | |
| <p>Back in 2015 @FROGGS and me used a hackathon to work on adding the ability to fudge tests for a specific version of Perl 6 (as it was called then). The idea was to be able to add a version to one or more tests or to a block with tests like this:</p> | |
| <pre><code>#?v6.0.0 | |
| is 2+2, 4; | |
| #?v6.0.5+ | |
| { | |
| is "Life, the Universe, and Everything".WHY, 42; | |
| is 42.WHAT, Int, 'some reason'; | |
| } | |
| #?v6.0.0..v6.0.2 2 | |
| is 2-2, 0; | |
| is 3*4, 12; | |
| #?v6.0.1..* | |
| is 2-2, 0; | |
| is 3*4, 12; | |
| </code></pre> | |
| <p>The above is taken from an old branch that still lives in the roast repo: https://github.com/Raku/roast/compare/master...fudge</p> | |
| <p>I wonder if this idea could still make sense (maybe in a different form).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VCrbk"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-02-11T13:15:01Z">2023-02-11 13:15</time> | |
| </div> | |
| <div class='body'> | |
| <p>Interesting... hmmm</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VC2UZ"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-02-11T16:06:31Z">2023-02-11 16:06</time> | |
| </div> | |
| <div class='body'> | |
| <p>I would propose the following:</p> | |
| <ol> | |
| <li>remove all "use v6" specifications: it is clearly that they are meant to indicate Raku rather than Perl, and thus indicate tests that should run ok on <em>any</em> Raku version, including the current development version.</li> | |
| <li>check out whether the files in roast that have a specific version specification (6.c or 6.d) really indicate they need to be run with that version. If not, then remove those as well.</li> | |
| <li>Implement an environment variable <code>RAKU_DEFAULT_LANGUAGE_VERSION=</code> that would indicate the language version with which Raku should run <strong>IF</strong> there is no specific <code>use v6.x</code> mention.</li> | |
| </ol> | |
| <p>This should allow us to run all current non-version specific test files with <code>v6.e.PREVIEW</code> without needing to make any (further) changes to roast.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VC61N"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2023-02-11T17:12:37Z">2023-02-11 17:12</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't really like making changes to rakudo just to avoid making changes for | |
| this single user. Instead of that environment variable, you could also have | |
| the the Makefile copy the files and prepend the appropriate use v6 statement | |
| (except they already have one). After all make is a really good tool when you | |
| need to propagate changes of a source to a target.</p> | |
| <p>This would have the advantage of having all those tests be part of a single | |
| test run. We could have this full tests run as a different target akin to | |
| stresstest.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VC65M"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-02-11T17:13:52Z">2023-02-11 17:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>Don't you think such an environment variable would have more general applications?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VC7wR"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2023-02-11T17:29:57Z">2023-02-11 17:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>In fact I don't :) Can't think of any</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VDCVc"> | |
| <div class='header'> | |
| <span class='author'>@usev6</span> commented at <time datetime="2023-02-11T19:26:52Z">2023-02-11 19:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>Basically I'm agreeing with @vrurg (from far above):</p> | |
| <blockquote> | |
| <p>Moreover, <em>each</em> test must have an explicit version.</p> | |
| </blockquote> | |
| <p>Since roast <em>defines</em> Raku, it has to be clear, which test is part of a specific version of Raku.</p> | |
| <p>I wonder if this could -- at least in theory -- be achieved by "just"</p> | |
| <ol> | |
| <li>keeping different branches of roast (we already have <a href="https://github.com/Raku/roast/tree/6.c">6.c</a>, <a href="https://github.com/Raku/roast/tree/6.c-errata">6.c-errata</a> and <a href="https://github.com/Raku/roast/tree/6.d-errata">6.d-errata</a>),</li> | |
| <li>removing all version annotations from test files</li> | |
| <li>running spectest for a specific version (a specific branch) with a mechanism like @niner suggested (using <code>make</code> to prepend the appropriate statement before actually running the tests)</li> | |
| </ol> | |
| <p>To me this sounds like a clean separation of concerns. And in theory the released versions of Raku should be immutable, so there shouldn't be much need to adjust test files for old versions.</p> | |
| <p>The most obvious disadvantage would probably be the need to run different spectests (for all versions -- or probably for the corresponding branch <code>6.?-errata</code>). But if we want to keep backwards compatibility for Rakudo, maybe that's the price? (As a thought experiment, there could be a different implementation that just aims to be compatible with the current version.)</p> | |
| <p>I'm not sure it this idea really makes sense, but the idea came back to my mind each time I looked at the comments in here. So I thought I should mention it ...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VDE1X"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-11T20:23:54Z">2023-02-11 20:23</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>As a thought experiment, there could be a different implementation that just aims to be compatible with the current version.</p> | |
| </blockquote> | |
| <p>This is what I thought, too, until the following statement happened:</p> | |
| <blockquote> | |
| <p>The situation is like this: a compiler to claim full Raku support has to pass the roast and support all three language versions.</p> | |
| </blockquote> | |
| <p>I think it's really about time to, well, specify the specification in this regard. When we talked about this with lizmat, the concept of "supported version" also came up - supported, as in the current language specification supports it, and not as in the compiler supports it; the compiler <strong>must</strong> support it. (Honestly, all of this sounds vague and fragile, without any precedent of removing a version from support.)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VgVLW"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-02-17T11:58:17Z">2023-02-17 11:58</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>running spectest for a specific version (a specific branch) with a mechanism like @niner suggested (using make to prepend the appropriate statement before actually running the tests)</p> | |
| </blockquote> | |
| <p>Although this would be nice for running spectests, it would make debugging issues in a specific test file <em>much</em> harder and error prone. The alternatives are:</p> | |
| <ul> | |
| <li>adding a <code>use v6.x</code> manually while testing (and then forgetting to remove it)</li> | |
| <li>using a make file for individual testing as well, which may hide issues</li> | |
| </ul> | |
| <p>Personally, if a test file is fudged, I much rather run the <code>rakudo.moar</code> version directly, optionally tweaking that, than going through a fudging process <em>every time</em>.</p> | |
| <p>Anyways, that's why I think having an environment variable to indicate the language version to be used in absence of a specific indication in a file, would be preferable.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Vhryr"> | |
| <div class='header'> | |
| <span class='author'>@coke</span> commented at <time datetime="2023-02-17T16:39:00Z">2023-02-17 16:39</time> | |
| </div> | |
| <div class='body'> | |
| <p>Another wrinkle - spec tests were updated to work with Unicode 15 in January - but this breaks the spec test runs for v6.c when using the 2022.12, which only has Unicode 13 support. (sjn++ for reporting)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VhtlT"> | |
| <div class='header'> | |
| <span class='author'>@sjn</span> commented at <time datetime="2023-02-17T16:44:35Z">2023-02-17 16:44</time> | |
| </div> | |
| <div class='body'> | |
| <p>For me, it would be nice with a visible warning (and pause) if I somehow run the spectests on code that is significantly older than the tests expect – perhaps noting that tests should be expected to fail, since they may be testing features that haven't been implemented in the currently-checked-out (old) code.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VmlMx"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-20T01:36:09Z">2023-02-20 01:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>Can't get too deep into this, but so far I like the idea of fudging the most. So, tests which are not explicitly designed for a particular language version would have <code>#?raku-version</code> line as the start. And that is all we need for reliably testing under various <code>use v6.x</code> pragmas.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="364"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/364"><span class='number'>364</span></a> - <span class='title'>Supply blocks may reorder flow of execution</span></div> | |
| <div class='author'>[open]<span class='author'>@patrickbkr</span> opend this issue at <time datetime="2023-01-27T13:33:52Z">2023-01-27 13:33</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>This is a follow up of | |
| https://github.com/rakudo/rakudo/issues/5141 | |
| and | |
| https://github.com/rakudo/rakudo/pull/5158</p> | |
| <p>Consider the following piece of code:</p> | |
| <pre><code>my $p = Promise.new; | |
| my $s1 = supply { | |
| await $p; | |
| say "processing whenever" | |
| }; | |
| react { | |
| whenever $s1 { } | |
| $p.keep; | |
| say "end of react block"; | |
| } | |
| </code></pre> | |
| <p>That piece of code prints</p> | |
| <pre><code>end of react block | |
| processing whenever | |
| </code></pre> | |
| <p>This is unexpected. The order seems reversed. Why is this so?</p> | |
| <p>By default whenevers tap their supply instantly and as a result run the supply block they are connected to. This has a potential for deadlocking when that supply block (or one nested via more <code>whenevers</code>) contains an <code>emit</code> as the <code>emit</code> will call the whenever block of the original supply, but by definition only a single execution branch is allowed in a supply block at any time. | |
| Possibly (I'm not sure about that) there are other scenarios posing similar deadlock issues without recursion being involved.</p> | |
| <p>The currently implemented solution for this deadlock problem in https://github.com/rakudo/rakudo/commit/26a9c313297a21c11ac30f02349497822686f507 and https://github.com/rakudo/rakudo/commit/547839200a772e26ea164e9d1fd8c9cd4a5c2d9f works as follows. When - in the setup phase, during the processing of a whenever tapping - an await happens (be it a protect, acquire, lock or plain await) a continuation starting at the root of the whenever tapping is taken. Only after the supply block itself finished running the continuation is resumed. So the order in which the code is executed is dependent on whether there is any locking going on in code tapped by the whenever.</p> | |
| <p>This behavior is difficult for a unknowing programmer to follow. Even a programmer knowing about this behavior will potentially have a hard time knowing whether there is a lock somewhere in the tapped code that could cause this reordering of code. This is a case of action-at-a-distance.</p> | |
| <p>Also there still is a possibility of the code deadlocking left. That's detailed in https://github.com/rakudo/rakudo/issues/5141. I consider that a problem separate from this issue.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5T1fC1"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-01-27T13:45:25Z">2023-01-27 13:45</time> | |
| </div> | |
| <div class='body'> | |
| <p>In https://github.com/rakudo/rakudo/pull/5158 I tried replacing the continuation based solution strategy with a much simpler approach of just always executing whenever tapping <em>after</em> the supply block itself has run. That behavior is a lot easier to understand.</p> | |
| <p>It does contradict the syntax though. Currently whenever blocks can be placed anywhere in a supply block, which strongly suggests that they are processed where they are placed. Only executing them after having processed the supply block is thus highly counterintuitive.</p> | |
| <p>Additionally it makes code like the following impossible to write:</p> | |
| <pre><code># Simplified from t/spec/S17-promise/nonblocking-await.t | |
| my $started = Promise.new; | |
| my $ok = start react { | |
| whenever IO::Socket::Async.listen($s-address, $port) -> $conn { | |
| whenever $conn.Supply(:bin) -> $buf { | |
| await $conn.write: $buf; | |
| $conn.close; | |
| } | |
| } | |
| $started.keep; | |
| } | |
| </code></pre> | |
| <p>In that piece of code a <code>Promise</code> is used to track the set up of the <code>react</code> block. When delaying whenever tapping <em>after</em> the processing of the react block, then that <code>$started.keep</code> happens too early.</p> | |
| <p>I thus consider https://github.com/rakudo/rakudo/pull/5158 a non-solution. At the moment I have run out of ideas of how to solve this.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5T-5ed"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2023-01-30T17:08:18Z">2023-01-30 17:08</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>This is unexpected. The order seems reversed. Why is this so?</p> | |
| </blockquote> | |
| <p>A <code>supply</code> block (and thus <code>react</code>) provides concurrency control by enforcing one-message-at-a-time semantics: that is, we must completely process a message (reach the end of the <code>whenever</code> block) before we process the next one. An <code>await</code> inside of a <code>whenever</code> block thus prevents execution of any other <code>whenever</code> block starting until the <code>await</code>ed event completes. (If one wants more concurrency, the answer is to instead use a nested <code>whenever</code>; were <code>await</code> to have different semantics then there'd not be a means to achieve back pressure).</p> | |
| <p>The body of a <code>supply</code> or <code>react</code> block itself is much like an OO constructor: just as we expect the constructor to complete before we have a complete object ready to receive method calls, we expect the setup phase of the <code>supply</code> or <code>react</code> block to run to completion before it processes any other messages.</p> | |
| <p>Thus, the behavior in that example seems as intended.</p> | |
| <blockquote> | |
| <p>Currently whenever blocks can be placed anywhere in a supply block, which strongly suggests that they are processed where they are placed.</p> | |
| </blockquote> | |
| <p>Yes, it's important for correctness that the subscription is established right away.</p> | |
| <blockquote> | |
| <p>The currently implemented solution for this deadlock problem in https://github.com/rakudo/rakudo/commit/26a9c313297a21c11ac30f02349497822686f507 and https://github.com/rakudo/rakudo/commit/547839200a772e26ea164e9d1fd8c9cd4a5c2d9f works as follows. When - in the setup phase, during the processing of a whenever tapping - an await happens (be it a protect, acquire, lock or plain await) a continuation starting at the root of the whenever tapping is taken. Only after the supply block itself finished running the continuation is resumed. So the order in which the code is executed is dependent on whether there is any locking going on in code tapped by the whenever.</p> | |
| <p>This behavior is difficult for a unknowing programmer to follow. Even a programmer knowing about this behavior will potentially have a hard time knowing whether there is a lock somewhere in the tapped code that could cause this reordering of code. This is a case of action-at-a-distance.</p> | |
| </blockquote> | |
| <p>The core of the issue really is that <code>supply</code> and <code>react</code> are primarily a tool for managing existing concurrency, rather than as a means to introduce concurrency. However, in an attempt to DWIM, we try to permit a <code>supply</code> to immediately <code>emit</code> in its body, rather than just subscribe to other underlying sources and <code>emit</code> based upon events from those. The <code>BlockAddWheneverAwaiter</code> approach, as noted in https://github.com/rakudo/rakudo/issues/5141, seems to have shortcomings when one mixes <code>supply</code> blocks with use of a <code>Supplier</code>, for example.</p> | |
| <p>I picked the continuation juggling approach to resolve the conflicts over the alternative of scheduling the continuations using the normal thread pool scheduler and letting the standard <code>await</code> mechanism take over, primarily on the basis that if <code>supply</code> blocks really were going to have to get into the business of introducing concurrency, then at least they should avoiding introducing threading too. Perhaps, however, the latter would have been the lesser evil; I'm curious if that would solve the problem at hand here and be more robust generally.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UC8N9"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-01-31T09:48:40Z">2023-01-31 09:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>Thanks for your input!</p> | |
| <blockquote> | |
| <blockquote> | |
| <p>This is unexpected. The order seems reversed. Why is this so?</p> | |
| </blockquote> | |
| <p>A <code>supply</code> block (and thus <code>react</code>) provides concurrency control by enforcing one-message-at-a-time semantics: that is, we must completely process a message (reach the end of the <code>whenever</code> block) before we process the next one. An <code>await</code> inside of a <code>whenever</code> block thus prevents execution of any other <code>whenever</code> block starting until the <code>await</code>ed event completes. (If one wants more concurrency, the answer is to instead use a nested <code>whenever</code>; were <code>await</code> to have different semantics then there'd not be a means to achieve back pressure).</p> | |
| </blockquote> | |
| <p>That question was meant as the heading for the following paragraph. But thanks for explaining anyways! ;-)</p> | |
| <blockquote> | |
| <p>Thus, the behavior in that example seems as intended.</p> | |
| </blockquote> | |
| <p>Which example are you refering to? The one in the first post does trigger the await magic and manages to change the order in which the supply block and tapping are executed.</p> | |
| <blockquote> | |
| <blockquote> | |
| <p>Currently whenever blocks can be placed anywhere in a supply block, which strongly suggests that they are processed where they are placed.</p> | |
| </blockquote> | |
| <p>Yes, it's important for correctness that the subscription is established right away.</p> | |
| </blockquote> | |
| <p>I agree.</p> | |
| <blockquote> | |
| <p>The core of the issue really is that <code>supply</code> and <code>react</code> are primarily a tool for managing existing concurrency, rather than as a means to introduce concurrency. However, in an attempt to DWIM, we try to permit a <code>supply</code> to immediately <code>emit</code> in its body, rather than just subscribe to other underlying sources and <code>emit</code> based upon events from those. The <code>BlockAddWheneverAwaiter</code> approach, as noted in <a href="https://github.com/rakudo/rakudo/issues/5141">rakudo/rakudo#5141</a>, seems to have shortcomings when one mixes <code>supply</code> blocks with use of a <code>Supplier</code>, for example.</p> | |
| <p>I picked the continuation juggling approach to resolve the conflicts over the alternative of scheduling the continuations using the normal thread pool scheduler and letting the standard <code>await</code> mechanism take over, primarily on the basis that if <code>supply</code> blocks really were going to have to get into the business of introducing concurrency, then at least they should avoiding introducing threading too. Perhaps, however, the latter would have been the lesser evil</p> | |
| </blockquote> | |
| <p>I can try implementing that. So that I get it right: I keep the BAWA (BlockAddWheneverAwaiter), but instead of putting the continuations in a list for later processing, I'd just instantly schedule the continuations on the ThreadPoolScheduler (<em>not</em> on the outer <code>$*AWAITER</code>, which would be a BlockingAwaiter and thus block the BAWA itself).</p> | |
| <blockquote> | |
| <p>I'm curious if that would solve the problem at hand here and be more robust generally.</p> | |
| </blockquote> | |
| <p>I guess that depends on whether we want to be pedantic. If the aspiration is to never have surprising order reversals, then queuing things on the thread pool isn't a step forward. I am confident though that having things in the thread pool will solve https://github.com/rakudo/rakudo/issues/5141 (the issue that made me explore the supply / whenever implementation in the first place). In that deadlock situation a continuation earlier in the list blocks on a lock a later continuation holds. But there is no "A waits on B, B waits on A" situation. So if the other continuations would be allowed to run, things would work out.</p> | |
| <p>It still feels wrong to give locks not being involved in the supply setup the same treatment. I think I'll start another experiment: I'll remove the entirety of the BlockAddWheneverAwaiter and see if the queue-on-recursion logic implemented in https://github.com/rakudo/rakudo/commit/547839200a772e26ea164e9d1fd8c9cd4a5c2d9f suffices to prevent deadlocks on construction. I think I have not yet seen a situation where a lock we need to resolve during construction has <em>not</em> been a recursion lock.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Uc1Fu"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-04T20:30:01Z">2023-02-04 20:30</time> | |
| </div> | |
| <div class='body'> | |
| <p>Just removing the BlockAddWheneverAwaiter logic basically means having recursing emits during supply construction instantly return and thus killing back-pressure. All tests and spectests pass except for a single test:</p> | |
| <pre><code>tap-ok Supply.zip( | |
| Supply.from-list("a".."e"), | |
| Supply.from-list("f".."k"), | |
| Supply.from-list("l".."p") | |
| ), | |
| [<a f l>,<b g m>,<c h n>,<d i o>,<e j p>], | |
| "zipping with 3 supplies works"; | |
| </code></pre> | |
| <p>The supply is <code>done</code> before a single value is emitted. That happens, because the first supply gets to emit all its values and <code>done</code> (each being put into the <code>protect-or-queue-on-recursion</code> queue) before the others. That queue is then processed in order causing the zip to be <code>done</code> as soon as all the messages of the first supply have been processed. | |
| Technically it still works as documented (The docs state: "The resulting supply is done as soon as any of the given supplies are done."), but I'm unsure if that behavior is acceptable.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Uc73o"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-04T23:04:12Z">2023-02-04 23:04</time> | |
| </div> | |
| <div class='body'> | |
| <p>I have now also tried making the BlockAddWheneverAwaiter queue its continuations on the thread pool. That gets <code>make test</code> pass and <code>make spectest</code> hang in <code>S17-supply/[flat|batch|unique|merge|zip].t</code>, but succeed otherwise.</p> | |
| <p>I have now pushed two branches to GitHub:</p> | |
| <ul> | |
| <li>https://github.com/patrickbkr/rakudo/tree/supply-whenever-no-bawa That contains a change removing the BlockAddWheneverAwaiter.</li> | |
| <li>https://github.com/patrickbkr/rakudo/tree/supply-whenever-bawa-on-threadpool That contains a change to make the BlockAddWheneverAwaiter queue its continuations on the thread pool instead of collecting and running them later.</li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Uc8Gf"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-04T23:08:24Z">2023-02-04 23:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>Also to note, both branches solve the dead-lock problem in https://github.com/rakudo/rakudo/issues/5141</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Uc8YN"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-04T23:14:03Z">2023-02-04 23:14</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'll see if I can get the put-continuations-on-thread-pool solution working (i. e. get the hangs to pass).</p> | |
| <p>In general I like the solution removing the BlockAddWheneverAwaiter better. I believe its easier to understand what's going on as only locks of the supplies themself are affected. Also there are no continuations involved.</p> | |
| <p>@jnthn What do you think?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UiSaC"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-05T21:53:45Z">2023-02-05 21:53</time> | |
| </div> | |
| <div class='body'> | |
| <p>I found the reason for the hangs with the schedule-continuations-on-the-thread-pool approach. The hanging tests replace <code>$*SCHEDULER</code> with <code>CurrentThreadScheduler</code> which purposely blocks on calls to <code>cue</code>. Since we rely on the scheduler to have our continuations executed concurrently to prevent deadlocks the code can't resolve locks with a <code>CurrentThreadScheduler</code>.</p> | |
| <p>The docs say the <code>CurrentThreadScheduler</code> is useful mostly for testing. So what's the point of having code run with the <code>CurrentThreadScheduler</code>? Is it forbidden to rely on the scheduler to resolve locks?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UiVFd"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-05T22:43:55Z">2023-02-05 22:43</time> | |
| </div> | |
| <div class='body'> | |
| <p>With the schedule-continuations-on-the-thread-pool approach there is also a test failure in <code>t/spec/S17-supply/flat.t</code></p> | |
| <pre><code>my $s = Supplier.new; | |
| my $f = $s.Supply.flat; | |
| my $seen1 = []; | |
| my $t1 = $f.tap( { $seen1.push: $_ } ); | |
| $s.emit([1,2]); | |
| is $seen1, [1,2], 'did we get the first emit (1)'; | |
| </code></pre> | |
| <p>Cause: Emitting on a <code>.flat</code>ed supply involves setting up a <code>whenever</code> and processing values in <a href="https://github.com/rakudo/rakudo/blob/main/src/core.c/Supply-factories.pm6#L460">src/core.c/Supply-factories.pm6:460</a>. That in turn activates the <code>BlockAddWheneverAwaiter</code> which causes the value to be emitted asynchronously, causing the <code>$s.emit</code> and <code>is</code> in the test to be racy.</p> | |
| <blockquote> | |
| <p>Perhaps, however, the latter would have been the lesser evil; I'm curious if that would solve the problem at hand here and be more robust generally.</p> | |
| </blockquote> | |
| <p>My conclusion from the above analysis is, that the schedule-continuations-on-the-thread-pool approach as I implemented it brings its own set of problems. I don't think these issues can be alleviated.</p> | |
| <p>So the only approach I still have hope in is the remove-the-BlockAddWheneverAwaiter-completely approach I also explored. See <a href="https://github.com/Raku/problem-solving/issues/364#issuecomment-1416843630">this comment</a> for the issue surrounding that approach.</p> | |
| <p>Unless other ideas of approaching this come up, I think the solution space has been exhaustively explored. I'm now dependent on feedback whether we should go forward with one of the two explored approaches.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5U3m5Q"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-09T09:13:10Z">2023-02-09 09:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'd like to make sure the state of this issue is clear.</p> | |
| <p>jnthn <a href="https://github.com/Raku/problem-solving/issues/364#issuecomment-1408997277">has explained</a> that we have to live with occasional reordering. That's known, intentional and we can't do much about it.</p> | |
| <p>So the only problem left to be solved is the deadlock described in https://github.com/rakudo/rakudo/issues/5141. I explored two approaches trying to solve the deadlock issue:</p> | |
| <ol> | |
| <li>The <a href="https://github.com/patrickbkr/rakudo/tree/supply-whenever-no-bawa">remove-the-BlockAddWheneverAwaiter-completely</a> approach. This solves the deadlock, but has the effect that recursing emits during whenever setup do not block anymore but are queued. This causes one spec test failure in a test that turned out to <a href="https://github.com/Raku/problem-solving/issues/364#issuecomment-1416843630">depend on non-deterministic behavior</a>. A positive side-effect of this approach is that locks in general do not cause reordering anymore, only recursion that would otherwise deadlock causes reordering. In my opinion this makes it easier to understand what's going on.</li> | |
| <li>The <a href="https://github.com/patrickbkr/rakudo/tree/supply-whenever-bawa-on-threadpool">schedule-continuations-on-the-thread-pool</a> approach. This solves the deadlock as well, but it introduces concurrency. <a href="https://github.com/Raku/problem-solving/issues/364#issuecomment-1418285405">One spec test failure</a> made clear that this concurrency is problematic. I think this renders this approach unsuitable.</li> | |
| </ol> | |
| <p>So to be able to continue working on this issue I'd like to either have:</p> | |
| <ol> | |
| <li>Some feedback if the remove-the-BlockAddWheneverAwaiter-completely approach has feasability. If yes I could adapt the failing <code>Supply.zip</code> spec test and we could do a Blin run to see if there is more fallout.</li> | |
| <li>Some input on how else I could approach this problem.</li> | |
| </ol> | |
| <p>So with the above summary I now ask for feedback. Ping @jnthn, @vrurg, @niner</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VBDpJ"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-10T21:01:50Z">2023-02-10 21:01</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm not much into supplies from their implementation side, so not much help on this. But removal of a non-obvious deadlock cause does sound good to me. What's not good is that the spectest mentioned can barely be changed without breaking backward compatibility. Thus I wonder if the option 1, would it be accepted eventually, can be a 6.e change? In which case the spectest would still define 6.c/d behavior and we'd have it different for 6.e.</p> | |
| <p>Though it may also depend on the degree of change required for the spec to pass.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VCpcK"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-11T12:38:23Z">2023-02-11 12:38</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>What's not good is that the spec test mentioned can barely be changed without breaking backward compatibility.</p> | |
| </blockquote> | |
| <p>I only partly agree.</p> | |
| <pre><code>tap-ok Supply.zip( | |
| Supply.from-list("a".."e"), | |
| Supply.from-list("f".."k"), | |
| Supply.from-list("l".."p") | |
| ), | |
| [<a f l>,<b g m>,<c h n>,<d i o>,<e j p>], | |
| "zipping with 3 supplies works"; | |
| </code></pre> | |
| <p>The test strongly relies on the supplies being processed round robin, where each supply only gets to emit a single value each round. Supplies never gave any guarantee along those lines. That this works out on the current implementation is because of a delicate implementation detail.</p> | |
| <p>The test looks as if <code>zip</code> is meant to process incoming values as long as at least one supply is still active. But that's different from the current implementation and the documentation.</p> | |
| <p>So I'm confident to say that there is a mismatch between test and implementation. One of the two must be wrong.</p> | |
| <p>I do agree though that the behavior of my proposed changes is sub optimal in this case (processing all values and the <code>done</code> from the first supply before working on the second).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VCp7T"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2023-02-11T12:49:50Z">2023-02-11 12:49</time> | |
| </div> | |
| <div class='body'> | |
| <p>An alternative reading is, that the spec really does require a round-robin | |
| processing by Supply.zip and the current implementation of this method is just | |
| very fragile and relies on current implementation details of other parts of | |
| Supply. So as part of the fix, method zip could be adjusted to deal with the | |
| new situation.</p> | |
| <p>Maybe by creating a local queue for each of the child supplies and taking one | |
| element at a time out of this queue and asking the child supply for more if | |
| the queue is empty? This way it wouldn't matter if the child supply emits one | |
| or multiple values.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VC3Q8"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2023-02-11T16:24:55Z">2023-02-11 16:24</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <ol> | |
| <li> | |
| <p>The <a href="https://github.com/patrickbkr/rakudo/tree/supply-whenever-no-bawa">remove-the-BlockAddWheneverAwaiter-completely</a> approach. This solves the deadlock, but has the effect that recursing emits during whenever setup do not block anymore but are queued. This causes one spec test failure in a test that turned out to https://github.com/Raku/problem-solving/issues/364#issuecomment-1416843630. A positive side-effect of this approach is that locks in general do not cause reordering anymore, only recursion that would otherwise deadlock causes reordering. In my opinion this makes it easier to understand what's going on.</p> | |
| </li> | |
| <li> | |
| <p>The <a href="https://github.com/patrickbkr/rakudo/tree/supply-whenever-bawa-on-threadpool">schedule-continuations-on-the-thread-pool</a> approach. This solves the deadlock as well, but it introduces concurrency. https://github.com/Raku/problem-solving/issues/364#issuecomment-1418285405 made clear that this concurrency is problematic. I think this renders this approach unsuitable.</p> | |
| </li> | |
| </ol> | |
| </blockquote> | |
| <p>If I understand option 1 correctly, this is simply saying that it is left to <code>Lock::Async</code> to do the queueing? In that case I think it's effectively achieving what 2 would, but by far more elegant and well-exercised means (e.g. we don't have to build anything new).</p> | |
| <p>So long as we process one message at a time in a given <code>supply</code> and <code>react</code> instance (where the running of the <code>supply</code> or <code>react</code> blody block is considered a message too), then it should be fine.</p> | |
| <blockquote> | |
| <p>An alternative reading is, that the spec really does require a round-robin | |
| processing by Supply.zip and the current implementation of this method is just | |
| very fragile and relies on current implementation details of other parts of | |
| Supply. So as part of the fix, method zip could be adjusted to deal with the | |
| new situation.</p> | |
| </blockquote> | |
| <p>That's a reasonable reading in my opinion. I did a draft PR https://github.com/rakudo/rakudo/pull/5200 that explores an alternative way to implement <code>Supply.zip</code> that passes all current spectests. It would be interesting to try it in combination with the deadlock fix; I think it should help.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5VDJdH"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-02-11T22:22:45Z">2023-02-11 22:22</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>If I understand option 1 correctly, this is simply saying that it is left to <code>Lock::Async</code> to do the queueing?</p> | |
| </blockquote> | |
| <p>Yes, that's exactly what happens.</p> | |
| <blockquote> | |
| <p>So long as we process one message at a time in a given <code>supply</code> and <code>react</code> instance (where the running of the <code>supply</code> or <code>react</code> blody block is considered a message too), then it should be fine.</p> | |
| </blockquote> | |
| <p>From all I know that invariant is not broken. Each supply block is still guarded by a lock and no code path enters that supply block without requesting that lock.</p> | |
| <blockquote> | |
| <p>I did a draft PR <a href="https://github.com/rakudo/rakudo/pull/5200">rakudo/rakudo#5200</a> that explores an alternative way to implement <code>Supply.zip</code> that passes all current spectests. It would be interesting to try it in combination with the deadlock fix; I think it should help.</p> | |
| </blockquote> | |
| <p>I have requested a change on that draft PR. With that change <code>make test</code> and <code>make spectest</code> both succeeded. I have now created a PR with those changes in <a href="https://github.com/rakudo/rakudo/pull/5202">rakudo/rakudo#5202</a>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XikA9"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2023-03-14T19:05:54Z">2023-03-14 19:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>I now consider https://github.com/rakudo/rakudo/pull/5202 ready for review. That PR passes <code>make test</code>, <code>make spectest</code> and the original deadlock in https://github.com/rakudo/rakudo/issues/5141. I have turned that deadlocking code into a roast test in https://github.com/Raku/roast/pull/833.</p> | |
| <p>The PR contains one controversial change in behavior: | |
| In https://github.com/patrickbkr/rakudo/commit/547839200a772e26ea164e9d1fd8c9cd4a5c2d9f the recursion breaking logic and <code>Lock::Async::protect-or-queue-on-recursion</code> was originally implemented. The commit message states: "A holder's recursion competes fairly with outside messages, thanks to the queueing being through Lock::Async." This is not true anymore, as the queued code objects are now synchronously called and not put on the thread pool anymore.</p> | |
| <p>This issue and the PR are now blocking on feedback / approval. @jnthn I think you have the deepest insight in that area of Raku. Thus I'd like to have your approval before going forward with my changes.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="363"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/363"><span class='number'>363</span></a> - <span class='title'>Feature request: snip counterpart for Str</span></div> | |
| <div class='author'>[closed]<span class='author'>@2colours</span> opend this issue at <time datetime="2023-01-25T01:20:01Z">2023-01-25 01:20</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p><a href="https://github.com/Raku/roast/commit/97f3444abe8e822a3ecba18ce4c1555bf7b943b7">snip got added to the language</a>, starting with v6.e. It would be useful to have something similar for strins, the way there is <code>contains</code>, <code>index</code> or <code>flip</code> as well.</p> | |
| <p>This would allow "splitting" strings not only by content but also by position.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>…</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5Us7W3"> | |
| <div class='header'> | |
| <span class='author'>@thundergnat</span> commented at <time datetime="2023-02-07T16:30:45Z">2023-02-07 16:30</time> | |
| </div> | |
| <div class='body'> | |
| <p>I am curious if https://raku.land/zef:thundergnat/String::Splice would cover your use case? Though in looking at the tests, (there is no mention of snip in the docs at all) it looks like snip is more closely related to https://raku.land/zef:thundergnat/List::Divvy so maybe not.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UuKrc"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-07T20:18:39Z">2023-02-07 20:18</time> | |
| </div> | |
| <div class='body'> | |
| <p>@thundergnat honestly, this is a horribly written issue, and it seems to me that I fundamentally misunderstood what <code>snip</code> does. https://discord.com/channels/538407879980482560/768511641758466088/1067610507932086372 (discord side) https://irclogs.raku.org/raku-beginner/2023-01-25.html#00:59 (IRC side)</p> | |
| <p>What I wanted (and thought to have found) was indeed more like your String::Splice distro, except:</p> | |
| <ul> | |
| <li>it would split into arbitrary number of pieces (so far <code>snip</code> fits)</li> | |
| <li>the places of splitting are determined by the position given, rather than the current value (or some mapping of it)</li> | |
| </ul> | |
| <p>Here is a better-working snippet than the one in the original message: https://gist.github.com/2colours/d4d247d98fa2d6071069387aaad4844a</p> | |
| <p>At the end of the day, I'm considering closing this issue because the inspiration of it was the misunderstanding that <code>snip</code> did the same thing but for lists.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UuNtP"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-02-07T20:28:00Z">2023-02-07 20:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>Perhaps you're looking <a href="https://raku.land/zef:lizmat/String::Fields"><code>String::Fields</code></a></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5UuxFq"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-02-07T22:21:59Z">2023-02-07 22:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>Yes - I like this interface a lot, even if it isn't exactly the same I described. Seems useful for some oldschool text based data format as well, never a bad thing if one has to deal with log files a lot. :)</p> | |
| <p>Anyway, the issue turned out to be mis-aimed so it seems appropriate to close it.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="362"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/362"><span class='number'>362</span></a> - <span class='title'>Expand DEPRECATED functionality.</span></div> | |
| <div class='author'>[open]<span class='author'>@0rir</span> opend this issue at <time datetime="2023-01-13T15:01:16Z">2023-01-13 15:01</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Looking at Raku user code on Github, I stumbled across usage of <code>Rakudo::Deprecations::DEPRECATED</code> much like this.</p> | |
| <pre><code>#!/usr/bin/env raku | |
| sub d(--> Str) { | |
| DEPRECATED( 'Me', '-Since', '-Gone', :what('sub d') ); | |
| return 'd'; | |
| } | |
| d(); | |
| </code></pre> | |
| <p>This seems a large increase of utility beyond its sanctioned use as a trait. So I suggest that such usage be defined in Raku rather than be an <em>implementation detail</em>.</p> | |
| <p>Such definition could allow future enhancements (or expose functionality I missed):</p> | |
| <ul> | |
| <li>Optional customized output.</li> | |
| <li>Redirection and silencing of notices so a repairer may fix in peace.</li> | |
| <li>Specification and overriding of the entity expressed by the output 'author'. Any or all of a Raku implementer, a library author, and a using-application author may wish end-user responses to go to the application author. When a contact is named, it should not imply authorship.</li> | |
| <li>A named <em>product</em> could be added as a sister to a named <em>contact</em>.</li> | |
| <li>Loosening of version number constraints/manipulation for non-Raku implementers' convenience.</li> | |
| </ul> | |
| <p>Be well.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5Sas58"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-01-14T12:55:06Z">2023-01-14 12:55</time> | |
| </div> | |
| <div class='body'> | |
| <p>Hi @0rir,</p> | |
| <p>let me ask if I have this straight: is this about deprecation within the Raku language specification or any deprecation that can happen in code?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5SbBba"> | |
| <div class='header'> | |
| <span class='author'>@0rir</span> commented at <time datetime="2023-01-14T14:59:29Z">2023-01-14 14:59</time> | |
| </div> | |
| <div class='body'> | |
| <p>@2colours, this is about making existing behavior into defined behavior in the Raku spec.</p> | |
| <p>Just throwing it into roast is good, but the existing code has some expectation of a specific style of version numbers.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Vy1bK"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2023-02-22T03:29:41Z">2023-02-22 03:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>I would also support stabilizing a more powerful version of <code>DEPRECIATED</code>. For comparison, this is pretty similar to how Rust <a href="https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute">handles depreciation</a> and it ends up being pretty useful in Rust user code.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5V_FKX"> | |
| <div class='header'> | |
| <span class='author'>@0rir</span> commented at <time datetime="2023-02-24T00:06:38Z">2023-02-24 00:06</time> | |
| </div> | |
| <div class='body'> | |
| <p>Though I did propose a mess of features, I think there is one most necessary: | |
| Decoupling the Raku version style to allow any kind of version string.</p> | |
| <p>Then <code>multi</code>s should allow a smooth expansion of functionality.</p> | |
| <p>And my 'contact' and 'author' thoughts were ill-thought--passing a generic and a more specific message would be more flexible.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5WDs6J"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2023-02-24T15:02:10Z">2023-02-24 15:02</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Decoupling the Raku version style to allow any kind of version string.</p> | |
| </blockquote> | |
| <p>Sorry, would you elaborate on this? I don't quite get what is it about and how you see it.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5WHR39"> | |
| <div class='header'> | |
| <span class='author'>@0rir</span> commented at <time datetime="2023-02-24T23:54:16Z">2023-02-24 23:54</time> | |
| </div> | |
| <div class='body'> | |
| <p>@vrurg, thanks.</p> | |
| <p>My <code>'-Since', '-Gone'</code> in the above code require the hyphens to avoid an initial letter 'v' being added because the they become <strong>Version</strong> objects. I did not explore this aspect--it just seemed clear that, for general use, plain strings are appropriate.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="361"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/361"><span class='number'>361</span></a> - <span class='title'>`LEAVE` phaser fires when errorring in argument binding</span></div> | |
| <div class='author'>[open]<span class='author'>@dakkar</span> opend this issue at <time datetime="2023-01-09T11:26:21Z">2023-01-09 11:26</time></div> | |
| </div> | |
| <div class='body'> | |
| <pre><code class="language-raku">sub foo(Int:D :$x) { | |
| ENTER { say "entering foo" }; | |
| LEAVE { say "leaving foo" }; | |
| } | |
| foo() | |
| </code></pre> | |
| <p>produces:</p> | |
| <pre><code>leaving foo | |
| Parameter '$x' of routine 'foo' must be an object instance of type | |
| 'Int', not a type object of type 'Int'. Did you forget a '.new'? | |
| </code></pre> | |
| <p>Two things feel surprising to me:</p> | |
| <ol> | |
| <li>the <code>LEAVE</code> block was run, without the <code>ENTER</code> block being run</li> | |
| <li>the <code>LEAVE</code> block was run ever though the sub was not "really" executed (I know that signature binding happens sort-of inside the sub, but I feel that should be an implementation detail, not something visible at the language level)</li> | |
| </ol> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5R_EN9"> | |
| <div class='header'> | |
| <span class='author'>@dakkar</span> commented at <time datetime="2023-01-09T11:27:03Z">2023-01-09 11:27</time> | |
| </div> | |
| <div class='body'> | |
| <p>See also the discussion at https://s.thenautilus.net/notes/99rjsevs52</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5SCsWN"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2023-01-09T22:43:51Z">2023-01-09 22:43</time> | |
| </div> | |
| <div class='body'> | |
| <p>Perhaps the reason why things are as they are is in case anyone writes a signature that requires post bind attempt clean up, and LEAVE was considered the appropriate hook.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5SHVSE"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2023-01-10T18:07:18Z">2023-01-10 18:07</time> | |
| </div> | |
| <div class='body'> | |
| <p>It seems to me that this comment disappeared, even though it might be good to at least be able to read it:</p> | |
| <blockquote> | |
| <p>I don't think this issue benefits from mentioning the ENTER phaser, at least not in the title and in comments from here on (unless I'm missing something).</p> | |
| </blockquote> | |
| <blockquote> | |
| <p>This is first and foremost because I didn't see anyone (in the linked discussion) saying they're surprised by how the ENTER phaser is interacting with signature binding.</p> | |
| </blockquote> | |
| <blockquote> | |
| <p>But it's also because the design does not keep ENTER and LEAVE phasers symmetrical. For example, the queue of ENTER phasers (there can be more than one) for a block is aborted if there's an exception thrown by an ENTER phaser, whereas the LEAVE phaser queue keeps on trucking even if an exception is thrown by a LEAVE phaser. So expecting symmetry between the ENTER and LEAVE phasers in general is a mistake and it may just be that expecting symmetry in this trial bind aspect is also a mistake.</p> | |
| </blockquote> | |
| <blockquote> | |
| <p>In summary, I currently suspect mentioning ENTER in any of our subsequent discussion is a red herring, and the mention in the title would best be removed.</p> | |
| </blockquote> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="358"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/358"><span class='number'>358</span></a> - <span class='title'>Request to deprecate untwigiled attributes </span></div> | |
| <div class='author'>[open]<span class='author'>@librasteve</span> opend this issue at <time datetime="2022-12-17T19:51:12Z">2022-12-17 19:51</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Problem:</p> | |
| <p>The untwigiled variant of <code>has</code> attributes unbalances the symmetry of <code>$.</code> public and <code>$!</code> private attributes.</p> | |
| <hr /> | |
| <p>This issue is the new home of the one I posted wrongly over here https://github.com/rakudo/rakudo/issues/5139 (now closed)</p> | |
| <hr /> | |
| <p>Details:</p> | |
| <p>Coming in from this <a href="https://www.reddit.com/r/rakulang/comments/znf103/day_16_santa_claws_part_2_steve_roe/">reddit post</a> and raising a new Problem Solving issue here as suggested.</p> | |
| <p>I am reflecting a comment on my post made by Tom Browder here, since I think it covers an important topic that is worthy of wider discussion:</p> | |
| <p>December 16, 2022 at 1:45 am<br /> | |
| Great article pair, thanks. But, according to my reading of the docs in “Object orientation,” a class created using <code>has $attr</code> is the same as <code>has $!attr</code>, i.e., private attributes; then the docs get a little muddy to me in the next paragraph, which I think needs a bit of work.</p> | |
| <p>Now, I checked the docs and (not surprisingly) Tom is right. I also checked the repl and yes, it matches the docs.</p> | |
| <p>BUT when I learned raku (from Think Raku) there were only two options:</p> | |
| <pre><code>has $.x; # public attribute | |
| has $!y; # private attribute | |
| </code></pre> | |
| <p>So, it seems to me that the un-twigiled variant <code>has $z; # private attribute</code> has crept in without my noticing.</p> | |
| <p>So, why am I agitated? The way I see it, raku has two gears (at least) for OO:</p> | |
| <p>First gear is for "making the easy stuff easy". Just like in languages such as Python, you use the dot twigil (.), get all the accessors you want for free and can then use dot notation to access the attr.</p> | |
| <pre><code>class C { | |
| has $.x = 42; | |
| } | |
| my $c = C.new; | |
| say $c.x; # 42 | |
| $c.x = 666; | |
| say $c.x; # 666 | |
| </code></pre> | |
| <p>Second gear is for "making the hard stuff possible". Just like in languages such as Java and C++, use the bang twigil (!) and this attribute requires getter/setter methods to be employed and is a key tool to enforce encapsulation.</p> | |
| <pre><code>class D { | |
| has $!y = 42; | |
| multi method y { $!y } #getter | |
| multi method y( $value ) { $!y = $value } #setter | |
| } | |
| my $d = D.new; | |
| say $d.y; # 42 | |
| $d.y = 666; # error - need a proxy for this | |
| $d.y: 666; | |
| say $d.y; # 666 | |
| </code></pre> | |
| <p>[Larry did many good things - but this use of the colon to create a cognitive triplet of <code>=</code>, <code>:=</code> and <code>:</code> was IMO the best of the lot]</p> | |
| <p>So, IN MY OPNION, the third way of the untwigil is a MISSTEP in language features since it is at the same time easier to write and harder to use (than the dot twigil). If this was consistent, then the easy thing to write <code>has $z;</code> should also be the easy thing to use by being bound to the dot twigil variant. But then IMO that makes it too easy to get stuck in gear one.</p> | |
| <p>A further negative to the untwigil is that the symmetric options <code>$.</code> and <code>$!</code> are easy to remember and impossible to forget, adding a third option creates more complexity for the coder and the maintainer.</p> | |
| <p>So I have two questions:</p> | |
| <ol> | |
| <li>Is the untwigiled variant now part of the language?</li> | |
| <li>If yes, then do we think it SHOULD be in the language?</li> | |
| </ol> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q2aw7"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-12-17T19:51:47Z">2022-12-17 19:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>Here's what jnthn said...</p> | |
| <p>Is the untwigiled variant now part of the language? | |
| Now? :-) I believe has been for a decade or longer. It's <a href="https://design.raku.org/S12.html#Attributes">mentioned in S12</a>, and Rakudo implements it as described there (has $foo actually declares has $!foo and then makes $foo an alias to it).</p> | |
| <p>If yes, then do we think it SHOULD be in the language? | |
| It's tempting to point out that it's a mild nuisance for the compiler to handle, but by that reasoning a lot of the language would be on the chopping block. :-)</p> | |
| <p>I can't find mention of it now, but I think the syntax was once described as a sop to those who don't like twigils. However, I suspect the number of folks who are consider twigils on attributes their only dealbreaker for using Raku is pretty small - if nothing else because I can't remember the last time I saw this form in the wild!</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q2a1p"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-12-17T19:52:21Z">2022-12-17 19:52</time> | |
| </div> | |
| <div class='body'> | |
| <p>Here's what 2colours said...</p> | |
| <p>I think from repo purism point of view, this issue might have a better place at <a href="https://github.com/Raku/problem-solving">Raku/Problem-solving</a>.</p> | |
| <p>Anyway, my two cents: if something already works with really low "maintenance cost", think twice before removing it. Raku is not a minimalistic language either way and we cannot have a discourse with potential users in the future who could miss it.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q2a4r"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-12-17T19:52:47Z">2022-12-17 19:52</time> | |
| </div> | |
| <div class='body'> | |
| <p>Here's what lizmat said...</p> | |
| <p>This would go through a deprecation cycle, so it won't be gone until at least 6.f or 6.g, or whatever we will call it then.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q_NFg"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-12-20T02:13:56Z">2022-12-20 02:13</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>IN MY OPINION, the third way of the untwigil is a MISSTEP in language features since it is at the same time easier to write and harder to use (than the dot twigil).</p> | |
| </blockquote> | |
| <p>To give you food for thought, I'll advocate in the reverse direction, in a manner I think is sympathetic to what Larry intended, or at least what I think he was being sympathetic toward.</p> | |
| <hr /> | |
| <p>Imo it's great design.</p> | |
| <p>Sigils are easier to get than twigils.</p> | |
| <p>A sigil'd attribute is easier to use, much easier, than a twigil'd one, whether it's a dot or an exclamation point one.</p> | |
| <p>Here's my elaboration of that opinion.</p> | |
| <p>First, twigils build on sigils. You have to know what a sigil is to learn about twigils. And if you learn very basic Raku coding, you will learn about sigils near the start, quite plausibly long before you learn twigils.</p> | |
| <p>Second, the step between the following two is merely the declarator:</p> | |
| <pre><code>my $foo = 42; | |
| has $bar = 99; | |
| </code></pre> | |
| <p>A newbie can focus on the distinction between <code>my</code> and <code>has</code> without getting distracted by a tsunami of other premature details ("Twigils?").</p> | |
| <p>Third, the twigil free version is perfect for learning two big OO things: A) some preliminary basics, and B) the underpinnings of the single most important thing about Raku OO which is that it's all built on <strong>100% encapsulation</strong>, something many other OO PLs get wrong. The importance of this cannot be overstated. And the fact this foundation, a necessary ingredient of data race free concurrency, aligns perfectly with not needing twigils, is deliberate I think.</p> | |
| <p>Fourth, one can initialize attributes at object instance creation time without introducing twigils:</p> | |
| <pre><code>class foo { has $bar is built } | |
| say foo.new: bar => 99; # foo.new(bar => 99) | |
| </code></pre> | |
| <p>An obvious dialog will arise next:</p> | |
| <blockquote> | |
| <p>Newbie: Can I get the value of the <code>$bar</code> attribute from outside the class?</p> | |
| <p>Guide: Sure. One simple and popular but potentially problematic way is via "dot" accessors.</p> | |
| </blockquote> | |
| <p>And <em>that</em> is when you begin to step into the world of twigils.</p> | |
| <p>It's a <em>very</em> good thing it is delayed until then. One of the most evil things in OO is setters, with getters a step on the slippery slope toward them. They are so enticing that folk love them, but the cost of making them too easy is well known by PL designers. cf <a href="https://stackoverflow.com/a/59673999/1077672">Jonathan in an SO answer</a>:</p> | |
| <blockquote> | |
| <p>getters and setters are methods that have an implicit connection with the state. While we might claim we're achieving data hiding because we're calling a method, not accessing state directly, my experience is that we quickly end up at a place where outside code is making sequences of setter calls to achieve an operation - which is a form of the feature envy anti-pattern.</p> | |
| </blockquote> | |
| <p>Yes, Raku makes dot accessors (getters/setters) easy to write <em>if you must</em> (which one really must for record types, but not objects in general), but Raku <em>also</em> makes sure they're not as easy to write as 100% private attributes, which really should be how coders write attributes in most cases.</p> | |
| <hr /> | |
| <p>The only downside I see, one that I suspect Larry did not foresee, is that someone influential on the official documentation was of like mind to you and avoided the way to teach good OO that I tried to outline above, instead unofficially deprecating twigil free attributes. One result is that most people currently learn Raku OO without ever hearing that twigil free attributes are a thing. Then, when they do, they're of no obvious value, perhaps even of negative value, because they've now learned in their mind to associate sigil'd variables with <em>not</em> being attributes. And then this becomes self-fulfilling. Not because twigil free attributes are worthy of deprecation, but because they've been unofficially deprecated (by documenters) which means they are currently kinda pointless despite being superb design.</p> | |
| <p>Anyhoo, now for advocacy mode off.</p> | |
| <hr /> | |
| <p>One other reason to keep them, that isn't advocacy but just the way of things, and seems non-controversial even if their merit is, is that they already exist, and generally don't actively do harm merely by existing.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5RBPBN"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-20T12:19:48Z">2022-12-20 12:19</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The only downside I see, one that I suspect Larry did not foresee, is that someone influential on the official documentation was of like mind to you and avoided the way to teach good OO that I tried to outline above, instead unofficially deprecating twigil free attributes.</p> | |
| </blockquote> | |
| <p>This part really sounded like a bunch of (way too) big words so I went on to actually check what the documentation has about this to see if there was a deliberate act like that.</p> | |
| <p>Turns out the starting assumption <a href="https://docs.raku.org/language/objects#Attributes">is wrong</a>:</p> | |
| <blockquote> | |
| <p>Alternatively, you can omit the twigil, which will still create the private attribute (with a ! twigil), and will also create an alias that binds the name (without the twigil) to that attribute. Thus, you can declare the same class above with</p> | |
| </blockquote> | |
| <p>This is an insightful description of the situation actually:</p> | |
| <pre><code class="language-raku">class Foo1 { has $bar = 12; method test { say $bar, ' ', $bar.VAR.WHICH; say $!bar, ' ', $!bar.VAR.WHICH; } } | |
| Foo1.new.test; | |
| # returns 12 and the same Scalar for both | |
| class Foo2 { has $!bar = 12; method test { say $bar, ' ', $bar.VAR.WHICH; say $!bar, ' ', $!bar.VAR.WHICH; } } | |
| # Error while compiling: Variable '$bar' is not declared. Did you mean '$!bar'? | |
| </code></pre> | |
| <p>So it <strong>is</strong> documented and it describes the actual behavior, as proposed in the Synopses.</p> | |
| <p>By the way, this makes twigilless attributes look even more like "low fat syntax sugar". I really don't get the sentiment that this would be some revolutionary missed opportunity in teaching Raku OO - neither "missed" nor "revolutionary". People just don't use it, it's not really a "living meme" within the community.</p> | |
| <p>Having said that, I'm still <em>not sure if</em> there can't be a good argument for twigilless attributes... although now that it became clear that it's just sugar, it's somewhat harder to imagine. 😅</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5RKKKw"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-12-21T16:25:26Z">2022-12-21 16:25</time> | |
| </div> | |
| <div class='body'> | |
| <p>@raiph - thank you for your patience and wisdom - I agree.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5RK2gS"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-12-21T18:12:29Z">2022-12-21 18:12</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The only downside I see, one that I suspect Larry did not foresee, is that someone influential on the official documentation was of like mind to you and avoided the way to teach good OO that I tried to outline above, instead unofficially deprecating twigil free attributes. One result is that most people currently learn Raku OO without ever hearing that twigil free attributes are a thing. Then, when they do, they're of no obvious value, perhaps even of negative value, because they've now learned in their mind to associate sigil'd variables with not being attributes. And then this becomes self-fulfilling. Not because twigil free attributes are worthy of deprecation, but because they've been unofficially deprecated (by documenters) which means they are currently kinda pointless despite being superb design.</p> | |
| </blockquote> | |
| <p>One of the reasons for the re-design of Perl, was that teaching it was troublesome. Especially wrt the behaviour of sigils. And I think Larry made a mistake here (again).</p> | |
| <pre><code>class A { | |
| has $foo; | |
| method bar { | |
| my $foo; | |
| # lots of code | |
| $foo = 42; # unclear whether this is the attribute or the lexical | |
| } | |
| } | |
| </code></pre> | |
| <p>You shouldn't have to look back through your code to know whether it is an attribute or a variable.</p> | |
| <p>A similar situation exists with formal parameters in blocks, where the twigil is also optional if there is at least one instance of use. Which causes all sorts of weird issues:</p> | |
| <pre><code>$ raku -e '{ my $a = $^a }' | |
| ===SORRY!=== Error while compiling -e | |
| Redeclaration of symbol '$^a' as a placeholder parameter. | |
| </code></pre> | |
| <p>So I think we need to be consistent, and call a spade a spade. <em>That</em> will allow teaching of twigils, when they're being used as first class citizens, not as something that can be ignored in some cases.</p> | |
| <p>Therefore I'm re-opening this issue.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XKIj-"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2023-03-09T15:40:57Z">2023-03-09 15:40</time> | |
| </div> | |
| <div class='body'> | |
| <p>I've been giving this issue a fair bit of thought, of and on, and I'm not sure which design decision seems correct to me. I personally find the style used in the docs (always use twigils) much more readable, but I can also see some merit in @raiph's argument that the twigil-less style provides an easier onramp for some users.</p> | |
| <p>But, even though I'm not sure of the best design, I strongly agree with one point @lizmat made: "You shouldn't have to look back through your code to know whether it is an attribute or a variable." In fact, the way Raku makes it easy to <a href="https://www.inner-product.com/posts/fp-what-and-why/#what-functional-programming-is">reason locally</a> is (normally!) one of the things I like most about Raku.</p> | |
| <p>So the fact that these two snipits produce the output they do really sucks:</p> | |
| <pre><code class="language-raku">class A { | |
| has $foo = "an attribute"; | |
| method bar { | |
| # lots of code | |
| say $foo.uc; | |
| } | |
| } | |
| A.new.bar; # OUTPUT «AN ATTRIBUTE» | |
| </code></pre> | |
| <p>and</p> | |
| <pre><code class="language-raku">class A { | |
| has $foo = "an attribute"; | |
| method bar { | |
| my $foo = "a variable"; | |
| # lots of code | |
| say $foo.uc; | |
| } | |
| } | |
| A.new.bar; # OUTPUT «A VARIABLE» | |
| </code></pre> | |
| <p><strong>However</strong>, after mulling it over, I'm not convinced that this shows a design flaw with non-twigiled attributes – I think it might just be a bug. As @lizmat also pointed out, the design allows for a similar issue with placeholder parameters but Raku won't let you use them in confusing ways:</p> | |
| <pre><code class="language-raku">say { my $a = "a variable"; | |
| $^a.uc | |
| }("an argument") | |
| # OUTPUT: ===SORRY!=== Error while compiling | |
| # Redeclaration of symbol '$^a' as a placeholder parameter. | |
| </code></pre> | |
| <p>(@lizmat I wasn't quite sure if you liked or disliked this error message; you showed it as an example of "weird issues". But, for what it's worth, I think it's <em>vastly</em> better than letting you use <code>$a</code> after declaring both <code>my $a</code> and <code>$^a</code>.)</p> | |
| <p>So, bottom line: I think that, regardless of what design decision we reach for future Raku versions, <em>right now</em> a class with a <code>$foo</code> Attribute and <code>my $foo</code> variable in one of its methods ought to throw a redeclaration ~~error~~ (<strong>edit</strong>: warning, see discussion in following comments). And IMO, not throwing that ~~error~~ warning is currently a Rakudo bug, not a design decision. Any disagreement?</p> | |
| <p>If not, I guess the next step is to open that as a Rakudo issue – which won't resolve the longer-term design decision, but will at least avoid some of the worst consequences of the current design.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XPdTR"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2023-03-10T11:28:57Z">2023-03-10 11:28</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>So, bottom line: I think that, regardless of what design decision we reach for future Raku versions, right now a class with a $foo Attribute and my $foo variable in one of its methods ought to throw a redeclaration error. And IMO, not throwing that error is currently a Rakudo bug, not a design decision. Any disagreement?</p> | |
| </blockquote> | |
| <p>Generally, declaration of a lexically scoped name that exists in an outer scope is not an error in Raku; for example, <code>sub foo() { my $x = 1; if blah() { my $x = 2; } }</code> is entirely fine. So in that sense, it'd be inconsistent.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XQ6DE"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2023-03-10T16:22:08Z">2023-03-10 16:22</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Generally, declaration of a lexically scoped name that exists in an outer scope is not an error in Raku</p> | |
| </blockquote> | |
| <p>That's true. But I'd distinguish between declaring a lexically scoped name that <em>exists</em> in an outer scope ("variable shadowing") from declaring a lexically scoped name that's <em>passed into</em> the current scope.</p> | |
| <p>Thus, as you point out, the following code is fine:</p> | |
| <pre><code class="language-raku">sub foo() { | |
| my $x = 1; | |
| if True { my $x = 2} | |
| } | |
| </code></pre> | |
| <p>But this code produces a warning:</p> | |
| <pre><code class="language-raku">sub foo($x is copy) { | |
| my $x = 2 | |
| } | |
| foo 1; | |
| </code></pre> | |
| <p>(and it errors without <code>is copy</code> or <code>is rw</code>)</p> | |
| <p>In that case, $x was passed in explicitly, but the same redeclaration warning comes up when $x is passed implicitly:</p> | |
| <pre><code class="language-raku">sub foo { | |
| $^x; | |
| my $x = 2; | |
| } | |
| </code></pre> | |
| <p>In my view, a class's attributes are much closer to the parameter-passing case than to the variable-shadowing case. After all, calling <code>C.new.foo</code> is equivalent to calling <code>foo</code> with <code>C.new</code> as its first parameter.</p> | |
| <p>Thus, in my view, the code</p> | |
| <pre><code class="language-raku">class C { | |
| has $x = 1; | |
| method foo { | |
| my $x = 2; | |
| $x | |
| } | |
| } | |
| </code></pre> | |
| <p>ought to generate the same warning as you'd get from passing <code>$x</code> to <code>foo</code> (explicitly or implicitly).</p> | |
| <p>(However, I mistakenly thought that the parameter-passing case generated an <em>error</em>. Since it only raises a warning, I withdraw my suggestion that the attribute case throw an error. It should just be a warning; I'll edit that into my previous comment.)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XQ9VP"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2023-03-10T16:32:46Z">2023-03-10 16:32</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I'd distinguish between declaring a lexically scoped name that exists in an outer scope ("variable shadowing") from declaring a lexically scoped name that's passed into the current scope.</p> | |
| </blockquote> | |
| <p>The thing is that the lexical "alias" to the attribute really <em>does</em> exist in the outer scope - that is, the scope of the class body! One can observe this by trying to use it outside of a method:</p> | |
| <pre><code>$ raku -e 'class C { has $a; say $a; }' | |
| ===SORRY!=== Error while compiling -e | |
| Variable $!a used where no 'self' is available | |
| at -e:1 | |
| ------> class C { has $a; say $a⏏; } | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5XQ_gX"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2023-03-10T16:39:16Z">2023-03-10 16:39</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The thing is that the lexical "alias" to the attribute really does exist in the outer scope - that is, the scope of the class body!</p> | |
| </blockquote> | |
| <p>Fair. But the parameter <em>also</em> exists in an outer scope, albeit a very small one: the lexical scope of the parameter list. That's why <code>sub foo($x, $y = $x + 1) {…}</code> works!</p> | |
| <p>(Of course, it's a small lexical scope that most people don't think much about. But I'd argue that the same is true of using attributes is a class body outside a method)</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="357"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/357"><span class='number'>357</span></a> - <span class='title'>Handling of non-breaking spaces when splitting to words</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-12-14T00:24:51Z">2022-12-14 00:24</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Hello,</p> | |
| <p>The TL;DR of this issue would be: non-breaking spaces are handled differently by <a href="https://docs.raku.org/routine/words">words</a> and <a href="https://docs.raku.org/language/quoting#Word_quoting:_qw">word quoting structures</a> despite both only talking about whitespaces. This also makes a number of doc code examples wrong about their output.</p> | |
| <p>The process of discovery was the following:</p> | |
| <ul> | |
| <li> | |
| <p>https://docs.raku.org/language/traps#___top "using Set subroutines (...)" part</p> | |
| <ul> | |
| <li>it produces <code>"a b"</code> and returns <code>False</code> for both code examples</li> | |
| <li>... for all bisectable6 versions</li> | |
| </ul> | |
| </li> | |
| <li> | |
| <p>https://docs.raku.org/language/quoting#index-entry-quote_%3C%3C_%3E%3E-quote_%C2%AB_%C2%BB-Word_quoting_with_interpolation_and_quote_protection:<em>%C2%AB</em>%C2%BB</p> | |
| <ul> | |
| <li>seems to work the same way as <code><<>></code> but that way also doesn't match the output in the docs: <code>("42 b", "c ")</code></li> | |
| </ul> | |
| </li> | |
| <li> | |
| <p>reason: non-breaking space!</p> | |
| </li> | |
| <li> | |
| <p>https://docs.raku.org/language/quoting#Word_quoting:_qw says:</p> | |
| <blockquote> | |
| <p>The <code>:w</code> form, usually written as <code>qw</code>, splits the string into "words". In this context, words are defined as sequences of non-whitespace characters separated by whitespace.</p> | |
| </blockquote> | |
| </li> | |
| <li> | |
| <p><a href="https://docs.raku.org/routine/words">words</a> does seem to match this description and produce the supposed output with non-breaking spaces as well</p> | |
| </li> | |
| <li> | |
| <p>both can make sense but which one is correct?</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5QefNk"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-14T00:29:14Z">2022-12-14 00:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>My impression is that not taking all whitespaces into account for quoting structures was a sincere mistake and it could simply be a Rakudo bug. However, the sole fact that the word quotes don't just identify whitespaces, unlike <code>words</code>, might hint something intentional. If it was intentional, the documentation needs to take that into account and wrong examples need to be updated.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QkOQD"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-12-14T15:49:49Z">2022-12-14 15:49</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>My impression is that not taking all whitespaces into account for quoting structures was a sincere mistake and it could simply be a Rakudo bug.</p> | |
| </blockquote> | |
| <p>I'm inclined to agree. As additional evidence, if you store a string with nonbreaking spaces in a variable and then interpolate it, those nonbreaking spaces <em>are</em> treated as word separators:</p> | |
| <pre><code class="language-raku"># NOTE: all spaces below are non-breaking | |
| say <a b c>.raku; # OUTPUT: "a b c" | |
| my $str = 'a b c'; | |
| say <\qq[$str]>.raku; # OUTPUT: ("a", "b", "c") | |
| </code></pre> | |
| <p>Unless someone disagrees, I'd say its fine to close this issue and open a Rakudo one.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q0J3Q"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2022-12-17T00:01:54Z">2022-12-17 00:01</time> | |
| </div> | |
| <div class='body'> | |
| <p>Well…</p> | |
| <p>The question is what IS the correct one? Nonbreaking spaces are tricky. We definitely consider <code>1,000,000</code> to be a single word. But oftentimes, thousands are separated with non-breaking spaces. They can also be used to designate to strings of characters that are conceptually a single word, but for whatever reason may be split visually.</p> | |
| <p>OTOH, they might be used for something as simple as preventing a break between a quote and a parenthetical notation (which isn't conceptually a single word).</p> | |
| <p>There is no perfect way, and the option is either break at all whitespace, or break at all breakable whitespace (thus FS, NBSP, NNBSP, WJ and ZWNBS would not break).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q0RLK"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-12-17T00:37:23Z">2022-12-17 00:37</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>There is no perfect way, and the option is either break at all whitespace, or break at all breakable whitespace (thus FS, NBSP, NNBSP, WJ and ZWNBS would not break).</p> | |
| </blockquote> | |
| <p>Agreed. And, given that the current implementation breaks on <em>almost</em> all spaces, it seems like it's better (and less breaking) to go in that direction. And that seems least-bad to me, anyway.</p> | |
| <p>(Incidentally, one area that always plays havoc with word counting/word division is legal citations. How many words should ideally be in <code>42 U.S.C. § 405(a)</code>? Does your answer change if I tell you that the last space (but no others) is non-breaking?)</p> | |
| <p>So, yeah, no perfect way.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q0o6t"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2022-12-17T02:46:15Z">2022-12-17 02:46</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Agreed. And, given that the current implementation breaks on <em>almost</em> all spaces, it seems like it's better (and less breaking) to go in that direction. And that seems least-bad to me, anyway.</p> | |
| <p>(Incidentally, one area that always plays havoc with word counting/word division is legal citations. How many words should ideally be in <code>42 U.S.C. § 405(a)</code>? Does your answer change if I tell you that the last space (but no others) is non-breaking?)</p> | |
| <p>So, yeah, no perfect way.</p> | |
| </blockquote> | |
| <p>So there's really two alternatives, and thankfully Raku allows for a module to fill in the other:</p> | |
| <ol> | |
| <li><code>.words</code> and <code>qw</code> are effectively equivalent to <code>.comb(/<:!Z>+/)</code></li> | |
| <li><code>.words</code> and <code>qw</code> are effectively equivalent to <code>.comb(/<:!Z+[ ]>+/)</code> (where the space between brackets there is the non-breaking characters)</li> | |
| </ol> | |
| <p>I'd probably personally go for the first one <em><strong>except</strong></em> I recall that Larry once said that he wanted the <code>.words</code> and <code>.lines</code> methods precisely so people weren't creating bad regexen to do the job and end up missing something. The question ultimately goes down to which of the two is the most likely to be the DWIM thing. After all, <em>any</em> whitespace that's not space, tab, or newline is probably inserted rather intentionally.</p> | |
| <p>But I think the first one is ultimately the simplest to explain, and anyone who does need to worry about them can (at least for <code>.words</code>) make a very easy modification in module space, etc. (And probably soon <code>qw</code> could too once slangs are more robust)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q1UqI"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-17T10:23:11Z">2022-12-17 10:23</time> | |
| </div> | |
| <div class='body'> | |
| <p>For what it's worth, I also think it's easier to "make peace" by sticking to the "all whitespaces separate words" concept. The way I see it, a non-breaking space is <em>usually</em> rather about visual presentation than the number of words. For example, you wouldn't want to break a movie title or something similar that strongly represents one concept. I don't know the definition of a "word" but in my mind, such a... well, string? would still consist of <em>multiple words</em>, just presented in a certain way.<br /> | |
| For numbers, this explanation may be less useful but I wouldn't call a sequence of digits a "word", whether it's separated by whitespace or something else - anyway, I wonder, does Raku parse nbsp separated numbers in the first place? If not then I don't think this is something to really take into account for the concept of words.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q18AS"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2022-12-17T15:57:10Z">2022-12-17 15:57</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>does Raku parse nbsp separated numbers in the first place</p> | |
| </blockquote> | |
| <p>No, but it also doesn't parse comma separated numbers either (it only allows for underscores to space digits). It <em>does</em> treat comma separated numbers as a single word for the purpose of <code>.words</code> though. The number isn't a theoretical thing, though. Since CLDR has started using both full and narrow non-break spaces in many of its number formats for major world languages, there's quite a few numbers in the real world floating around that are spaced accordingly and that number will grow. I would think most people understand that if <code>.words</code> slurps up words, it would slurp up different formats of numbers (such as <code>123,456.789</code>) and need to reparse those accordingly.</p> | |
| <blockquote> | |
| <p>I don't know the definition of a "word" but in my mind, such a... well, string? would still consist of multiple words, just presented in a certain way.</p> | |
| </blockquote> | |
| <p>Just as a background, the definition of a word is fairly nebulous. In English, in fact, we very frequently will see a progression in terms from <em>foo bar</em> to <em>foo-bar</em> to <em>foobar</em> (these are called, respectively, open, hyphenated, and closed compound words), but not all words go the full path (ice cream is just a conceptually a single thing as rainbow, and personally given that the former is a trochee and the latter a spondee, I'd actually argue the former should be one word and the latter two). Different languages can display different examples of how what's one word is really multiple or multiple words are really one (Spanish gives the wonderful example of both: <em>se lo dije</em> vs <em>díjeselo</em>, where the words/affixes are written separate or together based on position, but they are still pronounced as a single word unit either way).</p> | |
| <p>But that's just background, for the purpose of words that might have internal spaces, I'd agree that they should probably be expected to be split. The question might revolve more around what's going to be more common: encountering a purely formatting space with words, or encountering a</p> | |
| <p>I suppose we could split the baby by enforcing number boundaries (where a non-breaker would be considered a part of the word if surrounded on both sides by a number, thus units would be split but not the numbers that make them up, as those often also have NBSPs), but that's one of those extra complexities that I'm not sure if it's better to leave it to a module (because it would induce more surprise if default) or make it a part of it (because despite the complexity, it would produce the least complexity for the typical user).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q2Hjp"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-17T18:16:35Z">2022-12-17 18:16</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>No, but it also doesn't parse comma separated numbers either (it only allows for underscores to space digits).</p> | |
| </blockquote> | |
| <p>To be honest, I also don't "parse" comma separated numbers as one number, either. :P Or well, if it has exactly one comma, I would parse it as a fractional... anyway, I'm perfectly fine with settling on neither being one word, by this highly arbitrary and superficial definition of words.</p> | |
| <blockquote> | |
| <p>(...) what's going to be more common: encountering a purely formatting space with words, or encountering a</p> | |
| </blockquote> | |
| <p>Something seems to be missing here, doesn't it?</p> | |
| <p>Anyway, I think we are reaching further and further from the issue of generic word-splitting. Many of these things could be addressed by providing built-in regexes/tokens - for example, I would be happy if the patterns provided by the Rakudo parser could be accessed some way - especially since it uses many standardized concepts probably so it could easily be "more Raku than Rakudo" per se.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Q_jiw"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-12-20T04:51:55Z">2022-12-20 04:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>This is more food for thought than anything else, but here are what a few other programs make of the string <code>foo bar baz</code> (with nbsp)</p> | |
| <ul> | |
| <li>wc: 3 words</li> | |
| <li>vim: 3 words, 3 Words</li> | |
| <li>emacs: 3 words,</li> | |
| <li>emacs (evil mode): 3 words, 1 Word</li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ZRLJA"> | |
| <div class='header'> | |
| <span class='author'>@jubilatious1</span> commented at <time datetime="2023-04-05T15:21:55Z">2023-04-05 15:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>@alabamenhu said:</p> | |
| <blockquote> | |
| <p>... break at all breakable whitespace (thus FS, NBSP, NNBSP, WJ and ZWNBS would not break).</p> | |
| </blockquote> | |
| <p>Agreed.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="355"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/355"><span class='number'>355</span></a> - <span class='title'>Choose some precise (or rough) way to "adopt" modules in the Raku Module Adoption center</span></div> | |
| <div class='author'>[open]<span class='author'>@JJ</span> opend this issue at <time datetime="2022-11-30T07:52:50Z">2022-11-30 07:52</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>As you probably know, many (if not the majority) of modules in the <a href="https://github.com/raku-community-modules">Raku module adoption center (a.k.a. community modules) </a> are abandoned, with years-old issues, and mostly left to bitrot for good. | |
| Even in some cases where they are (roughly) taken care of, people step onto each other's work, or simply ignore each other, working on <code>main</code> and simply changing. | |
| This might lead to confusion, sometimes frustration, but mostly abandonment of modules that are already abandoned. | |
| What I would want is some rough policy for these modules that would cover stuff such as</p> | |
| <ul> | |
| <li>General policy for changes in them</li> | |
| <li>Release policies</li> | |
| <li>Real <em>adoption</em> policies, that is, how they should be moved to someone's repo.</li> | |
| </ul> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5PY1PM"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-30T10:04:34Z">2022-11-30 10:04</time> | |
| </div> | |
| <div class='body'> | |
| <p>I very much welcome bringing this up.</p> | |
| <p>Lately, I've been trying to touch everything that seemed remotely interesting, clearing up issues and PR's. I still have a pending PR for App::Mi6, <a href="https://github.com/skaji/mi6/pull/160">mostly unwelcome</a> - I wanted to <a href="https://github.com/kalkin/Ddt/pull/13">revive Ddt</a> but it mostly deteriorated.</p> | |
| <p>I got access granted to named group, and I felt this was actually a step forward. I finally knew my modifications won't be dangling forever. At the same time, I wouldn't want to claim exclusive ownership of all these modules that I might touch because not sure if I can maintain them on my own in the long run.</p> | |
| <p>To me, the following things seem to be the biggest problems:</p> | |
| <ul> | |
| <li>release policies. I'm done with my modification and want to publish it. How can I do that? Is there a mechanism hooked to git, based on labels for example; or do we just downright rely on who has access to the one single fez account?</li> | |
| <li>workflow processes. As you pointed out, it can happen that multiple people "claim" the same shared module simultaneously. There is no formal process of collaboration in this case.</li> | |
| </ul> | |
| <p>Regarding "real adoption", as I implied, I have mixed feelings. I think adoption can solve the "workflow process" problem (and in some sense the "release" problem as well; although it introduces further fragmentation in the ecosystem), however I believe adopted modules are at least as much prone to abandonment, and then they are really lost for good. Ddt isn't even the worst case that can happen. Talking for myself, I may want to adopt some modules I touch; most of them I'd only like to polish, directly accessing the rot feeling you mentioned.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PY6tA"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-11-30T10:22:29Z">2022-11-30 10:22</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I very much welcome bringing this up.</p> | |
| <p>Lately, I've been trying to touch everything that seemed remotely interesting, clearing up issues and PR's. I still have a pending PR for App::Mi6, <a href="https://github.com/skaji/mi6/pull/160">mostly unwelcome</a> - I wanted to <a href="https://github.com/kalkin/Ddt/pull/13">revive Ddt</a> but it mostly deteriorated.</p> | |
| </blockquote> | |
| <p>Sorry to have caused confusion here. I'm specifically talking about modules we, as a community, are responsible for, hosted by the <a href="https://github.com/raku-community-modules">Raku community modules org</a>.</p> | |
| <p>Whatever is done to "private" modules is under the responsibility of their owners. It might or might have some merit to create some ecosystem-wide policy, but that's not what I was talking about here.</p> | |
| <blockquote> | |
| <p>I got access granted to named group, and I felt this was actually a step forward. I finally knew my modifications won't be dangling forever. At the same time, I wouldn't want to claim exclusive ownership of all these modules that I might touch because not sure if I can maintain them on my own in the long run.</p> | |
| </blockquote> | |
| <p>This is not about forcing. It's more about acknowledging who are stakeholders in a specific, community-adopted module.</p> | |
| <blockquote> | |
| <p>To me, the following things seem to be the biggest problems:</p> | |
| <pre><code>* release policies. I'm done with my modification and want to publish it. How can I do that? Is there a mechanism hooked to git, based on labels for example; or do we just downright rely on who has access to the one single fez account? | |
| </code></pre> | |
| </blockquote> | |
| <p>There's a fez account <em>for the organization</em>.</p> | |
| <blockquote> | |
| <p>Regarding "real adoption", as I implied, I have mixed feelings. I think adoption can solve the "workflow process" problem (and in some sense the "release" problem as well; although it introduces further fragmentation in the ecosystem), however I believe adopted modules are at least as much prone to abandonment, and then they are really lost for good. Ddt isn't even the worst case that can happen. Talking for myself, I may want to adopt some modules I touch; most of them I'd only like to polish, directly accessing the rot feeling you mentioned.</p> | |
| </blockquote> | |
| <p>Again, I'm not talking about Ddt, who's got its properly qualified owner. That's a different topic.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PaYQC"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-30T15:09:57Z">2022-11-30 15:09</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Sorry to have caused confusion here. I'm specifically talking about modules we, as a community, are responsible for, hosted by the <a href="https://github.com/raku-community-modules">Raku community modules org</a>.</p> | |
| </blockquote> | |
| <p>There is no confusion on my side. I just brought up a few examples why "Raku community modules" is an important concept - it's really hard to contribute to random "private owned" Raku modules, even though some of them are admittedly abandoned, like Ddt. I wish that was also "donated" to the community domain.</p> | |
| <blockquote> | |
| <p>This is not about forcing. It's more about acknowledging who are stakeholders in a specific, community-adopted module.</p> | |
| </blockquote> | |
| <p>So, if I understand you right, the idea is to clarify maintainers <em>within</em> the organization?</p> | |
| <blockquote> | |
| <p>There's a fez account for the organization.</p> | |
| </blockquote> | |
| <p>I know that but someone who has just joined the contributors, like myself, probably wouldn't have access to it; and honestly, if it's really just one shared account, I'm not sure if it's a good idea in the first place to grant people login access to it.<br /> | |
| However, if this is something a few trusted individuals can manage, then we have a bottleneck for releases so I wouldn't overlook this problem.<br /> | |
| Once upon, it was mentioned that maybe fez could handle associations in some shape or form; not sure how feasible that is right now but it would be a much more comforting and sustainable position to be in.</p> | |
| <blockquote> | |
| <p>Again, I'm not talking about Ddt, who's got its properly qualified owner. That's a different topic.</p> | |
| </blockquote> | |
| <p>I don't think so, for multiple reasons:</p> | |
| <ol> | |
| <li>Ddt's <a href="https://github.com/kalkin/Ddt/pull/8#issuecomment-1288130682">properly qualified owner doesn't use Raku anymore</a>. I've tried to adopt it, the rest I have already said.</li> | |
| <li>considering the <a href="https://github.com/kalkin/Ddt#copyright-and-license">license note</a>, it seems that Ddt itself is adopted software some way.</li> | |
| </ol> | |
| <p>Considering these factors, I think it's a perfect illustration for modules that would have a happier place in the "adoption center", and what could possibly happen to some prematurely adopted modules.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Pa5Vw"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-11-30T16:45:20Z">2022-11-30 16:45</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>Sorry to have caused confusion here. I'm specifically talking about modules we, as a community, are responsible for, hosted by the <a href="https://github.com/raku-community-modules">Raku community modules org</a>.</p> | |
| </blockquote> | |
| <p>There is no confusion on my side. I just brought up a few examples why "Raku community modules" is an important concept - it's really hard to contribute to random "private owned" Raku modules, even though some of them are admittedly abandoned, like Ddt. I wish that was also "donated" to the community domain.</p> | |
| </blockquote> | |
| <p>Be that as it may, the title of this problem explicitly mentions the Raku Module Adoption Center. I would really prefer we stick to that issue, and I will most definitely not discuss anything that's not related to that.</p> | |
| <blockquote> | |
| <blockquote> | |
| <p>This is not about forcing. It's more about acknowledging who are stakeholders in a specific, community-adopted module.</p> | |
| </blockquote> | |
| <p>So, if I understand you right, the idea is to clarify maintainers <em>within</em> the organization?</p> | |
| </blockquote> | |
| <p>Correct. Including someone else that, for whatever reason, have access to that repository.</p> | |
| <blockquote> | |
| <blockquote> | |
| <p>There's a fez account for the organization.</p> | |
| </blockquote> | |
| <p>I know that but someone who has just joined the contributors, like myself, probably wouldn't have access to it; and honestly, if it's really just one shared account, I'm not sure if it's a good idea in the first place to grant people login access to it. However, if this is something a few trusted individuals can manage, then we have a bottleneck for releases so I wouldn't overlook this problem. Once upon, it was mentioned that maybe fez could handle associations in some shape or form; not sure how feasible that is right now but it would be a much more comforting and sustainable position to be in.</p> | |
| </blockquote> | |
| <p>Please read above. Fez is perfectly able to handle "associations" (organizations, that is), which is what I'm saying above.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Pbt8P"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-30T19:52:44Z">2022-11-30 19:52</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Be that as it may, the title of this problem explicitly mentions the Raku Module Adoption Center. I would really prefer we stick to that issue, and I will most definitely not discuss anything that's not related to that.</p> | |
| </blockquote> | |
| <p>My comment implicitly mentioned the Raku Module Adoption Center, and I think I've spent enough time to clarify that. Also, both of us are mentioning the abandonment of modules which can happen inside the Raku Module Adoption Center and outside of it, there are precedents for both. I'd say this is strongly related to the issue and frankly, even if you disagree with that for whatever reason I cannot see, it's frustrating that I welcome an issue that bears huge significance for whatever I've been doing in the last 3 months and someone superficially dismisses it out loud.</p> | |
| <blockquote> | |
| <p>Please read above. Fez is perfectly able to handle "associations" (organizations, that is), which is what I'm saying above.</p> | |
| </blockquote> | |
| <p>Well then, could you please elaborate on that, or at least link where I could find more about this "organization" feature? How do you, for example, make a community module release using fez? Just saying that there is a fez account does not help, I already knew that. I also have a fez account and I kinda hope you cannot make releases to my modules with it...</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="354"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/354"><span class='number'>354</span></a> - <span class='title'>`min` is presumptuous (on empty iterables)</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-11-26T02:36:12Z">2022-11-26 02:36</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p><code>min</code> returns <code>Inf</code> on empty Iterables, even though there is no reason to assume Numeric context. This makes it bothersome to work with it whenever used outside of Numeric context because there is an ad-hoc magic value to prevent from leaking.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>Hello,</p> | |
| <p>this is not the first time that I'm doing The Weekly Perl & Raku Challenges (courtesy of @manwar) and the min method bites me, heavier and heavier, in fact.</p> | |
| <p>To cite <a href="https://docs.raku.org/type/Any#routine_min">the documentation</a>:</p> | |
| <blockquote> | |
| <p>Coerces the invocant to <a href="https://docs.raku.org/type/Iterable">Iterable</a> and returns the numerically smallest element; in the case of Hashes, it returns the Pair with the lowest value.</p> | |
| </blockquote> | |
| <p>This is not true in the first place: for example, <code>((1, 2, 3), (4, 5)).min</code> returns <code>(1, 2, 3)</code> which would be the bigger element numerically. Instead, what the <a href="https://docs.raku.org/language/operators#infix_min">infix min</a> documentation states (<code>cmp</code> semantics) seems to be true.</p> | |
| <p>This already illustrates that ˙.min makes sense outside of Numeric context but the second paragraph makes it even clearer:</p> | |
| <blockquote> | |
| <p>If a <a href="https://docs.raku.org/type/Callable">Callable</a> positional argument is provided, each value is passed into the filter, and its return value is compared instead of the original value. The original value is still the one returned from <code>min</code>.</p> | |
| </blockquote> | |
| <p>This seems to be correct and intended - and this means that even if <code>min</code> only used Numeric comparison (which we have seen isn't true), it would make sense to use it on non-numeric values and it can return non-numeric values.</p> | |
| <p>In the light of this, it's errorprone that e.g <code>().min</code> will downright return <code>Inf</code>, assuming Numeric context. This means whenever there is a chance of an empty iterable showing up, the caller logic around <code>min</code> needs to be special-cased, or else we might end up checking for an inappropriate <code>Inf</code> value where it has nothing to do:</p> | |
| <pre><code class="language-raku">@normal-values.pairs.grep(*.value != 0).rotor(2 => -1).grep({ [!=] $_>>.value>>.sign }) andthen .so ?? .min({ [R-] $_>>.key }) !! Nil | |
| </code></pre> | |
| <p>... now I can tell you I didn't want to get any <code>Inf</code> from a Sequence of two-pair tuples... even a warning would have been more useful.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5PJyn0"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-26T02:51:24Z">2022-11-26 02:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>Disclaimer: the same problem affects <code>max</code> as well, which in turn returns <code>-Inf</code>.</p> | |
| <p>I think, without any adaptation that might lead far, the best option would be to just use <code>Nil</code>.</p> | |
| <ol> | |
| <li>it's conceptually compatible with all possible types</li> | |
| <li>it doesn't implicitly turn into legitimate values of the intended type - confer <code>Empty</code> which could sneak in as 0 or '', directly violating <code>min</code> semantics</li> | |
| <li>it is a falsy, furthermore undefined value so it's easy to pinpoint without awkward unreasonable boilerplate like <code>if $foo == Inf</code> would be for a supposed string, pair etc.</li> | |
| </ol> | |
| <p>It's not a perfect choice because it can also serve as a reset value of a container which then can be a defined value - however, I think it's overall more feasible than to try to define a "natural minimum/maximum" for everything that might appear in the domain of <code>min</code>, or to just downright ban it on empty iterables (which results in the same boilerplate that seems like the best solution with <code>Inf</code> as well).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PTHfS"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-29T10:27:16Z">2022-11-29 10:27</time> | |
| </div> | |
| <div class='body'> | |
| <p>How about it returning a <code>NumStr</code> ? <code>NumStr.new(-Inf,"")</code> and <code>NumStr(Inf,chr(0x10FFFF))</code></p> | |
| <p>FWIW, I think the use of <code>Inf</code> and <code>-Inf</code> actually predates the existence of allomorphs.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PTKsg"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-11-29T10:37:57Z">2022-11-29 10:37</time> | |
| </div> | |
| <div class='body'> | |
| <p>That would only cover one more type of input and I'm not sure it would even cover that well (after all a string consisting of multiple 0x10FFFF characters is a valid input). I think the problem is that a "natural" minimum/maximum only really exists for numbers. Or rather that for numbers this "natural" minimum/maximum can come in quite handy and helps avoiding additional tests. So we want that in numeric context but it hurts in all other contexts. Sadly an empty input list doesn't tell us anything about the context the result will be used in :(</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PTOUx"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-29T10:51:00Z">2022-11-29 10:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>The alternative would be to create some sentinel values, similar to <code>IterationEnd</code>, that would numerically / stringwise would <strong>always</strong> be less / more than what they're being compared to (by adding the right candidates to the comparison infix ops). And have <code>min</code> and <code>max</code> return those values.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PTQkj"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-29T10:58:55Z">2022-11-29 10:58</time> | |
| </div> | |
| <div class='body'> | |
| <p>Proof of concept, for 6.e:</p> | |
| <pre><code class="language-raku">constant MinInf = Any.new; | |
| multi sub infix:<gt>(MinInf,$ --> False) { } | |
| say MinInf gt ""; # False | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PUb0p"> | |
| <div class='header'> | |
| <span class='author'>@Leont</span> commented at <time datetime="2022-11-29T14:43:53Z">2022-11-29 14:43</time> | |
| </div> | |
| <div class='body'> | |
| <p>This sounds to me like the kind of case were returning <code>Any</code>/<code>Nil</code> makes most sense TBH.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PWlFc"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-29T21:15:38Z">2022-11-29 21:15</time> | |
| </div> | |
| <div class='body'> | |
| <p>These "numerically" in the documentation <strong>must</strong> be removed as <code>min</code> and <code>max</code> use, by default, <code>cmp</code> (structural comparison) semantics that is well defined for <code>Any</code> type in core.</p> | |
| <p><code>cmp</code> always returns an <code>Order:D</code>, but emit a <code>warn</code> when a <code>Any:U</code> is used.</p> | |
| <p>So certainly <code>min</code> and <code>max</code> could issue a 'warn' when none of its arguments are defined. Empty iterables are only the simplest case.</p> | |
| <blockquote> | |
| <p>… some sentinel values that would numerically / stringwise would always be less / more than what they're being compared to</p> | |
| </blockquote> | |
| <p>In the context of <code>cmp</code> (and by extension <code>min</code> and <code>max</code>) those sentinel values already exists:</p> | |
| <pre><code class="language-raku">say ("", "foo", -Inf, Inf, 100, -100).min; # -Inf | |
| say ("", "foo", -Inf, Inf, 100, -100).max; # Inf | |
| </code></pre> | |
| <p>On the other hand, the actual values returned by <code>min</code> and <code>max</code> when they have no defined values to work with, "compose" well with the <code>Range</code> constructed by <code>minmax</code>:</p> | |
| <pre><code class="language-raku">say ().minmax cmp Empty; # Same | |
| say ().minmax.list ~~ Empty; # True | |
| </code></pre> | |
| <p>If other values are chosen, they must retain that "closure" property.</p> | |
| <p>Finally, although it is not formally documented, the user can always change the semantic of <code>min</code> and <code>max</code>, providing the comparison operator (function of arity 2) that he needs. For example <code><=></code> or <code>leg</code> to force Numeric or String context:</p> | |
| <pre><code class="language-raku">say (8, 200, 10000, NaN).min(&infix:<leg>); # 10000 | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PXO6i"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-11-30T00:25:36Z">2022-11-30 00:25</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p><code>min</code> returns <code>Inf</code> on empty <code>Iterable</code>s, even though there is no reason to assume <code>Numeric</code> context.</p> | |
| </blockquote> | |
| <p>Where did <code>Numeric</code> context come into things?</p> | |
| <p>Quoting from Raku's design documents:</p> | |
| <blockquote> | |
| <p>any value of any type may be compared with <code>+Inf</code> or <code>-Inf</code> values, in which case the infinite value stands for "larger/smaller than any possible value of the type."</p> | |
| </blockquote> | |
| <pre><code>"foo" min +Inf # "foo" | |
| "foo" min -Inf # -Inf | |
| "foo" max +Inf # +Inf | |
| "foo" max -Inf # "foo" | |
| </code></pre> | |
| <blockquote> | |
| <p>All orderable object types must support <code>+Inf</code> and <code>-Inf</code> values as special forms of the undefined value.</p> | |
| </blockquote> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PXg5B"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-30T02:24:37Z">2022-11-30 02:24</time> | |
| </div> | |
| <div class='body'> | |
| <p>I would advise against overly protecting the status quo, as if it had some inherent value. Mind you, we are talking about something that is merely an (apparently controversial) API-level design decision, not something essential or hardwired. And I open problem solving issues with this in mind; generally presenting arguments why I think the behavior is problematic and coming up with a possible resolution.</p> | |
| <p>@raiph</p> | |
| <blockquote> | |
| <p>Where did Numeric context come into things?</p> | |
| </blockquote> | |
| <p><code>Inf</code> is a <code>Num</code> even according to the quoted design documents. I think this says it all. The minimum element of a list of <code>Str</code>s, even if empty, should never return a <code>Num</code>.</p> | |
| <blockquote> | |
| <p>Quoting from Raku's design documents:</p> | |
| </blockquote> | |
| <p>First, "Raku's design documents" are outdated, abandoned and not really followed anymore. From what I know, the only authoritative specification is Roast. Actually, this behavior is following the design documents and present in Roast - the very code snippet you included. I opened this issue as a problem solving issue exactly because I propose a change in the specification.</p> | |
| <p>Second, I looked up that part of the "old design documents" - please make sure to include links because it can be quite bothersome to search them; <a href="https://design.raku.org/S03.html">the named part comes here</a>. I don't think you should have left the first sentence of that paragraph off:</p> | |
| <blockquote> | |
| <p><strong>Not all types can support the concept of infinity.</strong> Therefore any value of any type may be compared with +Inf or -Inf values, in which case the infinite value stands for "larger/smaller than any possible value of the type."</p> | |
| </blockquote> | |
| <p>In my opinion, the design document doesn't even sound convincing - especially if we consider what I opened the issue for. My main concern isn't what <code>'foo' min -Inf</code> should return - my concern is that, despite apparently acknowledging that not all types support the concept of a natural maximum or minimum, yet an <code>Inf</code> can leak from, well, not comparing anything at all.</p> | |
| <p>By the way, I don't know if this is specced or not but apparently 'foo' is treated as the second biggest number after <code>Inf</code> - <code>'foo' min $n</code> returns $n for any other number. Is this interpretation bizarre? I'd think so but for me, saying that the smallest string of an empty list is <code>Inf</code> is just as bizarre.</p> | |
| <blockquote> | |
| <p>All orderable object types must support +Inf and -Inf values as special forms of the undefined value.</p> | |
| </blockquote> | |
| <p>I could actually agree with this but I don't think this is what we have currently. The types are "trying to play nice" with the one and only Numeric (floating point) <code>Inf</code> but they don't actually have <code>+Inf</code> and <code>-Inf</code> values they could use natively.</p> | |
| <p>Consider this piece of code:</p> | |
| <pre><code>my $input = prompt 'Insert your words here:'; | |
| my Str $first = $input.words.min | |
| </code></pre> | |
| <p>This will actually fail with a type error if the input only contains whitespace. I don't think this is what "support" means.</p> | |
| <p>@salortiz</p> | |
| <blockquote> | |
| <p>These "numerically" in the documentation must be removed as min and max use, by default, cmp (structural comparison) semantics that is well defined for Any type in core.</p> | |
| </blockquote> | |
| <p>Definitely. Ironically, I would argue the confusion could have arised from this "default to Inf" behavior.</p> | |
| <blockquote> | |
| <p>So certainly min and max could issue a 'warn' when none of its arguments are defined. Empty iterables are only the simplest case.</p> | |
| </blockquote> | |
| <p>This is insightful, I wouldn't have expected that, either. But I'm not using undefined values in Iterables, usually. And I'd assume most people also don't, most of the time. Therefore I think that could also be an interesting discussion but for now, I would focus on this particular case that I myself have used twice in this month.</p> | |
| <blockquote> | |
| <p>If other values are chosen, they must retain that "closure" property.</p> | |
| </blockquote> | |
| <p>I think this is a fair <em>argument</em> but I think it's a bit overboard to declare a "must". I for one would trade this "closure" property for type consistency, as demonstrated in the snippet above, at any moment. Apparently, type consistency wasn't a "must", although I am pretty sure that would be more useful for more people who ever come across these corner cases.<br /> | |
| Anyway, I think supporting that "closure" property shouldn't be too hard, e.g. by defining <code>Nil</code> as a range endpoint, or simply specialcasing an empty range for <code>minmax</code> (this solution would probably be more fragile out of the two).</p> | |
| <p>By the way, it's also a little interesting for a consequence that <code>(Nil, Any, Empty, Str).minmax.list ~~ Empty</code>, isn't it? Not sure what result I would expect but it did eliminate the elements big time, that's for sure. :)</p> | |
| <p>Also, I think if we scratched the surface a little harder, we could bump into more not-so-strangely-consistent things: <code>(1, 'foo')</code> has a <code>min</code> of 1, a <code>max</code> of 'foo' but it fails to provide <code>minmax</code> because such Ranges cannot be constructed in Raku (for now, at least).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Pa4el"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-11-30T16:42:37Z">2022-11-30 16:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>On Wednesday, 30 November 2022 03:24:48 CET Márton Polgár wrote:</p> | |
| <blockquote> | |
| <p>I would advise against protecting the status quo, as if it had some inherent | |
| value.</p> | |
| </blockquote> | |
| <p>But it does? After all we promised to stay backwards compatible to existing | |
| code when we made the 6.c release. Granted, we have broken it quite a few | |
| times already, but always with reluctance and good reason.</p> | |
| <blockquote> | |
| <blockquote> | |
| <p>Quoting from Raku's design documents: | |
| First, "Raku's design documents" are outdated, abandoned and not really | |
| followed anymore.</p> | |
| </blockquote> | |
| </blockquote> | |
| <p>While the design documents aren't kept up to date anymore, they still have | |
| worth. They often explain the reasoning behind the specification (i.e. Roast). | |
| In this case they explain why <code>Inf cmp "cat"</code> returns <code>More</code> and point at a | |
| way out of this conundrum. Maybe everything actually is fine just as it is and | |
| all we need is better documentation.</p> | |
| <blockquote> | |
| <p>my $input = prompt 'Insert your words here:'; | |
| my Str $first = $input.words.min</p> | |
| <pre><code> | |
| This will actually fail with a type error if the input only contains | |
| whitespace. I don't think this is what "support" means. | |
| </code></pre> | |
| </blockquote> | |
| <p>That would be a bug then, as it doesn't follow the "All orderable object types | |
| must support +Inf and -Inf values as special forms of the undefined value" | |
| rule.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbI2I"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-30T17:35:55Z">2022-11-30 17:35</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>But it does? After all we promised to stay backwards compatible to existing | |
| code when we made the 6.c release. Granted, we have broken it quite a few | |
| times already, but always with reluctance and good reason.</p> | |
| </blockquote> | |
| <p>Honestly, I don't think I can relate to this statement. I can only say that it definitely doesn't look like this promise have been kept, or even consistently followed in the core. The renaming and all that it involved/involves is the dead horse we can always beat but I could refer to the "build-depends", "test-depends" deprecation in META.json that ugexe didn't even notice back in the day, or the issue I opened about in fact <a href="https://github.com/Raku/problem-solving/issues/351">revoking a semi-implemented deprecation</a>. So I feel by now, only the casual reluctance to change things remained from that policy...</p> | |
| <blockquote> | |
| <p>While the design documents aren't kept up to date anymore, they still have worth.</p> | |
| </blockquote> | |
| <p>I wholeheartedly agree with this, and they indeed explain a lot of things about hyper metaoperators that I opened <a href="https://github.com/Raku/problem-solving/issues/346">a humongous issue about</a>. It could have helped greatly, still could. For me, that's still an open issue, though.</p> | |
| <blockquote> | |
| <p>In this case they explain why <code>Inf cmp "cat"</code> returns <code>More</code> and point at a way out of this conundrum.</p> | |
| </blockquote> | |
| <p>I have already said why I think that is <em>not</em> the case here. The document states that not all types support the concept of a minimum and a maximum - and reaches the conclusion that all types need to integrate <code>+Inf</code> and <code>-Inf</code>? I don't think this is a good explanation. It is not only vague but to me, it sounds contradictory, even - therefore unless it's authoritative (which it isn't), I don't find much value in quoting it. Unlike many other cases, of course.</p> | |
| <blockquote> | |
| <p>That would be a bug then, as it doesn't follow the "All orderable object types | |
| must support +Inf and -Inf values as special forms of the undefined value" | |
| rule.</p> | |
| </blockquote> | |
| <p>As I brought it up on the raku-dev IRC as well, I think that ship has actually sailed "much harder" than changing the return value of <code>min</code> and <code>max</code> for empty Iterables, at least. If these are floating point, <code>Num</code> values, what sort of special-casing would it take in the type system to allow them as undefined values for another type? Currently, not even <code>Num</code> would pass as an undefined value for <code>Str</code> or <code>List</code>, and at the same time <code>Inf</code> is <em>defined</em> which might even make sense if we look at it as a <code>Num</code> value. I honestly can't even imagine the magic involved to make a <code>Num</code> value pretend it's undefined for a different type, and possibly also pretending that it's defined for <code>Num</code> and possibly other <code>Numeric</code> types as well... how many breaking changes would that "fix" involve?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbKyh"> | |
| <div class='header'> | |
| <span class='author'>@Leont</span> commented at <time datetime="2022-11-30T17:43:05Z">2022-11-30 17:43</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>As I brought it up on the raku-dev IRC as well, I think that ship has actually sailed "much harder" than changing the return value of min and max for empty Iterables, at least. If these are floating point, Num values, what sort of special-casing would it take in the type system to allow them as undefined values for another type? Currently, not even Num would pass as an undefined value for Str or List, and at the same time Inf is defined which might even make sense if we look at it as a Num value. I honestly can't even imagine the magic involved to make a Num value pretend it's undefined for a different type, and possibly also pretending that it's defined for Num and possibly other Numeric types as well... how many breaking changes would that "fix" involve?</p> | |
| </blockquote> | |
| <p>Yeah, all of that. This just isn't a workable concept.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbNhC"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-30T17:53:35Z">2022-11-30 17:53</time> | |
| </div> | |
| <div class='body'> | |
| <p>The beauty of the matter is that all this is implemented directly in Raku and better than discussing it is presenting a concrete proposal. Lizmat is already working on a draft of what could be a solution for v6e, let's wait and see how it progresses.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbPWZ"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-30T18:00:26Z">2022-11-30 18:00</time> | |
| </div> | |
| <div class='body'> | |
| <p>Actually, trying to implement this, and seeing <em>nine</em>'s response on channel, I'm starting to think that adding special infix candidates (like done in this PR), but instead use <code>Inf</code> for <code>Most</code>, and <code>-Inf</code> for <code>Least</code> would actually make the most sense.</p> | |
| <p>Still mulling over this, though :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbfMK"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-30T19:03:00Z">2022-11-30 19:03</time> | |
| </div> | |
| <div class='body'> | |
| <p>Adding:</p> | |
| <pre><code class="language-raku">multi sub infix:<eq>(Inf, Inf --> Bool::True) { } | |
| multi sub infix:<eq>(Inf, \b --> Bool::False) { } | |
| multi sub infix:<eq>(\a, Inf --> Bool::False) { } | |
| </code></pre> | |
| <p>to the core makes this test fail in roast:</p> | |
| <pre><code class="language-raku">ok( $x eq 'Inf', 'string equal'); | |
| </code></pre> | |
| <p>So this will probably at least need to be moved to 6.e only.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbhKq"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-30T19:10:23Z">2022-11-30 19:10</time> | |
| </div> | |
| <div class='body'> | |
| <p>Why would you need to modify the semantics of <code>eq</code>? | |
| This is basically <code>cmp</code>, <code>min</code>, <code>max</code> and <code>minmax</code> territory, no?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbjL8"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-30T19:18:30Z">2022-11-30 19:18</time> | |
| </div> | |
| <div class='body'> | |
| <p>because if you expect the result of a <code>(...).min</code> to be a string, you would be using <code>eq</code> for testing</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbnI9"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-30T19:30:41Z">2022-11-30 19:30</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't expect the result of <code>min</code> to change until 6.e.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PboH1"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-30T19:32:25Z">2022-11-30 19:32</time> | |
| </div> | |
| <div class='body'> | |
| <p>Oh, definitely... I was just trying out stuff :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PbqeI"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-30T19:37:36Z">2022-11-30 19:37</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Actually, trying to implement this, and seeing nine's response on channel, I'm starting to think that adding special infix candidates (like done in this PR), but instead use Inf for Most, and -Inf for Least would actually make the most sense.</p> | |
| </blockquote> | |
| <p>I either don't understand what you mean, or I can't see how that would address the very issue of empty Iterables returning <code>Num</code>-typed <code>Inf</code> values, regardless the actual context. I've had an issue that had <a href="https://github.com/Raku/problem-solving/issues/350">completely the opposite resolution what I opened it for</a>, please, not again.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Pbrk8"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-30T19:42:46Z">2022-11-30 19:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>@2colours We try to be data driven here. The fact that a previous issue that you opened didn't get the resolution you wanted, will never affect the resolution of this issue. So saying:</p> | |
| <blockquote> | |
| <p>had completely the opposite resolution what I opened it for, please, not again.</p> | |
| </blockquote> | |
| <p>is what I would call, rather immature (put rather more radically than I normally would)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Pb19o"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-30T20:26:12Z">2022-11-30 20:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>@lizmat I don't know if the banally rational logic of "I won't open issues if I can anticipate the opposite will be done to what I want to achieve" is immature or not, However, I could have elaborated more on what I don't want to be repeated.</p> | |
| <p>I presented a whole reasoning why something that did work made sense and was useful and basically all of it was neglected in the nature of "something that was supposed to be useless incidentally turned useful, fix the regression". I put effort into reasoning for an improvement and got slapped by the dogma.</p> | |
| <p>This is what I mostly want to avoid. Ending up on the "losing side" of a constructive discourse is fine, however, if we fall back to "how about somehow save <code>Inf</code> in comparisons" while ignoring all the incoherence that arises around it, I think that would be more like getting slapped by the dogma, again.</p> | |
| <p>Also, please keep in mind that problems and solutions are two different things. I opened the issue for one particular problem: empty Iterables not knowing what kind of data they stand for, and presumptiously deciding on certain <code>Num</code> values, <code>Inf</code> and <code>-Inf</code> to be used as minimum and maximum. I had a proposal regarding that (returning <code>Nil</code> instead), which Leon seemed to support. Then we rallied off to the broader topic of <code>Inf</code>s as universal sentinel values, and there has been some brainstorming about how to "support Inf values for all ordered types", as the "old design documents" declared. I don't see how this addresses the issue I raised, and it doesn't seem like anyone has a simple idea how to support the type safety of the <code>my $first = $input.words.min</code> snippet and all of this kind.</p> | |
| <p><strong>So I'd like to ask you all to either explicitly state that you consider the original issue a non-issue about a feature - I'd be happy with an attached reasoning in this case - or please propose solutions that actually address the issue.</strong></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PcKoy"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-11-30T21:57:32Z">2022-11-30 21:57</time> | |
| </div> | |
| <div class='body'> | |
| <p>I would like to point out that nothing of consequence happened. No design was chosen. No commits were merged to rakudo's master branch. All that happened was some discussion, some learning about design docs, some brainstorming and experimentation with code.</p> | |
| <p>That's actually what the whole problem-solving process is about. Someone states a problem and creative minds explore solutions and hopefully we come up with a design that takes all different aspects into account. It may even be your intuitively picked favorite solution with the added bonus of a whole group having high confidence that it's also the right solution.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="353"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/353"><span class='number'>353</span></a> - <span class='title'>Artistic License not a default on Github</span></div> | |
| <div class='author'>[open]<span class='author'>@coke</span> opend this issue at <time datetime="2022-11-13T21:00:29Z">2022-11-13 21:00</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>When creating a new repository on github, you have an option to select a license from a drop down. Artistic License 2.0 isn't one of those options.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>Someone should submit a request to GH to add the most common Raku module license.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5PYWWZ"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-11-30T08:12:02Z">2022-11-30 08:12</time> | |
| </div> | |
| <div class='body'> | |
| <p>It's simply not possible to do that, or if it were, we would have no guarantee that it would be accepted. | |
| What GitHub does is to use license description from <a href="https://github.com/spdx/license-list-XML">SPDX, described here</a>. For instance, <a href="https://github.com/spdx/license-list-XML/pull/1167">this change to the Artistic license you're mentioning</a>. | |
| That's the extent of it, however. Whatever GitHub uses to pick a few "default" licenses, it's their own policy. | |
| At any rate, this would be something for The Perl and Raku foundation, not the Raku community.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5PaFkk"> | |
| <div class='header'> | |
| <span class='author'>@coke</span> commented at <time datetime="2022-11-30T14:31:37Z">2022-11-30 14:31</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm confused - it's not possible to... open a ticket? (I get we don't control it, it's their policy, and they might reject it - but they won't consider it at all if we don't ask them.)</p> | |
| <p>"Change you're mentioning" - I didn't mention this change, not sure what you're referring to;</p> | |
| <p>The SPDX list does include artistic 2.0 ... is this just to highlight that the decision of what to include is github's?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Pa35E"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-11-30T16:40:52Z">2022-11-30 16:40</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I'm confused - it's not possible to... open a ticket? (I get we don't control it, it's their policy, and they might reject it - but they won't consider it at all if we don't ask them.)</p> | |
| </blockquote> | |
| <p>You can most definitely ask customer support. Or open a discussion in github.community. That last one will at least have the nice side effect of being public. However, I don't think that will buy you anything. Or that you will need community endorsement or support for doing any of that.</p> | |
| <blockquote> | |
| <p>"Change you're mentioning" - I didn't mention this change, not sure what you're referring to;</p> | |
| <p>The SPDX list does include artistic 2.0 ... is this just to highlight that the decision of what to include is github's?</p> | |
| </blockquote> | |
| <p>It does, and after the PR, with a correct link to its definition. However, what you were mentioning is which ones of these available (and recognizable) licenses are available by default; only a few of them are available, I guess by choice of some product manager. It's not, as some other features (the documentation, the heuristics to recognize languages, or the gitignore files, to name the ones I've in the past interacted with) open to community suggestions, or requests, as far as I can tell.</p> | |
| <p>Even if there was a way of doing that, Raku stuff is not the one that majoritarily uses Artistic -- Perl is. So if there's some petitioning happening, it would probably have some real heft if it's done under the umbrella organization that covers us both... Not us.</p> | |
| <p>Long story short: it's not a problem, but if it is, it's not <em>our</em> problem (as in ours and no one else's): it's TPRF's.</p> | |
| <p>BTW, the only thing that dropdown menu does is to create a LICENSE file with the correct content. You can achieve the same with any of the existing Raku distro templates (I created one, there must be others) or with any of the generators. Unfortunately, if you try to "add" a license from the "community standards" page, it's not there either. I guess it's not popular enough for that, or who knows. But, again, it's a product decision which is apparently closed to our community.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="352"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/352"><span class='number'>352</span></a> - <span class='title'>Wanted: new Raku Infrastructure jack-of-all-trades</span></div> | |
| <div class='author'>[open]<span class='author'>@rba</span> opend this issue at <time datetime="2022-11-13T20:48:26Z">2022-11-13 20:48</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>In spring 2019 I decided to jump in spontaneously when realised the official perl6.org website was down. And for me it was personally unacceptable, then if information from a community driven programming language is not publicly available, it's not existing any more. | |
| Quickly @maettu was convinced as partner to join to help out on the infrastructure side. | |
| And while relatively quickly it was clear that this based on a hardware issue with the <em>main</em> server, we have realised that far more went down during this hardware outage. Not only the public website, but many developer resources went offline. | |
| Together with help of many people, especially @moritz, @lizmat and @niner we have been able to reinstall the public websites back on the sponsored server of AtIKON (🙏). Other devs themselves did bring back the missing developer resources.</p> | |
| <p>During 2019 many ideas where collected to improve the infrastructure. While some things went quite well, like setting up a central password store (thanks to 1password). Others like containerising the websites went only part of the distance. Luckily @patrickbkr made the whole way with rakubrew.org.</p> | |
| <p>My family and my day-job keeps me busy most of my time. This ended up in the situation where we are now. I tried to keep things alive and to make sure other community members have the chance proceed, was my main goal during the last time. While I don't like to speak for @maettu, I feel he is suffering too in lack of time.</p> | |
| <p>Now we need some fresh blood. Personally I hope someone will continue where we have left off. And new ideas are welcome! | |
| And I hope we find a team of two again. It's a good feeling when you know someone covers your back. Many thanks @maettu!!!</p> | |
| <p>If you're interested, please let us know.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5ORSkD"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-11-14T06:22:29Z">2022-11-14 06:22</time> | |
| </div> | |
| <div class='body'> | |
| <p>Thanks a lot for your service, willingness, and passion so far. I understand this perfectly.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OVWG-"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-14T18:46:45Z">2022-11-14 18:46</time> | |
| </div> | |
| <div class='body'> | |
| <p>Could somebody elaborate a bit on what this work covers? From what I can tell, this sort of activity was very much hidden from our eyes for the most part, at least I have barely come across any pointers about it. Perhaps this was unfortunate with regards to giving credit as well, but for now, it would be good to raise awareness for the supposed volunteers as well.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OViq1"> | |
| <div class='header'> | |
| <span class='author'>@maettu</span> commented at <time datetime="2022-11-14T19:31:03Z">2022-11-14 19:31</time> | |
| </div> | |
| <div class='body'> | |
| <p>@rba did almost all of the work. Thank you for doing it all!</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OXJbN"> | |
| <div class='header'> | |
| <span class='author'>@BloomingAzaleas</span> commented at <time datetime="2022-11-15T02:55:10Z">2022-11-15 02:55</time> | |
| </div> | |
| <div class='body'> | |
| <p>Agree with @2colours, some descriptive breakout of the tasks (daily, weekly, monthly,...) and skills required would be helpful. Sure there may be people with super jack-of-all-trades skills AND available time, but I suggest these people are rare. Also, as we see here, there is risk to operational continuity when there are only 1 or 2 volunteers. Smaller time commitments across a wider skills/people inventory (meaning a higher count of volunteers) would reduce the continuity risk of losing a volunteer. Coordination effort increases with people count of course, but coordination/project management is also a time-contributable skill. A descriptive breakout would help prospective volunteers identify skills niches and potential time commitments. For myself, it would be the utmost charity to say my hands-on skills are merely stale but gosh I know how to patiently herd cats toward the operational discipline of a business-critical IT service.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="351"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/351"><span class='number'>351</span></a> - <span class='title'>Deprecation of flatmap is foggy and debatable</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-11-11T00:41:09Z">2022-11-11 00:41</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Leon Timmermans directed my attention to the situation of flatmap. If you visit the <a href="https://docs.raku.org/routine/flatmap">documentation of it</a>, you can see that Any.flatmap appears as "deprecated as of v6.d and to be removed in v6.e" while List.flatmap only appears as discouraged. The issue is about the current situation, process, intentions and reasons. There are two goals of this issue:</p> | |
| <ol> | |
| <li>to reach a clear situation with <code>flatmap</code></li> | |
| <li>to potentially keep <code>flatmap</code> from being deprecated and removed</li> | |
| </ol> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <h2>1. The current Rakudo behavior (Rakudo v2022.07 on MoarVM 2022.07)</h2> | |
| <pre><code class="language-sh">raku -e '"asd".flatmap: { $_, "Lol" } andthen .say' # (asd Lol) | |
| raku -e 'use v6.e.PREVIEW; "asd".flatmap: { $_, "Lol" } andthen .say' # (asd Lol) | |
| </code></pre> | |
| <p>As we can see, there are no hints of <code>Any.flatmap</code> being deprecated, let alone removed.</p> | |
| <h2>2. Roast</h2> | |
| <p><code>flatmap</code> appears at two places in the Roast repository:</p> | |
| <ol> | |
| <li>at the <a href="https://github.com/Raku/roast/blob/master/docs/announce/6.d.md">announcement of language release v6.d</a></li> | |
| <li>at the <a href="https://github.com/Raku/roast/blob/50b47539c90da9b4786fc7d74b56e96c8a848588/S03-metaops/hyper.t#L376">nodality test of hyper metaoperator</a></li> | |
| </ol> | |
| <p>The former is about <code>Any.flatmap</code> while the latter uses <code>List.flatmap</code>. By the way, the latter appearance predates the former by a lot so I already couldn't decide if the distinction was intentional or not. However, the former also seems to be rather low for a "footprint" of a language change. Is there a way to define removed features in Roast at all?</p> | |
| <h2>3. <code>Any.flatmap</code> vs <code>List.flatmap</code></h2> | |
| <p>For this, I think we need to go back in time: <a href="https://github.com/Raku/old-issue-tracker/issues/5989">RT archive for deprecation</a> <a href="https://github.com/Raku/doc/issues/1428">discussion about the hint in the docs</a>.</p> | |
| <p>What I see... or well, better said, what I <em>don't see</em> is a clear intent that explains the apparently different fate of <code>Any.flatmap</code> and <code>List.flatmap</code>. I barely even see awareness of these two distinct things in these discussions. I couldn't decide if they were supposed to have the same fate (and Zoffix just missed it for v6.d), or there is a reason to remove it from <code>Any</code> but not <code>List</code>.</p> | |
| <p>For me personally, it seems an odd choice to keep it and kindly discourage it at one place and ditch it at another, generally less common place. Also, I think <code>List</code> methods that are defined for <code>Any</code> in order to support "listy" behavior for as many types as possible. Is this separation common that something is deliberately only defined for <code>List</code>s? Anyway, here, I don't see a clear and trackable decision.</p> | |
| <p>Anyway, I think there should be at least reassurance if that was indeed the intention (to keep <code>List.flatmap</code> and drop <code>Any.flatmap</code>).</p> | |
| <h2>4. Is the deprecation right?</h2> | |
| <p>I will refer to the former links again because that's all I know and have: <a href="https://github.com/Raku/old-issue-tracker/issues/5989">RT archive for deprecation</a> <a href="https://github.com/Raku/doc/issues/1428">discussion about the hint in the docs</a>.</p> | |
| <p>As the question implies, I'm not sure about the (supposedly predetermined) answer. It could be that we lack proper archives. (I must be honest, it's emotionally damaging to read IRC logs from a certain era.) Eventually, I couldn't see any additional information on the deprecation of <code>flatmap</code> so I'm left with the same feelings as Leon was in 2018: it does seem like basically a handful of people cared and made benefit of others' apathy / lack of communication. This would also explain the highly incomplete procedure of the deprecation - those people who facilitated this change aren't really present/active anymore.</p> | |
| <p>The way I understand the situation:</p> | |
| <ol> | |
| <li><code>flatmap</code> was originally highly regarded because of Perl 5 legacy (<code>map</code> behavior in Perl 5)</li> | |
| <li>after the Great List Refactor, this behavior became less relevant and also easy to mimic using <code>.map</code> and <code>.flat</code></li> | |
| <li>mainly because of the naming scheme of <code>deepmap</code> and <code>duckmap</code> (and an additional documentation issue around <code>flatmap</code>), a rather limited set of people decided that <code>flatmap</code> does more harm than good</li> | |
| <li>this wasn't properly communicated and proponents left anyway so we ended up in this foggy situation with semi-deprecated <code>flatmap</code> that is absolutely valid for contemporary Rakudo still</li> | |
| </ol> | |
| <p>I think we need to resolve the situation in a consistent manner, preferably addressing all main points.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5OJg5A"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-11T01:27:29Z">2022-11-11 01:27</time> | |
| </div> | |
| <div class='body'> | |
| <p><strong>My stance:</strong></p> | |
| <p>I think the deprecation should be revoked (for both <code>Any.flatmap</code> and <code>List.flatmap</code>) for the following reasons:</p> | |
| <ul> | |
| <li>I think the arguments made against <code>flatmap</code> misrepresented the weight of certain points: | |
| <ul> | |
| <li>the feature was there and its presence was completely aligned with Raku's deliberate redundance; it would take serious arguments to deprecate and remove something that has no apparent, objective issues. Rendering a method as "yet another thing to maintain, yet another possible name collision etc." in a batteries included++ language seems way off.</li> | |
| <li>I don't think doing stuff differently from either Perl or any other language is a virtue by itself. The fact that <code>flatmap</code> is a familiar name for a familiar thing for many people coming from different languages <em>does matter</em>. It's not everything but it's definitely more than nothing.</li> | |
| <li>similarly, I think if this feature is commonly used enough across very different languages - and has its legitimate uses in Raku as well - that in itself justified its existence just enough to not be deliberately removed</li> | |
| <li>I find <code>deepmap</code> and especially <code>duckmap</code> very confusing and arguably less useful, so I don't empathize with the "what about those people who think <code>flatmap</code> is like <code>deepmap</code>"; exactly because of the very different use, I don't think that's necessarily the concern of a user of one of these things what the other thing does</li> | |
| <li>for the previous reasons, I completely disagree with the sentiment that presented people who have wrong assumptions about <code>flatmap</code> as "Perl 6 experts". Raku is regularly proven to be the language that one single person cannot use to the greatest extent because its size, and this is <em>by design</em>. A Raku expert doesn't have a reductionist approach to mistake an otherwise widely known paradigm to some peculiar Raku utility functions.</li> | |
| <li>the argument that you can do <code>flat</code> followed by <code>map</code> seems very weak to me | |
| <ul> | |
| <li>I welcome Leon's sentiment that it's tidy to keep the callback at the end rather than chain an additional method call after</li> | |
| <li>doing subroutine style <code>flat map ...</code> with no parens might look clever but avoiding parens scales worse with composing expressions than even method chaining does. Trust me, as an <code>andthen</code> chain advocate following the footsteps of Jan Krňávek, I have experience with the gotchas it can cause.</li> | |
| <li>the <code>flat .map(...)</code> example was particularly ironic: not only Zoffix was confused by it but even right now, I thought "nope, that wouldn't work after allowing white spaces in method chaining". The participants talked a lot about expertise - I think I have decent knowledge of Raku by now and they provided an alternative that caught me even fully aware of the topic (while it also tripped Zoffix Znet at first)</li> | |
| <li>and anyway, a reiteration: this in itself surely wouldn't justify removing a fully working thing from Raku of all languages?</li> | |
| </ul> | |
| </li> | |
| </ul> | |
| </li> | |
| <li>I'm generally against "silent disapproval" like the case of <code>List.flatmap</code> - since it's even in Roast, it seems a bit like mocking our own language (for what it's worth, I generally dislike "traps" as well, for the same reason)</li> | |
| <li>since it was added/modified in Roast after the Great List Refactor, I think it's just authoritative enough. If it's a legitimate part of the language, what is the point of "outcasting" the similar method of <code>Any</code> that follows a usual pattern of supporting <code>List</code> features as long as something can be meaningfully coerced into a <code>List</code>?</li> | |
| <li>as this deprecation hasn't been actually implemented in any way, it's not a damaging "change of plans" to revoke it</li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OJtit"> | |
| <div class='header'> | |
| <span class='author'>@Leont</span> commented at <time datetime="2022-11-11T02:58:40Z">2022-11-11 02:58</time> | |
| </div> | |
| <div class='body'> | |
| <p>I find this deprecation entirely baffling. I find myself <code>flatmap</code>ping quite often, and I've repeatedly seen use-cases in other people's code too.</p> | |
| <p>I would also like to note that this method is present in several other modern languages such as <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/flatMap">Javascript</a>, <a href="https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.flat_map">Rust</a>, <a href="https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/flat-map.html">Kotlin</a> and <a href="https://www.geeksforgeeks.org/scala-flatmap-method/">Scala</a> (and probably many others); I'm genuinely puzzled by the suggestion that it's confusing when they don't find it confusing.</p> | |
| <p>It's particularly annoying because the alternatives are all harder to read. <code>@foo.map({ ... }).flat</code> is hard to read because of end-weight issues, especially if the map block contains multiple lines. <code>flat @foo.map({ ... })</code> contains a reversal of order (left to right for the method call and but right to left for function call), a break of the method chain and has subtle precedence issues. <code>flatmap</code> is usually the most readable option available in my experience.</p> | |
| <p>But most of all I find the process here disheartening. It was removed with very little communication with the wider community, and even when objections were raised soon after these were not taken seriously; telling people a feature is <em>"virtually useless"</em> when several people have said they do find it useful rather feels like talking to a wall. This is the sort of feature that is either incredibly useful and obvious or entirely useless depending on one's programming style; it rather feels like the alternatives were proposed by people who weren't using this feature in the first place and hence didn't understand why the stated alternatives were dissatisfying.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OLoeY"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-11T13:01:31Z">2022-11-11 13:01</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't think <code>.flatmap</code> is actually deprecated in the core???</p> | |
| <p>And it's used everywhere in the core?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ON4O0"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-11T23:21:07Z">2022-11-11 23:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>@lizmat do I understand you correctly: this deprecation policy was never in actual effect for Rakudo-related content in the first place?</p> | |
| <p>If that really is the case, I would say that's one less reason to stick to it...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OOeq-"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-12T09:03:44Z">2022-11-12 09:03</time> | |
| </div> | |
| <div class='body'> | |
| <p>What I'm saying is that using <code>flatmap</code> in your code never actually gave a DEPRECATED warning. And nobody reads documentation, so nobody knew about any <code>flatmap</code> deprecation.</p> | |
| <p>So I think this is mostly a documentation issue.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OOomR"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-12T11:30:40Z">2022-11-12 11:30</time> | |
| </div> | |
| <div class='body'> | |
| <p>See my issue headings 1 and 2. Seems like nobody reads issues... :)</p> | |
| <p>As a sidenote: I don't think the sole fact that something hasn't been implemented in Rakudo is a decisive language design argument. It's clear that <em>there has been intention to deprecate and remove <code>flatmap</code></em>. Therefore, you can say out of respect for the supposed design process, I presented this deprecation as a real but unimplemented part of the design.</p> | |
| <p>So overall I agree with the conclusion despite disagreeing with the implications ("if it's not in Rakudo, it doesn't exist").</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="350"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/350"><span class='number'>350</span></a> - <span class='title'>Smartmatching to S/// is not a bug but a feature</span></div> | |
| <div class='author'>[closed]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-11-01T22:19:42Z">2022-11-01 22:19</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p><code>'almafa' ~~ S/a/e/</code> (along with any smartmatch to an S/// construct) produces a "worry", even though the <em>already existing</em> behavior is reasonable and already has analogous precedents with other regex quoting constructs.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>To provide some context regarding the phenomenon:</p> | |
| <ul> | |
| <li>the message: <code>Potential difficulties: Smartmatch with S/// is not useful. You can use given instead: S/// given $foo</code></li> | |
| <li>the check was introduced a bit before "Christmas": https://github.com/rakudo/rakudo/commit/f54ff83371a6510a74adda65d0ff44427990bada</li> | |
| <li>this was changed in a couple of months to the current message with https://github.com/rakudo/rakudo/commit/be210fbaaf12a4a697d26c5fe2e5acca7e21640d. The explanation provided is here: https://github.com/Raku/old-issue-tracker/issues/5273</li> | |
| <li>the behavior is documented under https://docs.raku.org/language/regexes#S///_non-destructive_substitution, confer the "note" part. Actually, one could argue that it's inaccurate because the created message is not a run-time "warning" but a compile-time "worry" but that's beside the point for now.</li> | |
| </ul> | |
| <p>Here I am going to argue that the behavior should not be considered "worrying", without any modification otherwise.</p> | |
| <ol> | |
| <li><em><strong>Smartmatching =/= given/when</strong></em> | |
| The core idea behind labelling smartmatch with S/// as "useless" is that <code>when S/a/e/ {}</code> is indeed useless. However, we do use smartmatching with completely different motives than given/when structures. The documentation is a good example: it's full of code that uses smartmatching to regexes in order to obtain the match object, for example: <code>say "Zen Buddhists like Raku too" ~~ $regex; # OUTPUT: «｢Raku｣» </code>. If smartmatching exists (and is commonly used) outside of boolean context, why not acknowledge that smartmatching per se isn't a problem with S///?</li> | |
| <li>Strong analogy with smartmatch to m// or // | |
| This is mostly a refinement of the previous point. <code>$a ~~ S/x/y/</code> and <code>$a ~~ m/x/</code> aren't only visually similar; their behavior is strongly analogous: | |
| <ul> | |
| <li>setting the match variable $/, based on the matched pattern</li> | |
| <li>returning according to the operation (m matches, S substitutes)</li> | |
| </ul> | |
| </li> | |
| <li>The advice of the worry message ("You can use given instead") isn't convincing | |
| While <code>~~</code> is an operator that you can use as many times in an expression as you wish, <code>given</code> is a statement modifier that you can only use once in a statement. They are on different conceptual levels. The situation can be improved by using <code>andthen</code> for setting the topic variable, or using a <code>.&{ S/// }</code> call on something; however, if your intention with using smartmatch for substitution was clear, these all still seem workarounds, not proper alternatives.</li> | |
| <li><code>$foo ~~ S/a/b/ ~~ S/c/d/</code> is a good-looking paradigm :) | |
| I admit that this might be an unusual take but I definitely consider it a pro, worth mentioning. Thanks to the topic-setting nature of smartmatching (i.e the same thing that makes substitution with smartmatching possible in the first place), this chain will (although with redundant steps) execute just right, hence making S/// itself more useful. I wouldn't be surprised if the execution could be optimized almost with the same effort as the "worry" is generated; the syntax to recognize is almost the same. Mind you: this works "for free", completely respecting the properties of smartmatching - except the unwritten, implicit, already violated expectation that it should be boolean-centric.</li> | |
| </ol> | |
| <p>For me, this issue was already insightful, and I think it's good to think about smartmatching for a while. I personally think that as easily as removing a "worry" and a "note" from the documentation, we could increase both consistency and fun, and that might be the easiest way out. However, there are theoretical implications (mostly about smartmatch but also about these regex "operators") that can be investigated in many different ways.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5NeYrE"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-02T08:30:26Z">2022-11-02 08:30</time> | |
| </div> | |
| <div class='body'> | |
| <p>If your real concern is the "worry" produced by the compiler, these can be turned off by a simple 'no worries` pragma.</p> | |
| <pre><code class="language-raku">{ no worries; say 'almafa' ~~ S/a/e/ } # False | |
| </code></pre> | |
| <p>But I don't understand your use case.</p> | |
| <p>The <code>S///</code> operator returns a <code>Str</code>, not a <code>Regex</code>, so when used as the RHS of the smartmatch operator ask for a <strong>string equality comparison</strong> that returns a <code>Bool</code>, that will be <code>True</code> if and only if the substitution requested becomes a NOP (i.e. nothing was substituted). Anyway the result of the substitution is lost.</p> | |
| <p>Am I missing something?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NfGSt"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-02T10:24:01Z">2022-11-02 10:24</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>If your real concern is the "worry" produced by the compiler, these can be turned off by a simple 'no worries` pragma.</p> | |
| </blockquote> | |
| <p>I know but I don't think that's a "real solution". If something is conceptually not "worrying", it shouldn't produce worries in the first place - otherwise the whole concept of a "worry" turns useless.</p> | |
| <p>I really had a hard time figuring out what you are talking about - let me ask you: have you run the snippet you posted, or any of my examples? Because what you imply is just not the real behavior. It resembles TimToady's original message that got fixed by Zoffix in 2016.</p> | |
| <p>I'm not sure if it's even right to call m//, S///, s/// and the likes "operators" - mind you, they all behave in a way that contradicts your assumption here.<br /> | |
| Your assumption seems to be that they are executed right away, with huge precedence. If that was the case, <code>$foo ~~ m/test/</code> would also be useless because the right handside would downright match against the topic variable and then the smartmatch would turn into string ~~ match. Similarly with s///: it would modify the original topic variable and then end up smartmatching a string against a match.</p> | |
| <p>The actual relevance of the smartmatch operator <code>~~</code> in these cases is that it sets the topic variable, which is part of its definition. The "regex operators" are only executed afterwards - that's why all these work at all.<br /> | |
| One of my key points is that these cases of smartmatching already produce non-boolean values that <em>are</em> used outside of boolean context (as well). It's just that unlike S///, they are assumed to be useful <em>in boolean context</em> (as well).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NjlOT"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-02T20:11:27Z">2022-11-02 20:11</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>let me ask you: have you run the snippet you posted</p> | |
| </blockquote> | |
| <p>Yes, sure. No <em>boolean context</em> at all, I use a simple <code>say</code> to show the return value.</p> | |
| <p>The fact is that both <code>m//</code> and <code>s//</code> returns a <code>Match</code> if succeeds, or <code>Nil</code>:</p> | |
| <pre><code class="language-raku">my $str = 'aaaa'; | |
| say $str ~~ /o/; # Nil | |
| say $str ~~ /a/; # ｢a｣ | |
| say $str ~~ s/a/x/; # ｢a｣ (and $str was modified) | |
| say $str; # xaaa | |
| say $str ~~ s/o/y/; # False (because s// fail so the expression becomes `$str ~~ Nil`) | |
| </code></pre> | |
| <p>That is so because a <code>Match</code> at the RHS of <code>~~</code> <strong>always</strong> return its LHS. (And <em>foo</em> <code>~~ Nil</code> returns <code>False</code>)</p> | |
| <p>But the <code>S///</code> case is completely different, because it <strong>always</strong> returns <code>Str</code> (the original one if the match fails and the substituted one if succeeds) so <code>~~</code> always returns <code>Bool</code>,</p> | |
| <p>Yes, the first step of <code>~~</code> evaluation is <strong>temporal binding</strong> the topic (<code>$_</code>) with its LHS, but the second step is evaluate its RHS, then (third and finally) the result of the previous step is used as the invocant of <code>.ACCEPTS($_)</code>, determining the final result.</p> | |
| <p>I put emphasis in <em>temporal</em> because:</p> | |
| <pre><code class="language-raku">$_ = 'bar'; my $str = 'aaaa'; $str ~~ /a/; say $_; # bar (the $_ binding to 'aaaa' by `~~` gone) | |
| </code></pre> | |
| <p>So, the results of the <code>Match</code> (regex) cases are clear, but I really don't know what you want to obtain from <code>'foo' ~~ S/x/y/</code> nor why you want to remove the "worry".</p> | |
| <p>And observe that <code>$foo ~~ S/a/b/ ~~ S/c/d/</code> becomes <code>Bool ~~ Str</code>, let me ask you: Was those substitutions useful?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NjnMX"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-02T20:20:31Z">2022-11-02 20:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>Well, to be honest, I'm not sure what is going on, at this point...</p> | |
| <p>https://glot.io/snippets/gf1ua1dqxk</p> | |
| <p>It says "elmafa". Same with the freshly updated Raku evalbot on the IRC, same with my own instance of Raku v2022.07 on Ubuntu 20.04.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Njtuj"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-02T20:42:16Z">2022-11-02 20:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>It turns out that despite the reasoning of Zoffix implied the current behavior, it only manifested this year, with https://github.com/rakudo/rakudo/commit/32401c4762a18c98b3d5b0bdd7c03b27400cb521. Well, interesting. I think it increased consistency regarding the behavior but I'm not sure anybody was fully aware of this. Maybe @vrurg you can recall something about this change?</p> | |
| <p>Also @lizmat even if you are lurking, please don't edit my comments ever again. I'm not sure why anyone can do that in the first place; I think it's prone to manipulation and I can hardly think of something more disrespectful than changing one's words one-sidedly, without asking for any kind of consent.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Nj5wQ"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-02T21:05:56Z">2022-11-02 21:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>@2colours: you used the word "gaslighting", which in that context implied intent by @salortiz. Please don't be that disrespectful towards people trying to help you, especially an esteemed longtime community member.</p> | |
| <p>I thought the removed words did not change any of the intent that <em>you</em> meant. If it did, I'm sorry. But if you did, I would have flagged your comment as inappropriate and it would have disrupted the discussion.</p> | |
| <p>But your request is noted: I will not change any of your comments ever again.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NkPD3"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-02T21:46:59Z">2022-11-02 21:46</time> | |
| </div> | |
| <div class='body'> | |
| <p>@lizmat thank you for that. I think it's better if I am simply bearing responsibility for the words I'm using, they say it's a part of adulthood. :) Also, not to imply that I will (or even could) reform the manners of a community, but perhaps it's better to know someone's expressions in different situations; I think even the Raku conference has shown that even a dozen of people can have quite different attitudes under very similar circumstances. It can be inconvenient at times but I believe inconveniences don't have to lead to toxicity.</p> | |
| <p>For the concrete scenario: I really did feel "gaslit", not the "intentional" part but the "challenged sense of sanity" part; and I think in this regard, it does make a difference that @salortiz didn't seem to reflect at all to the behavior I described and my call that his explanation doesn't match with what I experience. This made me question if I actually have seen what I have seen, or what I am getting wrong about this. Again: I'm not saying this was deliberate harm, it's probably an example of how confidence in your knowledge can affect how you communicate in a contradictory situation.</p> | |
| <p>Back to my previous comment: I think "today we learned" - it's an interesting turn of events that Zoffix presented a reasoning in 2016 that still reads to me as something that applies to the <em>current behavior</em>, and yet, the current behavior is only a couple of months old... It would be really good to know what lead to the current behavior on the technical side, then. Maybe that would help to define what m//, S/// and s/// are, structurally: when they are executed, how they are parsed in an expression, and so on.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Nk379"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-03T00:12:53Z">2022-11-03 00:12</time> | |
| </div> | |
| <div class='body'> | |
| <p>I was certainly not aware of the optimization introduced by @vrurg commit and all my tests were done with an older (2021.12) version.</p> | |
| <p>Cut & paste after a new build:</p> | |
| <pre><code class="language-text">[sog@pilar ~]$ raku -v; raku -e "no worries; say 'alfama' ~~ S/a/e/" | |
| Welcome to Rakudo™ v2021.12. | |
| Implementing the Raku® Programming Language v6.d. | |
| Built on MoarVM version 2021.12. | |
| False | |
| [sog@pilar ~]$ rakubrew switch moar-2022.07 | |
| Switching to moar-2022.07 | |
| [sog@pilar ~]$ raku -v; raku -e "no worries; say 'alfama' ~~ S/a/e/" | |
| Welcome to Rakudo™ v2022.07. | |
| Implementing the Raku® Programming Language v6.d. | |
| Built on MoarVM version 2022.07. | |
| elfama | |
| </code></pre> | |
| <p>Somehow that "optimization" changed the documented semantics which, I suspect, were not properly tested in roast.</p> | |
| <p>Any way that change, IMO, seems broken because with 2022.07:</p> | |
| <pre><code class="language-text">[sog@pilar ~]$ raku -e "no worries; say 'alfama' ~~ ($ = S/a/e/)" | |
| False | |
| </code></pre> | |
| <p>Indeed "today we learned", already the "worry" doesn't make much sense and this isn't settled yet.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NmO4X"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-03T09:59:50Z">2022-11-03 09:59</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>For the concrete scenario: I really did feel "gaslit", not the "intentional" part but the "challenged sense of sanity" part;</p> | |
| </blockquote> | |
| <p>Then you should have used words to that effect, and not have used the word "gaslighting".</p> | |
| <p><advice> | |
| If someone can not reproduce the results that you're seeing, even though you think that they should be the same because the setup is considered the same, then it generally just means that you've missed a variable in the experiment that <em>did</em> make a difference. And you should think in <em>that</em> direction, rather than (consciously or unconsciously) assume someone is trying to make you crazy. | |
| </advice></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NmS98"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-03T10:14:08Z">2022-11-03 10:14</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>raku -e "no worries; say 'alfama' ~~ ($ = S/a/e/)" | |
| False</p> | |
| </blockquote> | |
| <p>I wouldn't consider this "broken". "Less Than Awesome" perhaps but it makes sense at least, in my opinion. Here, it's clear that the right handside is evaluated to a string - the assignment takes care of that. Actually, even <code>raku -e "no worries; say 'alfama' ~~ (S/a/e/)"</code> makes sure the right handside is executed prior to the smartmatch.<br /> | |
| What I consider interesting (but matches what you already said) is that (S/a/e/) was already executed <em>on the left handside</em> as the topic. I know that <code>~~</code> is a special operator (maybe even syntax special-cased?) but if it seems like an operator with a certain precedence, it shouldn't <strong>pre</strong>set the topic.</p> | |
| <p>Anyway, since it's a new finding that the behavior itself changed recently, I think it's worth for me to explain my "state of mind" when opening the issue.</p> | |
| <ol> | |
| <li>I expected the current behavior (based on the apparent analogy with s/// and m//)</li> | |
| <li>lizmat showed me the commits where the worry was added and then modified - the reasoning of Zoffix <em>to me read like</em> it confirmed the current behavior (although now I can see that perhaps this wasn't the case - it took some time...)</li> | |
| <li>the documentation reassured my expectation 1 (confer for example "It's common to use this operator with the ~~ smartmatch operator, as it aliases left-hand side to $_, which s/// uses." - same argument applies to S///)</li> | |
| <li>the documentation provides a vague argument that can be seen as a weak argument against the current behavior ("since the result is obtained as a return value, using this operator with the ~~ smartmatch operator is a mistake " - if the "return value" is propagated from the smartmatch - as it indeed is - this is not a mistake, just not bool-friendly).</li> | |
| </ol> | |
| <p><strong>Bonus issue</strong>: | |
| TR/// has the old behavior, AND it doesn't even produce a "worry", nor is there a note in the documentation about its apparent "uselessness". Now, no matter which one is the correct behavior, we have an inconsistency.</p> | |
| <p>As we make tiny steps forward, I come to realize that m//, tr///, s/// and the likes were all created as immediately executing code, rather than a callback, and as such, they had some consistency. <strong>However, the way they mimicked being callbacks are very questionable and also poorly described.</strong> I think this goes way beyond whether S/// behaves right or not.</p> | |
| <p>Eventually, either hacks like Str ~~ Match returns the Match need to be carefully documented - or, and I would really prefer this solution but I don't know how big the impact would be... - they need to be eliminated in the favor of "smartmatch-friendly" s///, m//, TR///, etc... everywhere.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Np2bm"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-11-04T00:20:20Z">2022-11-04 00:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't currently have enough time to look deep into this. But what I see here is that:</p> | |
| <ol> | |
| <li><code>S///</code> is OKish as <code>~~</code> RHS because there is valid topic to operate upon.</li> | |
| <li>It is not OK that the resulting string leaks smartmatch as it is not a <code>Match</code> and has to be boolified.</li> | |
| <li><code>S///</code> isn't really useful this way because one would rather has to deliberately model a situation where the resulting string would boolify into <code>False</code>.</li> | |
| </ol> | |
| <p>So, the current behavior is more correct correct that it isn't. The worry makes sense here. And it is a worry because there is nothing wrong about the construct, it's just barely bears any big meaning in it.</p> | |
| <p>Regarding the consistency, <code>TR///</code> should probably result in a warning too. At least for the moment it makes sense to me, unless I miss a point.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Np8Y8"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-04T01:10:32Z">2022-11-04 01:10</time> | |
| </div> | |
| <div class='body'> | |
| <p>@vrurg,</p> | |
| <blockquote> | |
| <ol start="2"> | |
| <li>It is not OK that the resulting string leaks smartmatch as it is not a Match and has to be boolified. | |
| So, the current behavior is more correct correct that it isn't.</li> | |
| </ol> | |
| </blockquote> | |
| <p>Bisectable <a href="https://gist.github.com/0fc6799a94adc117f1e1ba0e253ead6d">output</a> confirms the leaks starts with your https://github.com/rakudo/rakudo/commit/32401c4762a18c98b3d5b0bdd7c03b27400cb521, so the previous behavior was more correct. Seems that the attempted optimization, in this case, not only isn't boolified, it is returning the RHS string without applying .ACCEPTS semantic.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NrEcC"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-04T08:54:44Z">2022-11-04 08:54</time> | |
| </div> | |
| <div class='body'> | |
| <p>Well I'm not happy that a possibly useful behavior is pushed back into the cage - but more so because of this remark:</p> | |
| <blockquote> | |
| <p>It is not OK that the resulting string leaks smartmatch <strong>as it is not a Match</strong> and has to be boolified.</p> | |
| </blockquote> | |
| <p>I'm definitely going to open an issue against the special casing of Matches - actually, I think if they stop being hacked in smartmatches, compatibility demands would push towards the smartmatch semantics I'm describing. Either way, the (otherwise undocumented) smartmatching behavior might be the biggest design mistake I've yet discovered in Raku...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5N9ROM"> | |
| <div class='header'> | |
| <span class='author'>@jubilatious1</span> commented at <time datetime="2022-11-08T22:20:30Z">2022-11-08 22:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>I have always assumed the <code>s///</code> versus <code>S///</code> dichotomy was due to Perl's historical attempt at attempting to emulate BOTH <code>sed</code> and <code>awk</code> semantics under one architecture.</p> | |
| <p>See: https://www.nntp.perl.org/group/perl.perl6.users/2020/05/msg8403.html</p> | |
| <p>Essentially, I see this as a kludge which attempts to make uniform differences between a more-<code>awk</code>-like behavior which Perl6/Raku emulates well, versus the older <code>sed</code>-like behavior of 1). stream-processing i.e. automatic defaulting to <code>stdin</code>, and 2. 'autoprinting' i.e. providing a return value without an explicit print/put/say statement.</p> | |
| <p>That being said, I've just upgraded to <code>Rakudo_2022.07</code> and no longer see the need to add <code>given $_</code> at the end of my one-liners:</p> | |
| <pre><code>~$ -ne 'S:g/foo/bar/.put given $_;' file | |
| </code></pre> | |
| <p>...gives the same result as:</p> | |
| <pre><code>~$ -ne 'S:g/foo/bar/.put;' file | |
| </code></pre> | |
| <p>So, something has changed: maybe the warning is no longer necessary?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5N9UEB"> | |
| <div class='header'> | |
| <span class='author'>@jubilatious1</span> commented at <time datetime="2022-11-08T22:26:09Z">2022-11-08 22:26</time> | |
| </div> | |
| <div class='body'> | |
| <pre><code>~$ raku | |
| Welcome to Rakudo™ v2022.07. | |
| Implementing the Raku® Programming Language v6.d. | |
| Built on MoarVM version 2022.07. | |
| To exit type 'exit' or '^D' | |
| [0] > no worries; say 'alfama' ~~ ($ = S/a/e/) | |
| False | |
| [0] > no worries; say 'alfama' ~~ ($_ = S/a/e/) | |
| Cannot assign to an immutable value | |
| in block <unit> at <unknown file> line 1 | |
| [0] > no worries; say 'alfama' ~~ S/a/e/ | |
| elfama | |
| [0] > no worries; say $_ if 'alfama' ~~ S/a/e/ | |
| alfama | |
| [0] > no worries; say $_ if 'alfama' ~~ s/a/e/ | |
| Cannot modify an immutable Str (alfama) | |
| in block <unit> at <unknown file> line 1 | |
| [0] > no worries; say $/ if 'alfama' ~~ s/a/e/ | |
| Cannot modify an immutable Str (alfama) | |
| in block <unit> at <unknown file> line 1 | |
| [0] > no worries; say $/ if 'alfama' ~~ S/a/e/ | |
| ｢a｣ | |
| [0] > | |
| </code></pre> | |
| <p>@salortiz | |
| @vrurg</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OBDzx"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-11-09T15:05:14Z">2022-11-09 15:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>Except for <code>no worries; say 'alfama' ~~ S/a/e/</code> which is now fixed on master, everything else looks correct.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OBjLU"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-09T16:35:41Z">2022-11-09 16:35</time> | |
| </div> | |
| <div class='body'> | |
| <p>So the only good thing that I opened the issue for got "fixed" so that it is useless again... Is there a way to close an issue as "deliberately did the opposite"?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OBpoq"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-09T16:56:39Z">2022-11-09 16:56</time> | |
| </div> | |
| <div class='body'> | |
| <p>https://imgflip.com/i/704v56</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OBp3b"> | |
| <div class='header'> | |
| <span class='author'>@jubilatious1</span> commented at <time datetime="2022-11-09T16:57:25Z">2022-11-09 16:57</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm not sure what to say @2colours . I've never read anywhere about the origins of <code>s///</code> versus <code>S///</code> ( or <code>tr///</code> versus <code>TR///</code>) and the resulting assymetry in coding. What I wrote above is my own conjecture.</p> | |
| <p>What I really <em>would</em> appreciate is a table that tells me what return value I can expect, and when I can expect it. I'm happy to contribute, to test code, but I'm not sure I'm able to write that table in the correct historical context.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ODB9T"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-11-09T21:45:34Z">2022-11-09 21:45</time> | |
| </div> | |
| <div class='body'> | |
| <p>@jubilatious1 In this case smartmatch is basically equivalent to <code>do { my $_ := <LHS>; <RHS>.ACCEPTS($_) }</code>. <code><RHS></code> can make use of the topic variable. When <code><RHS></code> is a regex returning a <code>Match</code> then it is special-coded. But <code>S///</code> is not of that kind because it returns a <code>Str</code>.</p> | |
| <p>Therefore:</p> | |
| <ul> | |
| <li><code>'a' ~~ ($ = S/a/e/)</code> is about <em>'a'</em> matching <em>'e'</em> in an anonymous scalar</li> | |
| <li><code>'alfama' ~~ ($_ = S/a/e/)</code> fails because <code>$_</code> is bound to a string, it is not a container</li> | |
| <li><code>'alfama' ~~ S/a/e/</code> is currently <em>False</em> because <code><RHS></code> results in <code>elfama</code> and that doesn't match <code>alfama</code></li> | |
| <li><code>say $_ if 'alfama' ~~ S/a/e/</code> is <code>alfama</code> because <code>$_</code> is bound to the original string</li> | |
| <li><code>say $_ if 'alfama' ~~ s/a/e/</code> fails because <code>s///</code> tries to modify <code>$_</code> – see the second case above</li> | |
| <li><code>say $/ if 'alfama' ~~ s/a/e/</code> apparently the same, as above</li> | |
| <li><code>say $/ if 'alfama' ~~ S/a/e/</code> works because <code>S///</code> doesn't attempt to modify <code>$_</code>.</li> | |
| </ul> | |
| <p>So, things are quite logical if we know how it works. That was one of things the original design documents of Perl 6 were trying to overcome from Perl 5 legacy: being too DWIMMY, up to the level where too many special cases were requiring too many exceptions. Probably special-casing of regexes in smartmatch hadn't been done in first place as in this case it wouldn't be creating confusion with <code>S///</code>. But OTOH it lets us have things like <code>if $a ~~ /.../ { say $<submatch> }</code> in very concise and yet readable way.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ODP2y"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-09T22:32:26Z">2022-11-09 22:32</time> | |
| </div> | |
| <div class='body'> | |
| <p>The problem isn't <code>$a ~~ /.../</code>, actually that one doesn't even need special casing. <code>/.../</code> is just a regex with no dependencies, therefore it doesn't undergo any tricky side effects as the RHS of a smartmatch. Then we can witness a usual ACCEPTS call on <a href="https://docs.raku.org/type/Regex#method_ACCEPTS">that regex</a>.</p> | |
| <p>The "special casing" happens when a Match object is obtained <em>on the RHS</em>, so, for example <code>m/.../</code> or <code>s/../../</code> (<code>tr/../../</code> produces an <a href="https://docs.raku.org/type/StrDistance">StrDistance</a> object).</p> | |
| <p>I wouldn't even call it "special casing", it's worse than that: calling ACCEPTS on a Match instance returns the instance itself, <em>absolutely no matter what the LHS was</em>. <code>Nil ~~ $match</code> returns <code>$match</code>, <code>$match1 ~~ $match2</code> returns <code>$match2</code>, <code>$string-that-has-nothing-to do-with-match1 ~~ $match1</code> returns <code>$match1</code>. For now, it's <em>fortunately</em> not in Roast but it's not unintended either.</p> | |
| <p>I'm still not quite ready to open an issue for <em>that</em>. It's a big one that would either break <code>$a ~~ m/.../</code> style code, or <code>$a ~~ m/.../</code> kind of stuff would need to be syntax special-cased/semantically redefined indeed, much like an unintended special casing made <code>$a ~~ S/../../</code> useful for a couple of Rakudo releases.</p> | |
| <p>Anyway, that's what the meme targeted - that a useful regression has to go but an egregious design mistake that we can still target on the language level is taken at face value.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="349"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/349"><span class='number'>349</span></a> - <span class='title'>Raku / Perl 6 books - CCR measures and beyond</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-11-01T11:36:22Z">2022-11-01 11:36</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Currently, I don't see a good, official-ish, up-to-date source for Raku books but such a list could be created based on the perl6book site and links at raku.org. The goal: provide an "officially" maintained, presentation-agnostic store for Raku books.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>As mentioned in https://github.com/Raku/problem-solving/issues/347, lately I discovered the <a href="https://perl6book.com/">Raku / Perl 6 books</a> site created by Moritz Lenz. I have mixed feelings about it, especially considering that it's linked at sites like raku.org and the to-be docs.raku.org.</p> | |
| <ul> | |
| <li>the content is valuable, worth presenting AND maintaining</li> | |
| <li>the presentation is off-putting (in my opinion), with inaccuracies (perl6org Twitter) on the way</li> | |
| <li>+1: the domain perl6book seems unfortunate 3 years after the renaming</li> | |
| </ul> | |
| <p>So far, I think this is a perfect setup for a <a href="https://github.com/Raku/CCR">collect-conserve-remaster</a> scenario - however, I think having published learning materials always available and up-to-date even exceeds the usual scope of CCR.</p> | |
| <p>I think we should set the goal to have an easily accesible, maintained, safe-to-advise source for Raku-related learning materials. In order to avoid the perl6book situation, this should be formal data without presentation:</p> | |
| <ul> | |
| <li>no need to officially maintain a site or visual format, hence easier to keep up-to-date</li> | |
| <li>there can be multiple presentations; moreover it's easy to replace a presentation / start over if a particular presentation turns unmaintained.</li> | |
| </ul> | |
| <p>I consider this the "issue" itself - that's not to say it cannot be discussed or modified if others have a better idea. The technical details are considered a part of the solution.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5NZGof"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-01T12:14:56Z">2022-11-01 12:14</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think the content could live in another github repository. I don't feel strongly about the format; I'd think of a textual data serialization format, could be JSON, could even be XML given the document-ish nature of the content. Also, perhaps it could be hosted directly on the web some way, could be simply as a static file. It doesn't take more resources than hosting a site and it would allow sites to directly depend on the up-to-date content.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="348"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/348"><span class='number'>348</span></a> - <span class='title'>What to do with https://twitter.com/raku_news ?</span></div> | |
| <div class='author'>[open]<span class='author'>@moritz</span> opend this issue at <time datetime="2022-10-31T09:37:48Z">2022-10-31 09:37</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>I've been running https://twitter.com/raku_news for nearly 6 years now, and it has a bit more than a thousand followers.</p> | |
| <p>Given the recent direction of twitter's content moderation and monetization plans, I'm no longer willing to interact with twitter on a regular basis.</p> | |
| <p>I'd be happy to transfer this account to a person or email address of your choice, or shut it down. I'm also open to other proposals that don't involve me operating it long term.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5NUdsw"> | |
| <div class='header'> | |
| <span class='author'>@melezhik</span> commented at <time datetime="2022-10-31T14:54:05Z">2022-10-31 14:54</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Given the recent direction of twitter's content moderation and monetization plans</p> | |
| </blockquote> | |
| <p>What's wrong with that?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NVQ0d"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-10-31T17:22:33Z">2022-10-31 17:22</time> | |
| </div> | |
| <div class='body'> | |
| <p>@melezhik I don't think that that is important.</p> | |
| <p>What is important, is that @moritz is looking for someone to take over the job of (re)tweeting news about the Raku Programming Language. That alone should be enough for someone in the community to step forward :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NX-bl"> | |
| <div class='header'> | |
| <span class='author'>@rba</span> commented at <time datetime="2022-11-01T07:31:11Z">2022-11-01 07:31</time> | |
| </div> | |
| <div class='body'> | |
| <p>@moritz: Sorry for hijacking this, but my thoughts are just too similar. | |
| During name change I've registered @raku_lang on twitter (https://twitter.com/raku_lang). Mostly to make sure it's not taken by any non community member. I've used the account mostly for retweeting.</p> | |
| <p>Maybe it's worth to consolidate efforts here. I will hand it over to anyone who likes to use it or just like to keep it reserved.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NYJdn"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-11-01T07:55:37Z">2022-11-01 07:55</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>What's wrong with that? | |
| @melezhik I don't think that that is important.</p> | |
| </blockquote> | |
| </blockquote> | |
| <p>I agree it's off topic. Still I'm interested. Not as a justification, but because it could be relevant for me as well. Could someone provide a link or similar where to read up on this?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NYUBz"> | |
| <div class='header'> | |
| <span class='author'>@moritz</span> commented at <time datetime="2022-11-01T08:41:51Z">2022-11-01 08:41</time> | |
| </div> | |
| <div class='body'> | |
| <p>What's wrong? People like Tony Braxton getting whole volleys of hate messages and no interventions from twitter, simply for being a public black woman.</p> | |
| <p>In general, private companies are less accountable than public ones, and I don't want to wait until the drama plays out in full, or until the hate reaches myself.</p> | |
| <p>Regarding the monetization: there has been speculation that Musk wants to turn twitter into an "everything app", meaning adding lots of features, including payments processing, and taking a cut from that. That's simply not something I want my social media to be, independently of whether there is something wrong with that.</p> | |
| <p>I realize that these are all pretty soft reasons, but I don't want to give the person the benefit of a doubt who publicly called a cave rescue diver a pedophile, without any evidence, just because his ego was bruised.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ObasR"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-15T20:09:55Z">2022-11-15 20:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>FWIW, I've registered <code>https://fosstodon.org/@rakulang</code> to be the official Raku Programming Language feed. And it's now in use.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ObbA4"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-15T20:11:15Z">2022-11-15 20:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>@moritz @rba if you could post a message about this on your Twitter feed, and then request a backup, then we can freeze the Twitter feeds as far as I'm concerned.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ObeQC"> | |
| <div class='header'> | |
| <span class='author'>@melezhik</span> commented at <time datetime="2022-11-15T20:25:32Z">2022-11-15 20:25</time> | |
| </div> | |
| <div class='body'> | |
| <p>So, practically speaking, should Raku authors now advertise their news on fosstodon.org, not on twitter? ))) or this only affects official rakudo/raku news?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ObgPs"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-11-15T20:34:48Z">2022-11-15 20:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>you can post it anywhere on Mastodon, I'll be monitoring the #RakuLang tag</p> | |
| <p>I'll also keep monitoring Twitter for the time being, but don't know for how long</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Oea4D"> | |
| <div class='header'> | |
| <span class='author'>@moritz</span> commented at <time datetime="2022-11-16T08:33:57Z">2022-11-16 08:33</time> | |
| </div> | |
| <div class='body'> | |
| <p>I've published https://twitter.com/raku_news/status/1592797117923270656 and pinned it to the top of the account. Thanks @lizmat!</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Oe3l3"> | |
| <div class='header'> | |
| <span class='author'>@nxadm</span> commented at <time datetime="2022-11-16T09:54:24Z">2022-11-16 09:54</time> | |
| </div> | |
| <div class='body'> | |
| <p>Why not crossposting from Mastodon?</p> | |
| <p>(E.g. with https://crossposter.masto.donte.com.br)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OmZ-l"> | |
| <div class='header'> | |
| <span class='author'>@rba</span> commented at <time datetime="2022-11-17T14:07:18Z">2022-11-17 14:07</time> | |
| </div> | |
| <div class='body'> | |
| <p>I took @moritz pinned comment and tweeted and pinned it https://twitter.com/raku_lang/status/1593243663408451585 as well.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="347"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/347"><span class='number'>347</span></a> - <span class='title'>The Path to Raku, revisited</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-10-08T22:20:55Z">2022-10-08 22:20</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Hi all,</p> | |
| <p>this issue is inspired by the abundance of content that still refers to Perl6 some way - mostly in the file extensions but sometimes in domain names as well, or worst case, still referring to the language as "Perl 6". (Mind you: I'm not taking a stance on the renaming itself since it's history anyway; I start with the presumption that the language should be consistently represented by its name, which is "Raku".)</p> | |
| <p>When I tried to find out if there are already issues for the current situation, I found some issues and pointers around the time the renaming actually happened.</p> | |
| <p>The <a href="https://github.com/Raku/problem-solving/blob/18890dc9f416330897f536b177974cc6ec12b071/solutions/language/Path-to-Raku.md">Path to Raku document</a> targeted these issues - but "It does not pretend to be complete in scope or in time", and I think it's time to revisit it and update the considerations,</p> | |
| <p>At the time of writing the document, <code>6.e</code> seemed realistic in 2020. As things stand currently, it's not sure it can be finished in 2023. Since extensions and name-related code don't depend on the development of <code>6.e</code>, I think the deprecation policies should get stricter. Years of actual development and publishing have passed, people really shouldn't be using extensions that were "sentenced to death" 3 years ago. This goes for Rakudo as well, preferably - but I think it's easier to pardon Rakudo than simple modules that could be adopted easily.</p> | |
| <p>I think this is mainly a community decision, not a measure to implement. Also, this is probably something really easy to change. I can go around and ask people "don't Perl that much in 2022, please" but that's sort of an annoying, "bad cop" move. I hope we can reach a clear and up-to-date stance on our current position in the renaming process, and then I'd expect this to go almost automatically.</p> | |
| <p>PS: I can already recall deprecation warnings for using $*PERL or some similar dynamic variable so certain measures do have been implemented by now. It would be good to know how it is currently, and update that "roadmap" as well.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5MQVvZ"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-10-14T18:53:46Z">2022-10-14 18:53</time> | |
| </div> | |
| <div class='body'> | |
| <p>I also noticed that there is a <a href="https://perl6book.com">"perl6book"</a> site, created by @moritz . I don't think this is "official" stuff in the strictest sense but the domain itself sounds like it could be an outdated official site, and I'm not sure if I like the impression it makes. If it could be hosted in a more "Raku-ish" context, I think it could be much nicer and feel less like legacy left behind.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5MV7sw"> | |
| <div class='header'> | |
| <span class='author'>@moritz</span> commented at <time datetime="2022-10-17T12:56:02Z">2022-10-17 12:56</time> | |
| </div> | |
| <div class='body'> | |
| <p>If it's outdated, or somebody wants to contribute a different wording or style, feel free, the content is on https://github.com/moritz/perl6book-web</p> | |
| <p>If you prefer to have that information elsewhere, I'm happy to replace that site by a redirect with more up-to-date information.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5NY_TZ"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-01T11:43:21Z">2022-11-01 11:43</time> | |
| </div> | |
| <div class='body'> | |
| <p>@moritz I created an issue to address the status of published learning materials beyond the particular site - you are invited to share your thoughts about it. In my view, the eventual site should be based around the content abstracted away, redesigned (possibly in the style of an already existing Raku-related site but I think a straightforward Bootstrap theme is also a step forward), and secured at a place that plays well with the rename in 2019 - possibly but not necessarily a raku.org subdomain.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="346"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/346"><span class='number'>346</span></a> - <span class='title'>Semantics of hyper metaoperators - direction, "dwimminess", dimensions, etc.</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-09-16T21:02:25Z">2022-09-16 21:02</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Hello,</p> | |
| <p>I didn't want to apply a template because I thought this topic can cover parts of documentation, implementation and design itself.</p> | |
| <p>The main focus of my investigations was the chaining of hyper on flat iterables.</p> | |
| <h2>"Preface" about what is documented currently</h2> | |
| <p>Let's read the documentation carefully (https://docs.raku.org/language/operators#index-entry-hyper_%3C%3C-hyper_%3E%3E-hyper_%C2%AB-hyper_%C2%BB-Hyper_operators)</p> | |
| <blockquote> | |
| <p>They apply a given operator enclosed (or preceded or followed, in the case of unary operators) by « and/or » to one or two lists, returning the resulting list, <strong>(1)</strong> with the pointy part of « or » aimed at the shorter list. <strong>(2)</strong></p> | |
| </blockquote> | |
| <p><strong>R1</strong>: I don't know the exact definition but I suspect not only lists are okay. <code>(1, 2, 3).Seq >>+>> (4, 5).Seq</code> succeeds, yielding the list <code>(5, 7, 8)</code>. It would be good to use a more exact term: Positional, Iterable, or whatever else makes the statement true. If they are turned into lists using .List (or .cache for example), that could also be mentioned, like with many methods.</p> | |
| <p><strong>R2</strong>: this is a much more important point overall:</p> | |
| <ul> | |
| <li>the word "list" is even more problematic when referring to the length of something that might not actually be a list</li> | |
| <li>the declaration that the direction of the arrows must be decided based on the size of the (supposed) lists <em>does not conform with the implementation</em>: <code>(1, 2, 3) <<+<< (4, 5)</code> is a successful call yielding the list <code>(5, 7)</code>.</li> | |
| <li>it sounds impractical that the developer should give up on the power of choosing the "wrong direction" and keep the sizes in mind instead. In other words: I think the implementation is "more valid" in this case and the documentation should be rephrased in a way that hints the actual behavior. I have ideas about the phrasing for simple, 2-operand cases like this one - the directionality should be described in terms of what is fully traversed / what pushes values and what pulls them - but it can still fail for multi-operand cases that succeed.</li> | |
| </ul> | |
| <blockquote> | |
| <p>Single elements are turned to a list, so they can be used too. <strong>(3)</strong> If one of the lists is shorter than the other, the operator will cycle over the shorter list until all elements of the longer list are processed. <strong>(4)</strong></p> | |
| </blockquote> | |
| <p><strong>R4</strong>: I need to address this first. Again, this is only true if we respect (2) over the implementation - if we set the direction the opposite way, only the operand on the open end is fully traversed, as the same example shown. Actually, if these points were true... there wouldn't be any sense in having directions for the hyper metaoperators at all.</p> | |
| <p><strong>R3</strong>: I think this statement could really hold regardless (2) but sadly this also fails if the single element would be on the open end. See</p> | |
| <pre><code>(1, 2, 3).Seq <<+<< 4 | |
| Lists on either side of non-dwimmy hyperop of infix:<+> are not of the same length while recursing | |
| left: 3 elements, right: 1 elements | |
| </code></pre> | |
| <p>Interestingly, <code>(1, 2, 3).Seq <<+<< (4,)</code> does work and yields <code>(5, )</code> - so the error message hints that (3) was respected but (2) was enforced, unlike other cases. Also, it introduces the term "dwimmy" which I couldn't find in the docs - after some Googling, I concluded this is just a word play on DWIM as in "Do What I Mean". I don't know if this concept should appear in official stuff - but if it already appears in Rakudo error messages, it's still better if it does appear in the docs as well, with some formal(-ish) definition.</p> | |
| <blockquote> | |
| <p>You can chain hyper operators to destructure a List of Lists.</p> | |
| <pre><code>my $neighbors = ((-1, 0), (0, -1), (0, 1), (1, 0)); | |
| my $p = (2, 3); | |
| say $neighbors »>>+<<» ($p, *); # OUTPUT: «((1 3) (2 2) (2 4) (3 3))» | |
| </code></pre> | |
| </blockquote> | |
| <p>This works and I didn't know about it - honestly, I wouldn't have expected this under "chaining hyper operators", I meant something else with that. However, even here, it shows that a) either the behavior has changed lately b) or the author also wasn't sure about the behavior, because the WhateverStar is not needed on the right side. The example would work just as good with <code>($p, )</code><br /> | |
| Actually, I don't even know why it works <em>with</em> the WhateverStar. <code>(1, 2, 3, 4, 5) >>+>> (4, *)</code> gives <code>(5, 6, 7, 8, 9)</code> and the output doesn't change from Whatevers added to the end. However, if I add it in front, the right side acts like an empty List - similarly, elements that appear after the asterisk seem to be cut off. I don't know how much this is intended behavior but if it is, I'm willing to write it down; we need this covered because it's all black magic right now.</p> | |
| <p>I haven't talked about the >>[&op]<< and <<[&op]>> configurations because they weren't covered for lists - however, I realize that I can't actually turn to my concrete motive without taking a look at what the docs say about it <em>for hashes</em> (Maps - perhaps all Associatives, even?); and how it works for Lists.</p> | |
| <pre><code>(1, 2) <<~>> <a b c> # ("1a", "2b", "1c") | |
| (1, 2, 3, 4) <<~>> <a b c> # ("1a", "2b", "3c", "4a") | |
| (1, 2) >>~<< <a b c> # ("1a", "2b", "1c") # Lists on either side of non-dwimmy hyperop of infix:<~> are not of the same length while recursing; left: 2 elements, right: 3 elements | |
| </code></pre> | |
| <p>From this, I conclude that the "diamond shape" sets the direction according to the longer side while the "cross shape" enforces equal size (by throwing an error in all other cases). Again, this seems to be a good description for non-nesting cases but it doesn't seem to always help for nesting.</p> | |
| <p>Let's compare this to the docs about Maps:</p> | |
| <blockquote> | |
| <p>Hyper operators can work with hashes. The pointy direction indicates if missing keys are to be ignored in the resulting hash. The enclosed operator operates on all values that have keys in both hashes. <strong>(5)</strong></p> | |
| </blockquote> | |
| <p><strong>R5</strong>: It seems to me the enclosed operator also operates on values that are selected by the pointy direction but are missing from the other "hash" - in that case, an undefined value (probably corresponding to a missing key in that Map) is used, but apparently without the warning of using undefined values. (I'm gonna show the example later.)</p> | |
| <p>For the directions:</p> | |
| <blockquote> | |
| <p>| Code | Keys | | |
| |--------|---------------| | |
| | %foo «+» %bar; | intersection of keys <strong>(6)</strong> | | |
| | %foo »+« %bar; | union of keys <strong>(7)</strong> | | |
| | %outer »+» %inner; | only keys of %inner that exist in %outer will occur in the result <strong>(8)</strong> |</p> | |
| </blockquote> | |
| <p>I used <code>my %a =:common, only-here => 12; my %b = :!common, only-there => 53</code> for testing, also created <code>sub own-add($a, $b) { say "RUN with $a.raku() $b.raku()"; $a + $b }</code> to confirm when the calls are made and with what arguments.</p> | |
| <p><strong>R6-7</strong>: the documentation seems to match the behavior - however, they both go opposite to the semantics with Lists. The diamond shape covered both lists - for maps, that's the cross shape. I think, given the condition of the documentation so far, the behavior could be harmonized in either direction, with little damage.</p> | |
| <p><strong>R8</strong>: I don't understand the statement. Wouldn't "only keys of %inner that exist in %outer" mean the intersection again? Anyway, I cannot read it in a way that matches the behavior: the keys of %outer will occur in the result, simple as that:</p> | |
| <pre><code> > say %a >>[&own-add]>> %b | |
| RUN with 12 Any | |
| RUN with Bool::True Bool::False | |
| {common => 1, only-here => 12} | |
| </code></pre> | |
| <h2>Arriving to the hyper chains</h2> | |
| <p>First I would return to the chain the docs mentioned: in that case, it seems like the inner arrows do absolutely nothing and everything is decided by the outer pair of arrows. I would like to think this is NYI rather than the design itself... if I just don't get what they are supposed to do, please enlighten me.</p> | |
| <p>Last but not least... I wanted to use hyper metaoperators to join strings separated by some character, like <code><a b c> >>~>> '_' <<~<< <e f g></code>. This example does work and gives <code>("a-e", "b-f", "c-g")</code> as I expected. However:</p> | |
| <pre><code><a b c> >>~>> '-' <<~<< <e f g h> # ("a-e", "b-f", "c-g", "a-h") | |
| <a b c i j> >>~>> '-' <<~<< <e f g h> # ("a-e", "b-f", "c-g", "i-h") | |
| </code></pre> | |
| <p>Seems like the right handside wins, no matter what? Some further examples:</p> | |
| <pre><code><a b c i j> <<~<< '-' <<~<< <e f g h> # Lists on either side of non-dwimmy hyperop of infix:<~> are not of the same length while recursing; left: 5 elements, right: 1 elements | |
| <a b c i j> >>~>> '-' >>~>> <e f g h> # ("a-e", "b-f", "c-g", "i-h", "j-e") | |
| <a b c i j> >>~>> '-' >>~<< <e f g h> # Lists on either side of non-dwimmy hyperop of infix:<~> are not of the same length while recursing; left: 5 elements, right: 4 elements | |
| </code></pre> | |
| <p>The last example made me pay more attention to the associativity: is it possible that the hypered operator decides it all? Compare <code>(1, 2, 3) Z+ (4, 5, 6) Z* (-3, -4, -5)</code> to <code>(1, 2, 3) <<+>> (4, 5, 6) <<*<< (-3, -4, -5)</code> (or any direction really). The former says: "Only identical operators may be list associative; since 'Z+' and 'Z*' differ, they are non-associative and you need to clarify with parentheses". The latter succeeds and it always seem to apply a+b*c order, giving <code>(-11, -18, -27)</code>.</p> | |
| <p>Then I started experimenting with operators that have list associativity according to the docs:</p> | |
| <pre><code>(1, 2, 3) <<max>> (4, 5, 6) <<max<< (-3, -4, -5) # Only identical operators may be list associative; since '<<max>>' and '<<max<<' differ, they are non-associative and you need to clarify with parentheses | |
| (1, 2, 3) <<||>> (4, 5, 6) <<&&<< (-3, -4, -5) # (1, 2, 3) | |
| (1, 2, 3) <<&&>> (4, 5, 6) <<&&<< (-3, -4, -5) # (-3, -4, -5) | |
| (1, 2, 3) <<&&>> (4, 5, 6) <<||<< (-3, -4, -5) # (4, 5, 6) | |
| </code></pre> | |
| <p>Something seems off about that complaint with max and the arrows in different directions - especially since it doesn't complain when combined with <code>||</code> which has the same precedence and list associativity, too.<br /> | |
| Actually, comparing the results for <code>&&</code> with the results for <code>~</code>, it seems to me that <code>&&</code> is in fact left-associative - which is perfectly fine but it contradicts the docs.</p> | |
| <p>And here I got stuck because for actually list-associative operators, I couldn't get away with varied arrows...</p> | |
| <p>... or any arrows apparently:</p> | |
| <pre><code> (1, 2, 3) <<max>> (4, 5, 6) <<max>> (-3, -4, -5) # Too many positionals passed; expected 2 arguments but got 3 | |
| (1, 2, 3) >>max>> (4, 5, 6) >>max>> (-3, -4, -5) # Too many positionals passed; expected 2 arguments but got 3 | |
| </code></pre> | |
| <p>Now I really don't know what happened or what should have happened.</p> | |
| <p>I think if we can target half of these problems and questions, that's already a huge achievement.</p> | |
| </div> | |
| <div class='comments'> | |
| </div> | |
| </div> | |
| <div class='issue' id="345"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/345"><span class='number'>345</span></a> - <span class='title'>The semantics of >>.foo feel wrong and possibly need changing</span></div> | |
| <div class='author'>[closed]<span class='author'>@lizmat</span> opend this issue at <time datetime="2022-09-14T10:47:13Z">2022-09-14 10:47</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>This has been instigated by https://github.com/rakudo/rakudo/issues/5057 .</p> | |
| <p>I've come to the conclusion that my fix for that issue is either the wrong fix, or we need to rethink the semantics of >>.foo. The documentation currently states:</p> | |
| <blockquote> | |
| <p>This is the hyper method call operator. Will call a method on all elements of a List out of order and return the list of return values in order.</p> | |
| </blockquote> | |
| <p>Now, clearly, that doesn't work for <code>Associative</code>s, as the "elements" of <code>Associative</code>s are <code>Pair</code>s:</p> | |
| <pre><code>$ raku -e 'my $b := <a b c d c d>.BagHash; $_-- for $b; dd $b' | |
| Cannot resolve caller postfix:<-->(Pair:D); | |
| </code></pre> | |
| <p>So <code>Associative</code>s are handled differently by calling the operator on the <em>values</em> of the <code>Associative</code>.</p> | |
| <p>Now let's get back to the original example:</p> | |
| <pre><code>$ raku -e 'say <a b c d c d>.BagHash>>--' | |
| BagHash(c d) | |
| </code></pre> | |
| <p>This now returns what the op expected. But that expectation was actually <em>wrong</em>, because if we do something similar with an array that is created on the fly:</p> | |
| <pre><code>$ raku -e 'say [1,2,3,4,5]>>--' | |
| [1 2 3 4 5] | |
| </code></pre> | |
| <p><strong>will return a List of the return values in order</strong> And since <code>&postfix:<--></code> returns the original value, the return value is actually a <em>copy</em> of the original array, and the decrements that have been done, are lost in the ether. If we want to be consistent with that behaviour, then:</p> | |
| <pre><code>$ raku -e 'say <a b c d c d>.BagHash>>--' | |
| BagHash(a b c(2) d(2)) | |
| </code></pre> | |
| <p>And those decrements would be lost in the ether as well. And would be contrary to expectations of the op as well.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5KTwHF"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-09-14T12:29:18Z">2022-09-14 12:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>Related: https://github.com/rakudo/rakudo/commit/d0ec99a861</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5KT2m-"> | |
| <div class='header'> | |
| <span class='author'>@frithnanth</span> commented at <time datetime="2022-09-14T12:50:03Z">2022-09-14 12:50</time> | |
| </div> | |
| <div class='body'> | |
| <p>OK, I understand that it's about the difference between post and pre-decrement. | |
| Obviously (now :-) ) post-decrement returns the original value, then decrements the content of the variable. The pre-decrement does it in the opposite order. | |
| So</p> | |
| <pre><code class="language-bash">$ raku -e 'say [1,2,3,4,5]»--' | |
| [1 2 3 4 5] | |
| </code></pre> | |
| <p>while</p> | |
| <pre><code class="language-bash">raku -e 'say --«[1,2,3,4,5]' | |
| [0 1 2 3 4] | |
| </code></pre> | |
| <p>Yet doing the same on a BagHash still returns strange results using the stock Rakudo v2022.07:</p> | |
| <pre><code class="language-bash">$ raku -e 'say --«<a b c d c d>.BagHash' | |
| BagHash(d) | |
| $ raku -e 'say --«<a b c d c d>.BagHash' | |
| BagHash(c) | |
| $ raku -e 'say --«<a b c d c d>.BagHash' | |
| BagHash(c d) | |
| </code></pre> | |
| <p>(Those are really three successive tests on my computer :-o )</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5KT9Wi"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-09-14T13:12:43Z">2022-09-14 13:12</time> | |
| </div> | |
| <div class='body'> | |
| <p>That is what commit https://github.com/rakudo/rakudo/commit/d0ec99a861 fixed: rakudo HEAD now says:</p> | |
| <pre><code>$ raku -e 'say --«<a b c d c d>.BagHash' | |
| BagHash(c d) | |
| </code></pre> | |
| <p>as expected.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5KdqJa"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-09-16T12:12:24Z">2022-09-16 12:12</time> | |
| </div> | |
| <div class='body'> | |
| <p>Quoting from https://docs.raku.org/language/operators#index-entry-hyper_%3C%3C-hyper_%3E%3E-hyper_%C2%AB-hyper_%C2%BB-Hyper_operators:</p> | |
| <blockquote> | |
| <p>Hyper operators can work with hashes. The pointy direction indicates if missing keys are to be ignored in the resulting hash. The enclosed operator operates on all values that have keys in both hashes.</p> | |
| </blockquote> | |
| <p>I think it makes sense that >>. behaves similarly, operating on the values of the Associative data types. I'm not sure if the issue was concerned with this approach but maybe it's good to point out that this seems to derived from related documented behavior.</p> | |
| <p>There are still problems with the semantics/documentation of hyper operators, I wanted to open an issue for that, getting into it now.</p> | |
| <p>EDIT: #346 is ready now.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5KgF8u"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-09-16T23:08:39Z">2022-09-16 23:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>@2colours</p> | |
| <blockquote> | |
| <p>Quoting from [doc]:</p> | |
| <p>The pointy direction indicates if missing keys are to be ignored in the resulting hash. The enclosed operator operates on all values that have keys in both hashes.</p> | |
| </blockquote> | |
| <p>Aiui that doc is about binary op hypers ("both hashes", i.e. "missing keys" is about one hash having a key and the other not and so the direction controls whether the mismatch means that element is dropped or not), not unary ops like this issue. I'm not seeing a connection.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5KgJpd"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-09-16T23:53:14Z">2022-09-16 23:53</time> | |
| </div> | |
| <div class='body'> | |
| <p>@raiph</p> | |
| <p>I am making the connection by saying:</p> | |
| <blockquote> | |
| <p>I think it makes sense that >>. behaves similarly, operating on the values of the Associative data types.</p> | |
| </blockquote> | |
| <p>Since it seemed the "operating on the values" part may not be written down for the >>. call.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="344"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/344"><span class='number'>344</span></a> - <span class='title'>Interoperability of numeric type objects</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-09-06T11:02:24Z">2022-09-06 11:02</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Hello, | |
| I think it would be good to clarify how much type objects of different numeric types can be coerced into each other or used in the place of each other. Right now the situation is very mixed. I think this is something that will eventually need more documentation as well but I think there are some outcomes that don't seem to add up with others.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>Int covers both Real an Numeric - even for the type object, this means the former can be assigned to the latter without coercions involved.</p> | |
| <pre><code class="language-perl">my Int $origin; | |
| my Real $rversion = $origin; | |
| my Numeric $nversion = $origin; | |
| dd $origin, $rversion, $nversion; #all Int | |
| </code></pre> | |
| <p>The scene is very "colorful" with type object coercions:</p> | |
| <pre><code class="language-perl">Int.Int # Int | |
| Int.Real # cannot use type object in Numeric context | |
| Int.Numeric # cannot use type object in Numeric context | |
| Real.Real # cannot use type object in Numeric context | |
| </code></pre> | |
| <p>These are just a couple of examples.<br /> | |
| I think it would make sense for those coercions to work where the typed assignment works and Int.Int shows that they could work. It doesn't seem to me that there is anything Int-specific about it but you may correct me.</p> | |
| </div> | |
| <div class='comments'> | |
| </div> | |
| </div> | |
| <div class='issue' id="343"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/343"><span class='number'>343</span></a> - <span class='title'>When and by whom should changes in Rakudo be documented?</span></div> | |
| <div class='author'>[open]<span class='author'>@patrickbkr</span> opend this issue at <time datetime="2022-08-23T08:28:30Z">2022-08-23 08:28</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Here's what we are currently usually doing: <em>After</em> each release, someone from the docs team sets up an issue with all changes in the release that need to be documented. Then the docs team works trough that list and documents things.</p> | |
| <p>I think this is not ideal:</p> | |
| <ul> | |
| <li>The people most knowledgeable of a change (the implementers) are not the ones documenting the change. As a result the documentation is potentially not as good as it could be.</li> | |
| <li>The benefits of <a href="https://opensource.com/article/17/8/doc-driven-development">documentation driven development</a> are neglected.</li> | |
| <li>Puts pressure on the documentation team as they need to keep up with changes the implementers put into Rakudo and / or Raku.</li> | |
| <li>The documentation changes happen <em>after</em> the release has happened. This means users won't have documentation for the changes in the latest release.</li> | |
| <li>This also means, that freezing / versioning the documentation together with each release is not feasable. (That's something the docs team is currently thinking about.)</li> | |
| </ul> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5I8NAO"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-08-23T08:34:29Z">2022-08-23 08:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>An obvious solution is for implementers to document their changes right away. So idealy implementation, tests and documentation always come together.</p> | |
| <p>A potential drawback is, that not all implementers are necessarily good documenters thus putting pressure on those implementers. But either people can learn becoming better documenters or the documentation team can help out. (<em>Before</em> the release, that is!)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5I8Npu"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-08-23T08:36:51Z">2022-08-23 08:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>@JJ I'd value your opinion as you are the one faithfully doing the post-release documentation work for a very long time. (Thank you very much for the huge amount of work you put into this!)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5I8Q-x"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-08-23T08:48:30Z">2022-08-23 08:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>@lizmat I'd value your opinion, as you are the most prolific implementer in Rakudo. (Thank you for all the work you put into making Rakudo better!)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5I8VDm"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-08-23T09:02:28Z">2022-08-23 09:02</time> | |
| </div> | |
| <div class='body'> | |
| <p>Another obvious drawback is, that requiring implementors to write documentation reduces resources available for actual development. It's not like we have got those to spare. Point in case: RakuAST - arguably currently the strategically most important initiative - has not seen any development at all in more than a month, simply because I've been busy with my new job.</p> | |
| <p>Not less important is the question whether implementors even want to write documentation. This being a purely volunteer effort and all.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5I934T"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-23T14:45:43Z">2022-08-23 14:45</time> | |
| </div> | |
| <div class='body'> | |
| <p>+1 to the resources point. I'm even having troubles adding spectests lately to some changes if they are about fixes only. It makes me feel guilty, but better this way than no fixes.</p> | |
| <p>Besides, not with my clumsy English it is to mangle with the docs.</p> | |
| <p>But I will always be around to explain details of the changes I've done.</p> | |
| <p>And all this is written by the one who never releases a module without documenting it first. Preferably in full.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5I95hp"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-23T14:50:52Z">2022-08-23 14:50</time> | |
| </div> | |
| <div class='body'> | |
| <p>To make it kinda a separate statement: I'm well aware of the documentation lagging behind. Unfortunately, the problem won't be solved until there are enough volunteers to fill the gaps. No constraints would help because, as @niner stated, we all do it on voluntary basis.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5I98w7"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-23T15:00:41Z">2022-08-23 15:00</time> | |
| </div> | |
| <div class='body'> | |
| <p>BTW, the problem has another aspect. One better know the structure of the documentation and the future plans for it. Otherwise this would end up with unmanageable, unreadable, and, consequently, useless mess.</p> | |
| <p>This means one has to spent extra time to keep up with the events in this area. Resources, again...</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="342"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/342"><span class='number'>342</span></a> - <span class='title'>"Failure is Nil" and the anomalies this leads to</span></div> | |
| <div class='author'>[closed]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-08-06T15:15:09Z">2022-08-06 15:15</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Hello, | |
| to provide a very brief summary: the <em>contradicting implications</em> of "Nil as absence" and "Nil as soft error" leads to severe inconsistencies and drills holes to a type system.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>This problem came up as we were experimenting with the idea of a <code>?.</code> operator and missing values in general.<br /> | |
| (The first thing that we came across is that Nil gets out freely from typed functions, rather than the default value of the given type. This can be deduced from the current implementation of things and maybe it is specced even - but is this behavior worth it? It's a hole on the type system... I think it would deserve another issue.) | |
| As the documentation points out right at the beginning, <code>Nil</code> can stand for a missing value. When assigned to a container, the container will reset to the default value. The problems arise when we consider <code>Failure</code>s that descend from <code>Nil</code>:</p> | |
| <pre><code>my $nil-assigned = Nil; | |
| say $nil-assigned ~~ Nil; # False because the default value (Any) got assigned | |
| my $subnil-assigned = [].pop; # this is a certain Failure type | |
| say $subnil-assigned ~~ Nil; # True! Failures do get stuck in the container | |
| </code></pre> | |
| <p>This is a serious violation of Liskov Substitution Principle: among all <code>Nil</code>s, the actual <code>Nil</code> is the one that does not get assigned to a container.</p> | |
| <p>I get the idea behind failures - soft errors that can be detected and handled at runtime as values on their own - even if I'm not sure I like it. The problem is that it has nothing to do with the very apparent "absence semantics" of <code>Nil</code> and should be kept separate from that, wherever assignments and types can come up. It would be easy to make typed functions return something typed, instead of Nil, just like containers already do. That would break <code>Failure</code>s if they are subclassed from <code>Nil</code>.</p> | |
| <p>So my questions are:</p> | |
| <ul> | |
| <li>why are <code>Failure</code>s subclassed from <code>Nil</code>?</li> | |
| <li>is it really worth it, given the also established "Nil is absence" semantics?</li> | |
| <li>since <code>Failure</code>s already don't act compatible with <code>Nil</code>, what would it take if they got torn from <code>Nil</code>? What would break from it in the core language? What would break at "end users" apart from the shown smartmatch (that is a really strong WAT competitor)?</li> | |
| </ul> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9Uet"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-08-06T18:05:26Z">2022-08-06 18:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>I would really like feedback from @TimToady @thoughtstream @jnthn on this.</p> | |
| <p>I know Jonathan is on vacation and offline for the next weeks, so I'm not expecting anything from them for a while.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9Um5"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-08-06T18:08:41Z">2022-08-06 18:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>FWIW you can bind <code>Nil</code>:</p> | |
| <pre><code class="language-raku">my $nil := Nil; | |
| say $nil.^name; | |
| =output Nil | |
| </code></pre> | |
| <p>But if type and type safety is important, then I guess you should do at least one of two things:</p> | |
| <ul> | |
| <li>Specify the type on your variable, so <code>Nil</code> sets its value to the type, when there is no value</li> | |
| <li>Instead of <code>Nil</code>, return the type object</li> | |
| </ul> | |
| <p>If I'm missing something, ignore my comment.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9VeU"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-08-06T18:32:55Z">2022-08-06 18:32</time> | |
| </div> | |
| <div class='body'> | |
| <p>@CIAvash Why wouldn't you be able to bind <code>Nil</code>?</p> | |
| <p>If you wouldn't be able to do that, something like <code>my $a := @b.first(/ ... /)</code> would <code>die</code> if no match could be found.</p> | |
| <p>Re being able to do one of two things: isn't that already the case?</p> | |
| <pre><code class="language-raku">my Int $a := Nil; | |
| # Type check failed in binding; expected Int:D but got Nil (Nil) | |
| my Int $a = Nil; | |
| say $a; # (Int) | |
| </code></pre> | |
| <p>Or am I missing something?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9Wg3"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-08-06T19:02:05Z">2022-08-06 19:02</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>@CIAvash Why wouldn't you be able to bind <code>Nil</code>?</p> | |
| </blockquote> | |
| <p>You can, I mentioned it in case @2colours wasn't aware of it.</p> | |
| <blockquote> | |
| <p>Re being able to do one of two things: isn't that already the case?</p> | |
| <pre><code class="language-raku">my Int $a := Nil; | |
| # Type check failed in binding; expected Int:D but got Nil (Nil) | |
| my Int $a = Nil; | |
| say $a; # (Int) | |
| </code></pre> | |
| <p>Or am I missing something?</p> | |
| </blockquote> | |
| <p>You are correct. I'm saying that if your function is returning <code>Nil</code> and you want type safety, then your variable should have a type:</p> | |
| <pre><code class="language-raku">my Int $a = some_function_which_returns_nil; | |
| # Instead of | |
| my $a = some_function_which_returns_nil; | |
| </code></pre> | |
| <p>And the other one, your function can return <code>Int</code> type object instead of <code>Nil</code>, if you don't want to specify the type of the variable:</p> | |
| <pre><code class="language-raku">my $a = some_function_which_returns_defined_integer_or_Int; | |
| </code></pre> | |
| <p>And about the example given about <code>[].pop</code>. I'm not sure what it's showing about the issue:</p> | |
| <pre><code class="language-raku">my $subnil-assigned = [].pop; | |
| say $subnil-assigned.^name | |
| =output Failure | |
| say $subnil-assigned; | |
| =output Cannot pop from an empty Array | |
| </code></pre> | |
| <p>Again, it's possible I'm misinterpreting things, or not understanding the issue.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9ZBP"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-06T20:06:39Z">2022-08-06 20:06</time> | |
| </div> | |
| <div class='body'> | |
| <p>Yes, I "knew" (or at least didn't assume the opposite) that Nil is available as a value - after all, when you aren't using containers, the whole reasoning about "assignment to containers" won't apply.</p> | |
| <p>I would say it's a good workaround that you hardcode (Type) when you want function return types, still just a workaround. To provide further context: this came up in relations with a supposed <code>?.</code> operator which should be able to aggregate missing values. Now that we have typed missing values, it would be good to achieve that in such a (theoretical? eventual?) situation as well. This is another case where Nil as a function return value came up and since it signifies a missing value, it would be both convenient and logical that it doesn't leak untyped but wraps into the right type, like with containers.</p> | |
| <blockquote> | |
| <p>And about the example given about [].pop. I'm not sure what it's showing about the issue:</p> | |
| </blockquote> | |
| <p>It's just a hilarious illustration that semantically <code>Failure</code> is not <code>Nil</code>, disproving the values of the smartmatch swiftly. They have none of the absence semantics which is so essential to <code>Nil</code>. It's really just funnier that the exact behavior ends up reading like "Nil is not Nil but something not Nil is indeed Nil".</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9Zj8"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-08-06T20:24:38Z">2022-08-06 20:24</time> | |
| </div> | |
| <div class='body'> | |
| <p>Am I correct to assume that the main goal of this issue is that you don't want functions to be able to return <code>Nil</code>, but instead return the default value/type of the return value/type of the function?</p> | |
| <blockquote> | |
| <p>I would say it's a good workaround that you hardcode (Type) when you want function return types, still just a workaround.</p> | |
| </blockquote> | |
| <p>I wouldn't say it's a workaround, type objects in Raku are like option types from other programming languages; if there is a defined value, then it's <code>Some(value)</code>(Rust) or <code>Just value</code>(Haskell) and if there is no value, then it's a type object which is similar to <code>None</code>(Rust) or <code>Nothing</code>(Haskell).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9aM5"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-06T20:46:30Z">2022-08-06 20:46</time> | |
| </div> | |
| <div class='body'> | |
| <p>The Liskov Substitution Principle is a theory. But in practice when something is subclasses then the reason for a subclass to exist is to change the something and make it behave differently. In my view, what is missing from the short definition of the principle is the scope. I would specify it as what the existing environment expects from a type object must be provided by its subclasses. In a short form.</p> | |
| <p>What it means for <code>Nil</code>/<code>Failure</code> is that the environment expects for them to be transparent for type checks. And that's, basically, it. All other expectations are formulated <em>specifically</em> for each type. Therefore there are no discrepancies or holes.</p> | |
| <p>The case of assigning is also solved by the scope definition.</p> | |
| <p><code>Nil</code>/<code>Failure</code> in their current form allow to solve some tasks which are not solvable otherwise. This and the fact that they are too widely used by the existing codebase make any changes in this area basically impossible.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9bRq"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-06T21:24:26Z">2022-08-06 21:24</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I wouldn't say it's a workaround, type objects in Raku are like option types from other programming languages;</p> | |
| </blockquote> | |
| <p>I'm not even talking about that (even though I'm also not really happy about the way it's solved in Raku). All I'm saying is: if a function that has a return type returns Nil, it should either be the proper typed absence value returned, or a warning (possibly an error) should be issued for returning a not type safe value from the function. It would be elegant, perhaps even useful, to be able to return Nil and get the type wrapping for free.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9bma"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-06T21:35:37Z">2022-08-06 21:35</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>What it means for Nil/Failure is that the environment expects for them to be transparent for type checks. And that's, basically, it. All other expectations are formulated specifically for each type. Therefore there are no discrepancies or holes.</p> | |
| </blockquote> | |
| <p>I think this is a very arbitrary and implementation-centered approach. Read the documentations: https://docs.raku.org/type/Nil "Absence of a value or a benign failure", "The value Nil may be used to fill a spot where a value would normally go, and in so doing, explicitly indicate that no value is present."<br /> | |
| This is a good description, and this what concerns the user. Of course you will find common things in the implementation - it would be a big problem if related things have completely unrelated implementations - but why should it concern the supposed user if they are transparent for type checks or not?</p> | |
| <p>Anyway, what value does it add for a plain <code>Nil</code> and a <code>Failure</code> that they are transparent for type checks? This is what matters, after all, not the sole fact that they do. For a <code>Failure</code>, the added value is that you can return them as a sort of non-throwing exception; for a <code>Nil</code>, it's arguably that it can substitute anything missing, regardless of the type system. These are still unrelated motives.</p> | |
| <blockquote> | |
| <p>Nil/Failure in their current form allow to solve some tasks which are not solvable otherwise. This and the fact that they are too widely used by the existing codebase make any changes in this area basically impossible.</p> | |
| </blockquote> | |
| <p>This is why I asked the questions. What would be the cost to break them up, and if this cost is hard to estimate or just not worth it - what was the perceived benefit of basing non-throwing errors (that are very much present and act as such) on the absence value? Not going to lie: the behavior seems insane enough that it would require strong justification and a reasoning that one can just recite in case such a question arises.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9b7W"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-06T21:48:03Z">2022-08-06 21:48</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>the behavior seems insane enough that it would require strong justification</p> | |
| </blockquote> | |
| <p>I totally disagree here. It goes against your expectations – perhaps, why not? But it fitted mines almost perfectly from the start. So, that's very questionable statement of yours! :)</p> | |
| <blockquote> | |
| <p>related things have completely unrelated implementations</p> | |
| </blockquote> | |
| <p>Not true, in my view. As I said, there are certain expectations from <code>Nil</code>, and there are expectations from <code>Failure</code>. The common subset of properties is what is the essence of <code>Nillish</code> types. That's it.</p> | |
| <blockquote> | |
| <p>What would be the cost to break them up</p> | |
| </blockquote> | |
| <p>I'm somewhat busy to get deeper into theory and point of views. Besides, I think Jonathan may cover this part way better that I would. But I can tell you about the cost. It's going to be about overall performance of Rakudo runtime. Where it currently does a single typecheck two would be necessary. Where the proposed defaulting needs to take place more opcodes would be injected to replace the returned value. It's hard to say if we talk about 1%, or 10%, or whatever else. But the ubiquitousness of typechecks across the core gives me rather unfortunate estimations. :)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9cSI"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-06T22:01:06Z">2022-08-06 22:01</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I totally disagree here. It goes against your expectations – perhaps, why not? But it fitted mines almost perfectly from the start. So, that's very questionable statement of yours! :)</p> | |
| </blockquote> | |
| <p>Ask anyone about the snippet I embedded in the issue-opener. I wonder how many of them would say that it looks sane to them. You are free to add why one works this way and why one the other way - I still don't expect many of them would say it's perfectly okay for Failures to be Nil in this context...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H9m3c"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-08-07T05:09:15Z">2022-08-07 05:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>I see now that you were talking about <code>my Int $a</code>?</p> | |
| <p>I doubt the behavior of <code>Nil</code> will change. And I have to say it works the way I expect it to.</p> | |
| <p>Maybe the solution would be introducing a new type, like <code>Nothing</code>. I'm not sure.</p> | |
| <p>-------- Original Message -------- | |
| On Aug 7, 2022, 1:54 AM, Márton Polgár wrote:</p> | |
| <blockquote> | |
| <blockquote> | |
| <p>I wouldn't say it's a workaround, type objects in Raku are like option types from other programming languages;</p> | |
| </blockquote> | |
| <p>I'm not even talking about that (even though I'm also not really happy about the way it's solved in Raku). All I'm saying is: if a function that has a return type returns Nil, it should either be the proper typed absence value returned, or a warning (possibly an error) should be issued for returning a not type safe value from the function. It would be elegant, perhaps even useful, to be able to return Nil and get the type wrapping for free.</p> | |
| <p>— | |
| Reply to this email directly, <a href="https://github.com/Raku/problem-solving/issues/342#issuecomment-1207284842">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAIDK7WWUEUPHJVNPQQ5GA3VX3JZLANCNFSM55YXFYIA">unsubscribe</a>. | |
| You are receiving this because you were mentioned.Message ID: <em><strong>@</strong></em>.***></p> | |
| </blockquote> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H93hc"> | |
| <div class='header'> | |
| <span class='author'>@MasterDuke17</span> commented at <time datetime="2022-08-07T12:45:35Z">2022-08-07 12:45</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I see now that you were talking about <code>my Int $a</code>? I doubt the behavior of <code>Nil</code> will change. And I have to say it works the way I expect it to. Maybe the solution would be introducing a new type, like <code>Nothing</code>. I'm not sure. | |
| <a href="#">…</a></p> | |
| </blockquote> | |
| <p>I’ve sometimes felt that ‘Empty’ should be used a bit more.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H-Jik"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-07T19:53:32Z">2022-08-07 19:53</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Ask anyone about the snippet I embedded in the issue-opener.</p> | |
| </blockquote> | |
| <p>I'm not sure it's not survivorship bias we're observing. Most of those who see no problem understanding the current behavior would just shrug their shoulders and proceed to their own business.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IBICM"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-08T15:09:31Z">2022-08-08 15:09</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I'm not sure it's not survivorship bias we're observing. Most of those who see no problem understanding the current behavior would just shrug their shoulders and proceed to their own business.</p> | |
| </blockquote> | |
| <p>However, I'm pretty sure we are observing survivor bias <em>on your side</em> because somebody who has possibly spent years with the <em>internals</em> of a language without getting sick of it and moving on, pretty much must say that it makes sense for them.</p> | |
| <p>So yes, actually, I think "anyone" should rather include beginners and potential users in this case because those people are quite surely very well-represented who get it. They form the core members, after all.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IG5i4"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-08-09T19:04:36Z">2022-08-09 19:04</time> | |
| </div> | |
| <div class='body'> | |
| <p>This has made me learn a bit more about Nil, via some tests (Welcome to Rakudo™ v2022.02.):</p> | |
| <pre><code> 1 # use Nil to reset $x on assignment | |
| 2 my $x = Nil; | |
| 3 say $x; #(Any) | |
| 4 | |
| 5 # is the new $x Nil? (hint - no since it was reset by assigning Nil) | |
| 6 say $x ~~ Nil; #False | |
| 7 | |
| 8 # what does [].pop make? | |
| 9 dd [].pop; #Failure.new(exception => X::Cannot::Empty.new(, ... | |
| 10 | |
| 11 # what does [].pop do? (hint - throws the exception) | |
| 12 # [].pop; #Cannot pop from an empty Array ... | |
| 13 | |
| 14 # what happens when I assign that to $y? (hint - get's swallowed) | |
| 15 my $y = [].pop; | |
| 16 dd $y; #Failure $y = Failure.new(exception => X::Cannot::Empty... | |
| 17 | |
| 18 # do the contents of $y smartmatch Nil? | |
| 19 say $y ~~ Nil; #True | |
| 20 | |
| 21 # what happens when I assign this 'Nil' (hint - does not do a reset) | |
| 22 my $a = 42; | |
| 23 $a = $y; | |
| 24 dd $a; #Failure $a = Failure.new(exception => X::Cannot::Empty... | |
| 25 | |
| 26 # what does a pure (none failing) sub look like? | |
| 27 sub does-nowt() {} | |
| 28 my $w = does-nowt; # '' | |
| 29 say $w; #(Any) | |
| 30 | |
| 31 # how about if I pop a Nil? (hint - same as $v = Nil) | |
| 32 my $v = [Nil].pop; | |
| 33 dd $v; #Any $v = Any | |
| 34 say $v ~~ Nil; #False | |
| 35 | |
| 36 # remind me what is a child of what | |
| 37 say Nil ~~ Failure; #False | |
| 38 say Failure ~~ Nil; #True | |
| </code></pre> | |
| <p>Having hacked on raku for a bit, the new learnings from this for me were:</p> | |
| <ul> | |
| <li>assignment of a Failure gets swallowed which prevents it from throwing</li> | |
| <li>the Failure ~~ Nil smartmatch is quite surprising (not sure if this has any use)*</li> | |
| </ul> | |
| <p>Overall, while I have some sympathy with the OP, I think these behaviours are pretty sensible and I would vote for not going through the pain of a change.</p> | |
| <p>The takeaway (for me) is that [].pop wants to throw <code>Cannot pop from an empty Array ...</code> or return a Failure if it is assigned whereas [Nil].pop does not throw and just resets the lvalue Scalar if it is assigned.</p> | |
| <p>Maybe one day I'll RTFM the Exceptions and Try/Catch bits of the raku doc ;-)</p> | |
| <ul> | |
| <li>EDIT: see comment from @salortiz below to very neatly explain this</li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IG8nA"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-08-09T19:19:01Z">2022-08-09 19:19</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The bottom line is that [].pop throws Cannot pop from an empty Array ... whereas [Nil].pop does not throw and just resets if it is assigned.</p> | |
| </blockquote> | |
| <p>Because <code>[].pop</code> is a <code>Failure</code> which will throw when goes unchecked, whereas <code>[Nil]</code> resets before doing anything else and is <code>[Any]</code>, because <code>Array</code>s have containers.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IG-uE"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-08-09T19:29:03Z">2022-08-09 19:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>Not sure why one of my comments wasn't submitted. | |
| Even though this issue is about the behavior of <code>Nil</code>, here it goes:</p> | |
| <p>Based on discussions here and on IRC and the fact that similar things(on typing) have been brought up before, I think we'll need a pragma called <code>use StaticTypes</code> or something like that to tell the compiler to do strong typing. Then it should act like Rust, Haskell, …. More types will probably be needed as well.</p> | |
| <p>I don't know how feasible it is though.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IHkI4"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-08-09T22:10:21Z">2022-08-09 22:10</time> | |
| </div> | |
| <div class='body'> | |
| <p>@CIAvash - this is what rust does:</p> | |
| <pre><code>// An output can have either Some value or no value/ None. | |
| enum Option<T> { // T is a generic and it can contain any type of value. | |
| Some(T), | |
| None, | |
| } | |
| // A result can represent either success/ Ok or failure/ Err. | |
| enum Result<T, E> { // T and E are generics. T can contain any type of value, E can be any error. | |
| Ok(T), | |
| Err(E), | |
| } | |
| // a minimal example | |
| fn main() { | |
| let o: Result<i8, &str> = Ok(8); | |
| let e: Result<i8, &str> = Err("message"); | |
| assert_eq!(o.ok(), Some(8)); // Ok(v) ok = Some(v) | |
| assert_eq!(e.ok(), None); // Err(v) ok = None | |
| assert_eq!(o.err(), None); // Ok(v) err = None | |
| assert_eq!(e.err(), Some("message")); // Err(v) err = Some(v) | |
| } | |
| </code></pre> | |
| <p>Not sure you can just enable this (assuming that you really want to) with a pragma</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IIds8"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-08-10T05:28:06Z">2022-08-10 05:28</time> | |
| </div> | |
| <div class='body'> | |
| <p><code>Nil</code> is both a Type and a value, thinking of it as "absence of value" lacks a fundamental part: It is "absence of <strong>defined</strong> value".</p> | |
| <p><code>Nil</code>, besides always being undefined, is special in two important and orthogonal ways:</p> | |
| <ul> | |
| <li>The value <code>Nil</code>, when assigned to <code>Scalar</code> containers ask them to take its <em>declared</em> default value. | |
| A simple <code>my $can-be-nil is default(Nil);</code> suffice for <code>Nil</code> to stuck at assignment.</li> | |
| <li>Values of Type <code>Nil</code> and its subclasses are exempt from return type constraints.</li> | |
| </ul> | |
| <p>The second is the reason that <code>Failure</code> is a subclass of <code>Nil</code>. A Type hierarchy that allows us to handle exceptions in much more terse ways, without <code>CATCH</code> and <code>try</code> blocks.</p> | |
| <p>IMO the fact that any <code>Routine</code>, regardless of its declared return Type, can <code>fail</code> instead of <code>die</code> is an elegant property of raku´s type system, not a hole.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IKY_l"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-10T13:35:22Z">2022-08-10 13:35</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Nil is both a Type and a value, thinking of it as "absence of value" lacks a fundamental part: It is "absence of defined value".</p> | |
| </blockquote> | |
| <p>I don't think this is fundamental. What would the "absence of undefined value" even mean? Also, Type objects are generally values as well - Nil is not special by being a valid value of the Nil type.</p> | |
| <blockquote> | |
| <p>(...) is special in two important and orthogonal ways</p> | |
| </blockquote> | |
| <p>By pointing out that they are orthogonal, you are basically making my point. If it is, using your words, a fundamental property of <code>Nil</code> that it is the absence of a value that can implicitly fall back to a default, then picking the orthogonal property that it can avoid type checks as the sole basis of the Failure analogy, is conceptually faulty, and actually this doesn't seem hard to fix at all, if there is nothing hidden in this logic: separate the two orthogonal properties into two roles/classes. <code>Nil</code> inherits them both, <code>Failure</code> only inherits the second. Solved.</p> | |
| <p>I was thinking about how I could phrase my problem with the way vrurg (and now implicitly you as well) assumed that sharing the "type check dodging" property is just enough reason to mix them together. It's as if you modelled a car as a ship with additional wheels, arguing that they are both machines that are used for transportation. This is true but a ship has other fundamental properties, too, like that it travels on the surface of water, and this is something that isn't true for a car. They are both <em>vehicles</em>, though.</p> | |
| <p>And now I'd like to know it even more: what's wrong with my proposal? Honestly, I don't think I'm the first one who come up with it as it is rather commonsensical. What got in the way?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IKpAC"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-10T14:24:20Z">2022-08-10 14:24</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>What got in the way?</p> | |
| </blockquote> | |
| <p>I don't actually remember any prior complains about this subject. So, in my memory you're the first. But my memory doesn't span beyond 2018.</p> | |
| <p>Anyway, just to leave a quick note here, without actually considering all the consequences of the move. <code>Nil</code> and <code>Failure</code> could, possibly, be "divorced" if given a property in common. That property could be a special role to mark typecheck-transparent types. This way I could probably even like it, unless it would cause havoc in the existing code.</p> | |
| <p>Unfortunately, that might not be easy to implement even as a 6.e+ feature. I foresee a number of issues there.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ILtA2"> | |
| <div class='header'> | |
| <span class='author'>@TimToady</span> commented at <time datetime="2022-08-10T17:28:00Z">2022-08-10 17:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>Nil is a kind of singularity. Black holes have no hair, and trying to fit | |
| them neatly back into the fabric of the universe results in | |
| contradictions. Similarly, attempting to fit Nil back into the normal type | |
| system is bound to cause problems, which is why we have Raku's Nil rather | |
| than Perl's undef. Perl programmers often fall into the trap of trying to | |
| store undef as a normal value, and get themselves into trouble down the | |
| road.</p> | |
| <p>Black holes can also have an accretion disk (and maybe a "firewall"), which | |
| records some of the history of what is falling into the black hole. This | |
| is what a Failure does; it records some of the history of a singularity. | |
| The stuff still falling in is where black holes can keep their "hair", at | |
| least temporarily.</p> | |
| <p>The design of Nil with respect to Failure was primarily a cultural | |
| decision, not a technical decision. We do not want people thinking of Nil | |
| as a value, or as a type from which other user-defined types can be | |
| derived, other than user-defined Failures. We want them to think of Nil as | |
| the least-marked form of failure, so that they never treat Nil as some kind | |
| of nuanced success marker, or try to create a parallel system of | |
| nothingness that pretends to be storable as a value.</p> | |
| <p>We could conceivably redefine Nil and Failure as both forms of Singularity | |
| (the property which subverts the return type system of the universe by the | |
| permanent absence of a return value), but the universe discourages people | |
| from creating their own singularities, and I suspect we should too.</p> | |
| <p>Hope this helps...</p> | |
| <p>Larry</p> | |
| <p>On Wed, Aug 10, 2022 at 7:24 AM Vadim Belman <em><strong>@</strong></em>.***> | |
| wrote:</p> | |
| <blockquote> | |
| <p>What got in the way?</p> | |
| <p>I don't actually remember any prior complains about this subject. So, in | |
| my memory you're the first. But my memory doesn't span beyond 2018.</p> | |
| <p>Anyway, just to leave a quick note here, without actually considering all | |
| the consequences of the move. Nil and Failure could, possibly, be | |
| "divorced" if given a property in common. That property could be a special | |
| role to mark typecheck-transparent types. This way I could probably even | |
| like it, unless it would cause havoc in the existing code.</p> | |
| <p>Unfortunately, that might not be easy to implement even as a 6.e+ feature. | |
| I foresee a number of issues there.</p> | |
| <p>— | |
| Reply to this email directly, view it on GitHub | |
| <a href="https://github.com/Raku/problem-solving/issues/342#issuecomment-1210748930">https://github.com/Raku/problem-solving/issues/342#issuecomment-1210748930</a>, | |
| or unsubscribe | |
| <a href="https://github.com/notifications/unsubscribe-auth/AABHSYWEGDBKJHUAFEXRIWTVYO3R7ANCNFSM55YXFYIA">https://github.com/notifications/unsubscribe-auth/AABHSYWEGDBKJHUAFEXRIWTVYO3R7ANCNFSM55YXFYIA</a> | |
| . | |
| You are receiving this because you were mentioned.Message ID: | |
| <em><strong>@</strong></em>.***></p> | |
| </blockquote> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IMEZ8"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-08-10T18:48:35Z">2022-08-10 18:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>much ado about nothing (?)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IMHk-"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-10T18:59:51Z">2022-08-10 18:59</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>much ado about nothing (?)</p> | |
| </blockquote> | |
| <p>Ask Heidegger. ;)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IMWjD"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-10T19:52:12Z">2022-08-10 19:52</time> | |
| </div> | |
| <div class='body'> | |
| <p>@TimToady it's always insightful to get some feedback from you, and I don't think anyone can have as distant memories about the design of Raku anyway as you do.</p> | |
| <p>I still have the impression that we agree quite a lot on the concepts - this stands for @vrurg as well, concerning this "common ancestor".</p> | |
| <blockquote> | |
| <p>We could conceivably redefine Nil and Failure as both forms of Singularity | |
| (the property which subverts the return type system of the universe by the | |
| permanent absence of a return value), but the universe discourages people | |
| from creating their own singularities, and I suspect we should too.</p> | |
| </blockquote> | |
| <p>This part is a good example: the conclusion I draw from this presupposed Singularity type is that it would be rather internal; even if not completely hidden, definitely discouraged to use directly, in any shape or form. We can have different reasons to come to this conclusion: I perceive it as a technicality while someone else could consider it really too "meta" and Heidegger-ish to be used by "mere mortals",</p> | |
| <blockquote> | |
| <p>We do not want people thinking of Nil as a value, or as a type from which other user-defined types can be derived, other than user-defined Failures. We want them to think of Nil as the least-marked form of failure</p> | |
| </blockquote> | |
| <p>On the other hand, this is something I don't get. Why are Failures good to go? Why are they allowed to break this principle that you shouldn't treat Nil as a kind of value? Where does the "absence" nature of Nil, backed up by its behavior when assigned to a container, get lost and turned into "the least-marked form of failure"? The same goes for the "accretion disk" analogy - if we start with the assumption that Nil is essentially the proto-failure, then the "accretion disk" that carries additional data makes sense, however, if we start with Nil being the complete lack of a value to be used, it is paradox: Failures do have data, just not <em>valid</em> data. Their data should be kept (and propagated in case), and I suppose this is why they don't reset the container to the default value, like Nil does.</p> | |
| <p>The "complete absence of a value" interpretation isn't only backed up by the documentation and the assignment with containers - as it stands, a "void function" also returns Nil, not Empty or (Any) or anything of the likes. Conceptually, I think it's hardly tenable to say that all subroutines or blocks that don't return a value, "fail silently".<br /> | |
| One step forward: what about <code>sink</code>? Would you say that it turns everything into a "failure" and the happy ending is when this "failure" stays silent (Nil value)? To make things more complicated, <code>sink</code> propagates Failures as Exceptions, hence highlighting how much "present" Failures really are compared to Nil, and also contradicting the "Nil is a failure without any additional data" narrative.</p> | |
| <p>I elaborated on this point long but this is simply because sorting off disagreement or misunderstandings require the most care. I understand that Nil shouldn't be treated like something in the universe of values and hence it makes no sense to try to subject them to type checks. However, "the lack of values", which Nil apparently is and is not, at the same time, can be integrated to a type system, similarly to container assignments.</p> | |
| <p>This, in particular:</p> | |
| <pre><code>sub demo(-->Int) {} | |
| say demo # Nil | |
| </code></pre> | |
| <p>could and should work better i.e properly typed in my opinion. I haven't even written down Nil in the code, yet that's what I get, when I have a function with a type constraint. This shouldn't even have to know about Nil if that didn't have the "absence" semantics - anyway, aiming for a valid Int result and staying consistent with containered variables would be very desirable, in which case we should get (Int).</p> | |
| <p>This is one of my main points: the burden Nil carries by having to act both as absence and failure - two things that are to be treated differently - is too big for it to get either of these tasks well.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IQ6fw"> | |
| <div class='header'> | |
| <span class='author'>@Kaiepi</span> commented at <time datetime="2022-08-11T19:21:22Z">2022-08-11 19:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't like the semantics of <code>Failure:D</code> as a return value with regards to the type system in particular:</p> | |
| <pre><code class="language-raku">for ( | |
| anon only gives(--> Int) { 0 }, | |
| anon only sinks(--> Int) { Nil }, | |
| anon only fails(--> Int) { fail }, | |
| ) -> &value { | |
| CATCH { default { say .^name } } | |
| say my Int $ = value; | |
| } # OUTPUT: | |
| # 0 | |
| # (Int) | |
| # X::TypeCheck::Assignment | |
| </code></pre> | |
| <p>But there is a consistency there somewhere. I see the properties of instances, type objects, <code>Nil</code>, and <code>Failure</code> as existing on a sort of spectrum:</p> | |
| <pre><code>0 1 2 3 | |
| o-----o-----o-----o | |
| |=Instances | | | |
| |=Types | | |
| |=Nil | | |
| |=Failure | |
| </code></pre> | |
| <p>With repects to type smileys:</p> | |
| <ul> | |
| <li><code>0</code> is a valid <code>:D</code></li> | |
| <li><code>1</code> is a valid <code>:U</code> in a binding, in an assignment, and as a return value</li> | |
| <li><code>2</code> is a valid <code>:U</code> in an assignment and as a return value</li> | |
| <li><code>3</code> is a valid <code>:U</code> as a return value</li> | |
| </ul> | |
| <p>That <code>:_</code> covers in its entirety.</p> | |
| <blockquote> | |
| <p>I haven't even written down Nil in the code, yet that's what I get, when I have a function with a type constraint. | |
| This, in particular:</p> | |
| <pre><code>sub demo(-->Int) {} | |
| say demo # Nil | |
| </code></pre> | |
| <p>could and should work better i.e properly typed in my opinion. I haven't even written down Nil in the code, yet that's what I get, when I have a function with a type constraint. This shouldn't even have to know about Nil if that didn't have the "absence" semantics - anyway, aiming for a valid Int result and staying consistent with containered variables would be very desirable, in which case we should get (Int).</p> | |
| </blockquote> | |
| <p>Because no assignment is being made with <code>&demo</code>, you get the return semantics of <code>:U</code> instead of the more specific assignment semantics, so the default <code>Nil</code> return value is typed and remains as-is.</p> | |
| <p>But note the complicated nature of <code>:U</code> in comparison to <code>:D</code>. Personally, when I write a <code>:U</code>, what I <em>really</em> want to write is some shade of grey towards <code>0</code> that would need to be typed with a dynamic subset, and is awkward to produce generically. Would adding <code>:I</code>, <code>:N</code>, <code>:F</code> type smileys to represent <code>0-1</code>, <code>0-2</code>, and <code>0-3</code> explicitly help the situation somewhat?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IRvtn"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-08-12T00:17:47Z">2022-08-12 00:17</time> | |
| </div> | |
| <div class='body'> | |
| <p>@Kaiepi,</p> | |
| <p>The important characteristic of <code>Failure</code>, inherited of <code>Nil</code>, is that any <code>Failure:D</code> is <strong>undefined</strong>, so as a return value is trivially testable;</p> | |
| <pre><code class="language-raku">for ( | |
| anon only gives(--> Int) { 0 }, | |
| anon only sinks(--> Int) { Nil }, | |
| anon only fails(--> Int) { fail }, | |
| ) -> &value { | |
| with (value) { | |
| say my Int $ = $_; | |
| } else { | |
| say "Undefined"; | |
| } | |
| } | |
| # OUTPUT | |
| # 0 | |
| # Undefined | |
| # Undefined | |
| </code></pre> | |
| <p>The Raku documentation should put more emphasis in the difference between <code>definite</code> and <code>defined</code>,</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IS5bX"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-08-12T09:28:16Z">2022-08-12 09:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>Also note that <code>Empty</code> is definitely <code>DEFINITE</code> but not <code>defined</code>:</p> | |
| <pre><code class="language-raku">say Empty.DEFINITE; # True | |
| say Empty.defined; # False | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IUEJT"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-12T15:11:52Z">2022-08-12 15:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>To be precise, empty <code>Slip</code> is undefined: <code>say ().Slip.defined;</code></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IU_uv"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-08-12T19:51:58Z">2022-08-12 19:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>BTW, given the facts that</p> | |
| <pre><code class="language-raku">say Slip ~~ List; # True | |
| say Empty ~~ List; # True | |
| </code></pre> | |
| <p>But, as expected</p> | |
| <pre><code class="language-raku">my @a is List = (), () ,(); | |
| my @b is List = Empty, Empty, Empty; | |
| say @a; # (() () ()) | |
| say @b; # () | |
| </code></pre> | |
| <p>In the OP's line of thought, an LSP violation can be argued: "Among all <code>List</code>s, the actual <code>Empty</code> is the one that is not assigned to …", then "<code>Empty</code> don't act compatible with <code>List</code>".</p> | |
| <p>Does that warrant creating another type for <code>Empty</code>? I don't think so.</p> | |
| <p>There are certainly some subtle asymmetries in Raku, but as @TimToady once commented, "It's the asymmetries that make this universe an interesting one"</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IVXZ4"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-12T22:19:42Z">2022-08-12 22:19</time> | |
| </div> | |
| <div class='body'> | |
| <p>@Kaiepi I gotta respect the effort you have put into making it look more sensible but I have to say I don't find it sane that one needs to take assignment, binding and return values as three distinct phenomena to put it into any consistent table, and mainly that return values aren't any of the other two, is in my opinion a big enough red flag to begin with.</p> | |
| <blockquote> | |
| <p>Because no assignment is being made with &demo, you get the return semantics of :U instead of the more specific assignment semantics, so the default Nil return value is typed and remains as-is.</p> | |
| </blockquote> | |
| <p>Anyway, I think the important part is: "the default Nil return value". So it is the default value, after all, and we can ask once again: does it make conceptual sense that functions by default return "a silent error"? I'd argue that it makes no sense, hence we'd have to accept that it is an essential property of Nil is that it does represent the absolute lack of a value, QED. This conclusion doesn't have to be informed about the technicalities.</p> | |
| <p>Then back to DEFINITE and defined.</p> | |
| <p>This is a whole different issue but these two things would really deserve two different names that is harder to mix up, also to better see which one is involved in which situation.</p> | |
| <p>From what I understand, .defined is higher level, and it doesn't take to be <code>Nil</code> to act as a missing value with by the .defined semantics (confer the example from Lizmat). The docs also just say: | |
| <code>A few types (like [Failure](https://docs.raku.org/type/Failure)) override defined to return False even for instances:</code><br /> | |
| What about .DEFINITE, then? Well, even less data available in the docs but it seems to me it really just means whether you have a ("described") instance of a class, or the type object: | |
| <code>You can use the .DEFINITE method to find out if what you have is an instance or a type object:</code></p> | |
| <p>And here is another part where <code>Nil</code> has a certain behavior that <code>Failure</code> (and as far I'm concerned, no other class?) shares: the instances of Nil are not DEFINITE: Nil.new.DEFINITE returns False. Failure.new.DEFINITE returns true, on the other hand. This is probably related to Nil being such a universal default value, but it really reads like "Nil is a type that is its own only instance as well", and this is such a special property which again discourages any sort of inheritance at all from <code>Nil</code>.</p> | |
| <p>A few examples:</p> | |
| <pre><code>Nil eqv Nil.new #True | |
| Failure eqv Failure.new #False | |
| class CoolNil is Nil {} | |
| CoolNil eqv CoolNil.new #False | |
| CoolNil.raku #Nil | |
| CoolNil eqv Nil #False | |
| CoolNil.new eqv Nil #True | |
| CoolNil.new.DEFINITE #False | |
| </code></pre> | |
| <p>So CoolNil in itself is a "Nil" that isn't the real OG <code>Nil</code>, but its instances are, and its instances also refuse to acknowledge they are instances... aargh. This really just doesn't seem like something that should be done for any reason - I wonder how it's achieved that Failure can have proper instances that don't lie that they aren't instances.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IVZ2T"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-08-12T22:40:43Z">2022-08-12 22:40</time> | |
| </div> | |
| <div class='body'> | |
| <pre><code>So my questions are: | |
| why are Failures subclassed from Nil? | |
| is it really worth it, given the also established "Nil is absence" semantics? | |
| since Failures already don't act compatible with Nil, what would it take if they got torn from Nil? What would break from it in the core language? What would break at "end users" apart from the shown smartmatch (that is a really strong WAT competitor)? | |
| </code></pre> | |
| <p>IMO these points have been answered in this thread. N'est ce pas?</p> | |
| <p>Nothing to see here, move along...</p> | |
| <p>EDIT: I apologise for my over-emotional and intolerant comment.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IVcn9"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-12T23:12:12Z">2022-08-12 23:12</time> | |
| </div> | |
| <div class='body'> | |
| <p>The discussion is over when there is nothing more to talk about, or nobody to talk. I don't think any of these apply here. If you have nothing else to add, that's perfectly fine, you don't have to.</p> | |
| <blockquote> | |
| <p>On CoolNil, it's existence is a consequence of a consistent and open "everything is a class" approach ... but it is not intended to be a user facing language feature.</p> | |
| </blockquote> | |
| <p>And by the way, this is absolutely not true: <code>Failure</code>s show exactly that inheriting from <code>Nil</code> is a legitimate and common thing to come across - it is exactly my point that <code>Nil</code> is, very blantly put, so weird that for this sole reason one should have stayed away from subclassing it. Also, it doesn't just straight follow from "everything is a class" that some subclasses of <code>Nil</code> will have non-definite instances and they will have two different <code>Nil</code>s for the type object and the instance, the latter being the real <code>Nil</code>. Actually it's so weird that I would consider sharing it, if for no other reason, to see if this is known behavior at all.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IWJIh"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-08-13T05:48:01Z">2022-08-13 05:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>@2colours,</p> | |
| <p>The Nil constructor is special, it deliberately returns its own type:</p> | |
| <pre><code class="language-raku">Nil.new === Nil; # True (eqv isn't the best tool for value identity testing) | |
| </code></pre> | |
| <p>Your CoolNil, a new different class, inherits Nil constructor so <code>CoolNil === Nil</code> is False but <code>CoolNil.new === Nil</code> is True. | |
| BTW, the "reset to default" effect of Nil (as a value) in Scalar assignment isn't an intrinsic property of the Nil class, it is hardwired behavior of "scalar assignment" (but not "list assignment"), so your <code>CoolNil.new</code> will trigger it.</p> | |
| <pre><code class="language-raku">class CoolNil is Nil {} | |
| my $a is default(0) = 8; | |
| ($a = CoolNil.new) ~~ Nil; # False | |
| say $a; # 0 | |
| my &func is default(sub { 'def' }) = sub { 1 }; | |
| say func; # 1 | |
| &func = CoolNil.new; | |
| say func; # 'def' | |
| # Because | |
| dd &func.VAR.WHAT; # Scalar | |
| </code></pre> | |
| <blockquote> | |
| <p>I wonder how it's achieved that Failure can have proper instances that don't lie that they aren't instances.</p> | |
| </blockquote> | |
| <p>Any subclass can define its own constructor:</p> | |
| <pre><code class="language-raku">class OtherNil is Nil { | |
| method new { self.bless } | |
| } | |
| say OtherNil === Nil; # False (obvious) | |
| say OtherNil ~~ Nil; # True | |
| say OtherNil.new ~~ Nil; # True (by definition) | |
| say OtherNil.new.DEFINITE; # True (expected) | |
| dd OtherNil.new; # OtherNil.new | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IXj7J"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-13T10:42:08Z">2022-08-13 10:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>@salortiz I deliberately used <code>eqv</code> because if I used <code>===</code>, someone would have immediately said "that acts upon pointer values and isn't a good idea to rely on it".... By the way, correct me if I'm wrong but <code>eqv</code> uses <code>===</code> by default anyway, so in this case it's just an abstraction on top.</p> | |
| <p>Thank you for the explanation. At the end of the day, there is always something useful to learn. In the big picture of this issue, though, I think only the terms change as we keep digging deeper: if Nil silently but deliberately refuses to make actual instances, and hence it can never be DEFINITE, it doesn't seem to be a good idea to replace it with something that does make actual instances and can be DEFINITE...</p> | |
| <blockquote> | |
| <p>say OtherNil === Nil; # False (obvious)</p> | |
| </blockquote> | |
| <p>One more: this is not so obvious for CoolNil - also returned False but .raku gave 'Nil'.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IX-SN"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-13T23:08:59Z">2022-08-13 23:08</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I don't find it sane that one needs to take assignment, binding and return values as three distinct phenomena</p> | |
| </blockquote> | |
| <p>But they are different. Assignment and binding are different in what happens to a value with regard to the destination symbol. Return is not about assignment whatsoever. The only thing they have in common is type checking which <em>is</em> done the same way in all three cases.</p> | |
| <p><em>Upd</em> My mistake, assignment and binding do it differently from return. I mean, the type checking is not different, but what each operation does to the value is different. Where return is a transmission and it bypasses <code>Nil</code> as-is, assignment and binding are the terminal stages and as such they have to deal with a value somehow. But either way, they all <em>know</em> about <code>Nil</code> and in each case make their own decision as to how to deal with it.</p> | |
| <blockquote> | |
| <p>does it make conceptual sense that functions by default return "a silent error"?</p> | |
| </blockquote> | |
| <p>Have you tried to think of it as taking a value from a non-returning function is an error? Not a critical one though, hence the silence.</p> | |
| <blockquote> | |
| <p>it doesn't seem to be a good idea to replace it with something that does make actual instances and can be DEFINITE</p> | |
| </blockquote> | |
| <p>Again, the problem is that your scope of the problem is different, from what scope has been initially applied to Nil. Yet, speaking of <code>Failures</code>, they cannot be non-DEFINITE due to they carrying on a value which is expected to be an error description. As long as values are individual objects, their containers has to be different too.</p> | |
| <p>And yet, a <code>Failure</code> isn't a useful value on its own because it is representing a <em>problem</em> not a <em>solution</em>. This is why it is not <code>.defined</code>.</p> | |
| <p>Yes, these differences are subtle, but aren't we operate with subtle differences in our natural languages? We call them <em>nuances</em>, for example; or <em>synonyms</em>; or there are some other language constructs which allow us to differentiate between slightly different term, or emotional coloring, or whatever else one could think of.</p> | |
| <blockquote> | |
| <p>One more: this is not so obvious for CoolNil - also returned False but .raku gave 'Nil'.</p> | |
| </blockquote> | |
| <p><code>Nil</code> is a black hole, remember? It doesn't fir the classical laws. <code>CoolNil</code> is your shiny foil wrap for it. You just left a gap in that wrap. Cover it:</p> | |
| <pre><code class="language-raku">class CoolNil is Nil { | |
| method new { self.bless } | |
| method raku { "[" ~ self.^name ~ " wrap around Nil]" } | |
| } | |
| class OtherNil is CoolNil { } | |
| say OtherNil.new.raku; | |
| say OtherNil.raku; | |
| </code></pre> | |
| <p>Because <code>.raku</code> is just a method sticking out on the edge of the event horizon...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IYOLQ"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-14T08:17:02Z">2022-08-14 08:17</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>But they are different. Assignment and binding are different in what happens to a value with regard to the destination symbol. Return is not about assignment whatsoever. The only thing they have in common is type checking which is done the same way in all three cases.</p> | |
| </blockquote> | |
| <p>As I said: assignment and binding, so be it, but returning must be either binding or assignment, there is no third option. These are the two things you can set up a return value and these are the two options to tie the return value to a symbol from the caller's side. I think this made perfect sense in C++ - but anyway, what was the motive to create a third behavior that doesn't fit into the two "productive", actually available options?</p> | |
| <blockquote> | |
| <p>Have you tried to think of it as taking a value from a non-returning function is an error? Not a critical one though, hence the silence.</p> | |
| </blockquote> | |
| <p>I tried - it doesn't work, for me at least. Why would you be thinking that all functions start from a "soft error" position, if you can instead think that they are missing a return value altogether, which is not a failure, just a corner case?<br /> | |
| And mind you, this is how Raku also behaves. If you assign this value, it will do something that has no signs of being invalid: resets the value. This doesn't make sense if we treat Nil as explicitly invalid - we don't want invalid things to hide behind valid behavior.</p> | |
| <blockquote> | |
| <p>Yet, speaking of Failures, they cannot be non-DEFINITE due to they carrying on a value which is expected to be an error description. As long as values are individual objects, their containers has to be different too.</p> | |
| </blockquote> | |
| <p>Exactly! This makes sense. A Failure <em>is</em> a value, just not a <em>valid</em> one. A true Nil <em>is not</em> a value.</p> | |
| <blockquote> | |
| <p>Yes, these differences are subtle, but aren't we operate with subtle differences in our natural languages? We call them nuances, for example; or synonyms; or there are some other language constructs which allow us to differentiate between slightly different term, or emotional coloring, or whatever else one could think of.</p> | |
| </blockquote> | |
| <p>First off, I don't like the general idea - we create languages to make things easier, not to repeat the same inconveniences natural languages develop because of their heavy exposure to social and historical events. Natural languages are <em>not good enough</em> for programming; I would argue they often aren't good enough for their own purpose but for programming, surely not.<br /> | |
| Second, I still think this is about the ship and the car. "ship" isn't a synonym of "car", even though they are both vehicles. It's not a nuance that Nil is a lack of value (while Failure isn't) - it is part of the core behavior of Nil, anywhere you look.</p> | |
| <p>.defined has somewhat fragile semantics in my opinion, given that an empty Slip can also be "undefined". I'm not saying it's bad per se, it's just hard to come up with a consistent interpretation, if valid BUT empty values can also be "undefined".<br /> | |
| <strong>Maybe one could say: something is .defined if and only if it is a both <em>present</em> and <em>valid</em> value.</strong> In this interpretation:</p> | |
| <ul> | |
| <li>Empty is valid but not present</li> | |
| <li>Nil is not present (and it's a part of the argument whether it is valid or not)</li> | |
| <li>Failure is present but not valid</li> | |
| </ul> | |
| <p>Therefore I think it makes sense that no matter how we look at <code>Nil</code>, with <code>Failure</code> they will both be not .defined. <strong>The difference is that I think it's a way too fundamental difference between <code>Nil</code> and <code>Failure</code> that <code>Nil</code> is not present and <code>Failure</code> is present.</strong> This is a part of the reason why .DEFINITE works differently for them, I suppose.</p> | |
| <blockquote> | |
| <p>Nil is a black hole, remember? It doesn't fir the classical laws.</p> | |
| </blockquote> | |
| <p>I didn't want to intervene yesterday but I did note in your presentation when you said "what if Nil can also be a valid value of " certain attribute. Maybe not with these exact words but you probably remember. :P So honestly, let us decide if <code>Nil</code> is something legitimate or a weird special value that one shouldn't build API's around.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IYw79"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-14T21:23:57Z">2022-08-14 21:23</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>but returning must be either binding or assignment, there is no third option</p> | |
| </blockquote> | |
| <p><em>"Even if you've been eaten up there is still two exits from the situation..."</em></p> | |
| <p>Return is a transmission. It is certainly <em>not</em> an assignment or binding because what is returned doesn't end up bound to a symbol or an attribute.</p> | |
| <blockquote> | |
| <p>when you said "what if Nil can also be a valid value of " certain attribute</p> | |
| </blockquote> | |
| <p>A black hole is a physical object. <code>Nil</code> is a type object.</p> | |
| <p>Otherwise it feels to me like we're starting a second lap here. So, my conclusion would be to give another reason to rattle about:</p> | |
| <pre><code>my $a = 1; | |
| say $a === $a.Int; | |
| $a = <1>; | |
| say $a.WHAT; # IntStr | |
| say $a ~~ Int; # True | |
| say $a === $a.Int; # False | |
| </code></pre> | |
| <p>What would the Lipskov principle in the pure flat world say about it? It is broken because the allomorph cannot be used exactly everywhere where <code>Int</code> can be. But somehow we exclude the coercion case from the set of conditions and – voila! – allomorph conforms to the principle!</p> | |
| <p>That brings me to the cause of all this misunderstanding: the scope. Acceptance or denial of <code>Failure</code> as a subclass of <code>Nil</code> is purely a matter of expectations <em>or</em> following the documentation and the specs (I simplify here, but it's not a manuscript format to cover all the nuances).</p> | |
| <p>There is a point about disappointment or confusion. Well, the problem is: this world is a disappointment for all of us. If we can ever speak about expectations of a fetus, they are most certainly get broken after the birth.</p> | |
| <p>I have my own disappointments, speaking of Raku, BTW.</p> | |
| <p>So, I personally not convinced that there is real need in splitting the two. 🤷🏼♂️</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IY3ur"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-08-15T00:05:33Z">2022-08-15 00:05</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>It is certainly not an assignment or binding because what is returned doesn't end up bound to a symbol or an attribute.</p> | |
| </blockquote> | |
| <p>Why should that matter? This arguably violates a bigger "substitution principle" than the one from Liskov. It means that you cannot exactly reproduce the behavior of a function return value. Literally. You had two ways to capture it and it does a third thing. Again, for what purpose? I again don't know a language that does this and it seems to go against any unwritten design principles in any language. Maybe the xvalue of C++ could be compared - but that falls into a different conceptual layer and it also has a low-level purpose.</p> | |
| <blockquote> | |
| <p>A black hole is a physical object. Nil is a type object.</p> | |
| </blockquote> | |
| <p>I don't know what you tried to say with this but my point is that you cannot say both "Nil can be a value worthy of storing" and "Nil cannot be expected to work like a proper type of value(s)" without either contradicting yourself or implying that you are one of the harbringers. 😂</p> | |
| <blockquote> | |
| <p>What would the Lipskov principle in the pure flat world say about it? It is broken because the allomorph cannot be used exactly everywhere where Int can be.</p> | |
| </blockquote> | |
| <p>This sounds like a strawman to me, not gonna lie. By the same chance, you might as well have said the Liskov's Substitution Principle is literally against inheritance because whenever you want to check the exact type of the object, you won't get the same value.<br /> | |
| Now, you did something that strongly relies on exact type and the exact type is different by definition. But I mean... do you sincerely not feel the difference between "the exact types don't match" and "the thing users want to do most of the time - assignment, mind you - has contradicting outcomes for the two"?</p> | |
| <blockquote> | |
| <p>Acceptance or denial of Failure as a subclass of Nil is purely a matter of expectations or following the documentation and the specs (I simplify here, but it's not a manuscript format to cover all the nuances).</p> | |
| </blockquote> | |
| <p>It can be very well concluded from the documentation that this was a bad idea - and anyway, these things aren't either set into stone, nor any sort of authority to appeal to. "Fix the language, not the user", "Torture implementors on the user's behalf", just two thoughts from Larry Wall himself.</p> | |
| <p>I would say that this is a "disappointed but not surprised" situation - the same reason I didn't push harder around ne and != not being proper operators, and a few others. As I "predicted" on the IRC:</p> | |
| <ul> | |
| <li>there will be some sentiments about the technical reason why it works this way (even when it's explicitly pointed out that this is a deliberate design decision and I'm targeting it as such)</li> | |
| <li>some unconvincing arguments to chew (I have pointed it out on several occasions that I see the main contradiction around the "just missing" behavior and the "documented error" behavior and I have given up on waiting for a response better than "but have you tried thinking that it's right behavior")</li> | |
| <li>eventually we will get to "c'est la vie, time to move on, deal with it" sort of remarks</li> | |
| </ul> | |
| <p>This is indeed just a waste of time for all of us. Perhaps it would be better if I just collected these sort of eyebrow-raiser behaviors for myself and published a post somewhere whenever I find another ten of them.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5L84Wf"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-10-11T07:55:28Z">2022-10-11 07:55</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>The "complete absence of a value" interpretation isn't only backed up by the | |
| a "void function" also returns Nil, not Empty or (Any) or anything of the | |
| likes. Conceptually, I think it's hardly tenable to say that all subroutines | |
| or blocks that don't return a value, "fail silently".</p> | |
| </blockquote> | |
| <p>But you could say that those void functions or blocks "fail to return a | |
| value".</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5L9K51"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-10-11T08:44:41Z">2022-10-11 08:44</time> | |
| </div> | |
| <div class='body'> | |
| <p>Based on discussions here and on IRC and the fact that similar things have been brought up before, I think we'll need a pragma called <code>use StaticTypes</code> or something like that to tell the compiler to do strong typing. Then it should act like Rust, Haskell, …. More types will probably be needed as well.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5L_xKE"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-10-11T17:04:35Z">2022-10-11 17:04</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>But you could say that those void functions or blocks "fail to return a value".</p> | |
| </blockquote> | |
| <p>Indeed, "could say" that, however I think that's mostly a play with words, and even as such, it can be argued against: as someone who never climbed Chimborazo, it would be odd for me to state that I "failed to climb Chimborazo". I was never meant to do that.<br /> | |
| This is a typical case for "void functions" - they don't "fail" in any sense "Failure" implies, they are simply invoked for the side effect, and continuing with the execution flow is a sign of apparent success. It doesn't have to be this way but Raku, along with all mainstream imperative languages, is designed this way.</p> | |
| <p>By the way, just a couple of days ago, I noticed that <code>sub empty { Nil with Nil }; empty</code> returns Empty indeed. This seems to be because it's the same thing as the "list comprehension" mentioned in the transition guide from Python.<br /> | |
| So now, all of sudden, the <code>empty</code> function doesn't fail to return a value...</p> | |
| <p>I think what could still be a meaningful question is what MasterDuke already hinted: when to use Nil or Empty in the first place (let alone type objects :D).</p> | |
| <p>CIAvash is also making a good point but I think eventually we'll need to define new topics for new discussions because "Failure is Nil" is a dead horse... For the time being, I have enough open topics that nobody seemed to care about - even though I think the one about hyper metaoperators would be generally important - so personally, I'm more trying to focus on refurbishment of the resources we already have. Still, please don't leave me out if those discussions actually happen. :P</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5MBnVX"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-10-12T02:07:57Z">2022-10-12 02:07</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>This is a typical case for "void functions" - they don't "fail" in any sense "Failure" implies</p> | |
| </blockquote> | |
| <p>Any function that returns <code>Nil</code> in fact "fail" in the same sense that <code>Failure</code> implies.</p> | |
| <p>In Raku that "fail" is well defined and observable using the phasers <code>KEEP</code> and <code>UNDO</code>:</p> | |
| <pre><code class="language-raku">sub nothing() {} | |
| sub ToSucceed() { | |
| KEEP say 'Raku knows this succeeds'; | |
| UNDO say 'Raku knows this failed'; | |
| say "Executed"; | |
| } | |
| sub ToFail() { | |
| KEEP say 'Raku knows this succeeds'; | |
| UNDO say 'Raku knows this failed'; | |
| say "Executed"; | |
| Nil # This can be substituted by a call to nothing | |
| } | |
| </code></pre> | |
| <p>This is important, for example, to the semantic of the <code>let</code> declarations.</p> | |
| <p>In Raku the proper way to declare a "void function" is by explicitly annotate <code>Nil</code> as its return type. That results in the compiler optimize it forcing a <code>sink</code> context to its last statement (if any).</p> | |
| <p>On another side, you should not be surprised by the value returned by <code>Foo with Nil</code>. In Raku, any conditional statement when not executed, as a expression returns <code>Empty</code>:</p> | |
| <pre><code class="language-raku">('hi' with Failure.new()) === Empty; # True | |
| (42 with Any) === Empty; # True | |
| (Any if False) === Empty; # True | |
| (die 'Humm' unless True) === Empty; # True | |
| (say 'Foo' without 42) === Empty; # True | |
| Empty === do if False { die }; # True | |
| </code></pre> | |
| <p>Very useful because loops can constructs lists.</p> | |
| <p>I'm beating the dead horse because this thread shows that, in some topics, Raku´s documentation needs a more formal treatment.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5MFAmM"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-10-12T15:38:55Z">2022-10-12 15:38</time> | |
| </div> | |
| <div class='body'> | |
| <p>Again - these are "it works exactly as it is implemented" kind of technical details, not the user's concern. The way Raku is used builds upon "void functions" not causing any unexpected trouble, only expected side effects. If you are trying to use the return value of one, perhaps you weren't looking for "void function semantics" in the first place.</p> | |
| <p>I have never seen <code>let</code> declarations used - now, checking them, it seems to me it produces the right result for the wrong reason.<br /> | |
| Reading the docs: | |
| "Refers to a variable in an outer scope whose value will be restored if the block exits unsuccessfully, <strong>implying that the block returned a defined object</strong>." | |
| also | |
| "Restores the previous value if the block exits unsuccessfully. <strong>A successful exit means the block returned a defined value or a list</strong>."<br /> | |
| So the docs define success as "returning a defined value or a list", which is a stricter criterion than not returning <code>Nil</code> and its derivatives.</p> | |
| <blockquote> | |
| <p>In Raku the proper way to declare a "void function" is by explicitly annotate Nil as its return type. That results in the compiler optimize it forcing a sink context to its last statement (if any).</p> | |
| </blockquote> | |
| <p>It wasn't immediately clear what you mean but I think I got it eventually. By the way, this also implies that anything executed in sink context "produces Nil", and hence could be interpreted as a "silent failure". Once again: I don't know if this is true <em>technically</em>, but I'm confident it's not a useful mental framework, and the implications shouldn't show up at the user.</p> | |
| <blockquote> | |
| <p>On another side, you should not be surprised by the value returned by Foo with Nil. In Raku, any conditional statement when not executed, as a expression returns Empty:</p> | |
| </blockquote> | |
| <p>Honestly, it's not about the surprise. I rather like this behavior, even. However, it's very counter-intuitive that non-executed code produces <code>Empty</code> while no code produces <code>Nil</code>. It shows how fragile the "failed to produce value" interpretation is.</p> | |
| <p>So yes you are right, it would be nice to make the documentation cover the concepts and corner cases better - however, my complaint is that the concepts and the behavior themselves feel wrong, no matter whether they are specced or written down. To use a harsh comparison: esoteric languages can be specified and documented, that doesn't stop them being esoteric. Of course the situation isn't as bad here but nevertheless, the reason I opened the issue was to initiate discourse around the concepts and semantics, rather than to trace the implementation.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="341"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/341"><span class='number'>341</span></a> - <span class='title'>Rakudoc Delimited Block Comments</span></div> | |
| <div class='author'>[closed]<span class='author'>@finanalyst</span> opend this issue at <time datetime="2022-08-05T19:32:07Z">2022-08-05 19:32</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Rakudoc block comments do not work consistently. | |
| A <code>=begin comment</code> and <code>=end comment</code> sequence with an embedded <code>=begin code</code> / <code>=end code</code> | |
| generates a compiler error. If 'comment' is substituted for 'pod' in the above, there is no error. | |
| …</p> | |
| <p>According to the specification, a delimited block starts with <code>=begin BLOCKNAME</code> and <code>=end BLOCKNAME</code></p> | |
| <p><code>=begin comment</code> and <code>=end comment</code> sequence generates a <code>Pod::Block::Comment</code> as expected. | |
| However, it is not possible to embed another delimited block within such a comment - the compiler generates an error. | |
| By contrast, a named block, such as <code>begin pod</code> / <code>end pod</code> sequence will allow for embedded delimited blocks.</p> | |
| <p>There is no indication of multiline comments being a part of the specification. However, the current behaviour of Rakudo is inconsistent and there is no reason for treating <code>Pod::Block::Comment</code> any differently to other delimited blocks. How the multiline comment is rendered is for the renderer to decide, not the compiler.</p> | |
| <p>So, I suggest this Comment block behaviour is a compiler error. | |
| …</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5H8260"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-08-06T03:22:36Z">2022-08-06 03:22</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>If 'comment' is substituted for 'pod' in the above, there is no error.</p> | |
| </blockquote> | |
| <p>Huh?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ICBdZ"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2022-08-08T18:55:30Z">2022-08-08 18:55</time> | |
| </div> | |
| <div class='body'> | |
| <p>So lets create a file with</p> | |
| <pre><code>=begin pod | |
| something | |
| =begin code | |
| my $x='sss'; | |
| =end code | |
| =end pod | |
| </code></pre> | |
| <p>This compiles properly. If you inspect the Pod::Block for the <code>=begin pod</code>, it is a named block with name 'pod'. | |
| Now lets add a multi-line comment (I suppose I was a bit inaccurate earlier when I said 'substitute')</p> | |
| <pre><code>=begin pod | |
| =begin comment | |
| something | |
| =begin code | |
| my $x = 'sss'; | |
| =end code | |
| =end comment | |
| =end pod | |
| </code></pre> | |
| <p>This causes a compile error.</p> | |
| <pre><code>Expected "=end comment" to terminate "=begin comment"; found "=end code" instead. | |
| </code></pre> | |
| <p>Now upon inspecting a pod tree with a comment, the relevant Pod::Block is <code>Pod::Block::Comment</code></p> | |
| <p>So the behaviour of the Comment block is different to the behaviour of the Named Block.</p> | |
| <p>I would expect them to be the same.</p> | |
| <p>Hope this clarifies things</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ceZfE"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-05-17T14:11:23Z">2023-05-17 14:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>In RakuAST this now generates:</p> | |
| <pre><code class="language-raku">[Pod::Block::Named.new(name => "pod", config => {}, contents => [Pod::Block::Comment.new(config => {}, contents => ["something\n=begin code\nmy \$x = 'sss';\n=end code\n"])])] | |
| </code></pre> | |
| <p>So it appears this will be fixed automatically when using the RakuAST grammar as default.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ceZrE"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-05-17T14:11:48Z">2023-05-17 14:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think this can be closed in the meantime?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ciy-M"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-05-18T07:21:36Z">2023-05-18 07:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>if RakuAst is correct then this can be closed</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="340"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/340"><span class='number'>340</span></a> - <span class='title'>Dependency hell in Raku</span></div> | |
| <div class='author'>[open]<span class='author'>@atroxaper</span> opend this issue at <time datetime="2022-08-04T14:19:14Z">2022-08-04 14:19</time></div> | |
| </div> | |
| <div class='body'> | |
| <h2>Introduction</h2> | |
| <p>Take a look to any module in the Ecosystem, which has dependency of other module. META6.json file has a special section for specifying those dependencies. Information in the section means the module needs its dependency installed for correct work of the module. Probably, the module needs its dependency of a particular version. It will be luck if the module describes the author of a dependency. Unfortunately, there are not any guaranty except the dependency of correct version, author and api will be installed.</p> | |
| <p>If we see <code>use Module::A;</code> in the code, this means 'compiler will take a CompUnit of the Module::A (in other words compiled version of file Module/A.rakumod) the highest version from the local library'. If you think that the compiler will look to META6.json, you wrong.</p> | |
| <p>Even more, if we see <code>use CurrentModule::YourFile</code>, then the compiler will take a CompUnit of CurrentModule::YourFile the highest version from the local library. Except we write <code>use lib 'lib';</code> in code or <code>-Ilib</code> in command line.</p> | |
| <h2>Examples</h2> | |
| <p>Let's look to a few vulnerable scenarios:</p> | |
| <p>Scenario 1:</p> | |
| <ol> | |
| <li>install module A:ver<1>;</li> | |
| <li>install module B depends A:ver<1>;</li> | |
| <li>all B’s tests passed;</li> | |
| <li>install module A:ver<2>;</li> | |
| <li>module B works incorrectly.</li> | |
| </ol> | |
| <p>This is because either we see <code>use A::AModule;</code> without version in B code, or module A doesn't specify a version of its submodules in the code.</p> | |
| <p>Scenario 2:</p> | |
| <ol> | |
| <li>install module A:ver<2>;</li> | |
| <li>install module A:ver<1>;</li> | |
| <li>tests of A:ver<1> passed;</li> | |
| <li>module B works incorrectly.</li> | |
| </ol> | |
| <p>This is because module A doesn't specify a version of its submodules in the code. We are testing modules with <code>-Ilib</code> flag during installation, but run the program without it.</p> | |
| <p>Scenario 3:</p> | |
| <ol> | |
| <li>upload OpenSSL:ver<33> with malicious code to the fez;</li> | |
| <li>install cro;</li> | |
| <li>cro uses malicious code.</li> | |
| </ol> | |
| <p>This is because cro authors did not specify the author of OpenSSL in the META6.json.</p> | |
| <p>Scenario 4:</p> | |
| <ol> | |
| <li>upload any module with version 33 with malicious submodule OpenSSL::SSL (file OpenSSL/SSL.rakumod) to the fez;</li> | |
| <li>somehow install the module to target machine;</li> | |
| <li>cro on the target machine uses malicious code. | |
| This is because cro authors did specify a version and author of OpenSSL in the META6.json, but authors of OpenSSL did not specify a version and author of its submodules in the code.</li> | |
| </ol> | |
| <h2>We are not alone</h2> | |
| <p>Probably we can decide that in some universe the malicious code is unimportant (with what I as a specialist of information security disagree). Anyway general dependency hell scenarios are important part of programing language. For instance, as I can see in the <a href="http://perl.scaffidi.net/home/cpanhell">article</a>, in Perl world they are solving the problem through local CPAN installations and fixing foreign modules on its own. In JavaScript world, they <a href="https://npm.github.io/how-npm-works-docs/npm3/how-npm3-works.html">solve the problem in npm</a> through the coping to module code the code of its dependencies. In Python world they invent and build a huge system around virtual environment, but it <a href="https://npm.github.io/how-npm-works-docs/npm3/how-npm3-works.html">does not solve the problem completely</a>. In Java world they specify which dependencies of dependencies <a href="https://stackoverflow.com/a/39252671">include or exclude</a> from the classpath by hand or even <a href="https://stackoverflow.com/a/13620420">rename packages</a> of dependencies.</p> | |
| <p>What we have in Raku? The great system with :ver<>:auth<>:api<> which absolutely doesn't help to avoid the problem. For now to avoid the problem we need to obligate to write at least auth and ver each programmer (module author either module consumer) in each .rakumod file in each use statement. A programmer could make yourself to write such boilerplate (kudos lizmat). Unfortunately they couldn't obligate to do so the all community. Besides, such boilerplate looks ugly. It is dangerous <a href="https://en.m.wikipedia.org/wiki/Don%27t_repeat_yourself">repetition</a>.</p> | |
| <h2>Why it is important?</h2> | |
| <p>There are a few principles, which Raku adhere to:</p> | |
| <h3>Making Easy Things Easy and Hard Things Possible</h3> | |
| <p>In theory, we can avoid a dependency hell even in current state of the language, but is it so hard thing for <a href="https://thenewstack.io/larry-walls-quest-100-year-programming-language/">language for the next hundred years</a>? Can the language make that thing easy?</p> | |
| <h3>Try to minimize things that Less Than Awesome</h3> | |
| <p>Let's imagine a page in a documentation about dependency hell avoiding. There will be written that you have to write a boilerplate in each use statement, but even that doesn't help you. Or they need to stick to Perl strategy with local servers and fixing foreign modules. I think it will be much less than awesome.</p> | |
| <h3>Do What I Mean:</h3> | |
| <p>I cannot know what mean programmers who write versions in its META6.json but not in use statements. Probably, programmers do not even know the dependency hell problem exists. Let's analyze some objective data. There were 1447 modules in the fez in the past week. There are 3k of dependencies in META6.json files and 36k of use statements at all. If we exclude lizmat from the statistics, we have: 22.2% of dependencies and 0.12% of use statements have a version, for auth it is 5.4% and 0.2% respectively, for api - 0.6% and 0.2%. In other words, almost nobody specifies anything in use statement even if specifies in META6.json. Programmers mean the dependency hell problem does not exist.</p> | |
| <p>It is a huge problem, which we do not observe only because of small the Ecosystem. Once the Ecosystem becomes large enough, the problem will blow up.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5H18q1"> | |
| <div class='header'> | |
| <span class='author'>@atroxaper</span> commented at <time datetime="2022-08-04T14:20:05Z">2022-08-04 14:20</time> | |
| </div> | |
| <div class='body'> | |
| <h2>What I propose to solve the problem:</h2> | |
| <p>In case of CURI (CompUnit::Repository::Installation):</p> | |
| <ul> | |
| <li>obligate to specify a version and auth in depends section of META6.json;</li> | |
| <li>if author of a module omits a version and author in use statement, then use what specified in META6.json;</li> | |
| <li>if use statement specify either version or author, then use it;</li> | |
| <li>if use statement specify whatever (*) somewhere in :ver:auth:api, then use any highest version of module (as now works).</li> | |
| </ul> | |
| <p>In case of CUFS (CompUnit::Repository::FileSystem <code>use lib 'lib'</code>) a programmer takes responsibility for yourself for what they write in the code. If lib/../META6.json exists (<code>-I.</code>) then use its dependency section or the highest version.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H2M3g"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-08-04T15:11:14Z">2022-08-04 15:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>AFAIK it's difficult to get the "look in META6.json" solution to be performant. More complex solutions like somehow compiling the META6.json might be possible.</p> | |
| <p>Maybe an intermediate step (to buy us some time) could be to have a Raku program integrated into Fez that substitutes all use statements in <code>lib/</code>, <code>bin/</code>, <code>t/</code> and <code>xt/</code> with their META6.json equivalents before upload. (Or have a separate tool, which the user has to call manually and have Fez only verify that the versions in META6.json and the source files match.)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H2Pay"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-08-04T15:19:45Z">2022-08-04 15:19</time> | |
| </div> | |
| <div class='body'> | |
| <p>FWIW, I have been toying with the following idea:</p> | |
| <p>If you do <code>use pre-production</code> in your code, it will <strong>warn</strong> about unpinned versions in <code>use</code> statements (<code>use Foo</code>). We can discuss what we consider unpinned, but any <code>use</code> statement without associated <code>:auth<...></code> I would consider unpinned. It will also refuse to compile if it finds any <code>use lib</code> active (aka, any Repo of <code>CUR::FileSystem</code> type).</p> | |
| <p>If you do <code>use production</code> in your code, your code will fail to compile if there is any unpinned <code>use</code> statement. As well as all the <code>use pre-production</code> features.</p> | |
| <p>I think this will allow people to indicate the strictness they want.</p> | |
| <p>Note that it is possible to load a module such as <code>pre-production</code> as a command-line parameter, so you would not need to change any actual code to force this check.</p> | |
| <p>Now, time to find the hooks and the tuits to do this... :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H2YSm"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-08-04T15:49:22Z">2022-08-04 15:49</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>AFAIK it's difficult to get the "look in META6.json" solution to be | |
| performant. More complex solutions like somehow compiling the META6.json | |
| might be possible.</p> | |
| </blockquote> | |
| <p>Actually I think this might be ok. We'd only have to load the META6.json file | |
| of the distribution the module we're currently precompiling belongs to. During | |
| module installation, we do that already anyway. In the case we're re-compiling | |
| an installed module, I still think the cost of parsing that JSON would be | |
| drowned by the cost of the actual compilation.</p> | |
| <p>I think that would be sensible. Same as defaulting to the current dist when | |
| looking for dependencies that are contained in the same dist as the module | |
| we're compiling.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H2iS3"> | |
| <div class='header'> | |
| <span class='author'>@Kaiepi</span> commented at <time datetime="2022-08-04T16:22:18Z">2022-08-04 16:22</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think https://www.openbsd.org/faq/ports/guide.html might be a worthwhile reference for considerations pertaining to packaging security.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5H2oDl"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-08-04T16:35:47Z">2022-08-04 16:35</time> | |
| </div> | |
| <div class='body'> | |
| <p>@niner Yeah, that's what I also had in mind, until I got distracted by <code>App::Rak</code> and the conference :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IDkxo"> | |
| <div class='header'> | |
| <span class='author'>@atroxaper</span> commented at <time datetime="2022-08-09T04:25:27Z">2022-08-09 04:25</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Maybe an intermediate step (to buy us some time) could be to have a Raku program integrated into Fez that substitutes...</p> | |
| </blockquote> | |
| <p>If we can solve the problem through simple substitution of use statements in the sources (which is a hack), then we can solve the problem by substitution of use statements in a compile time (which is reliable and does not require any action from the user).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ILdVd"> | |
| <div class='header'> | |
| <span class='author'>@atroxaper</span> commented at <time datetime="2022-08-10T16:31:09Z">2022-08-10 16:31</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I think this will allow people to indicate the strictness they want.</p> | |
| </blockquote> | |
| <p>@lizmat It is interesting idea. I see two disadvantages:</p> | |
| <ol> | |
| <li>A user will need to write a boilerplate :auth<>:ver<>;</li> | |
| <li>This solution doesn't solve a transitive situation. The situation when a production module want to use dependency which uses unpinned use statements.</li> | |
| </ol> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IMuy4"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-10T21:29:52Z">2022-08-10 21:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't currently remember all the details of module loading sequence, but there should be no hacks necessary.</p> | |
| <p>First of all, META6 is available for the compiler or can be available. All we need is to parse it and keep the dependency info around as defaults for <code>CU::DependencySpecification</code>. This way we can use default auth/ver/api where not explicitly specified by user.</p> | |
| <p>When the module is resolved with all the user provided and default values in mind, it is identified by its hash value. So, loading pre-compiled code should not be a problem either.</p> | |
| <p>What am I missing here?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IM5Ub"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-08-10T22:17:11Z">2022-08-10 22:17</time> | |
| </div> | |
| <div class='body'> | |
| <p>Well, to me it was not just a SMOP :-(</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5INY1g"> | |
| <div class='header'> | |
| <span class='author'>@atroxaper</span> commented at <time datetime="2022-08-11T01:42:18Z">2022-08-11 01:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>I say it is a hack about substitution of use statements by some tool on the source code level.</p> | |
| <p>@vrurg. As I know, yes, you are right. All comp unit dependencies in CURI specified as hashes at the first lines of the precompiled file. But I do not know how precompiled use statement looks like - Raku allows us to use a different versions of module in different scopes. Probably, it will be difficult part.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5IVWw5"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-08-12T22:14:21Z">2022-08-12 22:14</time> | |
| </div> | |
| <div class='body'> | |
| <p>There is a thing which simplifies the task a lot. Basically, it makes it half-resolved. Each module final name in a repository is defined by distribution ID. The latter is computed as a hash over module name, version, api, and auth. All together. We just need to make sure that this exact name gets loaded. To do so the compiler needs access to META6.json data.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Im-J6"> | |
| <div class='header'> | |
| <span class='author'>@abraxxa</span> commented at <time datetime="2022-08-17T15:36:56Z">2022-08-17 15:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>I like that idea very much! 👍🏻 | |
| As raku compiles the source code to an intermediate format and stores those files, can't the infos from META6.json be added to all use statements in the intermediate files at that step?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Jty61"> | |
| <div class='header'> | |
| <span class='author'>@Skarsnik</span> commented at <time datetime="2022-09-05T09:13:26Z">2022-09-05 09:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't think there is a good solution for most use cases.</p> | |
| <p>I can take my Gumbo module for example. | |
| Its raku dependencies are XML. | |
| Should I pin a version/author? This look annoying since it means I will have to test every new version to see if that still works and update Gumbo just to change the pinned version. Also, it's better if the XML module is allowed to be updated so Gumbo can be faster or safer because the XML update fixed/improved stuff.</p> | |
| <p>Leaving unpinned obviously leads to the issue aborded by this issue.</p> | |
| <p>I think also we should look at the 2 main environments: | |
| -The whole neatly packaged env with every version knows and specified somewhere. It can be a docker env or a simple application where you provide all the deps. | |
| -A normal linux distribution: where you don't control the possible version of your dependencies.</p> | |
| <p>Both offer different challenges : | |
| For example</p> | |
| <ul> | |
| <li>Packed app : You can miss a critical security update</li> | |
| <li>Distrib : It's harder to control that your app will work with all deps updates</li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5JuBnw"> | |
| <div class='header'> | |
| <span class='author'>@atroxaper</span> commented at <time datetime="2022-09-05T10:07:53Z">2022-09-05 10:07</time> | |
| </div> | |
| <div class='body'> | |
| <p>@Skarsnik we have auth, ver and api. You case require dependency like XML:auth< zef:raku-community-modules >:ver<0.+>:api<1>.</p> | |
| <p>There are two problems: Firstly, XML module do not specify its api number. I think, self api number should be obligatory in META6.json. Secondly, 0.+ means any version more then 0. It is 0.3.4 and 15.5.2. There is no possibility to say ‘version more than 0, but less than 1’. But probably, we can use range here. Some thing like :ver<v0.3.2..^v1>.</p> | |
| <p>I think, such solution could satisfy you: you have tested you app on XML:ver<0.3.2>, and you expect, that XML developers will increase api number in case of api changes. Olso, we are protected from using future version 1 for sure.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5JuGue"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-09-05T10:29:09Z">2022-09-05 10:29</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>There is no | |
| possibility to say ‘version more than 0, but less than 1’. But probably, we | |
| can use range here. Some thing like :ver<v0.3.2..^v1>.</p> | |
| </blockquote> | |
| <p>Proper syntax for that is :ver(v0.3.2..^v1). It's just Raku code.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5JuJSU"> | |
| <div class='header'> | |
| <span class='author'>@Skarsnik</span> commented at <time datetime="2022-09-05T10:40:48Z">2022-09-05 10:40</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>@Skarsnik we have auth, ver and api. You case require dependency like XML:auth< zef:raku-community-modules >:ver<0.+>:api<1>.</p> | |
| <p>There are two problems: Firstly, XML module do not specify its api number. I think, self api number should be obligatory in META6.json. Secondly, 0.+ means any version more then 0. It is 0.3.4 and 15.5.2. There is no possibility to say ‘version more than 0, but less than 1’. But probably, we can use range here. Some thing like :ver<v0.3.2..^v1>.</p> | |
| <p>I think, such solution could satisfy you: you have tested you app on XML:ver<0.3.2>, and you expect, that XML developers will increase api number in case of api changes. Olso, we are protected from using future version 1 for sure.</p> | |
| </blockquote> | |
| <p>I think what could be first started is imposing a API number for Modules (but not apps). This could be a check in zef or when the module 'database' is generated. This way it's easier for other people to be able to use API numbers on the Meta/use statement. So that will solve my Gumbo issue where I can say use XML:api<1></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Ju9j4"> | |
| <div class='header'> | |
| <span class='author'>@atroxaper</span> commented at <time datetime="2022-09-05T13:39:18Z">2022-09-05 13:39</time> | |
| </div> | |
| <div class='body'> | |
| <p>@Skarsnik It will be only a half way solution - it will solve your problem by forcing you to write a boilerplate.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Jv-pG"> | |
| <div class='header'> | |
| <span class='author'>@Kaiepi</span> commented at <time datetime="2022-09-05T17:04:44Z">2022-09-05 17:04</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I think, self api number should be obligatory in META6.json.</p> | |
| </blockquote> | |
| <p>Yes, please; even if just a fez-ism, I have a bad habit of forgetting this, despite <em>always</em> wanting one, because there's no warning or anything if omitted.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5JwBHS"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-09-05T17:17:07Z">2022-09-05 17:17</time> | |
| </div> | |
| <div class='body'> | |
| <p>+1 one it being enforced by fez</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5J2cYx"> | |
| <div class='header'> | |
| <span class='author'>@nxadm</span> commented at <time datetime="2022-09-07T07:23:48Z">2022-09-07 07:23</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>FWIW, I have been toying with the following idea:</p> | |
| <p>If you do <code>use pre-production</code> in your code, it will <strong>warn</strong> about unpinned versions in <code>use</code> statements (<code>use Foo</code>). We can discuss what we consider unpinned, but any <code>use</code> statement without associated <code>:auth<...></code> I would consider unpinned. It will also refuse to compile if it finds any <code>use lib</code> active (aka, any Repo of <code>CUR::FileSystem</code> type).</p> | |
| <p>If you do <code>use production</code> in your code, your code will fail to compile if there is any unpinned <code>use</code> statement. As well as all the <code>use pre-production</code> features.</p> | |
| <p>I think this will allow people to indicate the strictness they want.</p> | |
| <p>Note that it is possible to load a module such as <code>pre-production</code> as a command-line parameter, so you would not need to change any actual code to force this check.</p> | |
| <p>Now, time to find the hooks and the tuits to do this... :-)</p> | |
| </blockquote> | |
| <p>Interesting, but to be workable I would have $future-raku-version default to the "production" mode and add a cli parameter for pre-prod. Being strict about dependencies is a feature.</p> | |
| <p>This may be interesting for deciding how to deal with library updates: https://go.dev/ref/mod#minimal-version-selection. Luckily, Raku has a more flexibility than Go on this matter, but the versioning should be set centrally per library + once for the project and not on a zillion of source files.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5J2cv5"> | |
| <div class='header'> | |
| <span class='author'>@nxadm</span> commented at <time datetime="2022-09-07T07:25:18Z">2022-09-07 07:25</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>+1 one it being enforced by fez</p> | |
| </blockquote> | |
| <p>Core functionality should not be handled by external tools. Or fez or fez-like should be pulled into core (and probably handled by a raku sub command).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5J2gL4"> | |
| <div class='header'> | |
| <span class='author'>@atroxaper</span> commented at <time datetime="2022-09-07T07:39:37Z">2022-09-07 07:39</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Core functionality should not be handled by external tools.</p> | |
| </blockquote> | |
| <p>Ecosystem is not a core functionality. Core functionality is how and where Raku looking PrecompUnits. Community could negotiate that Fez is official Ecosystem and fully supports Raku algorithms. If we use Fez/Fez then all going to be fine.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5J2iDt"> | |
| <div class='header'> | |
| <span class='author'>@nxadm</span> commented at <time datetime="2022-09-07T07:46:55Z">2022-09-07 07:46</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Ecosystem is not a core functionality.</p> | |
| </blockquote> | |
| <p>The rules (interfaces) and, in this case, their enforcement is a core functionality in my eyes. The contents of the ecosystem is not, of course.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5KcDXw"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-09-16T03:08:10Z">2022-09-16 03:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>rakudo/rakudo#5060</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="339"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/339"><span class='number'>339</span></a> - <span class='title'>Should the `handles` trait delegate by name or by code reference?</span></div> | |
| <div class='author'>[open]<span class='author'>@vrurg</span> opend this issue at <time datetime="2022-07-28T00:03:35Z">2022-07-28 00:03</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>When <code>handles</code> delegates via a method call there are two approaches:</p> | |
| <ul> | |
| <li>the original one we used for years was by delegating via method name: `self."$meth_name"()."$delegation_name"()</li> | |
| <li>the one I introduced with my fix for roles uses <code>&method_code_object(self)."$delegation_name"()</code></li> | |
| </ul> | |
| <p>There are a number of problems about the former approach. First, it makes it possible for a child to override the handling method and break the delegation by returning an object of different type:</p> | |
| <pre><code class="language-raku">class C1 { | |
| method dt handles<year month day> { DateTime.now } | |
| } | |
| class C2 is C1 { | |
| method dt { "something different" } | |
| } | |
| say C2.new.year; # 2022 on the master, dies on 2022.06 | |
| </code></pre> | |
| <p>Second, the new approach allows for anonymous methods to do delegation too:</p> | |
| <pre><code class="language-raku">class Foo { } | |
| Foo.^add_method("dt", anon method () handles<year> { DateTime.now }); | |
| say Foo.year; # Dies on 2022.06 | |
| </code></pre> | |
| <p>Third, <code>multi</code>-dependent delegation works the way it is expected to:</p> | |
| <pre><code class="language-raku">class C { | |
| multi method foo(::?CLASS:U:) handles<year> { DateTime.now } | |
| multi method foo(::?CLASS:D:) handles<Int> { "42" } | |
| } | |
| # Weird "No such method 'Int' for invocant of type 'DateTime'" on 2022.06, | |
| # and more correct "Invocant of method 'foo' must be an object instance of type 'C', not a type object of type 'C'. | |
| # Did you forget a '.new'?" on the master | |
| say C.Int; | |
| </code></pre> | |
| <p>Both approaches pass specs.</p> | |
| <p>The only problem is the code object approach breaks <code>CSS</code> and <code>LibXML</code> due to some of their child classes overriding a method with an attribute of the same name.</p> | |
| <p>Related is rakudo/rakudo#5006</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5HYe7u"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-07-28T03:05:41Z">2022-07-28 03:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>I tried to make the code object behavior <code>6.e</code> feature, while preserving the name-based one in <code>6.c/d</code>. Seems to be working nicely, but it is too late today to release it.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="338"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/338"><span class='number'>338</span></a> - <span class='title'>Include line numbers in Pod::Blocks</span></div> | |
| <div class='author'>[closed]<span class='author'>@finanalyst</span> opend this issue at <time datetime="2022-07-26T17:42:36Z">2022-07-26 17:42</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Pod::Blocks are objects that have attributes such as 'contents' and 'meta'. By having another attribute 'line' containing the line number within the program where the block starts, eg, where the <code>=head</code> marker appears, it will be possible to create tools to find errors more easily. | |
| …</p> | |
| <p>When Pod::Blocks are generated the compiler contains state information about where each Block starts. This can be found when a program is running eg <code>say "At $?LINE"</code>. Incorporating this as an attribute of a Pod::Block would make it easier to have tools when there are long Rakudoc documents. | |
| …</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5ceqUS"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2023-05-17T14:48:23Z">2023-05-17 14:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>In RakuAST, pod blocks will appear as <code>RakuAST::Doc::Block</code> objects in <code>RakuAST::StatementList</code>s in the RakuAST tree. This brings a lot of opportunity for introspection.</p> | |
| <ol> | |
| <li>the "origins" framework will allow you to find out the origin of any <code>RakuAST:: object</code>, such as filename and line number.</li> | |
| <li>this gives you the option to read that file. However, you could also call <code>.DEPARSE</code> on the <code>RakuAST</code> object in question to get a clean source representation of that object (which may or may not be preferable)</li> | |
| <li>when rendering rakudoc from a RakuAST tree, you could also e.g. extract the <code>RakuAST::Signature</code> object, and deparse that to add to the rakudoc.</li> | |
| <li>the contents of <code>RakuAST::Doc::Block</code> are as close as possible to the original source (including any additional whitespace), with two exceptions:</li> | |
| <li>implicit code block parsing inside <code>=begin pod</code> / <code>=end pod</code>. These are already parsed as if they were part of an explicit <code>=begin code</code> / <code>=end code</code> block.</li> | |
| <li>table cell parsing parsed into <code>RakuAST::Doc::Row</code> objects, in which each cell still has any additional whitespace, which could e.g. as an implicit way to indicate right justification or centering.</li> | |
| </ol> | |
| <p>and probably a lot more I couldn't think of now :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5cjLQ4"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2023-05-18T08:34:11Z">2023-05-18 08:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>The suggestion was made based on the $=pod representation. But the RakuAST representation offers much more information</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="337"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/337"><span class='number'>337</span></a> - <span class='title'>Function return types should also tell about the used assignment/container</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-07-21T23:23:06Z">2022-07-21 23:23</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Hello, | |
| this started bugging me lately... Instead of references, Raku has containers and the distinction between assignment and binding. This allows us to do assignments on data returned from a function and other powerful stuff. The problem is, it's not really recorded how certain functions return data - not even for built-in functions.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>To illustrate the problem, let me show you two different built-in functions (methods, in this case).</p> | |
| <pre><code>my @asd = 1, 4, 234, 23, 1, 88, 2, 49; | |
| @asd.batch(2)[0;0] =:= @asd[0]; # True | |
| </code></pre> | |
| <p>It seems that batch uses binding on the items of a list. It could be further tested that this is the case, it really seems to me that it does. | |
| On the other hand:</p> | |
| <pre><code>@asd[2] == @asd.categorize(* % 3){0}[0]; #True | |
| @asd[2] =:= @asd.categorize(* % 3){0}[0]; #False | |
| @asd.categorize(* % 3){0}[0].VAR.WHAT; #(Scalar) | |
| </code></pre> | |
| <p>We can conclude that categorize copies - one can assign values to items returned (they have a Scalar container) but they won't affect the original elements.</p> | |
| <p>The thing is... as much as I think this is important information, I don't know how this should be presented. Maybe there is no better solution than to describe it textually. | |
| I can think of 3 possible cases regarding the data: a) a container is bound to input data b) a container is freshly created c) there is no container returned, only a crude value.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5HGkf7"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-07-22T20:16:32Z">2022-07-22 20:16</time> | |
| </div> | |
| <div class='body'> | |
| <p>FWIW, whether binding or assignment is used in built-in functions, has usually been a case of historical development, and changing insights / experience.</p> | |
| <p>I think it would make sense to look at them (again) and decide which behaviour should be followed (and documented).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HRMEL"> | |
| <div class='header'> | |
| <span class='author'>@Kaiepi</span> commented at <time datetime="2022-07-26T16:11:51Z">2022-07-26 16:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>Return types have a unique grammar, despite being considered an ordinary parameter in more pure FP-ish languages. Would it be possible for them to become a parameter in their own right to check what sort of container the return value has and predeclare output variables? They could differ in the sense that a redeclaration is an assertion of equality to said argument (outer/dynamic?) + optional dogpile of checks.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HRWJF"> | |
| <div class='header'> | |
| <span class='author'>@Kaiepi</span> commented at <time datetime="2022-07-26T16:48:45Z">2022-07-26 16:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>If we can afford to be wishy-washy about symbols in the signature, maybe we'd get:</p> | |
| <pre><code class="language-raku">role Monad[::A] { | |
| method bind(&f:(A --> ::?ROLE ::B) --> B) { ... } | |
| method then(::?ROLE ::M \m --> M) { self.bind: -> \ { m } } | |
| method pure(A --> ::?CLASS) { ... } | |
| } | |
| </code></pre> | |
| <p>In which a type capture marks an input for instantiation.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HRqhz"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-07-26T18:05:57Z">2022-07-26 18:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>Hi @Kaiepi</p> | |
| <p>Is <code>self.bind: -> \ { m }</code> missing something after the <code>\</code> or is it pseudo-code? (Is that what you meant by "wishy-washy"?)</p> | |
| <p>Have you looked at what Larry said about return types in both the design docs and on IRC?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HR51A"> | |
| <div class='header'> | |
| <span class='author'>@Kaiepi</span> commented at <time datetime="2022-07-26T19:09:31Z">2022-07-26 19:09</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Is <code>self.bind: -> \ { m }</code> missing something after the <code>\</code> or is it pseudo-code? (Is that what you meant by "wishy-washy"?)</p> | |
| </blockquote> | |
| <p><code>\</code> is an anonymous term. I mean wishy-washy by <code>B</code> being captured within the context of the subsignature, but being used outside of it anyway. I figure if checks can be performed on a value on the way in, there should be a way to do so on the way out as well, particularly given <code>new-disp</code> work.</p> | |
| <blockquote> | |
| <p>Have you looked at what Larry said about return types in both the design docs and on IRC?</p> | |
| </blockquote> | |
| <p>I don't find anything specific about how the <code>'return type'</code> should behave on IRC or in the design docs. It is referred to as such in the design docs, and is stated to be kept <a href="https://design.raku.org/S06.html#Closure_parameters">separately from the parameter list within a Code</a>, which is <code>Signature</code>'d. This could translate to a list of "in" parameters and an "out" parameter. There is a <a href="https://design.raku.org/S06.html#Anonymous_subroutines">prefix form</a> of the return type given an <code>anon</code> which, if it works given any scope declarator, could help avoid the "wishy-washy" declaration ordering I was talking about:</p> | |
| <pre><code class="language-raku">#`[has is implied ordinarily.] | |
| has ::?ROLE ::B method bind(&f:(A --> B)) { ... } | |
| </code></pre> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="336"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/336"><span class='number'>336</span></a> - <span class='title'>Alternate name for MONKEY pragmas</span></div> | |
| <div class='author'>[open]<span class='author'>@wimvanderbauwhede</span> opend this issue at <time datetime="2022-07-19T11:30:36Z">2022-07-19 11:30</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>I propose to have an alias for the <code>MONKEY</code> pragmas used for unsafe features.</p> | |
| <p>The reason is that the term <code>MONKEY</code> is not descriptive. It relies on knowledge of idiomatic English to understand its purpose ("monkey around", "monkey see …"). The proposed term <code>UNSAFE-FEATURE</code> is self-describing: the action allowed by it is potentially unsafe. It is also in line with other languages: Rust (<code>unsafe</code> keyword), Go (<code>unsafe</code> package), Haskell (<code>unsafePerformIO</code>).</p> | |
| <p>I propose to the following aliases:</p> | |
| <pre><code>use UNSAFE-FEATURES; # all of them | |
| use UNSAFE-FEATURE-TYPING; | |
| use UNSAFE-FEATURE-EVAL; | |
| use UNSAFE-FEATURE-INTERNALS; # I prefer "internals" over "guts" as it is less visceral | |
| </code></pre> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5HGu9c"> | |
| <div class='header'> | |
| <span class='author'>@habere-et-dispertire</span> commented at <time datetime="2022-07-22T21:29:46Z">2022-07-22 21:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>I support this pragmatic suggestion which also avoids a term whose surface representation can be construed as speciesist.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HH-gR"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-07-24T08:39:34Z">2022-07-24 08:39</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think the question of use of terms is a broader topic in Raku and I think it would be wise to find a general answer. | |
| Raku (and Perl as well) has a long tradition to use non-technical and sometimes slang terms to describe things. Some examples are: '"Texas operators", "slurp", "spurt", "bless", "punning".</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HH-sh"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-07-24T08:44:37Z">2022-07-24 08:44</time> | |
| </div> | |
| <div class='body'> | |
| <p>May I add "Function 'x' needs parens to avoid gobbling block"?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HL95Q"> | |
| <div class='header'> | |
| <span class='author'>@gfldex</span> commented at <time datetime="2022-07-25T16:28:39Z">2022-07-25 16:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>None of the MONKEYs are inherently unsafe. They may have consequences the user has to take into account tho. The term MONKEY was choosen deliberately because monkey-typing is a well established term in dynamic languages.</p> | |
| <p>Ideology (and taste) have changed back and forth over the decades. If we want to have a 100-year language, we will have to accept that phrases go out of fashion and the meaning of words changes. Do we want to update CORE every 30 years to keep in sync with natural language? And what flavour of English do we base that on?</p> | |
| <p>I'm from eastern germany and was forced by my colonial masters to learn Russian. My Ideology-Warning-Light is blinking like mad with this proposal.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HMWkY"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-07-25T17:59:26Z">2022-07-25 17:59</time> | |
| </div> | |
| <div class='body'> | |
| <p>@patrickbkr "Texas operators" was removed just before the release in 2015, if I remember correctly. I don't believe "punning" exists in Perl. "spurt" was chosen after a long deliberation. "slurp" and "bless" were indeed inherited from Perl. Personally, I wouldn't mind changing "bless" to "instantiate".</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HMrUu"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-07-25T19:13:19Z">2022-07-25 19:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>@lizmat I think there are many more examples. (chomp, chop, die, Mu, Cool, KnowHOW, Dateish, Stringy, ...). My point is that this is not a question of a limited set of offending names we may or may not want to rename, but a question of culture we inherited and cultivate. Punning is an essential part of the fun the devs have on IRC. When choosing between two equally descriptive words to describe a thing, the Raku devs will usually choose the punnier one. Is this for some of us a part of -Ofun? Do we want to continue cultivating that culture or do we want move on? Moving on could mean setting the bar higher for understandability / obviousness and has the potential to lower the bar for non-native speakers.</p> | |
| <p>I believe there isn't an easy answer. I think in this case it really is tradeoffs. We can't have our punny-funny-Ofun world and at the same time be serious and scientific (i.e.no fun allowed). I think this relates to the discussions that come up from time to time around Camelia and the non-professional looks of it some people dislike.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HMs4i"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-07-25T19:19:13Z">2022-07-25 19:19</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Do we want to continue cultivating that culture or do we want move on? Moving on could mean setting the bar higher for understandability / obviousness and has the potential to lower the bar for non-native speakers.</p> | |
| </blockquote> | |
| <p>Ideally, I think we would want to do both. Now, in the case of <code>bless</code>, in Perl it means adding extra information to an existing data structure. In Raku, it means to instantiate an object of a given class. These are subtly different things in my opinion, so renaming <code>bless</code> to <code>instantiate</code> I think would make sense from understandability / obviousness point of view.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HPJsG"> | |
| <div class='header'> | |
| <span class='author'>@thoughtstream</span> commented at <time datetime="2022-07-26T08:13:03Z">2022-07-26 08:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don’t wish to comment on the <em>principle</em> of aliasing these names, | |
| just on their linguistic affordances.</p> | |
| <p>The proposal is:</p> | |
| <blockquote> | |
| <p><code> use UNSAFE-FEATURES;</code> | |
| <code> use UNSAFE-FEATURE-TYPING;</code> | |
| <code> use UNSAFE-FEATURE-EVAL;</code> | |
| <code> use UNSAFE-FEATURE-INTERNALS;</code></p> | |
| </blockquote> | |
| <p>I’d suggest that having both <code>...FEATURES</code> and <code>...FEATURE...</code> | |
| is going to lead to (trivial but persistent) aggravation | |
| when people inevitably use the wrong one.</p> | |
| <p>If this proposal is adopted, I’d suggest:</p> | |
| <pre><code class="language-raku"> use UNSAFE-FEATURES; | |
| use UNSAFE-FEATURES-TYPING; | |
| use UNSAFE-FEATURES-EVAL; | |
| use UNSAFE-FEATURES-INTERNALS; | |
| </code></pre> | |
| <p>...or maybe even make the feature selectors into arguments:</p> | |
| <pre><code class="language-raku"> use UNSAFE-FEATURES :ALL; | |
| use UNSAFE-FEATURES :TYPING; | |
| use UNSAFE-FEATURES :EVAL; | |
| use UNSAFE-FEATURES :INTERNALS; | |
| </code></pre> | |
| <p>...so that one can select multiple unsafe features in a single call:</p> | |
| <pre><code class="language-raku"> use UNSAFE-FEATURES :TYPING, :INTERNALS; | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HPV2W"> | |
| <div class='header'> | |
| <span class='author'>@wimvanderbauwhede</span> commented at <time datetime="2022-07-26T08:58:51Z">2022-07-26 08:58</time> | |
| </div> | |
| <div class='body'> | |
| <p>I like that proposal a lot:</p> | |
| <pre><code class="language-raku"> use UNSAFE-FEATURES :TYPING, :INTERNALS; # or :ALL | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HPewN"> | |
| <div class='header'> | |
| <span class='author'>@bbkr</span> commented at <time datetime="2022-07-26T09:26:24Z">2022-07-26 09:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>Linguistic stunts were the the thing that caught my attention waaaaaaaaay back when I was learning Perl. And I like those blesses, chomps, "manipulexity and whipuptitude", Cools, sinks...</p> | |
| <ul> | |
| <li>They give Perl / Raku distinct vibe.</li> | |
| <li>They act like mnemonic techniques needed in such complex language. For me "monkey typing" is far easier to remember than "unsafe features" despite the fact that I'm not native English speaker.</li> | |
| </ul> | |
| <p>I'm mildly against change. Creating formal/informal aliases may bring performance penalty in some areas and make learning Raku more difficult because aliases will bloat documentation and introduce even more coding standards in ecosystem.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HRiE3"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2022-07-26T17:34:18Z">2022-07-26 17:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>Humour is a good thing: it helps memory and it gives a subject some emotion. | |
| Puns are inherently linguistic and so seem opaque to a person for whom English is not a first language. | |
| I do like Monkey-typing because of the allusion to the three wise monkeys who 'See no evil', 'hear no evil', 'speak no evil'. The reference is from <a href="https://en.wikipedia.org/wiki/Three_wise_monkeys">Japanese culture</a> originally. There is also an emoji https://emojipedia.org/see-no-evil-monkey/</p> | |
| <p>So 'Monkey-See-No-Eval' is funny, because Eval is evil.</p> | |
| <p>"UNSAFE-FEATURES" ? It might be more 'descriptive' in some dry super-sensible way. But the impact of EVAL being Evil is just too good to lose.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5HZdFP"> | |
| <div class='header'> | |
| <span class='author'>@wimvanderbauwhede</span> commented at <time datetime="2022-07-28T08:51:45Z">2022-07-28 08:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>@finanalyst I am aware of the cultural origins. I understand the Japanese pun 見ざる・見猿 which is of course lost on non-Japanese speakers. I also know about the problematic emoji. | |
| The Confucian origin of the phrase is about sin, not evil. What Confucius' teaching says is that you should not commit sins because you observe others commiting sins. Which is a long way from saying that eval() is an unsafe operation. | |
| And I am not proposing to remove anything, just to have an alias.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Hcss2"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2022-07-28T22:56:44Z">2022-07-28 22:56</time> | |
| </div> | |
| <div class='body'> | |
| <p>@wimvanderbauwhede It's not the cultural origins that matter, but humour. | |
| The humour may not be apparent to everyone, but its not like 'MONKEY' is going to be misinterpreted. Anyone who comes across the term, which is clearly explained in the documentation, is going to remember it, whether it offends their sensibilities or tickles their whimsy. And surely is not the remembering bit a 'good' thing?</p> | |
| <p>I wonder whether you have come across the Wombles of Wimbledon Common in the Tests documentation. Even in the UK, the cultural reference is barely understood now. But all the cultural references in the Tests page make it one of my favourite pieces of documentation. It could have been written in a much drier and precise way. I don't think it would have been better.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QE5ID"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-08T22:31:19Z">2022-12-08 22:31</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>May I add "Function 'x' needs parens to avoid gobbling block"?</p> | |
| </blockquote> | |
| <p>Oh, and of course "dwimmy end of hyper operators", but also "spesh", arguably.</p> | |
| <p>@patrickbkr opened up a broader topic/narrative. I usually wouldn't talk about it because at the end of the day, it's not a big deal to use <em>any consistent</em> terminology you are given. (It's a whole different problem that even terms like "list", "array" and especially "container" are often thrown around without proper justification or even definition...)</p> | |
| <p>If one needs to take a stance on Raku's terminology, well... I think it could hardly get any worse, really. Perhaps if it even was offensive... Vague, arbitrary, insider joke names all around. Some "good examples" were already noted, and the MONKEY stuff isn't even remotely the worst in my opinion... Dateish, KnowHOW (this is a zero out of ten), HOW-WHAT-WHY in general but also "dwimmy" - good luck looking them up or grasping what they mean.</p> | |
| <p>I think they are problematic for two reasons:</p> | |
| <ol> | |
| <li>They are severely impractical. Giving something a name that is neither descriptive, nor properly searchable doesn't seem to be justified by the amount of fun they give to a rather closed set of people. Really, it's not fun at all to try to figure out how Dateish is not Date, what on earth dwimmy tries to mean or what does KnowHOW know how to do. Then go back, retry, and again find they don't make much more sense than zodiac signs.</li> | |
| <li>I'm generally with @gfldex on the "Ideology-Warning-Light" concept - however, I find it a bit more than ironic that the programming language that deliberately welcomes and encourages diversity, carries this size of inside joke baggage, often in a downright anglocentric fashion. A significant proportion of us here in this discussion aren't even native speakers of English... From my perspective, we are using English simply as a given common protocol, to go out of one's way in order to make an umpteenth anglo pun goes against the vision Raku offered for me.</li> | |
| </ol> | |
| <p>Will things change drastically, with or without my rant? Probably not. Perhaps at least error messages shouldn't use "dwimmy"... What matters more is rather the principle: let's not treat the Raku language as a sandbox for a handful of people. It's important to keep in mind that most potential users may not want to adapt to a whole isolated(-ish :P) culture; Raku won't automatically turn into another boring language just by letting outsiders manage without all the "funny Raku legacy".</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QFBZM"> | |
| <div class='header'> | |
| <span class='author'>@duncand</span> commented at <time datetime="2022-12-08T23:12:26Z">2022-12-08 23:12</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <ol> | |
| <li>They are severely impractical. Giving something a name that is neither descriptive, nor properly searchable doesn't seem to be justified by the amount of fun they give to a rather closed set of people. Really, it's not fun at all to try to figure out how Dateish is not Date, what on earth dwimmy tries to mean or what does KnowHOW know how to do. Then go back, retry, and again find they don't make much more sense than zodiac signs.</li> | |
| </ol> | |
| </blockquote> | |
| <p>What would you propose instead of <code>Dateish</code> for the name of that role (maybe <code>Datelike</code>)? It seems to be just the right level of specificity, similar to a <code>Date</code> but not generic enough to include <code>DateTime</code> or the like. I realize its not the best language but not every type name lends itself to the cleanest abstractor like say "fractional" could be a role for "fraction" etc so we kludge a bit.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QFZwP"> | |
| <div class='header'> | |
| <span class='author'>@thoughtstream</span> commented at <time datetime="2022-12-09T00:09:13Z">2022-12-09 00:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>As this discussion appears to be on-going, here are a few further (mostly historical) points to consider:</p> | |
| <ul> | |
| <li> | |
| <p>Having learned our lesson with Perl, one of our fundamental design criteria for Raku | |
| was to avoid providing synonyms for constructs. Hence, unlike Perl, Raku doesn't offer | |
| <code>for</code>/<code>foreach</code> or <code>eval{}</code>/<code>try{}</code> or <code><></code>/<code>readline</code> or <code><...></code>/<code>glob</code>. That still seems | |
| like a good policy to me. So, if we're renaming <code>MONKEY</code> stuff, I think it should be a | |
| complete rename, <em><strong>not</strong></em> a mere aliasing.</p> | |
| </li> | |
| <li> | |
| <p>The name <code>MONKEY</code> was indeed chosen both because of the existing concept of | |
| <em>"monkey typing"</em> and because of the pun of <em>"See no eval"</em> and because of the | |
| idiomatic English verb <em>"to monkey"</em> meaning to mess around with something | |
| that perhaps one doesn't fully understand.</p> | |
| </li> | |
| <li> | |
| <p>But <code>MONKEY</code> was also specifically chosen as a <em><strong>disaffordance:</strong></em> so that coders actually | |
| would feel a little embarrassed and unprofessional to have it appear in their code. | |
| Likewise <code>SEE-NO-EVAL</code> and <code>GUTS</code>. In other words, these terms are <em>intended</em> | |
| to make you a little uncomfortable or disoriented when they're used...so as to | |
| subtly discourage their use in the first place. In fairness, <code>use UNSAFE</code> might work | |
| almost as well in that respect <em>(and <code>use FREAKING-UNSAFE</code> would work even better! ;-)</em></p> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QHcfd"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-12-09T10:29:40Z">2022-12-09 10:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>Just to add my personal stance:</p> | |
| <p>I do like the way things are named in Raku. I do value having MONKEYs around and that I am allowed to slurp and spurt and die. Knowing the literal meaning of these words makes it easier for me to remember them. I have a tiny rebel living in my chest. Thus I wouldn't like for us to ban parts of the culture I have come to like in the hopes that we can cater to people that believe a programming language isn't good to use if it uses the wrong words. I do value consistency and understandability. I do believe that we can strive for consistency without giving up our culture.</p> | |
| <p>I do notice that having things named differently from other languages in rare situations requires to look a term up instead of understanding it from prior context. The only time I remember that happening to me was <code>Texas Operators</code> as I didn't know the saying that "everything is bigger in Texas" and happened to stumble upon that term before learning about the meaning. But looking a term up in the <a href="https://docs.raku.org/language/glossary#index-entry-Texas_operator">glossary</a> or documentation isn't a big deal.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QH0Cs"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-09T12:04:34Z">2022-12-09 12:04</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>What would you propose instead of <code>Dateish</code> for the name of that role (maybe <code>Datelike</code>)?</p> | |
| </blockquote> | |
| <p>Ironically enough, this requires me to go back and ponder yet another time why <code>Date</code> and <code>Dateish</code> exist as separate things in the first place - and find that there is no clear reason. From all I understand, <code>Dateish</code> only exists to offer <code>Date</code> semantics as a role... so eventually, -ish is the role marker? 🤔I mean, okay, if so then let's do it consistently, this is not the end of the world.</p> | |
| <p>However, "HOW-WHY-WHAT", "KnowHOW" in particular and "dwimmy" - also, I forgot to mention "Cool" which is cool indeed, among many things in Raku but makes no sense either on its own or as "convenient OO loop" - are still just there, with no context, in a completely arbitrary fashion.</p> | |
| <p>Do notice that I'm absolutely not naming the same things as @patrickbkr for example. slurp, spurt and die, these are all simple and understandable concepts. However, hyper metaoperators are <a href="https://github.com/Raku/problem-solving/issues/346">too complex</a> to pass funny-sounding, vague, underdefined words around. Similarly, the metamodel is too important to be hidden behind the completely undescriptive HOW name. Yes, I read @raiph's great article about the metamodel, or well, at least one great article - and no, "KnowHOW" <em>still makes no sense</em> for a name, not the slightest. "Singularity", "GodModel", "SelfModel" or even "BigMeta", these are fairly arbitrary and punny names but I think any of these random names I quickly came up with make magnitudes more sense than the "HOW" terminology and the word "Know" attached to it.</p> | |
| <p>If we manage to clarify Stringy-Dateish-etc. names as role names - the situation still won't become optimal because there are other role names with no similar hint: Blob, Buf, Associative, etc. - then that's one down. I think that in itself (i.e making clear that this "ish names" are base roles for common classes) might be an important step forward, without having to change anything about the language itself.</p> | |
| <p>I also agree that it's silly to avoid a language just because of "using the wrong words". Having said that, I think "we", as in the Raku community, need to humble down a bit about the appeal we are making to the outer world. We are in no position to say "well, we don't care about first impressions and superficial people". I think the renaming of the language is - partially - an acknowledgement of this. Letting some of the worst names go, or even just acknowledging that they are quite objectively bad names and compensate for that wherever possible, wouldn't mean "destroying the Raku culture" or anything like that. (It's weird to feel like the progressive one within this community, really. :D)</p> | |
| <p>Overall, I'd like to point out that my most important point is not about the (imo) bad naming conventions - it's much more about the "insider joke culture" that I think is bad both for marketing and the declared Raku values. Don't get me wrong when I say "Raku as a language and a community is hardly approachable". <strong>The people <em>are</em> helpful</strong> and overall nice, same goes for the language. But they both <strong>require a <em>very serious sacrifice</em> from the newcomer</strong>. And no, this isn't simply because Raku is a big language, not at all. This is because Raku was designed with a very specific, unique and complex vision in mind and one needs to basically buy into this vision - along with the "memes" - in order to successfully use the language.<br /> | |
| As long as we don't have a "killer feature" in the most classical, boring, marketing-management sense, we are facing a dichotomy: either we lower the "cultural entry point" of the language and the community - or we accept that the main offer of Raku is the vision itself and the success of the language is completely determined by the popularity of this "meme" (in the Dawkinsian sense, just like a religion is a "meme") over time.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QH7dR"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-09T12:37:33Z">2022-12-09 12:37</time> | |
| </div> | |
| <div class='body'> | |
| <p>For the specific topic of this issue: I think "rename over alias" is a dangerous policy at this point - because there are strong arguments against renaming (compatibility) that wouldn't apply to an alias. Also, as we all know well... an alias might turn into the new name over time; perhaps this can be handled at a new version.</p> | |
| <p>Having said that, I really don't have strong feelings about the MONKEY pragmas, I don't think I ever used them. Again, it's rather the principle that we aren't gonna achieve any changes if we think in extremes.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QJm7R"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-12-09T19:28:23Z">2022-12-09 19:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>My ¢2 on this very interesting discussion:</p> | |
| <ul> | |
| <li>On <code>Dateish</code> specifically: In theory, I like the idea of <code>ish</code> as a role marker – the problem is that Raku uses <code>y</code> as the role marker elsewhere: <code>Setty</code>, <code>Baggy</code>, <code>Mixy</code>, <code>Proxy</code> – oh, wait, no, not there :no_good:. As <code>Proxy</code> hints at, <code>y</code> is kind of ambiguous and I wish we'd been more consistent in using <code>ish</code> (e.g., <code>Setish</code>). Though <code>ish</code> and <code>y</code> aren't the only role endings…there's also <code>Positional</code>/<code>Associative</code>, etc. In the absence of consistency, maybe the docs could be clearer about what terms Raku uses to indicate roles? Is there a (grammatical) term that covers all of those words. (I know "adjective" does, but feels a bit vague…)</li> | |
| <li>On "rename over alias": I think @2colours makes a good point about not breaking code. I'd like to point out a middle ground, however: we can rename something but make the <em>old</em> name an alias – but an alias that triggers a depreciated warning. That wouldn't break any code but would avoid the "two names for the same concept" problem that @thoughtstream pointed out. [I'm not necessarily endorsing this approach in every case; just pointing it out as an option]</li> | |
| <li>On Raku's accessibility: I believe that the points @2colours brings up deserve serious consideration; after considering them seriously, I currently disagree. Imo, Raku does a good job of using accessible/non-inside-joke language for most concepts – <em>especially</em> most concepts that most userspace Raku code needs. (This is part of the <a href="http://www.wall.org/~larry/natural.html">"Many acceptable levels of competence"</a> idea.) But (again, imo), Raku also does a good job of using <strong>un</strong>familiar words to signal that something difficult/weird is going on – sort of a warning sign to users who are stumbling into the deep end. For example, it's possible to use Raku for years without needing to use any of the <code>HOW</code>/<code>WHAT</code>/<code>WHY</code> family – but if a user is going to mess with them, they need to understand the MOP at a reasonably deep level. And I view the odd names as a good signal of that.</li> | |
| </ul> | |
| <p>But all that <a href="https://knowyourmeme.com/memes/thats-just-like-your-opinion-man">is just, like, my opinion, man</a>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QKO6-"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-09T22:47:42Z">2022-12-09 22:47</time> | |
| </div> | |
| <div class='body'> | |
| <p>@codesections it's really good to see you around, (I have to say... I hope we will meet more often in Raku online spaces in the forecoming months.)</p> | |
| <p>Let me disagree with the point about accessibility - not on the principle because that sounds fine; on the details.</p> | |
| <p>"gobbling block" and "dwimmy end of hyper metaoperator" are in the userspace - to make it worse, they are in error messages. It feels like a bad gamble to put insider lingo inside error messages, of all places: that should be the most defensive place because that can cause the most headaches to a user. Give them an error message that they don't understand and can't even look up and well... see them explode.</p> | |
| <p>Also, my problem with the "HOW-WHAT-WHY" triangle (I would argue that WHAT is fairly everyday for <em>learning by trying</em>, by the way) and "KnowHOW" isn't that they are unfamiliar, odd, or that they need to be "shouted" - rather that they are downright unhelpful and undescriptive, even if you know the core concept. One might say that it won't matter if you just <em>learn the thing good enough</em> - however, my personal feeling is that metamodel stuff is communicated so badly that it actively kept me from understanding - and all of this starts with "HOW", and basically ends with "KnowHOW". Yes, now that I feel I understand at least the core concept of the metamodel, these words can hold me back much less - but do I feel they tried to? Yes, absolutely, and this isn't such a good thing when you are already at the position that you want to learn something...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QKt9K"> | |
| <div class='header'> | |
| <span class='author'>@duncand</span> commented at <time datetime="2022-12-10T02:37:03Z">2022-12-10 02:37</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <ul> | |
| <li>On <code>Dateish</code> specifically: In theory, I like the idea of <code>ish</code> as a role marker – the problem is that Raku uses <code>y</code> as the role marker elsewhere: <code>Setty</code>, <code>Baggy</code>, <code>Mixy</code>, <code>Proxy</code> – oh, wait, no, not there 🙅. As <code>Proxy</code> hints at, <code>y</code> is kind of ambiguous and I wish we'd been more consistent in using <code>ish</code> (e.g., <code>Setish</code>). Though <code>ish</code> and <code>y</code> aren't the only role endings…there's also <code>Positional</code>/<code>Associative</code>, etc. In the absence of consistency, maybe the docs could be clearer about what terms Raku uses to indicate roles? Is there a (grammatical) term that covers all of those words. (I know "adjective" does, but feels a bit vague…)</li> | |
| </ul> | |
| </blockquote> | |
| <p>I feel that there is a fundamental misunderstanding here by some people, as exemplified above.</p> | |
| <p>On naming, the way one distinguishes a class from a role is by the grammatical category of the word, NOT its spelling. A data type class has a NOUN as its name, indicating what an object of that class IS. A role has an ADJECTIVE as its name, indicating what an object of a class composing that role DOES.</p> | |
| <p>This is a GOOD design for a language, which I have also repeated in my Muldis Data Language etc from Raku's inspiration.</p> | |
| <p>The fact some roles end in "y" or "ish" or whatever is just a coincidence, and mainly comes from the lack of better dedicated words, which otherwise would be used in each instance, such as <code>Positional</code> or <code>Associative</code> or <code>Stringy</code> or <code>Numeric</code> etc.</p> | |
| <p>We definitely should not read into "y" or "ish" being a pattern, rather the names of roles should all be individual case by case, ideally describing what something does, and in the cases under question, things like <code>Setty</code> etc just mean "behave like that thing".</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QK4KK"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-12-10T03:36:43Z">2022-12-10 03:36</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>On naming, the way one distinguishes a class from a role is by the | |
| grammatical category of the word, NOT its spelling. A class has a NOUN | |
| as its name, indicating what an object of that class IS. A role has an | |
| ADJECTIVE as its name, indicating what an object of a class composing | |
| that role DOES.</p> | |
| <p>This is a GOOD design for a language, which I have also repeated in my | |
| Muldis Data Language etc from Raku's inspiration.</p> | |
| </blockquote> | |
| <p>I agree that <code>NOUN = class</code> and <code>ADJECTIVE = role</code> would be a good rule. | |
| The problem is that Raku doesn't consistently follow that rule (as can be | |
| seen in the list of <a href="https://docs.raku.org/type.html">Raku types</a>). | |
| That's what I meant by saying that describing role names as "adjectives" | |
| felt a bit too simple – there are lots of cases where we don't follow | |
| that pattern.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QK9Cf"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-12-10T03:48:44Z">2022-12-10 03:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't see a big discrepancy in using -ish vs. -y. Roughly, -ish characterizes something less tightly bound to the base term; whereas -y is more. If that loose/tight relation of a role changes over time then we're just left off with some legacy status quo.</p> | |
| <p>So, <code>Dateish</code> is something <code>Date</code>-like, but not quite; and <code>Setty</code> is almost like <code>Set</code>, but not is.</p> | |
| <p>BTW, it was a good exercise in English for myself and now I have a better rule of thumb as to when to use which suffix. ;)</p> | |
| <p>As to <code>Positional</code>, <code>Associative</code>. Let's be consistent and use <code>Listy</code>... <code>Listish</code>??? Eh... Thanks, no! ;)</p> | |
| <p>It really feels like Larry thing, more of a linguistic approach to things. While speaking we use what's better fitting the current situation, context, etc. It wouldn't be necessarily the same form of a term at any given time, we would vary it depending on circumstances. Perhaps people with a synthetic mother language do get all this better than the rest. ;)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QLLJR"> | |
| <div class='header'> | |
| <span class='author'>@duncand</span> commented at <time datetime="2022-12-10T04:23:21Z">2022-12-10 04:23</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>As to <code>Positional</code>, <code>Associative</code>. Let's be consistent and use <code>Listy</code>... <code>Listish</code>??? Eh... Thanks, no! ;)</p> | |
| </blockquote> | |
| <p>Nonsense! The <code>Positional</code> and <code>Associative</code> are the most optimal kinds of roles which are all about describing a kind of behavior on its own terms, and are NOT about saying "behaves like X". It doesn't make sense to associate them with <code>List</code> etc.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QLRAt"> | |
| <div class='header'> | |
| <span class='author'>@duncand</span> commented at <time datetime="2022-12-10T04:38:41Z">2022-12-10 04:38</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>On naming, the way one distinguishes a class from a role is by the grammatical category of the word, NOT its spelling. A class has a NOUN as its name, indicating what an object of that class IS. A role has an ADJECTIVE as its name, indicating what an object of a class composing that role DOES. This is a GOOD design for a language, which I have also repeated in my Muldis Data Language etc from Raku's inspiration. | |
| I agree that <code>NOUN = class</code> and <code>ADJECTIVE = role</code> would be a good rule. The problem is that Raku doesn't consistently follow that rule (as can be seen in the list of <a href="https://docs.raku.org/type.html">Raku types</a>). That's what I meant by saying that describing role names as "adjectives" felt a bit too simple – there are lots of cases where we don't follow that pattern.</p> | |
| </blockquote> | |
| </blockquote> | |
| <p>I can see what you mean if you're talking about roles like <code>Blob</code> or <code>Buf</code> or some others.</p> | |
| <p>In that case they probably should have been called <code>Blobby</code> and the like.</p> | |
| <p>A fundamental part of the problem here, shared by Raku and many other languages, though NOT shared by my Muldis Data Language, is the conflation between types and behaviours in the same named concepts "role" or "class".</p> | |
| <p>A better language design is such that a data type is strictly defined as a set of values, full stop. The definition of a type is just the enumeration and/or subset/union/etc definition etc that tells you whether a given value is a member of that type or not. And then all routines that define behavior or actions are NOT part of the type definition, but instead are external to that and they USE types. You can have libraries/modules that organize the routines that use types but aren't considered types themselves.</p> | |
| <p>The problem with a lot of languages is they use the same concept name, <code>class</code> or <code>role</code> etc to describe things that are data type definitions and things that define things which work with types but are not types. These should be separate, and then each would more naturally have its own independent naming conventions.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QLtRu"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-10T11:43:48Z">2022-12-10 11:43</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>So, Dateish is something Date-like, but not quite; and Setty is almost like Set, but not is.</p> | |
| </blockquote> | |
| <p>This sounds a lot to me that ultimately there is no difference...</p> | |
| <p>Again, we are back into deep analysis of English - what for, and frankly, why do we need to care this much about <em>English</em> of all languages? I swear, there are tons of interesting languages - actually, I have only come across languages that made more sense than English and that's still a very limited and Eurocentric vision. Anyway, I think we can admit that we are typically not linguists, neither Shakespeare, and most people (perhaps including the majority of people involved in this discussion) do struggle with these English neologisms.</p> | |
| <blockquote> | |
| <p>Nonsense! The Positional and Associative are the most optimal kinds of roles which are all about describing a kind of behavior on its own terms, and are NOT about saying "behaves like X". It doesn't make sense to associate them with List etc.</p> | |
| </blockquote> | |
| <p>I'm not saying that you are necessarily wrong but you cannot just make these declarations; the arguments are missing - especially since for some weird reason, <code>Array</code> descends from <code>List</code> which creates an inherent assymetry where <code>List</code> is a very general thing. <em>Why</em> does it not make sense to associate them with <code>List</code>? What is characteristic to a <code>List</code> that isn't characteristic to a <code>Positional</code>? <code>List</code>s can even be lazy so most properties that would follow from a "cached" structure don't even necessarily apply to it.</p> | |
| <blockquote> | |
| <p>On naming, the way one distinguishes a class from a role is by the grammatical category of the word, NOT its spelling. A data type class has a NOUN as its name, indicating what an object of that class IS. A role has an ADJECTIVE as its name, indicating what an object of a class composing that role DOES.</p> | |
| </blockquote> | |
| <p>The biggest problem with this, as Daniel pointed it out, is that it's not true in the first place. If it were true, it would still be a hassle because we are back to deep analysis of English - a word doesn't always give it away if it's a noun or an adjective and sometimes it can even be both - and during that deep analysis, we might conclude that the <code>does [adjective]</code> terminology is absolutely bonkers. It would make more sense the other way around: <code>is [adjective]</code> and <code>does [noun]</code>.</p> | |
| <p>Anyway, I'd say these weaknesses all just show that it's not such a great idea after all to base terminology on peculiarities of a natural language. Indeed, it can very well be a "Larryan" (Larry-ish?) thing - I probably said somewhere that "Larryan" things inflate heavily without his constant assistance to integrate them into a coherent system - obviously it's not possible to just blow the whole terminology away in favor of some simplistic, "boring" terminology; however, let me repeat this once more: it is important to at least <em>recognize</em> and <em>admit</em> when the terminology doesn't help as much as it could/should because we can/have to compensate for it, mostly by documentation but also some finetuning, setting good and advertisable paradigms in code etc.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QLwRb"> | |
| <div class='header'> | |
| <span class='author'>@librasteve</span> commented at <time datetime="2022-12-10T12:52:24Z">2022-12-10 12:52</time> | |
| </div> | |
| <div class='body'> | |
| <p>I suspect that most languages have Nouns and Adjectives, so English is not unique. I gather that Larry was a linguist and that this class / role dichotomy is deliberately intended to engage our existing language brain structures to help us reason about code.</p> | |
| <p>Since I did not know the "rules" (ok, there are no rules in English), I looked this up:</p> | |
| <p><em>A noun is a person, place or thing; an adjective modifies or describes the noun. The girl is a beauty -- beauty being a noun. The girl can also be beautiful -- beautiful, in this case, being an adjective. Turning a noun into an adjective requires only a few minor changes to the ending of a word.</em></p> | |
| <p><em>The simplest way to turn a noun into an adjective is to add suffixes to the end of the root word. The most common suffixes used to create adjectives are -ly, -able, -al, -ous, -ary, -ful, -ic, -ish, -less, -like and -y. For example, turn the noun "danger" into the adjective "dangerous" by adding the suffix -ous. Other examples include: "The lady enjoys magic; however, she is not very magical herself." "Those who have health are considered healthy, while those who follow fashion are thought of as fashionable." In these instances, the root nouns were turned into adjectives by adding appropriate suffixes.</em></p> | |
| <p><em>Sometimes you will have to make slight modifications to the root noun if it ends in -e, -y or -t. For example, if the noun is "offense," the adjective is "offensive." In this case, drop the -e from the noun and add -ive to create the adjective.</em></p> | |
| <p>source: https://www.theclassroom.com/change-noun-adjective-8387579.html</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QL7M-"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-10T16:43:59Z">2022-12-10 16:43</time> | |
| </div> | |
| <div class='body'> | |
| <p>Indeed - most languages have nouns and adjectives; the question is, why do we need to analyze English words in particular, whether they are nouns or adjectives. It's not regular or even clear enough to be worth it.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMHiI"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-12-10T18:17:59Z">2022-12-10 18:17</time> | |
| </div> | |
| <div class='body'> | |
| <p>@duncand wrote:</p> | |
| <blockquote> | |
| <p>A better language design is such that a data type is strictly defined as a set of values, full stop.</p> | |
| </blockquote> | |
| <p>If I'm understanding you correctly, this is just <a href="https://medium.com/@thejameskyle/type-systems-structural-vs-nominal-typing-explained-56511dd969f4">structural typing versus nominal typing</a>, right? (With you saying that you prefer structural typing). Imo, both have advantages.</p> | |
| <p>@2colours wrote:</p> | |
| <blockquote> | |
| <p>Anyway, I think we can admit that we are typically not linguists, neither Shakespeare</p> | |
| </blockquote> | |
| <p>Who is the "we" in that sentence? If "we" refers to "all Rakoons", then yeah, we aren't linguists. If "we" refers to the group deciding on Raku language design then … well, ok, most of us <em>still</em> aren't actually linguists. But I view one of Raku's <strong>core</strong> selling points as being that it was designed from a linguist-ish perspective (maybe that's part of what you mean with your comments about things being Larry-ish latter on?). And I'd very much like to keep that slant to the language as it continues to grow/evolve – though, as you point out, there's no particular reason to draw more heavily from English linguistic principles than from linguistic principles in other languages.</p> | |
| <p>I personally hope that someone looking back at Raku's overall, collaborative, design decades from now would describe the design team as linguists – and, if the stars align, I'd be thrilled by Shakespeare comparisons … though that's not anything anyone can realistically aspire to, whether writing prose, poetry, or code.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMKKo"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-12-10T19:09:32Z">2022-12-10 19:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think we are rallying too far from the original topic of the issue and I have my fair share of responsibility in that, too. Now that the Github Discussions feature is turned on in this repo, maybe we can move the kind of discussions that don't have an explicit tangible goal <a href="https://github.com/Raku/problem-solving/discussions">here</a>.</p> | |
| <p>Besides, I think what I tried to communicate is also falling apart a bit. If we need to stick to the "linguistics aspect": I would advise to think about designing conlangs and what makes a conlang worthy (I didn't want to use the word "useful" because that felt too reductive), and how that can be applied to programming. That seems like a more constructive form of linguistics for our purposes than analyzing one particular existing natural language and map it to programming.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMO76"> | |
| <div class='header'> | |
| <span class='author'>@duncand</span> commented at <time datetime="2022-12-10T21:04:45Z">2022-12-10 21:04</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>@duncand wrote:</p> | |
| <blockquote> | |
| <p>A better language design is such that a data type is strictly defined as a set of values, full stop.</p> | |
| </blockquote> | |
| <p>If I'm understanding you correctly, this is just <a href="https://medium.com/@thejameskyle/type-systems-structural-vs-nominal-typing-explained-56511dd969f4">structural typing versus nominal typing</a>, right? (With you saying that you prefer structural typing). Imo, both have advantages.</p> | |
| </blockquote> | |
| <p>Actually no, what I'm contrasting here is not structural typing versus nominal typing, that's something else, and in practice a type system tends to be a hybrid of those not just one or the other.</p> | |
| <p>Rather, what I'm arguing for is <em>decoupling</em> of routines from type definitions. I'm saying that a best type system design has that normal routines are not part of the definitions of types, but are their own separate thing that use types. So for example, your routine math operators like add or multiply, or your routine list operators like union or filter, they are not defined as methods of the Integer or List type definitions, but rather are defined in other libraries with different names and they take arguments of type Integer or List etc. Its probably more comparable to how languages considered "not object oriented" are designed, eg how type definitions and functions are separately defined in C.</p> | |
| <p>This is more of an organizational thing for code. The design I argue for still has the interesting features like polymorphism and so on that people often ascribe to OO languages but aren't specific to them.</p> | |
| <p>My point is that having a clear separation between a code unit that defines what a type is, and a code unit that defines operations you can do with types, it can be easier to have consistent naming for things, each of these has their own scheme.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMQbQ"> | |
| <div class='header'> | |
| <span class='author'>@duncand</span> commented at <time datetime="2022-12-10T21:42:22Z">2022-12-10 21:42</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Rather, what I'm arguing for is <em>decoupling</em> of routines from type definitions. ... | |
| My point is that having a clear separation between a code unit that defines what a type is, and a code unit that defines operations you can do with types, it can be easier to have consistent naming for things, each of these has their own scheme.</p> | |
| </blockquote> | |
| <p>On further reflection, I formally retract my arguments in this thread on good language design, not because I don't believe in them in other contexts, but because I realize that this wouldn't actually solve the problem being discussed on naming roles and classes etc.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMQ95"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-12-10T21:56:31Z">2022-12-10 21:56</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Rather, what I'm arguing for is <em>decoupling</em> of routines from type definitions. I'm saying that a best type system design has that normal routines are not part of the definitions of types, but are their own separate thing that use types.</p> | |
| </blockquote> | |
| <p>Oh, I understand now; thanks. Well (and you may well know this), in Raku allows for that design as well. Consider the following code:</p> | |
| <pre><code class="language-raku">class Foo { | |
| method A { say "A method"} | |
| } | |
| my method B(Foo $:) { say "B method"} | |
| my $f = Foo.new; | |
| $f.A; # OUPUT: «A method» | |
| $f.&B; # OUTPUT: «B method» | |
| </code></pre> | |
| <p><code>B</code> is a normal method that is "[its] own separate thing that use[s] types" (in this case, <code>Foo</code>). Of course, defining separate methods like that isn't common practice in (most) Raku code, and using it does require the extra <code>&</code> character. But that has more to do with the question of who gets to define the current lexical language: does <code>Foo</code> define it, or does the caller? There are advantages to both, depending on the intent.</p> | |
| <p>[<strong>Edit</strong>: But, as 2colors noted above, this is probably drifting too far from the issue and this thread likely isn't the best place for this conversation, as interesting as it's been]</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMSA_"> | |
| <div class='header'> | |
| <span class='author'>@duncand</span> commented at <time datetime="2022-12-10T22:19:21Z">2022-12-10 22:19</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>Rather, what I'm arguing for is <em>decoupling</em> of routines from type definitions. I'm saying that a best type system design has that normal routines are not part of the definitions of types, but are their own separate thing that use types.</p> | |
| </blockquote> | |
| <p>Oh, I understand now; thanks. Well (and you may well know this), in Raku allows for that design as well. Consider the following code:</p> | |
| <pre><code class="language-raku">class Foo { | |
| method A { say "A method"} | |
| } | |
| my method B(Foo $:) { say "B method"} | |
| my $f = Foo.new; | |
| $f.A; # OUPUT: «A method» | |
| $f.&B; # OUTPUT: «B method» | |
| </code></pre> | |
| <p><code>B</code> is a normal method that is "[its] own separate thing that use[s] types" (in this case, <code>Foo</code>). Of course, defining separate methods like that isn't common practice in (most) Raku code, and using it does require the extra <code>&</code> character. But that has more to do with the question of who gets to define the current lexical language: does <code>Foo</code> define it, or does the caller? There are advantages to both, depending on the intent.</p> | |
| </blockquote> | |
| <p>To be clear, I was never arguing against using classes to organize methods. Rather I was arguing that methods A and B should be in class Bar rather than class Foo, where Bar is a class with no fields or a static class.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMSMt"> | |
| <div class='header'> | |
| <span class='author'>@duncand</span> commented at <time datetime="2022-12-10T22:23:21Z">2022-12-10 22:23</time> | |
| </div> | |
| <div class='body'> | |
| <p>The easiest argument for a routine-type decoupling is to point to any method that involves multiple types as arguments or result types. When multiple types are involved, it is usually a contrivance to say the method "belongs to" one type more than another, by virtue of it living in the class defining the type. Whereas decoupling is then putting all the types on the same footing, and saying none are more special than the rest, and doing this consistently for all methods.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMTcl"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-12-10T22:55:57Z">2022-12-10 22:55</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>When multiple types are involved, it is usually a contrivance to say the method "belongs to" one type more than another, by virtue of it living in the class defining the type.</p> | |
| </blockquote> | |
| <p>This is true in many languages but <em>not</em> in Raku. This took me a while to grasp and I only really got it after reading jnth's answer to a Stack Overflow question asking <a href="https://stackoverflow.com/questions/56011589/why-is-adding-methods-to-a-type-different-than-adding-a-sub-or-an-operator-in-pe">"Why is adding methods to a type different than adding a sub or an operator in perl6?"</a>. The whole answer is worth reading, but the bottom line is what I was getting at before: when a method is defined inside a class, it's part of the <em>class's</em> lexical language; elsewhere, it's part of the caller's.</p> | |
| <p>(Oh and re: your previous point: "a class with no fields or a static class" isn't really a class in any meaningful sense – it's a module/package. Raku supports those, of course, and I'm sympathetic to the claim that they're often a better unit of code organization than the class)</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="335"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/335"><span class='number'>335</span></a> - <span class='title'>Does -I Directory Order Affect Whether Modules are Recompiled?</span></div> | |
| <div class='author'>[open]<span class='author'>@Xliff</span> opend this issue at <time datetime="2022-07-19T05:32:14Z">2022-07-19 05:32</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>If so, if this is due to the first specified -I directory being used for something, can we remove the need for that. I am of the thought that if a module is pre-compiled, it should <em>be globally precompiled</em>, and that the -I directories should be decoupled from the process.</p> | |
| <p>Please discuss.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>…</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5G2Nun"> | |
| <div class='header'> | |
| <span class='author'>@Xliff</span> commented at <time datetime="2022-07-19T05:33:08Z">2022-07-19 05:33</time> | |
| </div> | |
| <div class='body'> | |
| <p>As requested by the template, my proposed solution is thus:</p> | |
| <blockquote> | |
| <p>Can we use a $*HOME/.rakudo-precomp to act as a default location for precompiled files and then use a command-line flag to override this location?</p> | |
| </blockquote> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="334"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/334"><span class='number'>334</span></a> - <span class='title'>Class construction: should we reconsider our approach for performance?</span></div> | |
| <div class='author'>[closed]<span class='author'>@vrurg</span> opend this issue at <time datetime="2022-07-19T01:40:50Z">2022-07-19 01:40</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>While trying to find a solution for a problem, I produced the following benchmarking script and the outcomes of it were totally not what I expected them to be:</p> | |
| <pre><code class="language-raku">use nqp; | |
| class Cnew { | |
| has int32 $.n; | |
| method !SET-SELF(:$!n = 0) { self } | |
| method new(|c) { | |
| nqp::create(self)!SET-SELF(|c) | |
| } | |
| } | |
| class Cdefault { | |
| has Int $.n = 0; | |
| } | |
| constant WARM-UPS = 100000; | |
| constant REPETITIONS = 1000000; | |
| sub bench-type(\type, $warmup = False) { | |
| my $reps = $warmup ?? WARM-UPS !! REPETITIONS; | |
| my $dst = now; | |
| for ^$reps { | |
| my $inst = type.new(:n($_)); | |
| } | |
| now - $dst; | |
| } | |
| my @h = "default", "own new()"; | |
| say @h.join(" | "); | |
| say ("---" xx +@h).join("|"); | |
| for ^5 { | |
| my @res; | |
| for Cdefault, Cnew -> \type { | |
| bench-type(type, True); | |
| @res.push: bench-type(type); | |
| } | |
| say @res.join(" | "); | |
| } | |
| </code></pre> | |
| <p>On current <em>master</em>:</p> | |
| <p>default | own new() | |
| ---|--- | |
| 0.730388158 | 2.016668629 | |
| 0.729939058 | 1.960586197 | |
| 0.714930339 | 1.994514452 | |
| 0.733272278 | 2.000946608 | |
| 0.745431878 | 2.018232289</p> | |
| <p>I was curious if that approach ever made any sense, and turns out – yes, it did! On 2017.01 the benchmark came back with the following result:</p> | |
| <p>default | own new() | |
| ---|--- | |
| 3.2215718 | 1.8667579 | |
| 3.28101230 | 1.8537423 | |
| 3.35283597 | 1.8548766 | |
| 3.282788 | 1.8447700 | |
| 3.36808548 | 1.8681506</p> | |
| <p>Hence the question: isn't it time to put to rest that sometimes cumbersome approach of using <code>!SET-SELF</code> to speed up things?</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5G1xuF"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-07-19T01:41:25Z">2022-07-19 01:41</time> | |
| </div> | |
| <div class='body'> | |
| <p>Apparently, my answer would be: yes, the time has come.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G1yJ0"> | |
| <div class='header'> | |
| <span class='author'>@MasterDuke17</span> commented at <time datetime="2022-07-19T01:45:12Z">2022-07-19 01:45</time> | |
| </div> | |
| <div class='body'> | |
| <p>Do you get the same results if you swap the order you test the two cases in?</p> | |
| <p>Sent from my iPhone</p> | |
| <blockquote> | |
| <p>On Jul 18, 2022, at 9:41 PM, Vadim Belman <em><strong>@</strong></em>.***> wrote:</p> | |
| <p> | |
| Apparently, my answer would be: yes, the time has come.</p> | |
| <p>— | |
| Reply to this email directly, view it on GitHub, or unsubscribe. | |
| You are receiving this because you are subscribed to this thread.</p> | |
| </blockquote> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G1yTx"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-07-19T01:46:34Z">2022-07-19 01:46</time> | |
| </div> | |
| <div class='body'> | |
| <p>Gonna try, but consider the warmup stage before each of them.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G1yvP"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-07-19T01:50:16Z">2022-07-19 01:50</time> | |
| </div> | |
| <div class='body'> | |
| <p>Reversed order:</p> | |
| <p>2017.01:</p> | |
| <p>own new | default | |
| ---|--- | |
| 1.7128334 | 3.4771897 | |
| 1.71532246 | 3.500296 | |
| 1.7280119 | 3.51300360 | |
| 1.73421150 | 3.50224591 | |
| 1.7431859 | 3.49703611</p> | |
| <p><em>master</em>:</p> | |
| <p>own new | default | |
| ---|--- | |
| 1.985668847 | 0.790770787 | |
| 1.99817258 | 0.796513102 | |
| 1.971275435 | 0.788280027 | |
| 1.95291269 | 0.782028382 | |
| 1.952078772 | 0.789872244</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G1zIN"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-07-19T01:53:34Z">2022-07-19 01:53</time> | |
| </div> | |
| <div class='body'> | |
| <p>BTW, not to mention that <code>CStruct</code>/<code>CPointer</code> representations are now the slowest ones. But this is off-topic.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G4FI5"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-07-19T14:12:35Z">2022-07-19 14:12</time> | |
| </div> | |
| <div class='body'> | |
| <p>@timo pointed out at the cost of using <code>Capture</code> <a href="https://irclogs.raku.org/moarvm/2022-07-19.html#01:56">on IRC</a> and that does make BIG difference. With the following modification to <code>Cnew</code>:</p> | |
| <pre><code class="language-raku">class Cnew { | |
| has int32 $.n; | |
| method !SET-SELF($!n = 0) { self } | |
| method new(:$n) { | |
| nqp::create(self)!SET-SELF($n) | |
| } | |
| } | |
| </code></pre> | |
| <p>Results are as follows:</p> | |
| <p>own new | default | |
| ---|--- | |
| 0.282024096 | 0.775953319 | |
| 0.283046057 | 0.789541219 | |
| 0.282974815 | 0.783523175 | |
| 0.282654953 | 0.777844951 | |
| 0.283326496 | 0.776175484</p> | |
| <p>A quick grep through the core did not reveal any captures used in construction, so that's probably the final answer at what I have missed initially. :)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G4NoJ"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-07-19T14:40:54Z">2022-07-19 14:40</time> | |
| </div> | |
| <div class='body'> | |
| <p>A benchmark like this:</p> | |
| <pre><code> for ^$reps { | |
| my $inst = type.new(:n($_)); | |
| } | |
| </code></pre> | |
| <p>Is not likely to represent a real-world program too well, since real-world programs will often keep objects they create around rather longer. MoarVM has only basic escape analysis today, but isn't that far off being able to turn the "own new" benchmark here into an empty loop.</p> | |
| <p>One of the costs in default new is the temporary hash used to slurp the object arguments into. That, however, is also a juicy target for later escape analysis and scalar replacement improvements.</p> | |
| <p>I'd hope that some day spesh can turn both cases into empty loops, however given "own self" is far easier for it to do that with than "default", I'd advise a little caution about this benchmark, since there will likely be a time when all the work in "own self" is determined dead code, and won't really be measuring what is wanted.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G5KUj"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-07-19T17:57:29Z">2022-07-19 17:57</time> | |
| </div> | |
| <div class='body'> | |
| <p>Any suggestion how to improve reliability of the results?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G5Lzq"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-07-19T18:04:26Z">2022-07-19 18:04</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Any suggestion how to improve reliability of the results?</p> | |
| </blockquote> | |
| <p>Binding the created objects into a (pre-sized) array would be one way.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G8mKO"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-07-20T13:29:56Z">2022-07-20 13:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>I was considering an array, but overlooked the size-limiting approach. Anyway, due to rakudo/rakudo#4989 I cannot currently get reliable results on HEAD. But preliminary I can tell that despite the numbers are different, the <em>own new</em> is still ~1.5 times faster.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="333"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/333"><span class='number'>333</span></a> - <span class='title'>Specify an implementation neutral method for extracting pod</span></div> | |
| <div class='author'>[open]<span class='author'>@finanalyst</span> opend this issue at <time datetime="2022-07-15T21:39:10Z">2022-07-15 21:39</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Any POD6 stanzas in the current CompUnit is available as $=pod.<br /> | |
| Accessing the POD6 in another file, eg., a documentation file in a directory, is not specified. Consequently, extracting the POD6 array relies on implementation details, such as the Precompilation modules. | |
| …</p> | |
| <p>All the Raku documentation is in pod6 files, eg., <code>github.com/Raku/doc/doc/Language/containers.pod6</code> (eventually the extension will be '.rakudoc').</p> | |
| <p>In order to access the information, the POD6 has to be compiled (because POD6 is a part of a Raku program), and then the pod is extracted from the precompilation store. This requires finding the id of the file in the store, which can be turned into a handle, which can then be accessed using <code>nqp::atkey</code> to get the pod array.</p> | |
| <p>This process is highly implementation dependent, and uses subclasses that could be changed.</p> | |
| <p>Suppose a syntax is agreed, for example, <code>my @pod = EVALDOC "filename.rakudoc" </code> (by analogy with `EVALFILE "some-program.raku"), then the mechanism by which the pod is extracted, eg from a Precompilation Store, can be hidden from the user.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5GtUzh"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-07-16T20:38:44Z">2022-07-16 20:38</time> | |
| </div> | |
| <div class='body'> | |
| <p>Just an idea off the top of my head. It might be a bad one:</p> | |
| <pre><code>EVALFILE :doc($module), $file | |
| </code></pre> | |
| <p>behaves in a manner consistent with:</p> | |
| <pre><code>raku --doc(MODULE) | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5GuX1T"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2022-07-17T16:20:22Z">2022-07-17 16:20</time> | |
| </div> | |
| <div class='body'> | |
| <p><code>raku --doc(MODULE) program.raku</code> is not the same as I was proposing.</p> | |
| <p>It takes <code>program.raku</code> and renders the POD6 in that program with the renderer specified as MODULE (actually, it uses <code>Pod::To::MODULE</code>).</p> | |
| <p>So <code>raku --doc program.raku</code> is the same as accessing <code>$=pod</code> inside <code>program.raku</code>.</p> | |
| <p><code>EVALFILE :doc, $file</code> maybe better because it does not increase the number of function names. However <code>EVALFILE $file</code> evaluates $file as a Raku program and returns the value of the final statement of the program. So the <code>:doc</code> changes the return value.</p> | |
| <p>The suggestion <code>EVALDOC $file</code> returns the pod tree that results from evaluating $file.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5GyuhE"> | |
| <div class='header'> | |
| <span class='author'>@FCO</span> commented at <time datetime="2022-07-18T16:21:22Z">2022-07-18 16:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>Could it ignore any possible code (not pod6) inside the file?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G1ShG"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-07-18T22:13:01Z">2022-07-18 22:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>Aiui:</p> | |
| <blockquote> | |
| <p>Could it ignore any possible code (not pod6) inside the file?</p> | |
| </blockquote> | |
| <p>Yes, but there will be associated (potentially major) risks.</p> | |
| <p>A minor one is that it might mean a source file fails to compile (and the doc would not be generated).</p> | |
| <p>A major one is that it might be a security hole, leading to a source file that would ordinarily just compile in a correct or at least benign way instead being malign in some respect.</p> | |
| <p>(This is because the nature of Raku, like Perl, is that to correctly parse it you must execute a variety of constructs as you go during the compilation phase. These constructs have statically unknowable consequences in terms of side effects. These side effects include altering Raku's syntax, which alters the parsing of code after such a side effect has occurred. Which alteration can alter the meaning of code from one thing to another depending on whether you process or skip some earlier code.)</p> | |
| <p>The biggest risk would be trashing Raku's reputation. Someone's system is hosed because they tried to pull up some doc.</p> | |
| <p>We run that risk anyway due to Raku's design, but introducing deliberate ignoring of code amplifies that risk and the consequences of falling afoul of that risk.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G1a7g"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-07-18T22:54:56Z">2022-07-18 22:54</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p><code>EVALFILE $file</code> evaluates <code>$file</code> as a Raku program</p> | |
| </blockquote> | |
| <p>So does this new feature, right?</p> | |
| <blockquote> | |
| <p>and returns the value of the final statement of the program.</p> | |
| </blockquote> | |
| <p>Yes. That's the difference.</p> | |
| <p>One can imagine other reasons to <code>EVALFILE</code> such as running the type checker (<code>-c</code>, so perhaps <code>EVALFILE :c, $file</code>).</p> | |
| <blockquote> | |
| <p>So the <code>:doc</code> changes the return value.</p> | |
| </blockquote> | |
| <p>Yes. If there were ever an <code>EVALFILE :c, $file</code>, then presumably that would also change the return value.</p> | |
| <p>More generally, I was thinking <code>EVALFILE</code> might be a principled way to selectively introduce access to some things that Rakudo does, with one principle being to use a named argument that matches the Rakudo command line argument to keep things clean and relatively easy to remember and document.</p> | |
| <p>Maybe <code>EVALFILE :M<foo> $file</code> to evaluate <code>$file</code> after loading module <code>M</code>? And so on.</p> | |
| <p>Anyhoo, 'tis just an idea.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G4y3O"> | |
| <div class='header'> | |
| <span class='author'>@finanalyst</span> commented at <time datetime="2022-07-19T16:20:50Z">2022-07-19 16:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>My original suggestion of <code>EVALDOC</code> is not so different from <code>EVALFILE :doc</code>, and personally I think it is a consistent extension to have <code>EVALFILE :c</code> or <code>EVALFILE :M(module) file</code>.</p> | |
| <p>@FCO</p> | |
| <blockquote> | |
| <p>Could it ignore any possible code (not pod6) inside the file?</p> | |
| </blockquote> | |
| <p>If you write a raku program with a whole load of embedded Pod::Blocks, and then inspect a variable called <code>$=pod</code> (it could be eg. <code>$=documention-in-this-file</code>), you will see that it is an array of <code>Pod::Blocks</code>. This data structure is created by the Raku compiler.</p> | |
| <p>The specification of POD6 refers to the <code>ambient</code> and to POD6. The ambient is the code part of a program. The ambient is not included in the Pod::Block array. However, it is possible to have sections of code inside the POD6 using either the FormattingCode <code>C<></code> or a code block bracketted by <code>=begin code</code> and <code>=end code</code>.</p> | |
| <p>So it is possible to have code inside the POD6, but unless you are playing significant compiler tricks, this code is not the ambient code written to be evaluated as a program.</p> | |
| <p>My suggestion is to have a simple way implementation-neutral to get hold of the POD array associated with another program or module, or just a documentation file in a directory.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="332"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/332"><span class='number'>332</span></a> - <span class='title'>POD6 consistency problems</span></div> | |
| <div class='author'>[open]<span class='author'>@finanalyst</span> opend this issue at <time datetime="2022-07-15T18:40:37Z">2022-07-15 18:40</time></div> | |
| </div> | |
| <div class='body'> | |
| <ol> | |
| <li>Rakudo does not properly implement Pod::Block::Table or Pod::Defn because these blocks do not contain Pod::Blocks relating to embedded POD6. Other Pod::Blocks allow for Pod::Blocks to be recursively embedded.</li> | |
| <li>Extend POD6 specification so that all Pod::FormattingCode objects follow the behaviour of <code>L<></code>, <code>X<></code>, and <code>P<></code>.</li> | |
| </ol> | |
| <hr /> | |
| <p>There is a difference between POD6 implementation problems, covered here, and the way POD6 is rendered, which is mostly the content of #69. The renderer <em>Pod::To::HTML2</em> (in raku-pod-render) handles some of the problems in #69, eg. <code>P<></code>. <code>P<></code> is correctly implemented by Rakudo, but is not rendered by <em>Pod::To::HTML</em>. Moreover, <em>Pod::To::HTML</em> does not provide a mechanism for Custom Pod or FormattingCode blocks, which is specified, but <em>Pod::To::HTML2</em> does provide a mechanism to render custom blocks.</p> | |
| <p>Implementation error: | |
| Allow for Pod to be embedded in Pod::Block::Table and Pod::Defn (also possibly Pod::Headings)</p> | |
| <ul> | |
| <li>This bug is reported as an issue for <em>Pod::To::HTML</em>, but it is not a rendering issue because the Pod::Block::Table returned by the compiler does not recursively contain Pod::Blocks which could be properly rendered.</li> | |
| <li>This is an implementation flaw because there is nothing in the Specifications to indicate embedding should not be done.</li> | |
| <li>There is a test in the <em>Pod::To::HTML</em> test suite for embedded tables, but it is fudged.</li> | |
| <li>I think the flaw arose because the current syntax for POD6 tables was changed from Damian's original specification</li> | |
| </ul> | |
| <p>Language Extension: | |
| Extend the syntax of FormattingCodes <code>L<></code>, <code>X<></code> and <code>P<></code> to all FormattingCodes. FormattingCode P, X & L have the form, eg for X, <code>X< some text that will be in the Contents | a list that will be in Meta ></code></p> | |
| <ul> | |
| <li>When P, L or X are processed by Rakudo, a Pod::FormattingCode object is returned in which the <strong>contents</strong> attribute is set to 'some text that will be in the Contents', and the <strong>meta</strong> attribute is set to the scalar or list after the <code>|</code>.</li> | |
| <li>The Renderer then handles the contents and meta parts appropriately (or not).</li> | |
| <li>The implemented behaviour fulfills the specification for P, L, X.</li> | |
| <li>The extension suggested here would enable custom FormattingCodes to be more flexible.</li> | |
| <li>This extension is implemented by the <em>Pod::To::HTML2</em> renderer by parsing the <strong>contents</strong> string of a non-standard Pod::Formatting block.</li> | |
| </ul> | |
| <hr /> | |
| </div> | |
| <div class='comments'> | |
| </div> | |
| </div> | |
| <div class='issue' id="330"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/330"><span class='number'>330</span></a> - <span class='title'>modules.raku.org should be deprecated</span></div> | |
| <div class='author'>[open]<span class='author'>@lizmat</span> opend this issue at <time datetime="2022-07-10T14:09:33Z">2022-07-10 14:09</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>One of the older Raku websites, is https://modules.raku.org. Started in 2009, it is based on Perl and Mojolicious, for the simple reason that Raku was not capable of providing the necessary functionality then.</p> | |
| <p>In the past year, it has basically not been maintained at all. But before that, maintenance was already pretty minimal, and mostly because of the name change.</p> | |
| <p>Since early 2021, https://raku.land has been serving the need to be looking at the Raku module ecosystem very well, and has now become the de-facto place to get informed about modules in the Raku ecosystem.</p> | |
| <p>It feels like it is therefore time to put the modules.raku.org web site to rest, and to make referrals to https://raku.land the official way of referring to Raku modules.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5G3mvm"> | |
| <div class='header'> | |
| <span class='author'>@MARTIMM</span> commented at <time datetime="2022-07-19T12:18:31Z">2022-07-19 12:18</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think that 'raku.land' is very nice to work with and that the older one, 'modules.raku.org', can be removed.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G4uPt"> | |
| <div class='header'> | |
| <span class='author'>@jubilatious1</span> commented at <time datetime="2022-07-19T16:13:26Z">2022-07-19 16:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>I like the domain name:</p> | |
| <p>https://modules.raku.org/</p> | |
| <p>It's a quick edit away from https://raku.org/ and the "modules" prefix tells you what you'll find there.</p> | |
| <p>How to re-direct "raku.land" content so it propagates to the https://modules.raku.org/ domain?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G4xoe"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-07-19T16:18:52Z">2022-07-19 16:18</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think we'd first want to do it the other way around: redirect modules.raku.org traffic to raku.land ?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G404B"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-07-19T16:25:06Z">2022-07-19 16:25</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I think we'd first want to do it the other way around: redirect | |
| modules.raku.org traffic to raku.land ?</p> | |
| </blockquote> | |
| <p>Why? If modules.raku.org is the designated domain name for our module search | |
| (and I'd personally like that as the name is much more descriptive and it's | |
| part of the "official" raku.org thing) all we'd have to do is take down the | |
| current app, point the domain at the server that runs raku.land and redirect | |
| from raku.land to modules.raku.org.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G413I"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-07-19T16:28:56Z">2022-07-19 16:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>The current app is a. still under development, and b. the person responsible for it, might not want to give up on it?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G431V"> | |
| <div class='header'> | |
| <span class='author'>@jubilatious1</span> commented at <time datetime="2022-07-19T16:36:53Z">2022-07-19 16:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>Clarification: I wasn't suggesting abandoning or transitioning away from https://raku.land/ , but rather "saturating the market" so that users landing on https://modules.raku.org/ would see https://raku.land/ content.</p> | |
| <p>(That, and I like the <code>modules.raku.org</code> domain name).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G5qAJ"> | |
| <div class='header'> | |
| <span class='author'>@JRaspass</span> commented at <time datetime="2022-07-19T20:27:16Z">2022-07-19 20:27</time> | |
| </div> | |
| <div class='body'> | |
| <p>So if we rename to r.l to m.r.o we'd need another set of redirects to redirect old m.r.o content to it's location on r.l (which would now be m.r.o). To that end we might want to wait until r.l has feature parity, things like source code viewing it doesn't yet do.</p> | |
| <p>As for the name, I find the confusion around modules vs distributions vs libraries a little confusing. I went will calling them dists on r.l as it was my understanding that a dist contains multiple modules/libraries, but I might have that completely wrong.</p> | |
| <p>If nothing else I do intend to add more features to r.l since there's been an uptick in feature requests, but as with everything, there's only so much tuits on the world. PRs would be gladly welcome! I plan to add author search soonish. And a recent request for dark mode shouldn't be too tricky, even with my poor art skills (actually that's a place where I would appreciate any help, just needs someone to suggest a palette).</p> | |
| <p>Also I'd like to hear what @jjatria thinks as he's the co-creator of Raku Land.</p> | |
| <p>I'd also note that metacpan never inherited the branding/name of cpan when it replaced it, redirects were just setup and that was a long time after it became a suitable replacement.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G7t_X"> | |
| <div class='header'> | |
| <span class='author'>@jjatria</span> commented at <time datetime="2022-07-20T09:42:48Z">2022-07-20 09:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>I welcome the community embracing our work in raku.land and join in on the effort. I think both @JRaspass and I agree that the aim of the project was always to support <em>at least</em> all the (good) features in modules.raku.org, so we'll be happy to get to that point. I think any deprecation of the old site should probably use that as a milestone.</p> | |
| <p>As far as the domain goes, I've never been a fan of modules.raku.org, to be honest. It feels long and, as I understand it, a little misleading since it has never hosted anything that indexes modules: both the existing site and raku.land index distributions (although we have thought about how to index individual modules, a little like MetaCPAN does).</p> | |
| <p>I'm also not entirely sure we need the directory to live under the language's domain. Off the top of my head, the only languages I can think that do it are <a href="https://pkg.go.dev/">Go</a>, <a href="https://hackage.haskell.org/">Haskell</a>, and <a href="https://cran.r-project.org/">R</a>, but they're in the minority: <a href="https://crates.io/">Rust</a>, <a href="https://www.npmjs.com/">Node</a>, <a href="https://metacpan.org/">Perl</a>, <a href="https://pypi.org/">Python</a>, <a href="https://rubygems.org/">Ruby</a>, <a href="https://packagist.org/">PHP</a>, <a href="https://www.ctan.org/">TeX</a>, <a href="https://swiftpackageindex.com/">Swift</a>... they all have their directories in some other domain, and I think I for one like this model: it means that if / when a better version comes up the change is transparent in the URL (= since the domain changed, it communicates that the site is different).</p> | |
| <p>I would personally vote for making modules.raku.org redirect to raku.land, maybe with some deprecation notice, and we can change it to point instead to <code>$fancy-new-site.$tld</code> when that one comes around.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5LEVCD"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-09-27T12:20:41Z">2022-09-27 12:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>As I was checking the modules.raku.org website for pointers regarding how it works, I noticed for the first time that it was a much better site I assumed it was, and especially with regards to being "the official thing" of the Raku community - which I think is seriously lacking in raku.land.</p> | |
| <blockquote> | |
| <p>In the past year, it has basically not been maintained at all. But before that, maintenance was already pretty minimal, and mostly because of the name change.</p> | |
| </blockquote> | |
| <p>Now that I'm re-reading this issue, it points out exactly what I feared while looking at the content: the site was drastically abandoned during the changes in 2019.</p> | |
| <p>I might be too optimistic but I see no reason why the Todo, the Most Wanted page or the Citation page couldn't be revived in some form. In particular, the Citation index seems so great, I never knew there was something like that. It doesn't only look awesome but it's very intuitive feedback on the status of the ecosystem both to developers and potential users. I wonder what Richard Hainsworth thinks about it. If there is no technical barrier and nobody wants to continue it, I am willing to take over it, I consider it A tier marketing/management content.</p> | |
| <p>I haven't checked all the sites @jjatria linked but it's interesting to see how it aligns with what I wanted to say before checking this issue again. <em>raku.land is like npmjs.org</em>, in the sense that by design, it seems somewhat distant from the underlying language. modules.raku.org seemed like an official site for Raku modules, and I like this approach - actually, <em>this is the approach of 2 of the listed 3 languages having their package registry frontend on their own domain</em>. I think the Go site does this really well but even the Rust site which lives in its own domain can be a good example of what I miss from raku.land currently.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5LEm7q"> | |
| <div class='header'> | |
| <span class='author'>@jjatria</span> commented at <time datetime="2022-09-27T13:20:40Z">2022-09-27 13:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>Other than the Todo, the things that you mention are not really part of modules.raku.org: the citation page is a link to an external Github Page, and the Most Wanted is a link to a document hosted in Github itself. As for the to-do, which of the features mentioned there are particularly interesting?</p> | |
| <p>Would you be able to explain a little more in detail what you mean by raku.land being "somewhat distant from the underlying language [by design]", in opposition to modules.raku.org? A lot of the design decisions that have gone into raku.land (like the separation between distributions and modules, and the way that auth is managed, etc) are very much <em>because</em> of the language it targets: they wouldn't make much sense if this were not a site <em>for Raku</em>.</p> | |
| <p>I don't think there's anything wrong with the modules.raku.org site itself, apart from the fact that it's not written in Raku and that it's largely unmaintained and difficult to revive (in part because of the first point). Well, and I guess the search bar is a little frustrating...</p> | |
| <p>The language choice might seem cosmetic, and in most cases it would be, but in this one I think Raku would greatly benefit from being dogfooded.</p> | |
| <p>More generally, if you can be more explicit about the things you miss from raku.land, I am pretty sure you won't see any blockers from us.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5LFKMH"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-09-27T15:05:19Z">2022-09-27 15:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>First off, I definitely agree that dogfooding in this case is very much desirable. I think the general points made by @lizmat were very accurate and overall it's a good idea to "give the upper hand" to raku.land. I just realized that modules.raku.org actually had positives that I would miss if a redirection happened today.</p> | |
| <blockquote> | |
| <p>Other than the Todo, the things that you mention are not really part of modules.raku.org: the citation page is a link to an external Github Page, and the Most Wanted is a link to a document hosted in Github itself.</p> | |
| </blockquote> | |
| <p>That's right but I think it's much more important <em>where they appear</em> than <em>where they are hosted</em>. Without checking modules.raku.org, I wouldn't have an idea these things can exist, and I do think they improve the cohesion within the community. They are both useful and appealing.</p> | |
| <blockquote> | |
| <p>Would you be able to explain a little more in detail what you mean by raku.land being "somewhat distant from the underlying language [by design]", in opposition to modules.raku.org?</p> | |
| </blockquote> | |
| <p>I think if you check the Go site as opposed to the Npm registry (which I'm not even comfortable calling "the Node site"), you will have a lot of pointers. The Go site has a complete header and footer all about Go itself and the visuals shout "this is a dedicated and official Go site". The Npm site is also really nice but it barely mentions Javascript, let alone Node.js. The Npm registry 1. assumes you know JS and Node in and out 2. tries to be a brand on its own. To some extent, this holds for Packagist, PyPI and even CPAN, crates.io being the counterexample: it communicates that it is tightly integrated with the Rust community, both by its motto and the footer structure.</p> | |
| <p>Putting it into perspective: modules.raku.org links several Raku sites in the menu - I admit it may be a bit on the bloated side of things, however I think the general aim is good. Again, what is linked matters, over what is owned/maintained by the site.</p> | |
| <p>Linking to the "most wanted" list gave purpose to the "most wanted" list. Likewise the Citation Index, which apparently died with the site, despite not being a part of it technically. (I think it's so nice and useful that I definitely don't want to give up on having something like that, now that I now it existed once.)<br /> | |
| For the Todo... well, I think that one feels a bit like a draft. Maybe (? big question mark) besides doing something like "fez checkbuild", there could be a way to signal todo's or "help wanted" in the code, if only by convention?</p> | |
| <p>This is a recurring thought of mine that we have bigger deficiencies on the presentation and communication side than content-wise - and actually this might be easier to improve.<br /> | |
| Summing it up and putting it into the context of raku.land:</p> | |
| <ul> | |
| <li>I'd advise to add a "raku.org-ish" footer (not necessarily by look but by content)</li> | |
| <li>I would consider finding a place for linking content that can be saved/recycled from the "philosophy" of modules.raku.org</li> | |
| <li>bonus: the search bar might require some changing for raku.land as well :P</li> | |
| </ul> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="328"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/328"><span class='number'>328</span></a> - <span class='title'>Adding head, skip, tail as subroutines</span></div> | |
| <div class='author'>[closed]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-06-27T17:12:54Z">2022-06-27 17:12</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Hello, | |
| this has been mentioned on chat a couple of days ago. | |
| It would be nice to have head, skip and tail as subroutines with the iterable as their last parameter, similarly to grep and map. | |
| This would both increase consistency (why <em>shouldn't</em> they work, if grep and map do work?) and the usefulness off the feed operators, since this would allow us to write | |
| 1, 3 ... * ==> grep &some-condition ==> head 20 | |
| and similar code.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5Fp2Xb"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-06-28T11:28:03Z">2022-06-28 11:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>@SmokeMachine Is this related work of Reds respective operators? Do they match?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5FqCko"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-06-28T12:19:07Z">2022-06-28 12:19</time> | |
| </div> | |
| <div class='body'> | |
| <p>I've also created a module to allow for this functionality in older Rakudo versions:</p> | |
| <p>https://raku.land/zef:lizmat/head-skip-tail (aka https://github.com/lizmat/head-skip-tail)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5GYUWc"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-07-11T19:26:19Z">2022-07-11 19:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>This has been merged, so closing this issue.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="327"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/327"><span class='number'>327</span></a> - <span class='title'>Inherit(aliz)ability and compos(aliz)ability are too ad-hoc</span></div> | |
| <div class='author'>[open]<span class='author'>@Kaiepi</span> opend this issue at <time datetime="2022-06-24T08:59:06Z">2022-06-24 08:59</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>In Rakudo, we don't tend to depend on <code>&trait_mod:<is></code>/<code>&trait_mod<does></code> themselves, but the <code>^add_parent</code>/<code>^add_role</code> metamethods backing them because we don't really want redundant validation within the MOP for the sake of performance. We are inconsistent about when and where checks should be performed however: they're split between the traits, the <code>Metamodel::MultipleInheritance</code>/<code>Metamodel::RoleContainer</code> metaroles backing them, and wherever we depend on them in some cases. Because we are being inconsistent in the MOP, we get <a href="https://github.com/rakudo/rakudo/pull/4478">bugs</a>. The <code>inheritable</code>/<code>composable</code> archetypes are very similar, as are their lazy <code>inheritalizable</code>/<code>composalizable</code> counterparts, to which <code>generic</code> can relate. There should exist a protocol of sorts in inheritance and composition akin to generics and their <code>^instantiate_generic</code> that can factor out these checks in a way that's compatible with the ecosystem's needs, capable of offloading the burden of validation from <code>&trait_mod:<is></code>/<code>&trait_mod<does></code> themselves.</p> | |
| </div> | |
| <div class='comments'> | |
| </div> | |
| </div> | |
| <div class='issue' id="326"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/326"><span class='number'>326</span></a> - <span class='title'>`div` and `mod` don't convert to Int, unlike everything else</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-06-07T11:03:41Z">2022-06-07 11:03</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Hello, | |
| there seems to be a very definite principle in Raku that by default, operators try to interpret given data reasonably for the operation one expresses with the operator. There are some operators, however, that stand out of the row and make things break unsurprisingly: | |
| <code>'6' / 2 #works, gives 3</code> | |
| <code>'6' div 2 #errors, cannot be dispatched to Int:D</code> | |
| (In my particular case, I was doing factorization with repeated div= calls - it's faster than /= but it didn't work on the string input that otherwise wouldn't have caused any problems.)</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>I find that this behavior is inconsistent with all the other Numeric operators but <code>mod</code> - <code>mod</code> also stands out of the row.<br /> | |
| Actually, even the <code>gcd</code> and <code>lsm</code> operators coerce to Int - operators that are the most similar both by looks and behavior to <code>div</code> and <code>mod</code>.</p> | |
| <p>I wonder if there is a technical reason for this apparent inconsistency - I have to be honest, even if there is, this seems to go against the overall Raku approach and "marketing" so much that it might be worth revising. From what I know, the implementation change wouldn't be significant or difficult to make - also, it arguably wouldn't make existing code break, only "not-break" (when it was previously expected to).</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5EeTiC"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-06-07T15:02:17Z">2022-06-07 15:02</time> | |
| </div> | |
| <div class='body'> | |
| <p>This is what I found in the source, related to <code>mod</code>:</p> | |
| <pre><code># NOTE: According to the spec, infix:<mod> is "Not coercive, | |
| # so fails on differing types." Thus no casts here. | |
| </code></pre> | |
| <p>But up to my understanding, the comment is about <code>Real</code> casting via <code>.Bridge</code> only.</p> | |
| <p>Either way, I tested <code>.Int</code> coercion for <code>mod</code> and <code>div</code> and this doesn't seem to break any tests. If no objections raised, I'd be in favor of aligning the ops with other arithmetic.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Efflb"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-06-07T19:59:42Z">2022-06-07 19:59</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>"Not coercive, so fails on differing types." Thus no casts here.</p> | |
| </blockquote> | |
| <blockquote> | |
| <p>But up to my understanding, the comment is about <code>Real</code> casting ...</p> | |
| </blockquote> | |
| <p>The code comment may well have been introduced as part of the bridge mechanism work, but the comment it quotes ("Not coercive, so fails on differing types.") is from <a href="https://github.com/Raku/old-design-docs/commit/66279de9998040c4442b7ddd3030a1dc1f4b43ce">a design doc commit</a> (repeated for <code>div</code> and <code>mod</code>) by Larry Wall as part of a design clean up introduced by @Larry 13 years ago. It's explicitly general.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Efgfa"> | |
| <div class='header'> | |
| <span class='author'>@MasterDuke17</span> commented at <time datetime="2022-06-07T20:03:52Z">2022-06-07 20:03</time> | |
| </div> | |
| <div class='body'> | |
| <p>But why are those not coercive? There's no reason given.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5Efpeb"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-06-07T20:41:48Z">2022-06-07 20:41</time> | |
| </div> | |
| <div class='body'> | |
| <p>I did several hours worth of research as part of uncovering an initial tranche of the discussion for this design and documented it in <a href="https://stackoverflow.com/a/71072660/1077672">this SO answer</a>.</p> | |
| <p>Please click on the IRC search link to read comments made about it starting in 2006. Click on those individual comments to view the surrounding discussion each time, and pay particular attention to discussions in the minutes/hours/days preceding commits to related design doc or code.</p> | |
| <p>For example, see some relevant IRC discussion in 2010 starting <a href="https://irclogs.raku.org/perl6/2010-06-07.html#01:05">here</a> ("(looking at div, %, and mod) spec"), continuing on through mention of posting <a href="https://justrakudoit.wordpress.com/2010/06/07/real-operators/">Real Operators</a> ("loliblogged"). And also search for "colomon" to see related code and design doc commits.</p> | |
| <p>Or, if you'd rather not spend that time, please consider my recollection that I had concluded it was carefully designed after substantive discussion, with my TL;DR in that SO representing a good distillation of what I thought the design conclusion was, albeit without the underlying rationale (which, iirc, emerged as I read the various discussions).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5EfqAv"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-06-07T20:44:07Z">2022-06-07 20:44</time> | |
| </div> | |
| <div class='body'> | |
| <p>S03 has this (highlight mine):</p> | |
| <blockquote> | |
| <p>Dispatches to the infix:<div> multi most appropriate to the operand types, <strong>returning a value of the same type</strong>. Not coercive, so fails on differing types.</p> | |
| </blockquote> | |
| <p>Thus the lack of coercion seems to be the logical consequence of wanting a return type matching the argument types.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5EgExV"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-06-07T23:10:47Z">2022-06-07 23:10</time> | |
| </div> | |
| <div class='body'> | |
| <p>This still sounds rather cryptic.</p> | |
| <p>On the other hand, I have a very simple question: what makes all other operators, <strong>with special regards to <code>gcd</code> and <code>lcm</code></strong>, suited for Numeric coercions, but not <code>mod</code> and <code>div</code>? How to make this seem consistent?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5EgItJ"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-06-07T23:35:08Z">2022-06-07 23:35</time> | |
| </div> | |
| <div class='body'> | |
| <p>For the old design documents: I also followed the trace based on what I could understand from your remarks. The blog belongs to Solomon Foster - he was the one who changed the description from Larry Wall's "status quo" that said "<em>typically</em> returning a value of the same type", not strictly "returning a value of the same type".</p> | |
| <p>From what I gather, <code>div</code> was meant to be to <code>/</code> what <code>eqv</code> is to <code>==</code>, hence it was called "generic division" at some point. When core members noticed that this concept is just not feasible, it got repurposed as "integer division", hence pulling the remark regarding the return type - this is what I think wasn't completely thoroughly thought out. Actually, I think it's rather problematic that the "no coercion" clause and the "~~typically~~ returns the same type" clause are from contradicting design versions: one was meant for a "generic division" for which "no coercion" made sense, the other was meant for an "integer division" for which the previous reasoning won't apply per se.</p> | |
| <p>The operators <code>gcd</code> and <code>lcm</code> got added later, thus it's harder to compare the design directly. I can only repeat that I for one see no reason why the rationale of <code>gcd</code> and <code>lcm</code> couldn't apply to <code>˛div</code> and <code>mod</code>, please do point it out if you do.</p> | |
| <p>Overall I think the fundamental design principles should apply since it's noticeable that these operators didn't have a clear purpose in the time of the old design docs you guys are referring to.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5EgpGs"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-06-08T03:13:58Z">2022-06-08 03:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm somewhat baffled by the same-type restriction, seemingly artificially applied to what was initially considered an integer operator. I mean, if it's integer then let it be just integer. It is quite reasonable and clear. The "same type" rule follows quite naturally then for in-core candidates.</p> | |
| <p>But the "non-coercive operator" rule is looking contradictory to me. Let's say I have a class which is <code>Int</code>-y in all respects except that it is not inheriting from <code>Int</code>. I.e. it coerces, it plays nicely in all arithmetic operators, etc. Why isn't it allowed to be used with <code>mod</code> and <code>div</code>?</p> | |
| <p>I think the big problem of all previous discussion on the topic is that they all assumed that types mentioned are numeric types leaving aside those which are not but can unambiguously represent a number. <code>Str</code> is one of those. The above mentioned custom class is too. What we can rely upon is that <code>"42".Numeric</code> is <code>Int</code>, <code>"42.13".Numeric</code> is <code>Rat</code>.</p> | |
| <p>Summing up, I'd propose that the default candidates of <code>mod</code> and <code>div</code> would try <code>.Numeric</code> coercion on their operands and then test for the "same type" rule (particular implementation is irrelevant). I.e. we would have:</p> | |
| <pre><code class="language-raku">multi infix:<mod>(\a, \b) { | |
| a.Numeric mod b.Numeric | |
| } | |
| </code></pre> | |
| <p>And there be it. Looks like an acceptable compromise solution.</p> | |
| <p>Not to focus too much on this, would I know my input flow might include non-numeric but convertible data then using <code>.Numeric</code> on each value wouldn't bother me not a single bit. So, while generally be in favor of introducing the above candidate, I'm totally ok if the idea is not accepted.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G1YSJ"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-07-18T22:42:20Z">2022-07-18 22:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>I haven't gone through the material I researched before, but I note that no one has mentioned a key point I recall from that research (though not enough to recall <em>where</em> exactly I saw it, nor even if it's among that material and not somewhere else).</p> | |
| <p>To wit, iirc, a good general purpose language should have a maximal performance integer divide and integer modulus because a lot of algorithms are completely reliant on that for their speed.</p> | |
| <p>Of course, one can always bail to C code, but still.</p> | |
| <p>So perhaps Larry was thinking that ensuring <code>div</code> and <code>mod</code> failed <em>at compile time</em> if they were not given integers would help ensure the code generated for them would be as fast as possible.</p> | |
| <p>Maybe I recall wrongly, or rightly but Larry is wrong, or he's right but wrong to think that making them integer only will one day allow them to be maximal performance, or right about that but wrong to think that worth the anomaly of being non-coercive, or right about that but...</p> | |
| <hr /> | |
| <p>I know Larry dislikes spaces such as GH and I'm with him on that even if I have to date chosen the uncomfortable compromise of holding my nose and using GH. He has commented once or twice on GH in recent years but I suspect he's done with that.</p> | |
| <p>I know he's at a point where he has to conserve his energy for other aspects of life.</p> | |
| <p>I know he is gentle and thoughtful and does his best to be kind toward all (and is inspiringly good at that) and would, I think, only want to engage with those willing to be on their kindest behavior, respectful of his wisdom (even if he wouldn't describe it as such), and paying full attention to what he has to say if he says anything.</p> | |
| <p>With that all out of the way, Larry does occasionally comment on the relevant mailing lists. So if you'd like him to comment on this, perhaps it would be worth posting there.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G5B9s"> | |
| <div class='header'> | |
| <span class='author'>@jubilatious1</span> commented at <time datetime="2022-07-19T17:19:21Z">2022-07-19 17:19</time> | |
| </div> | |
| <div class='body'> | |
| <p>I question the linked pull request.</p> | |
| <p>The title of this Issue, "<code>div</code> and <code>mod</code> don't convert to Int, unlike everything else" is misleading.</p> | |
| <p>Surely, Perl and Raku both have infix operators that <code>filter</code> their operands? Such as when trying to check numeric equivalence with <code>eq</code>, or string equivalence with <code>==</code> ?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5G5ff2"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-07-19T19:35:29Z">2022-07-19 19:35</time> | |
| </div> | |
| <div class='body'> | |
| <p>How is it misleading? And an even better question would be: what does it mean that certain operators "<code>filter</code> their operands"? One thing is sure: neither <code>eq</code>, nor <code>==</code> fail on operands that <em>can be coerced</em> into Str and Numeric respectively. Unlike <code>div</code> and <code>mod</code> which do fail on anything that isn't an Int in the first place. And the point is that <code>div</code> and <code>mod</code> are the odd-one-out, since <code>gcd</code>, <code>lcm</code>, numeric + - * / all do coerce.</p> | |
| <p>For @raiph : this could make sense but I personally don't see this logic applied anywhere (else), exactly because + - * are also very fundamental operators for integer-related calculations, and yet they all coerce. Also, there are actual traces of <code>div</code> and <code>mod</code>˙being meant as general purpose equivalents of / and % so I don't think there was an established policy for non-coercive, "performant" operators. Either way, I think consistency would be the most important. I would be happy if <code>div</code> and <code>mod</code> coerced because in my use case, the coercion would only happen once and I would still win performance - but if they don't, then I see no reason for <code>lcm</code>˙and <code>gcd</code> to do coerce.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="324"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/324"><span class='number'>324</span></a> - <span class='title'>Taking responsibility for Raku Documentation issues</span></div> | |
| <div class='author'>[closed]<span class='author'>@lizmat</span> opend this issue at <time datetime="2022-05-02T16:38:17Z">2022-05-02 16:38</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>After many years, JJ Merelo has decided to step back from taking responsibility for the documentation of the Raku Programming Language.</p> | |
| <p>Therefore the Raku Community is looking for a person willing to take on this role, which would consist of:</p> | |
| <ul> | |
| <li>ensuring consistency in the Raku documentation</li> | |
| <li>ensuring the Raku documentation is up-to-date</li> | |
| <li>being a tie-breaker on documentation matters if no consensus could be reached</li> | |
| </ul> | |
| <p>On behalf of the Raku Community, the Raku Steering Council would like to thank JJ for all the work they've done for Raku, and its documentation in particular. For many, many years! In the hope that JJ will continue to be a pillar of the Raku Programming Language!</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5Cd-si"> | |
| <div class='header'> | |
| <span class='author'>@coke</span> commented at <time datetime="2022-05-02T17:31:44Z">2022-05-02 17:31</time> | |
| </div> | |
| <div class='body'> | |
| <p>Thanks to JJ for their work over the years.</p> | |
| <p>I am happy to volunteer on the three points noted by lizmat above.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CyLsQ"> | |
| <div class='header'> | |
| <span class='author'>@coke</span> commented at <time datetime="2022-05-08T16:50:37Z">2022-05-08 16:50</time> | |
| </div> | |
| <div class='body'> | |
| <p>I am trying to setup a call (skype/zoom/etc.) with anyone interested in working on the docs site (newcomers, folks with work in progress, everyone) so we can look at planning, setting expectations, etc.</p> | |
| <p>If anyone is interested in attending, please add a note to:</p> | |
| <p>https://github.com/Raku/doc/wiki#meeting</p> | |
| <p>or stop by <code>#raku-doc</code> on IRC.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="323"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/323"><span class='number'>323</span></a> - <span class='title'>Our symbol resolution implementation is totally counter-thread-safe</span></div> | |
| <div class='author'>[closed]<span class='author'>@vrurg</span> opend this issue at <time datetime="2022-04-28T02:08:24Z">2022-04-28 02:08</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Short intro: <code>require</code> my result in broken symbol tables.</p> | |
| <p>A little longer.</p> | |
| <p>Rakudo implementation of symbol tables is heavily based upon <code>Hash</code>/<code>Map</code>. This is true for both <code>Stash</code> and <code>PseudoStash</code>. When it comes to dynamic symbol resolution (<code>::()</code>) everything is more or less OK because <code>BOOTHash</code> is read-safe. But as soon as we add <code>require</code> there is non-zero chance of conflicting read/write taking place in a multi-threaded application.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5CQryV"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-04-28T02:22:34Z">2022-04-28 02:22</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't have any solution for this so far. The biggest players here are <code>PseudoStash</code>, <code>&REQUIRE_IMPORT</code>, and <code>&INDIRECT_NAME_LOOKUP</code>.</p> | |
| <p>There is no workaround from user code perspective. One could lock-protect symbol lookups and <code>require</code> within their application, but can't take care of 3rd party modules.</p> | |
| <p>A module could also use a lock, but it would be different from what user code is using, drawing it useless.</p> | |
| <p>From the compiler perspective, it is noticeable that <code>GLOBALish</code> is heavily used by the code working with symbols. So, the first impression that a global lock must be used. This would help with mutually exclusive invocations of <code>&REQUIRE_IMPORT</code> and <code>&INDIRECT_NAME_LOOKUP</code>, but barely useful when <code>PseudoStash</code> is involved and used by user code.</p> | |
| <p>Though the problem with <code>PseudoStash</code> is solvable if the global lock becomes part of our public API and is properly documented. But this would also require Raku specs to be updated as the changes of such scope cannot remain compiler-specific.</p> | |
| <p>Sorry for somewhat chaotic text, but I'm in the process of realizing the extent of the problem.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CRlKj"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-04-28T08:36:48Z">2022-04-28 08:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>pinging @jnthn</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CR8jc"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-04-28T10:00:41Z">2022-04-28 10:00</time> | |
| </div> | |
| <div class='body'> | |
| <p>Given writes to symbol tables are comparatively rare, one option is to always clone the underlying hash (that the <code>Stash</code> references), change it, and install the new version. That way, reads don't need protecting, and writes can be serialized either by a lock for that purpose or by CAS on the attribute of the <code>Stash</code> holding the underlying hash.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CR_QP"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-04-28T10:08:15Z">2022-04-28 10:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>I do think the <code>nqp::clone</code> needs protecting, though, doesn't it?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSEAH"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-04-28T10:16:13Z">2022-04-28 10:16</time> | |
| </div> | |
| <div class='body'> | |
| <p>There are two objects involved in a clone, the source and the target. A <code>clone</code> reads the source, which may be shared globally, and writes into the target, which is referenced only by the <code>clone</code> implementation. Since it only reads the source, then so long as all changes are doing a <code>clone</code> first, there's no read/write conflict.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSEIC"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-04-28T10:16:27Z">2022-04-28 10:16</time> | |
| </div> | |
| <div class='body'> | |
| <p>If the nqp::clone is not protected by the lock, then what is? Without that protection, two competing threads may clone the same original hash, make modifications to their local copy and then replace the original with their extended copy. But that will mean that whoever replaces last gets their change in while the other change is lost.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSE1n"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-04-28T10:19:20Z">2022-04-28 10:19</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Without that protection, two competing threads may clone the same original hash, make modifications to their local copy and then replace the original with their extended copy.</p> | |
| </blockquote> | |
| <p>As I said, writes need to be serialized. Not just the clone, but from pre-clone attribute read to post-clone installation. That can be done via a lock or via OCC.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSFZT"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-04-28T10:22:01Z">2022-04-28 10:22</time> | |
| </div> | |
| <div class='body'> | |
| <p>To clarify further, there are two things we want to achieve:</p> | |
| <ol> | |
| <li>Not violating the contract that a (VM-provided) hash may not be read concurrent with writes done by other threads, or be written to by multiple threads at once</li> | |
| <li>Not losing changes to the stash</li> | |
| </ol> | |
| <p>The "clone, change the clone, install the clone" approach only achieves 1. Some kind of change serialization solves 2.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSHrK"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-04-28T10:32:58Z">2022-04-28 10:32</time> | |
| </div> | |
| <div class='body'> | |
| <p>so basically:</p> | |
| <pre><code class="language-raku">if $needs-to-add { | |
| $lock.protect: { | |
| my $clone := nqp::clone($hash); | |
| nqp::bindkey($clone,$key,$value); | |
| $hash := $clone; | |
| } | |
| } | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSI_j"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-04-28T10:39:35Z">2022-04-28 10:39</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'd guess that changes very rarely conflict. After all compilation and loading modules (the big writers to stashes) mostly happen serialized.</p> | |
| <p>Given that, going the CAS way would be more efficient: <code>cas $!storage, -> $orig { my $new := nqp::clone($orig); nqp::bindkey($new, $key, $value); $new }</code></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSJ0q"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-04-28T10:43:36Z">2022-04-28 10:43</time> | |
| </div> | |
| <div class='body'> | |
| <p>Wouldn't that potentially be a deadlock with 2 threads trying to put in different values?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSKYX"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-04-28T10:46:17Z">2022-04-28 10:46</time> | |
| </div> | |
| <div class='body'> | |
| <p>Why would it?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSKYw"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-04-28T10:46:19Z">2022-04-28 10:46</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Wouldn't that potentially be a deadlock with 2 threads trying to put in different values?</p> | |
| </blockquote> | |
| <p>Assuming you mean the CAS approach: if one "transaction" under CAS fails it's because a different one succeeded, so there's a global progress bound. (There's <em>not</em> a local progress bound, which is a failure mode of these approaches, but primarily in situations where the transactions differ in size and the rate of conflicts is high.)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CSLUb"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-04-28T10:51:37Z">2022-04-28 10:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>ok, gotcha both :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CYjRo"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-04-29T21:07:06Z">2022-04-29 21:07</time> | |
| </div> | |
| <div class='body'> | |
| <p>This discussion has cleared up some of my mind. Perhaps, I would manage to get thing done right.</p> | |
| <p>Just one note so far: CAS is not an option to guarantee atomicity. First, <code>$!storage</code> on Map is not a container.</p> | |
| <p>Second, the most typical course of events would be to clone a stash -> merge symbols -> replace. Merging is not cheap. If, on occasion, we get into a situation of multiple replacements the cost of CPU time would be even higher than one could expect. I was experimenting with <code>AttrX::Mooish</code> and found out that <code>cas</code> results in 4 time higher <em>usr time</em> even though the protected code is much cheaper on average, than symbol merging we'd need to do under each <code>cas</code> loop.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5De5eT"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-05-19T20:27:07Z">2022-05-19 20:27</time> | |
| </div> | |
| <div class='body'> | |
| <p>rakudo/rakudo#4917 resolves this issue.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5L8rNW"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-10-11T07:15:59Z">2022-10-11 07:15</time> | |
| </div> | |
| <div class='body'> | |
| <p>As always with complex performance questions, the only way to know what's | |
| better will be to benchmark.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="321"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/321"><span class='number'>321</span></a> - <span class='title'>Allow "bare" indexing terms in documentation</span></div> | |
| <div class='author'>[closed]<span class='author'>@JJ</span> opend this issue at <time datetime="2022-04-24T16:34:39Z">2022-04-24 16:34</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Since categories (#250) were standardized, and they were implemented in the documentation source in Raku/doc#4051, it's no longer possible to simply index a term by doing <code>X<indexed term></code>. This is due to the solution to #250 (#271) considering bare terms "categories", and the limitation of these categories, thus effectively banning "bare" words.</p> | |
| <p>This is, however, a problem. Although there were only a few of these (since, in their majority, they had been provided with indexing terms <em>and</em> anchors just above where they were defined), this causes where there were before:</p> | |
| <pre><code class="language-raku">X<Single Argument Rule> | |
| </code></pre> | |
| <p>now we have</p> | |
| <pre><code class="language-raku">X<Single Argument Rule|Language,Single Argument Rule> | |
| </code></pre> | |
| <p>This causes two problems. First, there's no single source of truth for the indexing term and/or DRY, we're repeating what we have to index twice, one for what's actually rendered (left of <code>|</code>) and another for what's actually indexed (rhs of that, rhs of the comma). Second, the category it's assigned is either a judgment call or obvious: <code>Language</code>, since these are usually sections in tutorials that explain a concept (although the real difference between that category and <code>Reference</code> is not totally obvious).</p> | |
| <p>So I would propose to allow these <em>bare</em> indexing terms, going forward, as well as revert changes or categories for those that were already there.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5CCOGx"> | |
| <div class='header'> | |
| <span class='author'>@Altai-man</span> commented at <time datetime="2022-04-24T16:56:45Z">2022-04-24 16:56</time> | |
| </div> | |
| <div class='body'> | |
| <p>What category/categories do you suggest as being default for those?</p> | |
| <p>The motivation for banning implicit categories except for headers was that prior to that decision everything "bare" was dumped into the "Reference" category, resulting in it being a bit of everything in the world, thus highly limiting any meaning in the categorization at all. Very few people cared about categories and thus everything was mindlessly thrown into "Reference".</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CCO5m"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-04-24T17:14:46Z">2022-04-24 17:14</time> | |
| </div> | |
| <div class='body'> | |
| <p>Any category that's suggested as default, you can always change it by simply adding an indexing category. Repeating rendered and indexed terms is not <em>always</em> bad. It's bad when it's not possible <em>not</em> doing it.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CCPBM"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-04-24T17:17:49Z">2022-04-24 17:17</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>It's bad when it's not possible <em>not</em> doing it.</p> | |
| </blockquote> | |
| <p>I think I don't understand. In what case is it not possible to write something similar to <code>X<Single Argument Rule|Language,Single Argument Rule></code> ?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CCPDr"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-04-24T17:18:49Z">2022-04-24 17:18</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <blockquote> | |
| <p>It's bad when it's not possible <em>not</em> doing it.</p> | |
| </blockquote> | |
| <p>I think I don't understand. In what case is it not possible to write something similar to <code>X<Single Argument Rule|Language,Single Argument Rule></code> ?</p> | |
| </blockquote> | |
| <p>Please read the OP.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CCPiE"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-04-24T17:30:37Z">2022-04-24 17:30</time> | |
| </div> | |
| <div class='body'> | |
| <p>From what I think I understand from the OP is that not repeating is more DRY (I only partly agree, because the letters might be the same, but the semantic meaning is different.), and less typing. But neither less DRYness, nor more typing make something impossible ("not possible"). I think there is a misunderstanding somewhere. Can you please try to explain more?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CCQ73"> | |
| <div class='header'> | |
| <span class='author'>@Altai-man</span> commented at <time datetime="2022-04-24T18:06:36Z">2022-04-24 18:06</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I think I don't understand. In what case is it not possible to write something similar to X<Single Argument Rule|Language,Single Argument Rule> ?</p> | |
| </blockquote> | |
| <p>It's about not being able to just do <code>X<Single Argument Rule></code> with some arbitrary category being assigned the writer doesn't need to think about.</p> | |
| <p>So we just came from years of obscure implicit rules commanding how categorization is done, which resulted in a mess, replacing it with the simplest possible system "just write it explicitly from this list and you're good", and the suggestion is about going back to obscure implicit set of rules, justified by DRY.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CCRVQ"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-04-24T18:16:18Z">2022-04-24 18:16</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>So we just came from years of obscure implicit rules commanding how categorization is done, which resulted in a mess, replacing it with the simplest possible system "just write it explicitly from this list and you're good", and the suggestion is about going back to obscure implicit set of rules, justified by DRY.</p> | |
| </blockquote> | |
| <p>Given this history, I currently don't think that's what JJ is proposing or there is some deeper reasoning that I'm missing. Thus my suspicion of some kind of misunderstanding and my try to clarify this.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CCTEJ"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-04-24T19:02:36Z">2022-04-24 19:02</time> | |
| </div> | |
| <div class='body'> | |
| <p>@Altai-man in view of your characterization of my suggestion, I'll just close this and refrain from doing any other suggestion regarding documentation.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CDqH3"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-04-25T08:36:39Z">2022-04-25 08:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>@JJ I am sad to see you go. Please consider that this is a prestressed discussion and I'm pretty sure there still is an unsolved misunderstanding still here.</p> | |
| <p>@Altai-man I do understand the sentiment, but your statement is bordering a violation of the <a href="https://en.wikipedia.org/wiki/Principle_of_charity">Principle of Charity</a>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CEczU"> | |
| <div class='header'> | |
| <span class='author'>@Altai-man</span> commented at <time datetime="2022-04-25T11:40:36Z">2022-04-25 11:40</time> | |
| </div> | |
| <div class='body'> | |
| <p>@patrickbkr I am sure it is not just bordering, but can be seen as pure violation.</p> | |
| <p>Here goes a wall of text mostly useless to the reader, scroll down to the last paragraph.</p> | |
| <p>I do tend to get very subjective seeing how people in this community tend to oppose any changes. Even with the language name, this topic was pushed for years and the ones voting pro it were seen as aggressive and non-constructive, leading to some community members quitting, with the name being eventually changed for best or worse. It can be seen otherwise, but software needs to evolve, learn by its mistakes, and the software product not being developed is considered dead.</p> | |
| <p>It is hard for me to see this being repeated again and again. Once back we had implicit categories and it resulted in a mess. Were people who caused the mess wrong or the system that allowed them to cause it wrong? My stance is people would do mistakes, even JJ, who undoubtedly knows and loves the documentation more than anyone, for years had the wrong syntax written in the CONTRIBUTING guide, not being in sync with Documentable, so blaming people won't solve the issues. Hence my desire to build a system that prevents people from doing mistakes. If implicit did not work in the past, we can try explicit and see where it goes.</p> | |
| <blockquote> | |
| <p>So I would propose to allow these bare indexing terms, going forward, as well as revert changes or categories for those that were already there.</p> | |
| </blockquote> | |
| <p>This ticket suggests getting back to the implicit system that proved it being hard to use. Given I spent my time suggesting, discussing and putting the new system in place, of course I don't want for all that work to go in vain. Speaking from the technical point of view:</p> | |
| <blockquote> | |
| <p>First, there's no single source of truth for the indexing term and/or DRY, we're repeating what we have to index twice</p> | |
| </blockquote> | |
| <p>Besides DRY there is AHA - avoid hasty abstractions. As I mentioned, we had abstractions for implicit categories before and it led us to mistakes. | |
| But if it really is such an issue that causes us more harm than good, we can introduce some dead simple abstraction syntax like <code>X<Single Argument Rule,Language,$_></code> to not type it twice. This solves the DRY note and doesn't move back to the system prone to allow mistakes again.</p> | |
| <blockquote> | |
| <p>Second, the category it's assigned is either a judgment call or obvious</p> | |
| </blockquote> | |
| <p>Judgement call - yes. | |
| Obvious - absolutely.</p> | |
| <p>Categories <em>need</em> to be obvious when you query. If you are using a search engine to shop for something, you want to see shopping items, not images or videos. If you are looking for images, you don't want to see videos or shopping items.</p> | |
| <p>Categorization that is not obvious is useless to the reader and to the writer.</p> | |
| <hr /> | |
| <p>I am sure JJ cares about documentation more than anyone here and he also did put an immeasurable amount of efforts toward it being in a better thing. I remember times when <code>htmlify.p6</code> was the thing, and it wasn't extensible nor easy to understand. Heck, nobody wanted to deal with it and when people tried to do changes - it led to horrible issues occurring, because too many implicit things were going on. Not because the people doing the changes were wrong or something, but because the system was built not being easy to understand and it made the system fragile. Then JJ pushed towards Documentable and we're already in a better place. I still believe we have tickets stating it is not perfect. I don't think we would be there if his efforts were met with "No, htmlify.p6 is a simple script, why are you building something so complex instead, let's revert it and get back".</p> | |
| <p>@JJ, I cannot read your mind, but I believe your aim was and is - to have a better documentation for everyone, both readers and writers. I remember you mentioning how the new system looks and feels better, so while details can vary, maybe if those of us willing to work on it can show we're heading to a better place than we originally were, you will be glad for the overall direction of the project?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5CEeUj"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2022-04-25T11:47:42Z">2022-04-25 11:47</time> | |
| </div> | |
| <div class='body'> | |
| <p>Sorry, I'm not on board any more regarding any documentation changes, on account of my suggestions and how they're treated. I've created a branch with the old docs, minus the category changes, and will be updating rakudocs.github.io (and/or any user domain emanating from #320) from it from now on, cherry-picking changes from the master branch when convenient (essentially where applicable), and making changes only to that <code>old-docs</code> branch myself. Feel free to do whatever you see fit with the main branch and/or docs.raku.org.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="319"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/319"><span class='number'>319</span></a> - <span class='title'>Junctions with comparisons - or why is != meta</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-03-14T23:04:04Z">2022-03-14 23:04</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p><code>!=</code> appears to behave like a meta-operator construction with junctions which results into confusing semantics ("all elements aren't equal to $n" turns into "not all elements are equal to $n" !); while other comparisons like <code>></code> have their non-meta counterparts (like <code><=</code>), I don't see anything similar for <code>==</code> (or eq, for that matter).</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>There seems to be some discrepancy with the semantics of junction comparisons and the implementation adds to it.<br /> | |
| <code>so all(1,3) > 2 #False</code> | |
| <code>so all(1,3) <= 2 #False</code> | |
| In these cases, it seems like the semantics is "for all elements listed, the substitution results into a True value".</p> | |
| <p>However<br /> | |
| <code>so all(1,3) == 3 #False</code> | |
| <code>so all(1,3) != 3 #True!</code> | |
| The last line seems to contradict this semantics - indeed, it doesn't hold for all values that they aren't equal to 3. What does hold, though, is that not all of them is equal to 3... Actually, we don't have to play this guessing game: | |
| <code>all(1,3) != 3 #True</code> | |
| It collapsed the junction straight away.</p> | |
| <p>It seems to me <code>!=</code> is implemented using the <code>!</code> meta-operator so eventually <code>all(1,3) != 3</code> is the same as <code> !(all(1,3) == 3)</code>. This behavior can be replicated by using <code>!></code> instead of <code><=</code>.</p> | |
| <p>I think it's arguable whether this behavior of the <code>!</code> meta-operator is reasonable at all - the bigger problem is that <code>!=</code> is THE negation of <code>==</code> and we don't really have much choice or control over this meta-behavior, unlike in the case of <code>></code> where we can use an equally "real" operator as the negation of it, without collapsing the junction.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c4_nxKJ"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-03-14T23:10:23Z">2022-03-14 23:10</time> | |
| </div> | |
| <div class='body'> | |
| <p><strong>Bonus issue(?)</strong> | |
| <code>all(1,4) &infix:<!=> 4</code> might look like something that should do the same as <code>all(1,4) != 4</code> - what it actually does is more than surprising: it parses as <code>(all(1,4))&(infix:<!=>(4))</code>, hence accidentally creating a new junction rather than using <code>&</code> as a sigil. Moreover, <code>infix:<!=> 4</code> is True - actually, I failed to pass anything to it that wouldn't have given True, including 0 and Nil.</p> | |
| <p>This also may be worth taking a look at. Why is the precedence like this? Why does <code>infix:<!=> 4</code> not only work with one argument but return True, pretty much no matter what?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_oj6e"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-03-15T06:05:40Z">2022-03-15 06:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>I know this is not the point of the issue, but it's probably better to use <code>so none(1,3) == 3</code>.</p> | |
| <blockquote> | |
| <p>all(1,4) &infix:<!=> 4 might look like something that should do the same as all(1,4) != 4 - what it actually does is more than surprising: it parses as (all(1,4))&(infix:<!=>(4)), hence accidentally creating a new junction rather than using & as a sigil.</p> | |
| </blockquote> | |
| <p>That behavior is correct. If you want to call a function, you shouldn't use the <code>&</code> sigil, unless you use parenthesis: <code>&infix:<!=>(all(1,4), 4)</code> or <code>infix:<!=> all(1,4), 4</code>. If you want to use it as an infix, you should wrap in brackets: <code>all(1,3) [&infix:<!=>] 4</code></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_pqgP"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-03-15T11:35:06Z">2022-03-15 11:35</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I know this is not the point of the issue, but it's probably better to use so none(1,3) == 3.</p> | |
| </blockquote> | |
| <p>Yes, I realized it somewhere on the way and it definitely impacts the severity of the whole phenomenon that there is a nice way out. But yes... as we all know, "sometimes consistency is not a bad thing either". "all" is logically a more transparent concept than "none" and "all of the values are different from 3" is a perfectly valid equivalent of "none of the values are equal to 3".</p> | |
| <blockquote> | |
| <p>That behavior is correct. (...)</p> | |
| </blockquote> | |
| <p>Thank you for the explanation. What I would still be curious about is why <code>infix:<!=> 4</code> works at all and why it returns True.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_p3bX"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-03-15T12:37:51Z">2022-03-15 12:37</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>What I would still be curious about is why infix:<!=> 4 works at all and why it returns True.</p> | |
| </blockquote> | |
| <p>The answer to the first part is <a href="https://github.com/rakudo/rakudo/blob/eab780f38df83ca60f6e96e10345862355326314/src/core.c/Numeric.pm6#L290">here</a>. As for the second part, I think I saw a discussion about it or at least something similar, the reason may be to allow infix operators work with <code>reduce</code> and <code>map</code>, ..., but I'm not sure. It's better to leave it to a more knowledgeable person answer that.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_qRPm"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-03-15T14:21:57Z">2022-03-15 14:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>With regard to the expected behavior, <code>!</code> is a meta. Basically, it is a shortcut for <code>!(<expression>)</code>. In this particular case, to <code>!($a == $b)</code>. So, two rules:</p> | |
| <ul> | |
| <li>one cannot expect negation of an expression to act as a singular operator</li> | |
| <li><code>!=</code> must not behave differently from what it is a shortcut for</li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_rY5N"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-03-15T18:46:12Z">2022-03-15 18:46</time> | |
| </div> | |
| <div class='body'> | |
| <p>Hi @vrurg ,</p> | |
| <p>As someone who (from what I can tell) has worked quite a lot with junctions with regards to their semantics and implementation as well, I kind of hoped for you to show up. However, I have to say this remark from you feels way too little. It's mostly stuff that "everybody knows already" and falls outside of the discussion.</p> | |
| <p>I could refer to my own comment under https://github.com/rakudo/rakudo/pull/3874 to avoid writing the same thing - the "too long; didn't read" would be: don't take neither the meta behavior with junctions (i.e that the negation is applied <em>outside of the whole junction</em>, rather than value-by-value) nor "!= is a shortcut for !==" for granted. These are technicalities, and from what I see, technicalities that can be changed, it only takes a decision, especially for the latter.</p> | |
| <p>I think it's very important to point out that <strong>the reasoning should revolve around the semantics, not the implementation</strong>. I'm yet to see but one explanation as to why all(1,4) != 4 being straight-up True would be a <em>do what I mean</em> design choice or why it would be desirable behavior, even if you know and accept the reasoning behind it.</p> | |
| <p>And then the <code>ne</code> operator still remains. I think it's seriously questionable to implement a <code>!=</code> shortcut for <code>!==</code> that is one character shorter and just tries to hide the meta-behavior - but then what can we say about <code>ne</code> that doesn't give the slightest hint of not being a "singular operator"? What good reason is there to make people learn lexical peculiarities like "<code>ne</code> is not a real operator, <code><=</code> is a real operator, <code>!=</code> is not a real operator ..."?</p> | |
| <p>I feel that I'm giving so much evidence - maybe even too much, considering that several people have agreed with the overall sentiment over time, including @lizmat - and compared to that, the feedback is so little and feels so... inbred. Sorry for the more personal tone in advance but like... do you guys really not feel how crazy <code>all(1,4) != 4 #True</code> seems to anyone expecting a clean and straightforward "for all of the values, P(x) holds" semantics? How crazy it seems that something that works flawlessly for <code><=</code> just won't work for <code>!=</code> or even <code>ne</code>? This is what you guys should address for the sake of the users and this what drives remarks like (I took this one from https://github.com/rakudo/rakudo/issues/3748)</p> | |
| <blockquote> | |
| <p>This may be a notabug, but it's really unexpected and annoying behavior. This makes junctions way too unpredictable to work with.</p> | |
| </blockquote> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_ro09"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-03-15T19:51:24Z">2022-03-15 19:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>@2colours I barely can add much to the discussion in rakudo/rakudo#3874. Neither I have much spare time for this kind of discussions these days. Just two notes.</p> | |
| <p>How many questions would there be asking about the distinction between <code>!==</code> and <code>!=</code>? It's a rather 50/50 kind of situation. Unfortunately, DWIM is good until it results in too many special cases which are kind of apparent, but not always. Sometimes strict rules work better, even if they're kind of counterintuitive.</p> | |
| <p>To add some personal touch to this. Emotionally I tend to like the semantics you're pushing for. But emotions are bad advisors. :)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_t87d"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-03-16T11:13:46Z">2022-03-16 11:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>Please don't feel pressurized, any feedback is welcome and I'm still hoping for someone to show up with a thorough rationale that can be applied to the described scenario. :)</p> | |
| <p>Still I would like to target this remark shortly:</p> | |
| <blockquote> | |
| <p>How many questions would there be asking about the distinction between !== and !=? It's a rather 50/50 kind of situation. Unfortunately, DWIM is good until it results in too many special cases which are kind of apparent, but not always. Sometimes strict rules work better, even if they're kind of counterintuitive.</p> | |
| </blockquote> | |
| <p>Honestly, I don't think there would be a lot. The ! metaoperator is kind of overrated. It's an advanced, exotic feature of Raku, completely different from people expecting a negative counterpart of <code>==</code> (that they actually don't really get in Raku...) I think if we think broader, <code>!==</code> and <code>!=</code> being the same raises more questions for the newcomer than <code>!==</code> and <code>!=</code> being different - and <code>!=</code> isn't a regular formation in Raku either, it's not the meta of <code>=</code>.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5LW_xB"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-10-01T10:25:44Z">2022-10-01 10:25</time> | |
| </div> | |
| <div class='body'> | |
| <p>Thanks to deoac (IRC), I think the last nail in the coffin of <code>!=</code> and <code>ne</code> has really arrived:</p> | |
| <pre><code>(1, 1).one (elem) (1..10) # one(True, True) | |
| (1, 1).one ∉ (1..10) # one(False, False) | |
| #as opposed to: | |
| (1, 1).one !(elem) (1..10) # True | |
| </code></pre> | |
| <p>This proves that</p> | |
| <ul> | |
| <li>as opposed to https://docs.raku.org/language/unicode_ascii#index-entry-%E2%88%89, <code>∉</code> is NOT equivalent to <code>!(elem)</code></li> | |
| <li><code>∉</code> apparently "deserves" to be an operator on its own while <code>!=</code> and <code>ne</code> doesn't</li> | |
| </ul> | |
| <p>I think the current behavior of <code>∉</code> is really an excessive proof that there are good precedences already, and it's really hard to justify why <code>!=</code> and <code>ne</code> still go against the flow.</p> | |
| <p>Also, since I think it's valid behavior that <code>∉</code> and <code>!(elem)</code> are not equivalent, hoping that it stays this way (and <code>ne</code> and <code>!=</code> will be fixed in this direction as well), I am willing to take care of the documentation change that this observation requires.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="317"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/317"><span class='number'>317</span></a> - <span class='title'>Uniform approach to distributing important messages about Raku</span></div> | |
| <div class='author'>[open]<span class='author'>@vrurg</span> opend this issue at <time datetime="2022-02-20T21:24:02Z">2022-02-20 21:24</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>As it was recently discussed at a Raku Steering Council meeting, we don't have a common way to distribute important messages amount community members and Raku users in general. Those message could carry any kind of notifications: from important decisions to security alerts.</p> | |
| <p>This issue could also be considered as a development of #246.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c4-XaaE"> | |
| <div class='header'> | |
| <span class='author'>@nxadm</span> commented at <time datetime="2022-02-20T21:30:38Z">2022-02-20 21:30</time> | |
| </div> | |
| <div class='body'> | |
| <p>~~advertisements about~~</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-XcbS"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-02-20T22:19:46Z">2022-02-20 22:19</time> | |
| </div> | |
| <div class='body'> | |
| <h1>Proposal</h1> | |
| <p>Here is a solution I proposed at the meeting and would like it to be considered here and possibly accepted for implementation.</p> | |
| <h2>Tasks To Be Solved</h2> | |
| <ul> | |
| <li>No limitation on kind of messages distributed. The only requirement for a notification to hit the system is for it to be considered important for the community.</li> | |
| <li>Easy access by public</li> | |
| <li>Priority/urgency levels</li> | |
| <li>Categorization of notifications (public, core development, etc.)</li> | |
| <li>Simpilicity</li> | |
| </ul> | |
| <h2>Solution</h2> | |
| <p>The implementation I propose is a Github repository under Raku organization. The repository's primary content would be text or markdown files containing notification messages. The directory structure of the repository would only consists of top-level directories named after full 4-digit years. The root directory would contain some number of auxiliary files like <em>README.md</em> and, perhaps, few special ones necessary to maintain the notifications. For example:</p> | |
| <pre><code>$ ls | |
| 2021/ | |
| 2022/ | |
| README.md | |
| meta.json | |
| </code></pre> | |
| <h2>Categorization</h2> | |
| <p>Notifications can have three levels of importance:</p> | |
| <ul> | |
| <li>Emergency <em>(mostly for security problems, but not only)</em></li> | |
| <li>Urgent</li> | |
| <li>Announcement</li> | |
| </ul> | |
| <p>A notification can also be tagged to determine its desired audience and, correspondingly, the preferred channels of distribution. Say, the following standard tags could be supported initially:</p> | |
| <ul> | |
| <li>public – for anybody, including non-Raku people; namely, broadcasts</li> | |
| <li>community</li> | |
| <li>core</li> | |
| </ul> | |
| <p>I barely see a reason to introduce any extra audience-related tags. And even if I overlooked something, it is better to stay limited to no more than 5 tags of this kind altogether.</p> | |
| <p>Yet, the above doesn't mean no other tags are allowed as they may be helpful for cataloging purposes.</p> | |
| <h2>File Format And Content</h2> | |
| <p>As it was previously stated, only text or markdown formats are allowed.</p> | |
| <p>A markdown format can include a <a href="https://jekyllrb.com/docs/front-matter/">Jekyll Front Matter section</a> with importance level and tags:</p> | |
| <pre><code>--- | |
| level: announcement | |
| tag: community | |
| --- | |
| # We have news | |
| News to be told... | |
| </code></pre> | |
| <p>Any announcement must start with a header line to be used by those distribution channels where displaying the full text is undesirable. Alternatively, the header could be represented with <code>title</code> keyword of the Front Matter section.</p> | |
| <p>A text format is only accepted for cases where the notification has default level and tag. I my view those would be <em>announcement</em> and <em>community</em> as they're likely to be the most commonly used.</p> | |
| <p>The first line of a text file is always considered as message title.</p> | |
| <h2>File Naming Convention</h2> | |
| <p>Any message file name must start with numeric date and UTC time of submission in YYYY-MM-DD-HH-MM format. Brief description may or may not follow after a space. <em>.md</em> or <em>.txt</em> extensions are mandatory.</p> | |
| <h2>Possible Usage</h2> | |
| <p>The repository would only serve as an authoritative source of information. The simplicity of accessing it and parsing the textual formats of submitted notifications would make it rather simple to re-distribute them over any kind delivery channel:</p> | |
| <ul> | |
| <li>mailing lists</li> | |
| <li>social networks (tags can be used for hashtagging)</li> | |
| <li>specialized utilities</li> | |
| <li>...</li> | |
| </ul> | |
| <p>Github actions can be used to implement immediate publishing.</p> | |
| <h2>Submission</h2> | |
| <p>New notifications are to be submitted via PR process.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-Xm3Z"> | |
| <div class='header'> | |
| <span class='author'>@ugexe</span> commented at <time datetime="2022-02-21T01:11:03Z">2022-02-21 01:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>As far as how things would consume this I would expect a simple, single endpoint (or an endpoint-per-topic) that contains some number of messages. Tooling that consumes this then does not need to know about e.g. git, just how to read whatever remote file(s) might be of interest (because unlike git, Windows has the tools for fetching remote files already installed). Of course the repository could still be populated and structured as suggested, but then there should be some automation that generates the <code>/foo-notifications.txt</code> file in the repo (which can be served by github) or endpoint (which lives somewhere to just map <code>/foo-notifications.txt</code> to the current <code>YYYY-MM-DD.txt</code>).</p> | |
| <p>As far as the format we should consider something that allows for either no dependencies or for a copy-paste type dependency (like an INI grammar). For instance when a tool like zef reads <code>/foo-notifications.txt</code> how would it filter the number of messages it consumes, and/or filter the types of notifications based on user configuration? A naive solution would be a message-per-line, with parts of the message separated by <code>|</code> (so like <code>security|2022-12-1|This is an important security message\nsecurity|2022-11-2|This is an older important security message\n"</code>, such that a parser is basically just <code>$file.IO.lines.map(*.split("|", 3))</code></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-bY8w"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-02-22T02:30:42Z">2022-02-22 02:30</time> | |
| </div> | |
| <div class='body'> | |
| <p>@ugexe Makes full sense. I don't see it as a part of the specification as it more on the implementation detail side of the things.</p> | |
| <p>Moreover, it might be possible to "wrap" the repo into some kind of static generator (Jekyll?) and publish on github.io. It would make it possible to implement RSS/Atom feeds too.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-byIC"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-02-22T06:34:50Z">2022-02-22 06:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>I've been bringing up #158 in discussions in vain, but with Hugo you can achieve this as well. With <a href="https://gohugo.io/content-management/taxonomies">Taxonomies</a> for [custom] tags or categories and <a href="https://gohugo.io/templates/data-templates/">Data Templates</a> for storing JSON, YAML, XML and TOML data in the data directory and retrieving them in a template or even fetching remote JSON and CSV content.</p> | |
| <p>And of course you can have RSS/Atom feeds for them too.</p> | |
| <p>Just thought it wouldn't hurt to mention it.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="316"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/316"><span class='number'>316</span></a> - <span class='title'>Preparing the Raku Ecosystem for the Future</span></div> | |
| <div class='author'>[closed]<span class='author'>@lizmat</span> opend this issue at <time datetime="2022-02-20T16:54:15Z">2022-02-20 16:54</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>This is an update of #39, with an account of the current situation and an explanation of all the pros and cons of each ecosystem backend.</p> | |
| <h1>Introduction</h1> | |
| <p>As of February 2022, the <a href="https://github.com/raku/REA">Raku Ecosystem Archive</a> is fully operational and accessible with recent versions of <a href="https://raku.land/github:ugexe/zef">zef</a> after enabling it by installing <a href="https://raku.land/zef:lizmat/Zef::Configuration">Zef::Configuration</a> and running <code>zef-configure enable rea</code>.</p> | |
| <p>This means that modules can no longer "disappear" from the ecosystem, as a copy will be available in the REA. So it is no longer an issue should the <a href="https://github.com/raku/ecosystem"><code>p6c ecosystem</code></a> or the <code>CPAN ecosystem</code> no longer be supported. You can in fact now already mimic that by running <code>zef-configure disable p6c</code> and <code>zef-configure disable cpan</code>. Authors would still be able to upload to these ecosystem, as the REA harvester <strong>will</strong> continue to scan these ecosystems to make sure any updates will become available in the ecosystem.</p> | |
| <h1>Overview</h1> | |
| <p>But module authors should be discouraged from using the <code>p6c</code> and <code>CPAN</code> for other reasons as well. So let's list the pros and cons of each ecosystem.</p> | |
| <h2>p6c</h2> | |
| <p>The original Raku ecosystem.</p> | |
| <h3>Pros</h3> | |
| <ul> | |
| <li>it was very easy to implement</li> | |
| <li>an author does not need to signup for anything</li> | |
| <li>just need a URL for a META file that contains the download location of a distribution</li> | |
| </ul> | |
| <h3>Cons</h3> | |
| <ul> | |
| <li>it is <strong>not</strong> clear who is responsible for the integrity of the module (unclear <strong>auth</strong>ority)</li> | |
| <li>can impersonate any <em>auth</em>or, there are <strong>no</strong> upload checks</li> | |
| <li>can have <strong>different</strong> versions with the same <strong>version</strong> value (thus breaking immutability principle)</li> | |
| <li>takes up to <strong>4</strong> hours to become visible to <em>zef</em>, which can be a pain in CI when working with multiple dependent distributions</li> | |
| <li>difficult to install any version other then the most recent (some 100+ modules in <code>p6c</code> do not have any version information at all!)</li> | |
| <li>modules can disappear without notice (unless already archived in the REA)</li> | |
| </ul> | |
| <h2>CPAN</h2> | |
| <p>Actually, not CPAN as most people know it, but using the file distribution network of CPAN to make Raku distributions available.</p> | |
| <h3>Pros</h3> | |
| <ul> | |
| <li>integrated distribution upload support in e.g. <a href="https://raku.land/cpan:SKAJI/App::Mi6"><code>App::Mi6</code></a></li> | |
| <li>the author is verified on upload of a distribution</li> | |
| <li>the version of a distribution is checked (immutability guaranteed)</li> | |
| </ul> | |
| <h3>Cons</h3> | |
| <ul> | |
| <li>need to procure a PAUSE login if you don't have one already, which can be troublesome nowadays</li> | |
| <li>the <em>auth</em>ority of the module is not checked, so no guarantee that the uploader is responsible</li> | |
| <li>takes up to <strong>4</strong> hours to become visible to <em>zef</em>, which can be a pain in CI when working with multiple dependent distributions</li> | |
| <li>modules can disappear without notice (unless already archived in the REA)</li> | |
| </ul> | |
| <h2>zef (fez)</h2> | |
| <p>The name of the latest ecosystem is a bit confusing. The easiest way to think about it, is that it is called the "zef ecosystem", and that <code>fez</code> is the tool to upload (similar to <code>PAUSE</code> being the place to upload modules to <code>CPAN</code>).</p> | |
| <h3>Pros</h3> | |
| <ul> | |
| <li>integrated distribution upload support in e.g. <a href="https://raku.land/cpan:SKAJI/App::Mi6"><code>App::Mi6</code></a></li> | |
| <li>the author is verified on upload of a distribution</li> | |
| <li>the <em>auth</em>ority and <em>ver</em>sion are checked on upload</li> | |
| <li>the distribution becomes available within seconds</li> | |
| <li>once uploaded, it can <strong>not</strong> be removed</li> | |
| </ul> | |
| <h3>Cons</h3> | |
| <ul> | |
| <li>need to apply for a fez login (automated with email reply)</li> | |
| <li>it's a black box that lives in the cloud somewhere somehow</li> | |
| </ul> | |
| <h1>Recommendations</h1> | |
| <p>I'd like to therefore offer the following recommendations:</p> | |
| <h2>Disable p6c / cpan, enable rea by default in zef</h2> | |
| <p>This will make it clear that the <code>p6c</code> and <code>cpan</code> ecosystems are being phased out, while still not forcing module authors to immediately change their workflows with regards to module maintenance.</p> | |
| <h2>Publicize the sunsetting of the p6c / cpan ecosystems extensively</h2> | |
| <p>Now that we no longer need <code>p6c</code> and <code>cpan</code> to be available, we can announce that support for these ecosystems will be dropped on Jan 1st, 2023 (or another date not too distant in the future). It should be noted that this does <strong>not</strong> affect any modules currently in those ecosystems, as they will be available in the REA.</p> | |
| <p>This would also need to include an extensive "how-to migrate to zef", more extensive than <a href="https://deathbyperl6.com/faq-zef-ecosystem/">the faq</a> documents.</p> | |
| <h2>Start creating issues in the remaining distributions</h2> | |
| <p>Any modules not having a more recent version in the zef ecosystem, should have issues created after July 1st, 2023 (6 months before the sunsetting date).</p> | |
| <h2>Sunset the <code>p6c</code> and <code>cpan</code> ecosystem updates</h2> | |
| <p>Stop the REA harvester to look at the <code>p6c</code> and <code>cpan</code> ecosystems. This would effectively ignore any updates done there. Module authors would be forced to migrate to the zef ecosystem. Should any of the unmigrated modules need a security / language version compatibility fix, then a higher numbered version of that module should be published in the <a href="https://github.com/raku-community-modules">Raku Language Module Adoption Center</a>, which would effectively made that module Raku Community supported.</p> | |
| <h1>Conclusion</h1> | |
| <p>It should be clear that the <code>p6c</code> and <code>CPAN</code> ecosystems have had their use in the past, but that they are not ready for the future where stability and security become more and more important with applications based on Raku are being used in production.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c4-XUcC"> | |
| <div class='header'> | |
| <span class='author'>@tbrowder</span> commented at <time datetime="2022-02-20T19:01:54Z">2022-02-20 19:01</time> | |
| </div> | |
| <div class='body'> | |
| <p>Huzzah!</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-XZoM"> | |
| <div class='header'> | |
| <span class='author'>@jonathanstowe</span> commented at <time datetime="2022-02-20T21:10:53Z">2022-02-20 21:10</time> | |
| </div> | |
| <div class='body'> | |
| <p>First up, in principle, I'm generally in favour of moving to a single better ecosystem backend, <strong>but</strong>:</p> | |
| <blockquote> | |
| <p>Any modules not having a more recent version in the zef ecosystem, should have issues created after July 1st, 2023 (6 months before the sunsetting date).</p> | |
| </blockquote> | |
| <p>Probably a typo but this is not consistent with:</p> | |
| <blockquote> | |
| <p>support for these ecosystems will be dropped on Jan 1st, 2023</p> | |
| </blockquote> | |
| <p>But assuming that the year is wrong in the former I'm not convinced that four months is sufficient before nagging people (at least myself.)</p> | |
| <p>I have quite a few modules on CPAN, I'm planning on moving them all in one go when I'm ready to do so: I need to adjust my own tools and workflow to accommodate this.</p> | |
| <p>I really would rather not get eighty or ninety issues on my modules however well meaning. If nothing else it's a waste of two people's time.</p> | |
| <p>There are also a number of third party modules where I am the de-facto maintainer, these are going to have to be dealt with on a case by case basis.</p> | |
| <p>So :+1: to the general principle of shifting the ecosystem but :-1: to encouraging putting issues on transgressing authors on an arbitrary deadline.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-XZoc"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-02-20T21:11:00Z">2022-02-20 21:11</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Any modules not having a more recent version in the zef ecosystem, should have issues created after July 1st, <strong>2023 (6 months before the sunsetting date)</strong>.</p> | |
| </blockquote> | |
| <p>Typo?</p> | |
| <blockquote> | |
| <p>CPAN PRO the <em>author</em> is verified on upload of a distribution</p> | |
| <p>CPAN CON the <em>authority</em> of the module is not checked, so no guarantee that the uploader is responsible</p> | |
| </blockquote> | |
| <p>Ooc, does <em>author</em> mean the uploader's login id (PAUSE id), <em>authority</em> mean the <code>:auth<...></code> tag, and is the missing guarantee that the uploaded module's <code>:auth<...></code> matches the uploader's login id?</p> | |
| <blockquote> | |
| <p>zef (fez)</p> | |
| </blockquote> | |
| <pre><code>publishing-foo> fez foo = author's 💻 🢂 ☁️ | |
| installing-foo> zef foo = ☁️ 🢂 installer's 💻 | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-XdY2"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-02-20T22:42:48Z">2022-02-20 22:42</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I really would rather not get eighty or ninety issues on my modules however well meaning. If nothing else it's a waste of two people's time.</p> | |
| </blockquote> | |
| <p>Nothing actually urges a maintainer to migrate immediately. If a module is not getting its version updated it could remain as it is and be available via REA. But as soon as there is a need to release a new version, this could be used as an opportunity to migrate as well. A lazy sequence, you know... :)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-XeKQ"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-02-20T23:01:42Z">2022-02-20 23:01</time> | |
| </div> | |
| <div class='body'> | |
| <p>@raiph</p> | |
| <blockquote> | |
| <p>Ooc, does author mean the uploader's login id (PAUSE id), authority mean the :auth<...> tag, and is the missing guarantee that the uploaded module's :auth<...> matches the uploader's login id</p> | |
| </blockquote> | |
| <p>Indeed</p> | |
| <p>@jonathanstowe</p> | |
| <blockquote> | |
| <p>I really would rather not get eighty or ninety issues on my modules however well meaning. If nothing else it's a waste of two people's time.</p> | |
| </blockquote> | |
| <p>Point taken. I guess it would be best if we could create one issue per module author. Also, please note that even after sunsetting <code>p6c</code> and <code>cpan</code>, your modules would continue to be available through the REA. It's just that when you need to update a module, it would have to move to the zef ecosystem in order to be "seen". So if modules are stable and not in need of an update, you wouldn't have to do anything.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-Xii8"> | |
| <div class='header'> | |
| <span class='author'>@jonathanstowe</span> commented at <time datetime="2022-02-21T00:23:02Z">2022-02-21 00:23</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm not proposing that I won't have them all migrated by January, just that I may not have <em>any</em> migrated by July :rofl: The overhead of doing them piecemeal doesn't warrant doing a new release to the new ecosystem in isolation if I haven't adapted my own tools, so they'll all be done at once.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-c08s"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-02-22T12:25:00Z">2022-02-22 12:25</time> | |
| </div> | |
| <div class='body'> | |
| <p>@jonathanstowe re: updating your tools. <code>fez upload</code> in the module directory, claims to be enough to upload to the zef ecosystem. Which would mean you'd only need to up the <code>version</code> and change the <code>auth</code> in the <code>META6.json</code>? Not trying to push you, you thought I'd mention it since we all can get set in our ways and not realize there are maybe other, possibly better ways to things nowadays. FWIW, I also like <code>App::Mi6</code> a lot :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-76bZ"> | |
| <div class='header'> | |
| <span class='author'>@cognominal</span> commented at <time datetime="2022-03-01T21:48:22Z">2022-03-01 21:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>I am not competent to give an opinion on the modes of module distribution…</p> | |
| <h2>No privilege or setup to access modules</h2> | |
| <p>… except that care must be made no privilege should be needed to access them. I thought I had filed an issue about that. But where ?</p> | |
| <p>Here, not by me : | |
| https://github.com/pierre-vigier/Perl6-Data-MessagePack/issues/15</p> | |
| <p>Time to learn how to use the vscode notebook extension to search issues across git repos.</p> | |
| <p>https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-github-issue-notebooks</p> | |
| <h2>User point of view</h2> | |
| <p>I propose to also see things from the user point of view.</p> | |
| <p>in https://modules.raku.org/ there is no way to see which modules are part of rakudo star and no way to vote a module for inclusion. Or do I miss something ?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_KZf4"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2022-03-05T05:09:12Z">2022-03-05 05:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>Probably out of scope of this issue, but I have a question regarding checking the integrity of uploaded/installed modules. Maybe @ugexe and @tony-o can answer that. Is there any package checking being done at the moment or is it possible? Like checking checksums/hashes. The goal of my question is can we verify that the package fez generates is the same as the package zef installs, in other words, can zef know the package hasn't been compromised on the server which hosts the package?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5BnEiA"> | |
| <div class='header'> | |
| <span class='author'>@melezhik</span> commented at <time datetime="2022-04-16T21:58:36Z">2022-04-16 21:58</time> | |
| </div> | |
| <div class='body'> | |
| <p>Just my 2 cents, maybe off-topic, I could probably add a simple check to SparkyCI to verify that <code>Meta6.json</code> has <code>"auth": "zef:author"</code> ...</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ChF6D"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2022-05-03T10:59:17Z">2022-05-03 10:59</time> | |
| </div> | |
| <div class='body'> | |
| <p>@lizmat This issue is solved and can be closed, correct?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ChGGL"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-05-03T11:00:30Z">2022-05-03 11:00</time> | |
| </div> | |
| <div class='body'> | |
| <p>Indeed :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5KE_28"> | |
| <div class='header'> | |
| <span class='author'>@tony-o</span> commented at <time datetime="2022-09-11T00:12:28Z">2022-09-11 00:12</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Probably out of scope of this issue, but I have a question regarding checking the integrity of uploaded/installed modules. Maybe @ugexe and @tony-o can answer that. Is there any package checking being done at the moment or is it possible? Like checking checksums/hashes. The goal of my question is can we verify that the package fez generates is the same as the package zef installs, in other words, can zef know the package hasn't been compromised on the server which hosts the package?</p> | |
| </blockquote> | |
| <p>The name of the file is the md5 sum of the dist at the time of upload. As of now, there isn't an independent way of verifying the integrity unless it's built into the dist somehow</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="315"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/315"><span class='number'>315</span></a> - <span class='title'>Make grammars called from grammars more intuitive</span></div> | |
| <div class='author'>[open]<span class='author'>@alabamenhu</span> opend this issue at <time datetime="2022-02-14T23:10:31Z">2022-02-14 23:10</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>There should be an easy way for one grammar to call another grammar.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>Lately we've seen a number of people playing around a lot more with how one grammar can interact with another (for instance <a href="https://www.reddit.com/r/rakulang/comments/sex4qa/comment/humrie1/?utm_source=share&utm_medium=web2x&context=3">here</a> and <a href="http://clarkema.org/lab/2022/2022-02-09-raku-multiple-grammars/">here</a>.</p> | |
| <p>As Raku adoption increases, we are no doubt likely to see many others attempting to do similar mixing and matching of grammars. Unfortunately, there are a number of different drawbacks with the different ways that this can be done today (including potential for namespace overlaps and seams in the match process), besides being maybe not the most intuitive thing.</p> | |
| <p>Therefore, I'd propose that we support an easy-to-read and easy-to-access way for one grammar to integrate another grammar into itself.</p> | |
| <p>(Note: I would not imagine that this is something that would even be looked at until <code>6.f</code>)</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c49-D3t"> | |
| <div class='header'> | |
| <span class='author'>@alabamenhu</span> commented at <time datetime="2022-02-14T23:28:32Z">2022-02-14 23:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>For reference, Rakudo internally handles the switch by way of a method called <a href="https://github.com/rakudo/rakudo/blob/b5f49ace1dc6d097704ef567af3be84bb3159a78/src/Perl6/Grammar.nqp#L254"><code>nibble</code></a>. But that's an internal method not intended for use by regular coders. It has the advantage (over the technique I describe <a href="https://www.reddit.com/r/rakulang/comments/ssd1lf/comment/hwxjdo3/?utm_source=share&utm_medium=web2x&context=3">here</a>), however, that the full parse tree is maintained since it hands over the cursor directly to the next language.</p> | |
| <p>It would probably be most intuitive to users to be set up as a (pseudo)token, e.g., <code><foreign: Grammar, Actions></code>, but the naming would be a key issue. While I used foreign thinking about switching between different languages, a grammar might not necessarily be a language, and so a more general term would be better. Maybe <code>external</code> or <code>other</code>, or even just <code>grammar</code>. Anything chosen would have the (likely slim) possibility that a grammar in the wild already uses it.</p> | |
| <p>Alternatively, a different syntax could be provided, but I'm not sure what that would be.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="314"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/314"><span class='number'>314</span></a> - <span class='title'>Operator precedence/associativity API needed</span></div> | |
| <div class='author'>[open]<span class='author'>@codesections</span> opend this issue at <time datetime="2022-02-13T20:43:39Z">2022-02-13 20:43</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Rakudo currently exposes operator precedence and associativity info through Code's prec method. Being able to introspect into precedence and associativity is very helpful. However, @jnthn brought up some good reasons not to stabilize that API:</p> | |
| <blockquote> | |
| <p>There should be a way to introspect these things, but I'd not support specifying <code>prec</code>, as:</p> | |
| <pre><code>1. I don't think a hash is the right thing to return here. (It raises all kinds of questions. Like, | |
| can you mutate the hash to change the precedence? :-)) | |
| 2. It's a bit odd that getting the precedence level is `.prec<prec>`. We're using the word to mean | |
| everything related to precedence _and_ to the level. | |
| </code></pre> | |
| </blockquote> | |
| <p>See rakudo/rakudo#4776. Accordingly, I'm opening this PR to solicit people's views on what API we <em>should</em> stabilize. A few questions to get us started, (I'll post my own views on the below separately).</p> | |
| <p>Do we want to</p> | |
| <ul> | |
| <li>…expose this API on all Code or just operators?</li> | |
| <li>…include just precedence and associativity, or also other related values (e.g., <code>thunky</code>, <code>iffy</code>, <code>diffy</code>, <code>fiddly</code>)?</li> | |
| <li>…commit to/spec an <em>exhaustive</em> list of properties or a current (but extensible) set?</li> | |
| <li>…expose the internal values or a human-readable version? Or both? (e.g., for precedence, <code>t@=</code> or <code>tighter than &infix:<+></code>)</li> | |
| <li>…expose (and thus spec) the names of various precedence categories used internally (the ones currently listed in the <a href="https://docs.raku.org/language/operators#Operator_precedence">operator precedence</a> table)? This might make the example above <code>tighter than additive</code> instead.</li> | |
| <li>…have this be a read-only API or do we want to use it for mutation as well? If so, just at compile time, or also at runtime (what would that mean)?</li> | |
| <li>…deprecate the existing .prec API (though maybe that's a Rakudo question rather than one for this repo)</li> | |
| </ul> | |
| <p>Additional thoughts are very welcome :)</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c495P-0"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-02-13T20:47:07Z">2022-02-13 20:47</time> | |
| </div> | |
| <div class='body'> | |
| <p>@jnthn finished the comment I quoted above by saying:</p> | |
| <blockquote> | |
| <p>A further design issue in Rakudo today is that operator precedence properties are duplicated in multiple places: in the grammar and then also for introspection via <code>.prec</code>. That's not really ideal. In the <code>rakuast</code> branch (work thanks to @lizmat) there is an <code>OperatorProperties</code> object, along with some shortcut methods that delegate to it. I think that would be a better API to spec.</p> | |
| </blockquote> | |
| <p>I haven't familiarized myself with the <code>rakuast</code> branch yet, but I took a look at <a href="https://github.com/rakudo/rakudo/blob/rakuast/src/Raku/ast/operator-properties.rakumod">operator-properties.rakumod</a> and I agree that it looks like a great foundation for a spec-ed API.</p> | |
| <p>Here are my own views on the questions I posed above (though I'm open to persuasion on any, of course).</p> | |
| <blockquote> | |
| <p>expose this API on all Code or just operators?</p> | |
| </blockquote> | |
| <p>"all Code objects". Non-operators may all have the same precedence/etc., but it seems nice to be able to see what that is anyway. However (warning: bikeshedding) that raises the question of whether "OperatorProperties" is really the right name for these objects…</p> | |
| <blockquote> | |
| <p>include just precedence and associativity, or also other related values (e.g., <code>thunky</code>, <code>iffy</code>, <code>diffy</code>, <code>fiddly</code>)?</p> | |
| </blockquote> | |
| <p>I lean towards "all", but I'm not sure I entirely know the effect of all of those properties. (But maybe that's part of <em>why</em> I lean towards "all" – once they're spec'ed, we can doc them).</p> | |
| <blockquote> | |
| <p>commit to/spec an <em>exhaustive</em> list of properties or a current (but extensible) set?</p> | |
| </blockquote> | |
| <p>"an extensible set", imo. I think we're currently using "associativity" to capture something about arity (see rakudo/rakudo#4779) and I think the best solution to that is to add a new operator property. Even assuming that's added before we spec this API, I wouldn't want to commit to us having thought of everything.</p> | |
| <blockquote> | |
| <p>expose the internal values or a human-readable version? Or both? (e.g., for precedence, <code>t@=</code> or <code>tighter than &infix:<+></code>)</p> | |
| </blockquote> | |
| <p>My preference would be for "both", but via some sort of lightweight wrapper class that could .gist to one value and .raku to another.</p> | |
| <blockquote> | |
| <p>expose (and thus spec) the names of various precedence categories used internally (the ones currently listed in the <a href="https://docs.raku.org/language/operators#Operator_precedence">operator precedence</a> table)? This might make the example above <code>tighter than additive</code> instead.</p> | |
| </blockquote> | |
| <p>I'd like to see these categories spec'ed regardless, and this seems like a good chance to do so. Right now, they're in an awkward grey area: they're mentioned in the Synopses and in the docs, but not in Roast and they're not <em>really</em> documented (just mentioned on the operators page).</p> | |
| <blockquote> | |
| <p>have this be a read-only API or do we want to use it for mutation as well? If so, just at compile time, or also at runtime (what would that mean)?</p> | |
| </blockquote> | |
| <p>I'd say "read-only", but handle compile-time OperatorProperty modification happen by creating a new OperatorProperty (or whatever we call it) object. I don't think runtime mutation of OperatorProperty objects makes sense (though of course there are various ways to nest a compile time inside runtime, which would have much the same effect).</p> | |
| <blockquote> | |
| <p>deprecate the existing .prec API (though maybe that's a Rakudo question rather than one for this repo)</p> | |
| </blockquote> | |
| <p>We can probably deprecate it unless it's needed for some reason I'm not aware of.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="313"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/313"><span class='number'>313</span></a> - <span class='title'>"Tight or" precedence level of //, min, max operators</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2022-02-10T00:01:24Z">2022-02-10 00:01</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>"Tight or" has lower precedence than the "chaining infix" operators. This makes sense in the case of operators like || and ^^ that actually are logic operators in the first place - much less so for //, min and max that are just similar to the technicalities of ||.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>Hello, | |
| after the short summary, I would like to elaborate on my point more... | |
| First off, I would like to point out the conceptional inconsistency in the <a href="https://docs.raku.org/language/operators">docs</a>: the "chaining infix" operators share a more important thing than the technicalities of chaining - they describe relations and hence they return boolean values. The name "tight or", on the other hand, tries to capture this property of the operators in the group, namely that they appear in logical expressions where they have the properties of a logical "or". | |
| The thing is, 3 relations out of 5 in that group aren't really or-like, moreover it doesn't make much sense to use them in logical expressions. | |
| It caught me while using R// but it doesn't take that much trickery to see this behavior is unintuitive, take for example: | |
| 3 < 1 min 4 # False - so far so good, right? | |
| 3 < 5 min 1 # 1 - WAT? | |
| 3 < 5 min 2 # True - umm... "would I lie to you, baby, would I lie to you" | |
| I don't think anyone would ever want this behavior as the "default". It reminds me of Pascal with "and" and "or" being higher precedence than comparing operators themselves - but Pascal came with the excuse that there were like 4 precedence levels altogether and on some level it was elegant to draw the parallel between * and "and", + and "or". In Raku, looking at that table, there might be around 20 precedence levels so I don't think this can serve as a basis to slapping predominantly logic-operators to predominantly value-operators. | |
| I personally think their reasonable place would be around the junction operators and the additive operators; anyways, this isn't the time and place to propose a new definition. At the moment, I just want to get confirmation that 1. this behavior is indeed unnecessarily unintuitive and generally useless (counter-arguments if there are) and 2. whether there are technical constraints behind the scenes that force the devs and the users into this compromise. | |
| Any feedback is welcome. :) | |
| M. Polgár</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c49qMk-"> | |
| <div class='header'> | |
| <span class='author'>@pmichaud</span> commented at <time datetime="2022-02-10T04:05:54Z">2022-02-10 04:05</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't know that I agree that "tight or" is intended to indicate that all operators in the group are to be "or-like". The level names in the original incarnation were primarily just shorthand for referring to operators at that level, they weren't intended to be descriptive or restrictive in the actual operators that could appear at that level.</p> | |
| <p>What's really being captured at this precedence level is that the "min" and "max" operators have list associativity, as opposed to right or left associativity. And that list associativity is likely part of the reason why they're lower precedence, and should be kept away from the junctive or additive operators. Also, I think "min" and "max" belong in the same general vicinity as "cmp", upon which they are based. Finally, as list associative, they are perhaps a bit more like "list infix" operators that appear even farther down the list.</p> | |
| <p>In terms of "3 < 5 min 1" giving 1, that feels like a valid result to me. "3 < 5" gives True, and "True min 1" can be either "True" or "1" since the two operands compare the same. (Try "True cmp 1" ==> # Same .)</p> | |
| <p>So, "3 < 1 min 4" gives False because "False cmp 4" is Less, "3 < 5 min 1" gives 1 because "True cmp 1" is Same, and "3 < 5 min 2" gives True because "True cmp 2" gives Less. (False numerifies to 0 and True numerifies to 1 for these comparisons.)</p> | |
| <p>Pm</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c49rNX6"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-02-10T10:16:08Z">2022-02-10 10:16</time> | |
| </div> | |
| <div class='body'> | |
| <p>Hello, | |
| thanks for the quick feedback. To be honest, I can't say I feel there were convincing points made.</p> | |
| <blockquote> | |
| <p>In terms of "3 < 5 min 1" giving 1, that feels like a valid result to me. (...)</p> | |
| </blockquote> | |
| <p>Here you are describing how the expression is evaluated. <em>I know that, that's the cornerstone of the whole issue.</em> The behavior is <strong>valid</strong> according to the specs - my argument is that this behavior is <strong>horrible to look at and nobody would really want it</strong>.</p> | |
| <blockquote> | |
| <p>I don't know that I agree that "tight or" is intended to indicate that all operators in the group are to be "or-like". The level names in the original incarnation were primarily just shorthand for referring to operators at that level, they weren't intended to be descriptive or restrictive in the actual operators that could appear at that level.</p> | |
| </blockquote> | |
| <p>This is a doc issue if anything; I think the names should be descriptive if they exist in the first place. They should give us some hint why actual logic operators like || and ^^ should have the same precedence as // or max. If the reason for that is the list associativity, the name should capture at least that.</p> | |
| <p>Good that you mentioned "cmp" a couple of times - <strong>"cmp" actually has higher precedence than the "chaining infix operators</strong>. I for one would be pleased if these operators happened to have the same precedence as "cmp". :)</p> | |
| <blockquote> | |
| <p>What's really being captured at this precedence level is that the "min" and "max" operators have list associativity, as opposed to right or left associativity. And that list associativity is likely part of the reason why they're lower precedence, and should be kept away from the junctive or additive operators.</p> | |
| </blockquote> | |
| <p>I would focus on this part as this contains the most tangible evidence.</p> | |
| <ol> | |
| <li>First, I don't know if what you said applies to // as well - I think // would make zero sense to be list associative.</li> | |
| <li>Actually, I see no particularly good reason for min and max to be list associative, either... the described operations themselves are virtually <em>associative</em>, similarly to * and +. They could have any associativity and have the same output. Therefore, unlike Z, it's a mere technicality that they have list associativity.</li> | |
| <li>To elaborate on this point further: I would have thought an advantage of list-associativity could be in this case to give more predictable results regardless the order of operands. I was wrong. min isn't even commutative: <code>False min 0</code> and <code>0 min False</code> aren't the same. However, <code>0 min 2 min False # 0</code> also doesn't have the same result as <code>0 min False # False</code>. This also feels like unnecessarily unintuitive behavior to me and it could instantly be fixed by switching to either left- or right-associativity; that would still be easier to comprehend.</li> | |
| </ol> | |
| <blockquote> | |
| <p>Finally, as list associative, they are perhaps a bit more like "list infix" operators that appear even farther down the list.</p> | |
| </blockquote> | |
| <p>Honestly, now that you mention it, "list infix" operators also have a precedence that's rarely ever useful! X and Z usually cry for parentheses. It probably all boils down to the very low precedence of the comma operator - an operator that not even the .raku output uses without the parens... So to me this seems like justifying a bad decision with another (more fundamental) bad decision. Let's say we accepted that anything involving lists will have useless default precedence and we better use parens - why should it follow that we need to extend that to //, min and max as well?</p> | |
| <p>And anyway, touching the comma operator or the "list infix" operators would surely break everything around, that issue is far out of reach. Let's just focus on the mentioned 3 operators. Does list associativity really affect their precedence? Is it even worth having? Are there other, either technical or usage reasons?</p> | |
| <p>The feedbacks are obviously still more than welcome. :)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4909mC"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-02-12T16:38:22Z">2022-02-12 16:38</time> | |
| </div> | |
| <div class='body'> | |
| <p>I've been mulling this over since you opened the issue – I think you raise a lot of good points. Despite my mulling, I'm not sure I really reached a coherent conclusion, but I'll post my thoughts here in the hope that they're helpful – apologies in advance if this isn't as organized as I usually aim to be.</p> | |
| <h5>1. These sorts of precedence calls are especially subjective</h5> | |
| <p>By choosing to have operator precedence at all (unlike, say, a Lisp or an APL), Raku is already wading into pretty subjective waters. It's all going to turn on user expectations – which will, in turn, depend on what other programming languages/math systems that user has experience with. This is doubly true for operators like <code>min</code> or <code>//</code>, which aren't present in most programming languages, because there's less likely to be a "consensus" view of the correct precedence. (Many languages have <code>min</code> <em>functions</em>, but I can't think of one with a <code>min</code> operator.)</p> | |
| <p>That said, I personally agree with you that <code>3 < 5 min 2</code> returning <code>True</code> is a bit of a WAT. I notice, however, that I'd actually expect <code>5 min 2 < 3</code> return <code>True</code>, so my personal (subjective) intuitive expectation seems to be that <code>min</code> and <code><</code> are on the same precedence level and are left-associative. I wonder if you share that intuitive expectation? (This expectation <strong>can't</strong> actually be true, because <code><</code> has chaining associativity and thus can't also be left-associative.)</p> | |
| <p>I'm not as sure if I share your intuitions for <code>//</code> and <code>R//</code>. I definitely recall needing to use parenthesis with <code>R//</code> a few times when I thought I really shouldn't need to – but I can't come up with specific examples. I'd be interested to hear the context that first brought this to your attention.</p> | |
| <h5>2. min and max are a bit odd</h5> | |
| <p>Unlike most operators, <code>min</code> and <code>max</code> share their name with a Sub. As a result, the following is code is possible:</p> | |
| <pre><code class="language-raku">say 3 < 5 min 2 # OUTPUT «True» (your example) | |
| say 3 < 5 [&min] 2 # OUTPUT: «False» | |
| say 3 < min 5, 2 # OUTPUT: «False» | |
| </code></pre> | |
| <p>The second line is interesting, but not something I'd use/expect to see. But the third is pretty practical, and one I <em>would</em> expect to see. IMO, this removes a fair bit of the urgency from this issue, since there's already a way to express <code>the minimum of 5 and 2</code> without needing to parenthesize. That doesn't remove the WAT, but makes it less of a big deal.</p> | |
| <h5>3. List associativity still matters for <code>min</code> and <code>max</code></h5> | |
| <p>You said that:</p> | |
| <blockquote> | |
| <p>the described operations themselves are virtually associative, similarly to <code>*</code> and <code>+</code>. They could have any associativity and have the same output.</p> | |
| </blockquote> | |
| <p>I agree, but that "virtually" can matter quite a bit – at least in the edge case of multiple ops with the same precedence level. Consider the expression <code>5 min 2 max 10</code>: with left associativity, we'd get <code>10</code>; with right, <code>5</code>; with list (what we actually have) we get <code>Only identical operators may be list associative; since 'min' and 'max' differ, they are non-associative and you need to clarify with parentheses</code>.</p> | |
| <p>(I'm actually not sure whether this means that <code>min</code> and <code>max</code> are not <a href="https://en.wikipedia.org/wiki/Associative_property#Notation_for_non-associative_operations">mathematically associative</a>. Mathematical associativity is always talked about in the context of a single operator – how does it treat operators with tied precedence?)</p> | |
| <p>You also said:</p> | |
| <blockquote> | |
| <p>I would have thought an advantage of list-associativity could be in this case to give more predictable results regardless the order of operands. I was wrong. min isn't even commutative: <code>False min 0</code> and <code>0 min False</code> aren't the same. However, <code>0 min 2 min False # 0</code> also doesn't have the same result as <code>0 min False # False</code>.</p> | |
| </blockquote> | |
| <p>I agree that <code>min</code> isn't commutative and that list associativity should give more predictable results. However, list associativity <em>should</em> mean that <code>0 min False</code> is the same as <code>min(0, False)</code> – but your last example shows that it isn't. I'm pretty sure that's just a Rakudo bug and I'll try to submit a PR.</p> | |
| <h5>4. Regarding docs issues</h5> | |
| <p>I generally agree with you that "the names [used in the docs] should be descriptive if they exist in the first place" and that the docs could be a bit clearer on that front. This issue inspired me to put together a docs PR (Raku/doc#4031) that took a first step along those lines (and also got sidetracked into some points that caused me to discover a few related Rakudo issues (rakudo/rakudo#4779 and rakudo/rakudo#4780)). But I'm sure there's more we could do to clarify this area.</p> | |
| <hr /> | |
| <p>I was kind of hoping I'd work my way to a conclusion, but no such luck. I'm not sure where I come down on the overall issue, but it is a good one to think about (and has lead to discovering/starting to fix some bugs, so it's already been productive!).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c493020"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-02-13T11:42:23Z">2022-02-13 11:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>Hello, | |
| even if there is no conclusion, I'm happy that "we are working"; I think that thinking about these things is always beneficial some ways. Also... I think I have seen you under another issue I opened but only now do I recognize you as the author of the "105 C++ Algorithms in 1 line of Raku" video which I keep going back to... so thank you for that. :) It's my honor that pioneers of this community join these discussions.</p> | |
| <blockquote> | |
| <p>I notice, however, that I'd actually expect 5 min 2 < 3 return True, so my personal (subjective) intuitive expectation seems to be that min and < are on the same precedence level and are left-associative.</p> | |
| </blockquote> | |
| <p>I think you got the conclusion "backwards" here because the same result would follow from "min" having straight-up higher precedence than "<" (which my intuition would assume).</p> | |
| <blockquote> | |
| <p>I'm not as sure if I share your intuitions for // and R//. I definitely recall needing to use parenthesis with R// a few times when I thought I really shouldn't need to – but I can't come up with specific examples. I'd be interested to hear the context that first brought this to your attention.</p> | |
| </blockquote> | |
| <p>I wanted a one-liner without parentheses and eventually this not particularly useful precedence of R// ruined it... <code>+@common-children <= (-1 R// @prev-filter.first: *.so, :end, :k)</code> so yes, if the @prev-filter contains a True value that couldn't be zipped to @common-children, that will need a special treatment.</p> | |
| <blockquote> | |
| <p>IMO, this removes a fair bit of the urgency from this issue, since there's already a way to express the minimum of 5 and 2 without needing to parenthesize. That doesn't remove the WAT, but makes it less of a big deal.</p> | |
| </blockquote> | |
| <p>Indeed; I was mostly caught by // and then I looked it up and "extended" it. In that group, || and ^^ are "logical operators" and legitimately share the precedence, the rest I don't think so. I used examples with min because they are easier to construct and I think the point still stands for them.</p> | |
| <blockquote> | |
| <p>Consider the expression 5 min 2 max 10: with left associativity, we'd get 10; with right, 5; with list (what we actually have) we get Only identical operators may be list associative; since 'min' and 'max' differ, they are non-associative and you need to clarify with parentheses.</p> | |
| </blockquote> | |
| <p>I haven't thought about that, fair point. Although as we can see the advantage of list associativity is not some reasonable output but catching it as something unparseable. I think I would prefer this behavior for this expression regardless associativity but this seems like a technicality that shouldn't be tied with associativity in the strictest sense. Also, I still think that <strong>even for this expression both right and left associativity would result in an acceptable (although less desirable) output, not straight-up a WAT</strong>.</p> | |
| <blockquote> | |
| <p>However, list associativity should mean that 0 min False is the same as min(0, False) – but your last example shows that it isn't. I'm pretty sure that's just a Rakudo bug and I'll try to submit a PR.</p> | |
| </blockquote> | |
| <p>Oh that's good to know... this is how sidenotes can turn into useful evidence. :D One more reason why these discussions are useful.<br /> | |
| Similarly, I'm happy to see that the issue kind of lead to doc improvements, although it feels a bit weird to create work for others this way... although I don't feel competent enough to make changes like this on my own. Some day, hopefully. :)</p> | |
| <p>Also not a conclusion here but... I'm still bugged by the remark about list infix operators and the whole list business... having list construction as a basic operator rather than special syntax seems very elegant but I wonder why list-related operators must have such low precedences. Actually, I often feel positionals were always meant to be a parallel universe within Raku for some reason. List assignment as a separate thing, all the peculiarities of the % and @ sigils (including the weird destructuring I opened an issue for), hard to get it working with types... It would be good to know about decisions of this kind, whether it's operator precedence, or the special assignment type, or the difficulty of <code>sub fun(Int @nums) {}</code> because for me it still often feels like these things work differently from all languages I know just for the sake of being different... and then it escalates to other decisions in order to be consistent and we just can't see why it has to be like that in the first place.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c494Wvq"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-02-13T15:10:01Z">2022-02-13 15:10</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>only now do I recognize you as the author of the "105 C++ Algorithms in 1 line of Raku" video</p> | |
| </blockquote> | |
| <p>I'm glad you liked the video and thanks for the kind words :) But I'm hardly a "pioneer", just someone who discovered Raku a few years ago and dove in (with a lot of help). The other participant in this thread, on the other hand, really <em>is</em> a pioneer in the Raku community: I'm not exactly sure when @pmichaud first got involved with Raku (then Perl 6), but it was at least ~15 years before I did. And <em>that</em> was the time that the true pioneering work was being done – the work that <em>really</em> laid the foundation for Raku as it exists today.</p> | |
| <blockquote> | |
| <p>Indeed; I was mostly caught by <code>//</code> and then I looked it up and "extended" it. In that group, <code>||</code> and <code>^^</code> are "logical operators" and legitimately share the precedence, the rest I don't think so.</p> | |
| </blockquote> | |
| <p>Hmm, I'm not sure I agree. I definitely view <code>//</code> as a logical operator and, though I haven't really thought of <code>min</code> and <code>max</code> as logical operators, I'm starting to think that they might be (at least in infix form). Consider the following code (which I'm imagining as code for reviewing something on a scale from 0 stars to 5 stars):</p> | |
| <pre><code class="language-raku">$rating || 3; | |
| $rating // 3; | |
| $rating max 0; | |
| $rating min 5; | |
| </code></pre> | |
| <p>In each expression, we check whether the LHS passes a predicate; if it does, we return the LHS; if not, we return the RHS. That is, we could achieve the same thing with:</p> | |
| <pre><code class="language-raku">$rating.so ?? $rating !! 3; | |
| $rating.defined ?? $rating !! 3; | |
| $rating > 0 ?? $rating !! 0; | |
| $rating < 5 ?? $rating !! 5; | |
| </code></pre> | |
| <p>They're not logical operators in the <em>strictest</em> sense of the term because they don't return a boolean value. But <code>&&</code> and <code>||</code> don't either, and I have no hesitation in calling them logical ops.</p> | |
| <p>(One distinction we could draw is whether they short-circuit: <code>||</code> and <code>//</code> both do, but <code>min</code> and <code>max</code> don't).</p> | |
| <p>[Edit: I'm also thinking about the points you raised in your "not a conclusion here but..." paragraph, and will comment separately after a bit more thought.]</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c494Yk5"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-02-13T15:22:53Z">2022-02-13 15:22</time> | |
| </div> | |
| <div class='body'> | |
| <p>"deleted" (because this comment was unhelpful)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4944g7"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-02-13T18:26:51Z">2022-02-13 18:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>Hi @raiph , | |
| I hope you to engage with some of my points because this doesn't seem particularly useful or related to anything. I said that I wanted to get that line right without needing parentheses - which failed on a not particularly useful or meaningful-looking precedence rule on R//. Not like it should matter at all as it is really just trivia.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c495Ibf"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2022-02-13T19:54:14Z">2022-02-13 19:54</time> | |
| </div> | |
| <div class='body'> | |
| <p>"deleted" (because this comment was unkind)</p> | |
| <p>Sorry 2colours.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c495N7s"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-02-13T20:32:50Z">2022-02-13 20:32</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't think you should act as if it was impossible to add something meaningful to the discussion - and if your best idea was to nitpick about my example use-case that bears little value to the overall topic I tried to set up, maybe you have something to wonder about with your attitude here in the first place.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c495PL0"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-02-13T20:41:42Z">2022-02-13 20:41</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm sorry to see that this conversation took a turn and am locking it for now to give everyone a chance to take a breath. @2colours, you've had some very interesting thoughts and seem like you'd add a lot to our community. That said, we try to be a pretty friendly group and your criticism of a good-faith comment wasn't in keeping with that. I can see why @raiph's first response was "ouch".</p> | |
| <p>@raiph, you we one of the people who welcomed me into the Raku community. If I'd been greeted with comments like the rest of your comment, I'm not sure I would have felt all that welcome or gotten involved the way I did.</p> | |
| <p>Both of you seem like good folks who got a bit frustrated, so lets all take a breath.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4-NDIU"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-02-17T23:20:36Z">2022-02-17 23:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>Well, I actually wanted to also react to @codesections 's message that I only saw afterwards but that opportunity came much later apparently... By the way, certain things don't depend on the number of "breaths taken"; like, if we are trying to put effort into a discussion, it's not very elegant at best to interrupt with a Stackoverflow-style comment mostly about the stylistics of an insignificant detail. :\ So I'm not so sure how to feel about self-proclaimed friendliness and good-faith.</p> | |
| <blockquote> | |
| <p>I'm not exactly sure when @pmichaud first got involved with Raku (then Perl 6), but it was at least ~15 years before I did. And that was the time that the true pioneering work was being done – the work that really laid the foundation for Raku as it exists today.</p> | |
| </blockquote> | |
| <p>Fair enough - got to give credit to those who did the main work without any big scene around it. (Also, I don't even know who I would recognize on a forum from those people I know about in the first place so it's not a very good measure. :) ) But at the end of the day, it's always like this: the appeals are more "attractive" in the literal sense, and I definitely wouldn't overlook the importance of "PR activity" even for programming.</p> | |
| <blockquote> | |
| <p>In each expression, we check whether the LHS passes a predicate; if it does, we return the LHS; if not, we return the RHS.</p> | |
| </blockquote> | |
| <p>I know what you mean and I kind of tried to imply it in the issue opener: "much less so for //, min and max that are just <em>similar to the technicalities of ||</em>." I think this is a "term mismatch" we are dealing with.<br /> | |
| When I say "logical operator", I mean it in a near-strictest sense: it acts upon a logical value, enforcing boolean context. The attribute I quoted from you, I would rather call it "selector operator", for example. Given these quasi-definitions, I would say that ^^ and || as logical operators are based on abstractions that makes them selector operators as well (the semantics of ^^ is also interesting by the way; one-way exclusivity rather than a binary xor relation).<br /> | |
| While // and possibly even min and max are also based on this abstraction, they have no particular use for boolean values - this is especially true for //.<br /> | |
| I'm pretty sure <code>$a == $b // $default</code> will never do anything useful - actually I can't see it explicitly stated that $a == $b always returns True or False unless there is a Failure but I think this is implied; in this case, this will always evaluate to the True or False value of the equality.</p> | |
| <p>I think, as a principle, the precedence of an operator should strongly take reasonable usage into account. You are right that there are many subjective questions here but this example with // wasn't really subjective: if you want to set a default value on the right side of a comparison (==, eq, < and the likes), you will need the parens, otherwise you end up with the result of the comparison, no matter the right handside of //. I think this (and the enforced context of an operator in general) is much more important to the user when creating an expression than underlying abstractions like what I called "selector operator".</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="312"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/312"><span class='number'>312</span></a> - <span class='title'>Wrong behavior is specced for classify method</span></div> | |
| <div class='author'>[closed]<span class='author'>@vrurg</span> opend this issue at <time datetime="2022-02-08T01:08:37Z">2022-02-08 01:08</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>rakudo/rakudo#2814 describes classify behavior which is considered weird, to say the least. The produced output is highly confusing, if not totally wrong. For <code><a b c d e f>.classify( * eq 'a'|'c'|'f' )</code> one would expect <code>'a'</code> to be classified as <em>True</em>, but it also appears in <em>False</em>. Same applies to <code>'c'</code> and <code>'f'</code>.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c49hNBJ"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-02-08T01:21:35Z">2022-02-08 01:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm proposing a solution where the method would classify over junctions, produced by the tester code, without collapsing them and autothreading. So, where <code>'a'</code> is encountered it would be classified as <code>any(True, False, False) => ['a']</code>. Together with #311, i.e. when <code>Junction</code> becomes a value object, the classification would produce correct classes for the same junctions. For example, if <code>'a'</code> is encountered more than once in the original list, there there will be single entry of <code>any(True, False, False) => ['a', 'a']</code>, instead of what happens with a non-value <code>Junction</code> which results in two classification entries for each individual junction instance produced by the tester: <code>any(True, False, False) => ['a'], any(True, False, False) => ['a']</code>.</p> | |
| <p>The biggest problem about the proposed behavior is the fact that the incorrect behavior is actually currently specced in <em>t/spec/S32-list/classify.t</em>.</p> | |
| <p>The second problem is that the proposed behavior would require the classification <code>Hash</code> to be parameterized with <code>Mu</code>-typed keys and this also breaks this test and <em>t/spec/S32-list/categorize.t</em>.</p> | |
| <p>The latter issue should be minor because <code>Mu</code>-typed keys actually rather extend the range of allowed values, than adds more restrictions. So, unless there is a Blin fallout, it should be doable. Moreover, it fixes <em>t/spec/S09-hashes/objecthash.t</em> where two tests are currently dying.</p> | |
| <p>It's not that simple with the first problem because it's would be a rather major change to 6.c spec. But my proposal would be the same: give it a try and see if any module in the ecosystem relies on the wrong behavior. If there is any then a decision is to be made about the fate of this change.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c49hNck"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-02-08T01:25:03Z">2022-02-08 01:25</time> | |
| </div> | |
| <div class='body'> | |
| <p>A code sample and outcome with my current implementation of #311 and this proposal together:</p> | |
| <pre><code class="language-raku"><a b a c a d e f e>.classify( * eq 'a'|'c'|'f' ).say; | |
| # {any(False, False, False) => [b d e e], any(False, True, False) => [c], any(False, False, True) => [f], any(True, False, False) => [a a a]} | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c49sso-"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-02-10T16:28:01Z">2022-02-10 16:28</time> | |
| </div> | |
| <div class='body'> | |
| <p>I agree that the current behavior is a problem and I <em>tentatively</em> agree with the proposed solution (pending Blin fallout/push back from others.)</p> | |
| <p>(A note for other readers: the Rakudo issue linked in the OP (rakudo/rakudo#2814) is more than just a description of the problem – it also contains discussions of other potential solutions and why they wouldn't be ideal. In particular, before reading that thread, I was inclined to think that &classify <em>should</em> collapse junctions, but the points raised in that thread changed my mind.)</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="311"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/311"><span class='number'>311</span></a> - <span class='title'>Make Junction a value object.</span></div> | |
| <div class='author'>[closed]<span class='author'>@vrurg</span> opend this issue at <time datetime="2022-02-08T01:00:30Z">2022-02-08 01:00</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Inspired by rakudo/rakudo#2814 and #297 (<a href="https://github.com/Raku/problem-solving/issues/297#issuecomment-962220387">this comment of mine</a> in particular).</p> | |
| <p>While playing with possible ways of resolving rakudo/rakudo#2814 I realized then when basically fixed, <code>classify</code> method creates single entry per each <code>Junction</code> instance, no matter some are actually the same. But it would really make big sense if <code>any(True, False)</code> and <code>any(True, False)</code>, or <code>one('a', 'b')</code> and <code>one('a', 'b')</code> were considered same values.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c49hKmM"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-02-08T01:02:18Z">2022-02-08 01:02</time> | |
| </div> | |
| <div class='body'> | |
| <p>It does make sense for <code>Junction</code> to be a value object because it is both immutable and it deconts its eigenstates. Test implementation doesn't seem to produce any spectest fallout.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c49somr"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2022-02-10T16:14:23Z">2022-02-10 16:14</time> | |
| </div> | |
| <div class='body'> | |
| <p>That all makes sense and the proposed solution LGTM.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c49ysIU"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2022-02-11T22:36:36Z">2022-02-11 22:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>fwiw, I don't see any downsides to the proposed change.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="309"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/309"><span class='number'>309</span></a> - <span class='title'>A Mechanism for Adding Hooks into CURI for Custom Installation Output</span></div> | |
| <div class='author'>[open]<span class='author'>@Xliff</span> opend this issue at <time datetime="2021-12-15T14:41:45Z">2021-12-15 14:41</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Since its start, Rakudo has relied well upon CURI (ala CompUnit::Repository::Installation) for its installation purposes, and it has served its purpose well. However, as Rakudo grows older and Raku just grows the software CURI is responsible for will only grow more complex, it is only expected that CURI, in its current state, will take longer to execute.</p> | |
| <p>Herein lies the problem. Here is a recent example of an recently performed install:</p> | |
| <pre><code>===> Searching for: LibXML | |
| ===> Updating fez mirror: https://360.zef.pm/ | |
| ===> Updated fez mirror: https://360.zef.pm/ | |
| ===> Updating cpan mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json | |
| ===> Updating p6c mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json | |
| ===> Updated p6c mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json | |
| ===> Updated cpan mirror: https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan1.json | |
| ===> Searching for missing dependencies: File::Temp, W3C::DOM:ver<0.0.2+>, XML | |
| ===> Searching for missing dependencies: File::Directory::Tree | |
| ===> Building: LibXML:ver<0.6.10>:auth<cpan:WARRINGD> | |
| ===> Building [OK] for LibXML:ver<0.6.10>:auth<cpan:WARRINGD> | |
| ===> Testing: File::Directory::Tree | |
| ===> Testing [OK] for File::Directory::Tree | |
| ===> Testing: File::Temp:ver<0.0.10>:auth<zef:rbt> | |
| ===> Testing [OK] for File::Temp:ver<0.0.10>:auth<zef:rbt> | |
| ===> Testing: W3C::DOM:ver<0.0.2>:auth<cpan:WARRINGD> | |
| ===> Testing [OK] for W3C::DOM:ver<0.0.2>:auth<cpan:WARRINGD> | |
| ===> Testing: XML:ver<0.3.1>:auth<github:raku-community-modules> | |
| ===> Testing [OK] for XML:ver<0.3.1>:auth<github:raku-community-modules> | |
| </code></pre> | |
| <p>[ long wait, here ... ]</p> | |
| <pre><code>===> Testing: LibXML:ver<0.6.10>:auth<cpan:WARRINGD> | |
| </code></pre> | |
| <p>[ long wait, here ... ]</p> | |
| <p>Where "long wait" means "anything over 2 minutes with no interaction with the user".</p> | |
| <p>As the Raku user-base grows, I expect this type of behavior will prove to be very daunting, and my fear is that <em>many of these users will abandon Raku, and do so quietly</em>.</p> | |
| <p>Suggestions like 'Use RAKUDO_MODULE_DEBUG' are not helpful, as they provide the user with <em>too much</em> information.</p> | |
| <p>The recent addition of the RAKUDO_PRECOMPILATION_PROGRESS environment variable is a step in the right direction, however I feel it remains too technical as a practical solution.</p> | |
| <p>What I would like to discuss is adding a mechanism, possibly triggered via META6.json to give the package maintainer a way to customize this output, so that users remain informed during the install process.</p> | |
| <p>Something as simple as a console-bar graph, or a by-line message showing which compunits have been tested or installed would be enough to satisfy this issue.</p> | |
| <p>Thank you in advance for your suggestions and comments.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c47TPaw"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-12-15T15:25:38Z">2021-12-15 15:25</time> | |
| </div> | |
| <div class='body'> | |
| <p>This is potentially a naive question, but to what extent is this a <code>CompUnit::Repository::Installation</code> issue versus a Zef issue?</p> | |
| <p>Running that same command with <code>zef -v</code> already produces a fairly reasonable (and, imo, non-overwhelming) amount of output. Even if we want to let package maintainers customize the default output via a setting in the META6.json file, I'd have thought that Zef could handle that. (We already have the concept of <a href="https://docs.raku.org/language/modules#index-entry-META6.json-META6.json">customary</a> fields – which aren't required/spec'd but that are used by standard tools – for the META6.json format.</p> | |
| <p>Am I missing a reason to address this issue at the <code>CompUnit::Repository::Installation</code> level instead of via Zef?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47TeTQ"> | |
| <div class='header'> | |
| <span class='author'>@Xliff</span> commented at <time datetime="2021-12-15T16:34:12Z">2021-12-15 16:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>@codesections - I've already had this discussion with ugexe. We both have agreed that this issue is best settled via CURI</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47Tezf"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-12-15T16:36:40Z">2021-12-15 16:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>That's totally fine. Out of curiosity, what makes it a better fit for CURI?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47TqQC"> | |
| <div class='header'> | |
| <span class='author'>@Xliff</span> commented at <time datetime="2021-12-15T17:31:04Z">2021-12-15 17:31</time> | |
| </div> | |
| <div class='body'> | |
| <p>@ugexe - I disagree. RAKUCO_PRECOMPILATION_PROGRESS is <em>not sufficient</em>. It can't be. It too does not know what the distributor wants to communicate to the user at install time. If this can be done without a hook into CURI, I'm all for it. Otherwise I don't see how this can be done without it.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47UC5z"> | |
| <div class='header'> | |
| <span class='author'>@Xliff</span> commented at <time datetime="2021-12-15T19:15:18Z">2021-12-15 19:15</time> | |
| </div> | |
| <div class='body'> | |
| <p>@ugexe,</p> | |
| <p>This is because you <em>still</em> underestimate what I am saying. It's not just <em>that</em> the user remains informed, it is <em>how</em>.</p> | |
| <p>Once again you take it upon yourself to redefine the issue.</p> | |
| <p><em>That question is not for you to answer</em>.</p> | |
| <p>It is for the person writing the package.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47UHp3"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2021-12-15T19:29:18Z">2021-12-15 19:29</time> | |
| </div> | |
| <div class='body'> | |
| <p>If I understand this issue correctly, what you are asking for is for a module to kind of plug into the installation process to output messages. If that's right, then the mechanism seems to be there already: BEGIN time code is executed during compilation, so also during precompilation. A <code>BEGIN note ...</code> will tell the user whatever you want.</p> | |
| <p>I have to say though that personally as a user I'd not expect to get told arbitrary things during installation and may even get annoyed by messages that are not actually helping me and interfere with what I have practice with processing.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47UJ86"> | |
| <div class='header'> | |
| <span class='author'>@Xliff</span> commented at <time datetime="2021-12-15T19:35:47Z">2021-12-15 19:35</time> | |
| </div> | |
| <div class='body'> | |
| <p>@niner:</p> | |
| <p>Thanks for the comment. From my prospective as a user, I'd want to know a few a few things:</p> | |
| <ol> | |
| <li>What is going on</li> | |
| <li>Where are we currently in the process</li> | |
| <li>How much longer is this going to take</li> | |
| </ol> | |
| <p>Given these criterion, Raku provides <em>none of them</em>.</p> | |
| <p>A BEGIN note is fine, but it's CompUnit scoped for a reason. The solution to <code>1-3</code> implies something with a wider perspective.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47VJJB"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-16T03:08:42Z">2021-12-16 03:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>@niner The problem is about huge projects with hundreds+ modules where pre-compilation takes eons. Imagine any heavy GUI app, which loads tons of stuff on the start and displays a progress bar just to entertain you while it's heating up (GIMP? ;) ).</p> | |
| <p>BTW, as far as I understand, this is not only the case of installing a module/app, but recompiling it if Rakudo version changes. It is rather scary to wait for minutes, sometimes, without knowing what's going on when an app is started for the first time after upgrade.</p> | |
| <p>Theoretically, it is possible to use <code>BEGIN</code> for the purpose of reporting each module, but:</p> | |
| <ul> | |
| <li>this is a boilerplate to be added to each particular module</li> | |
| <li>basically, a module doesn't know how many was compiled already and how many is yet to compile</li> | |
| <li>the previous item could be solved, but the solution would only add extra to the complexity of the project</li> | |
| <li>and if any change is needed – go, do it for each individual module</li> | |
| <li>eventually, this all is going to be too error prone</li> | |
| </ul> | |
| <p>Callbacks invoked before/after a unit compilation is the most clean solution here. A startup script would just pre-load META6 and monitor which modules are being/has been compiled.</p> | |
| <p>Since Rakudo cannot cover all possible use cases, the best is to allow user's code to do what it needs to.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47XALa"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-16T14:47:54Z">2021-12-16 14:47</time> | |
| </div> | |
| <div class='body'> | |
| <p>BTW, it just crossed my mind that it must be a <code>Supply</code>, emitting pre-comp events.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47Xcas"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-12-16T16:57:19Z">2021-12-16 16:57</time> | |
| </div> | |
| <div class='body'> | |
| <p>hmmm... that's an interesting thought!</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47Z_8N"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2021-12-17T12:04:11Z">2021-12-17 12:04</time> | |
| </div> | |
| <div class='body'> | |
| <p>I noticed that the issue report says:</p> | |
| <pre><code>===> Testing [OK] for XML:ver<0.3.1>:auth<github:raku-community-modules> | |
| [ long wait, here ... ] | |
| ===> Testing: LibXML:ver<0.6.10>:auth<cpan:WARRINGD> | |
| </code></pre> | |
| <p>This is <strong>not</strong> an issue with long installation time. It's long time of running tests! What's not being reported here is the tests' output. I have occasionally wondered about this design decision in zef. But that may be just because I am used to seeing the output from Perl module installers. This is not something that Rakudo can change at all, since it doesn't even know that tests are being run. In fact it doesn't know the concept of "test" at all.</p> | |
| <p>However, since there was also a lot of discussion about the precompilation stage of the installation process, I may as well add my thoughts on that. Why do people seek information about progress in the first place? The answer is clear: because installation may just take a long time. While some form of progress report may keep users entertained or help preventing wrong assumptions about the program hanging, it wouldn't actually fix the underlying problem. Quite contrary it would only make that worse.</p> | |
| <p>Progress reporting by itself consumes CPU time and will make installation slower. You might say that the impact is surely negligible and the increased user confidence worth it. But that's judging a solution that we do not even know how it will look like? Yes, just emitting events won't matter that much. But who will receive the events? If - as was being suggested - the receiving end is supplied by the distribution that gets installed, then this is code that itself has to be (pre-)compiled first. And that is certainly going to take a measurable and even noticeable amount of time.</p> | |
| <p>I'd much rather we invest our time and effort into attacking the underlying problem itself. For some reason I don't see much happening in that regard, despite us all surely getting bored and annoyed by module installation times. My guess is that people think that the only way to improve this would be via major refactors deep inside the compiler, like RakuAST or super complicated spesh improvements that you'd need a PhD on compiler internals to understand. Nothing could be further from the truth.</p> | |
| <p>There is quite a bit of low hanging fruit that could yield massive improvements. Right now for example every module gets compiled twice when installed with zef. Once for testing and then on installation. That's quite unnecessary! We have all the foundation we need to first install a module into a CompUnit::Repsoitory::Staging repository, use that for tests and if successful simply copy the resulting files from the Staging repository to the actual target. That's btw. exactly what happens when installing modules from RPM packages: the build process installs into a Staging repository and the resulting files are packaged up and on installation only extracted from the archive into their final location.</p> | |
| <p>Right now, module installation uses a single one of the 16 CPU cores in my desktop computer. All other cores lie there dormant and underappreciated. That's because the precompilation part of CompUnit::Repository::Installation is a simple <code>for</code> loop iterating over the <code>%provides</code> hash from the distribution's meta data. Raku is a language that provides a lot of very nice high level support for parallelism. Xliff++ has already experimented with parallelized build, but unfortunately this work so far only made it into a custom build script.</p> | |
| <p>Frankly, parallelizing installation looks like a beginner task to me. A good opportunity to explore Raku's concurrency support. And I happen to know that the author of the code is happy to answer questions and provide assistance.</p> | |
| <p>There was also mention of upgrading Rakudo leading to prolonged application startup times. A script that precompiles all installed modules as (optional) part of Rakudo's installation process would again be something quite short and simple. This would basically be what Android does in the "optimizing apps" stage after updating the system. Of course this script would try to parallelize as much as possible. Parallelizing precompilation during application startup would be really hard and require something like heuristic look ahead parsing or plain guesses. Doing so for installed modules on the other hand is really quite trivial as all the information that's needed is there already and easily accessible.</p> | |
| <p>That's all low hanging fruit that would cut down waiting time to a fraction of what it is now. Really, the 2 minutes could become 10 seconds on a beefy machine.</p> | |
| <p>But the possibilities do not even stop there. If you really mean business, you start thinking about how to get rid of precompilation during installation altogether. MoarVM bytecode (and by extension precomp files) is 100 % platform independent. When I install a Java application, I do not wait for any compiler. I copy some jar files and be done with it. The same could be true for Raku applications. And indeed, it is actually true, if you install said application from RPM packages like we do on our servers.</p> | |
| <p>Compared to Java the only disadvantage we have is that precomp files are dependent on the exact Rakudo version. But then, we expect most people to use the monthly releases. We could have modules precompiled for these releases by some central build server from which zef could download and deploy the precomp files. We already do build those modules with the Blin runs that precede every release. What if we just didn't throw away the results?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47aGG0"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-12-17T12:47:27Z">2021-12-17 12:47</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>===> Testing [OK] for XML:ver<0.3.1>:auth<a href="github:raku-community-modules">github:raku-community-modules</a> | |
| [ long wait, here ... ] | |
| ===> Testing: LibXML:ver<0.6.10>:auth<a href="cpan:WARRINGD">cpan:WARRINGD</a></p> | |
| <p>This is not an issue with long installation time. It's long time of running tests! What's not being reported here is the tests' output. I have occasionally wondered about this design decision in zef. But that may be just because I am used to seeing the output from Perl module installers. This is not something that Rakudo can change at all, since it doesn't even know that tests are being run. In fact it doesn't know the concept of "test" at all.</p> | |
| </blockquote> | |
| <p>That's why I love my "run-tests" script:</p> | |
| <pre><code>https://raku-advent.blog/2020/12/13/day-13-helping-the-github-action-elves/ | |
| </code></pre> | |
| <p>It will output <em>everything</em>, even a --ll-exception backtrace, if a test failed or an error was thrown. And otherwise, it is (almost) silent.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47aerQ"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-17T15:11:59Z">2021-12-17 15:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>@niner In general, I agree with your point. BTW, the fact that we still don't really parallelize pre-comp came as a surprise to me. I remember there was a lot of work done to allow it. Or was it something different?</p> | |
| <p>Anyway, yes, there is a lot can be done to pre-cache the prepared bytecode. But there are always ways to break this. It'd be good to think beyond zef and installation in general. In particular, even the development process is affected because often change in a module deep down the dependency chain leads to long re-compile where the dev would have no idea of wether it's done yet or his code is stuck.</p> | |
| <blockquote> | |
| <p>But who will receive the events? If - as was being suggested - the receiving end is supplied by the distribution that gets installed, then this is code that itself has to be (pre-)compiled first.</p> | |
| </blockquote> | |
| <p>There are options here. But normally there is some single point of start, either a script or the root module. Both can do the reporting by using <code>BEGIN</code>:</p> | |
| <pre><code class="language-raku">BEGIN { | |
| PROCESS::<$REPORT> = Supplier.new; | |
| start react whenever $*REPORT { | |
| note $_; | |
| } | |
| } | |
| for ^10 { | |
| $*REPORT.emit: "step $_"; | |
| sleep .1; | |
| } | |
| $*REPORT.emit: "done"; | |
| sleep .3; | |
| </code></pre> | |
| <p>So, basically, I don't see why not to add a couple of lines for event emitting? I'd try it myself, but first I'd like to eventually be done with the current smartmatch project; and second, I don't know enough about CU internals to make proper decisions as to what data could be provided to the user land, and what is better be kept internal.</p> | |
| <p>BTW, this could even be helpful if one wants to collect some statistics about the pre-comp stage.</p> | |
| <blockquote> | |
| <p>A script that precompiles all installed modules as (optional) part of Rakudo's installation process would again be something quite short and simple.</p> | |
| </blockquote> | |
| <p>There is possible problem with this: a project might use a dedicated module repository, not known to the compiler upgrade script.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47alq8"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2021-12-17T15:48:09Z">2021-12-17 15:48</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>There is quite a bit of low hanging fruit that could yield massive improvements. Right now for example every module gets compiled twice when installed with zef. Once for testing and then on installation. That's quite unnecessary! We have all the foundation we need to first install a module into a CompUnit::Repsoitory::Staging repository, use that for tests and if successful simply copy the resulting files from the Staging repository to the actual target.</p> | |
| </blockquote> | |
| <p>ugexe has already (pre-dating this issue) started work on this in the <a href="https://github.com/ugexe/zef/commits/use-cur-staging-workflow">use-cur-staging-workflow</a> branch.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47auCe"> | |
| <div class='header'> | |
| <span class='author'>@Xliff</span> commented at <time datetime="2021-12-17T16:36:33Z">2021-12-17 16:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>@niner - Thank you for you <em>very</em> insightful post. I would love to see more work in this direction and would be willing to devote some time to it. It would be interesting to see how I can shrink install times for the first few unreleased modules I have in the can.</p> | |
| <p>Speaking of cans, though. I still feel this is kicking one particular can down the road. For particularly long installs, we still should be sending something to the user. The issue of precompiling the code that does the output is well received. In those cases we should be putting out caveats to those on the distribution end to "Keep it Simple!".</p> | |
| <p>For what its worth, if you feel the time is better spend putting our efforts into speeding up installation time, then I am all for it. I am willing to do that and then revisit this issue to still see if it remains relevant.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_wFpP"> | |
| <div class='header'> | |
| <span class='author'>@hythm7</span> commented at <time datetime="2022-03-16T20:11:23Z">2022-03-16 20:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>@niner</p> | |
| <blockquote> | |
| <p>We have all the foundation we need to first install a module into a CompUnit::Repsoitory::Staging repository, use that for tests and if successful simply copy the resulting files from the Staging repository to the actual target.</p> | |
| </blockquote> | |
| <p>For distributions that make use of <code>%?RESOURCES</code> for example, when copying the precompiled files from <code>CompUnit::Repository::Staging</code> to the actual target, these precompiled files still have the <code>%?RESOURCES</code> absolute path pointing to the <code>Staging</code> repository making it fails to obtain resources. can this be worked around somehow or for such distribution one need to re-install again to the target repository?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_wRlC"> | |
| <div class='header'> | |
| <span class='author'>@niner</span> commented at <time datetime="2022-03-16T20:50:39Z">2022-03-16 20:50</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>For distributions that make use of <code>%?RESOURCES</code> for example, when copying | |
| the precompiled files from <code>CompUnit::Repository::Staging</code> to the actual | |
| target, these precompiled files still have the <code>%?RESOURCES</code> absolute path | |
| pointing to the <code>Staging</code> repository making it fails to obtain resources. | |
| can this be worked around somehow or for such distribution one need to | |
| re-install again to the target repository?</p> | |
| </blockquote> | |
| <p>That's already a solved issue and the whole reason why e.g. | |
| <code>%?RESOURCES<libraries/foo></code> | |
| returns a <code>Distribution::Resource</code> object that's mimicking an <code>IO::Path</code> | |
| instead of getting an <code>IO::Path</code> directly. The <code>Distribution::Resource</code> object | |
| knows the name of the repository it was initialized from and will update its | |
| path at runtime. Since the staging repository is pretending to be the target | |
| (e.g. you have a staging repository for "site"), the resource will look up the | |
| path of the correct repository.</p> | |
| <p>And NativeCall also knows how to handle <code>Distribution::Resource</code> so no | |
| absolute path will be contained in precompiled files.</p> | |
| <p>This is not just theoretical but used in practice when we create RPM packages | |
| for Raku modules: | |
| https://build.opensuse.org/project/show/devel:languages:perl6</p> | |
| <p>Packaging follows the exact process I outlined here. The distribution will be | |
| installed into a staging repository for "vendor" which on the build service | |
| worker is somewhere like /home/abuild/rpmbuild/BUILDROOT/usr/share/perl6/ | |
| vendor. All generated files are then put into the package and on installation | |
| they are just extracted onto the file system into /usr/share/perl6/vendor.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_0SSW"> | |
| <div class='header'> | |
| <span class='author'>@Xliff</span> commented at <time datetime="2022-03-17T09:46:38Z">2022-03-17 09:46</time> | |
| </div> | |
| <div class='body'> | |
| <p>Why is the testing process silent?</p> | |
| <p>CPAN doesn't do this.</p> | |
| <p>Is it possible to at least emit the current test file being run and its results?</p> | |
| <p>For example, this here is the relevant out for a module I just installed:</p> | |
| <pre><code>PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t | |
| t/AE.t .................. skipped: AnyEvent is not installed. | |
| t/AETk.t ................ skipped: AnyEvent and/or Tk is not installed. | |
| t/ReadLine.t ............ ok | |
| t/release-pod-syntax.t .. skipped: these tests are for release candidate testing | |
| t/Tk.t .................. skipped: Tk is not installed. | |
| All tests successful. | |
| Files=5, Tests=15, 0 wallclock secs ( 0.01 usr 0.00 sys + 0.12 cusr 0.01 csys = 0.14 CPU) | |
| Result: PASS | |
| </code></pre> | |
| <p>This is exactly what I would like to see when installing a package. I don't necessarily need to know what actual test is running, but a single test file and an PASS/FAIL on each line would be sufficient.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_05HA"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-03-17T11:48:38Z">2022-03-17 11:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>@Xliff please privmsg me</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_2EET"> | |
| <div class='header'> | |
| <span class='author'>@hythm7</span> commented at <time datetime="2022-03-17T17:40:55Z">2022-03-17 17:40</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>That's already a solved issue and the whole reason why e.g. <code>%?RESOURCES<libraries/foo></code> returns a <code>Distribution::Resource</code> object that's mimicking an <code>IO::Path</code> instead of getting an <code>IO::Path</code> directly. The <code>Distribution::Resource</code> object knows the name of the repository it was initialized from and will update its path at runtime. Since the staging repository is pretending to be the target (e.g. you have a staging repository for "site"), the resource will look up the path of the correct repository. And NativeCall also knows how to handle <code>Distribution::Resource</code> so no absolute path will be contained in precompiled files. This is not just theoretical but used in practice when we create RPM packages for Raku modules: https://build.opensuse.org/project/show/devel:languages:perl6 Packaging follows the exact process I outlined here. The distribution will be installed into a staging repository for "vendor" which on the build service worker is somewhere like /home/abuild/rpmbuild/BUILDROOT/usr/share/perl6/ vendor. All generated files are then put into the package and on installation they are just extracted onto the file system into /usr/share/perl6/vendor.</p> | |
| </blockquote> | |
| <p>Most likely I'm missing something, because that is not what I'm experiencing. currently when I install a distribution using <code>install-dist.raku</code> which uses <code>CompUnit::Repository::Staging</code> the installed precomp files try to access the <code>Staging</code> repository <code>%?RESOURCES</code> not the target repo <code>%?RESOURCES</code>.</p> | |
| <p>Anyway I don't want to hijack this issue so I created a new <a href="https://github.com/rakudo/rakudo/issues/4818">issue</a> in rakudo</p> | |
| <p>EDIT: The behavior I described in this comment was actually a bug in Linenoise distribution (as pper niner in the mentioned issue).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4_2Ou6"> | |
| <div class='header'> | |
| <span class='author'>@ugexe</span> commented at <time datetime="2022-03-17T18:19:28Z">2022-03-17 18:19</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>This is exactly what I would like to see when installing a package. I don't necessarily need to know what actual test is running, but a single test file and an PASS/FAIL on each line would be sufficient.</p> | |
| </blockquote> | |
| <p>so pass zef the <code>--verbose</code> or <code>--debug</code> flag depending on how much you want to see</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="308"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/308"><span class='number'>308</span></a> - <span class='title'>More flexible Phasers</span></div> | |
| <div class='author'>[open]<span class='author'>@wayland</span> opend this issue at <time datetime="2021-12-13T19:57:01Z">2021-12-13 19:57</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>My experience with phasers is that: | |
| a) The ones that I want to use often don't exist anyway, because the orthogonal things haven't been kept orthogonal.<br /> | |
| b) There are a lot of them, and I have to look them up if I want to use them. "Set phasers to the max" sounds fun ... until you have to remember all their names.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>Examples of things that should be achievable with phasers include:</p> | |
| <ul> | |
| <li>Damian Conway's <code>for {} else {}</code> structure that he had to add a slang to get (runs the "else" part if there are no items to iterate)</li> | |
| <li>The <code>for {} </code> problem discussed at https://stackoverflow.com/questions/70281827/raku-last-on-non-loops in which a good solution is pointed out, but the docs specifically say that solution shouldn't work (though rakudo permits it, as would the not-yet-implemented <code>leave</code> keyword).</li> | |
| </ul> | |
| <p>There are others, though.</p> | |
| <p>In a lot of ways this is a request for a) the orthogonal things to be kept orthogonal, and b) more flexibility. I'm afraid this problem statement is somewhat nebulous and non-compelling. However, when I posted a suggested solution (that I'm not particularly attached to, apart from the idea of "Make the easy things easy, the hard things possible, and the orthogonal things orthogonal") on perl6-users, people seemed keen that I bring it here.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c47LZ3_"> | |
| <div class='header'> | |
| <span class='author'>@wayland</span> commented at <time datetime="2021-12-13T20:09:21Z">2021-12-13 20:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>Initial Proposal</p> | |
| <p>Attached is a slightly modified version of the document I posted to the perl6-users mailing list.</p> | |
| <p><a href="https://github.com/Raku/problem-solving/files/7706589/PhasersMkIIDocumentation.pdf">PhasersMkIIDocumentation.pdf</a></p> | |
| <p>Hopefully it's not too detailed. My intent was to make it just detailed enough to get my ideas across. Unfortunately this required the presentation of a few (orthogonal) ideas.</p> | |
| <p>Please note that if by "implement the solution", it's meant "write documents (and/or translate them to Markdown)", then I can work on it, but if it's meant "implement in the language grammar", then I'm at the very least going to need a fair whack of help.</p> | |
| <p>Hope this is useful. Thanks for your time!</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47Otrs"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-14T16:24:52Z">2021-12-14 16:24</time> | |
| </div> | |
| <div class='body'> | |
| <p>@wayland I'm sorry to say this as I realize what amount of work have you done already, but it'd be much more practical to have your proposal posted here, in a comment. First of all, it would make it much easier to comment by referring to particular parts of the proposal. And this might be my personal discomfort only, but I don't like this switching between browser and PDF viewer as it draws my focus away.</p> | |
| <p>Anyway, @Xliff had some thoughts on this they posted in the mailing list. Perhaps worth moving over here?</p> | |
| <p>My personal first reaction: Fortran, Basic, aren't this you, my old pals? Perhaps, some would think of Cobol too. To be frank, I haven't read it all, just browsed quickly.</p> | |
| <p>Overall, the idea worth considering. The weak points I see from the start are block-less phasers like <code>BEGIN say "Compiling";</code>. The current form is compact and serves the purpose of quickly inserting something useful in the code. <code>COMPILE ENTER say "Compiling";</code>?</p> | |
| <p>Going more Raku-way is, perhaps, have adverbs involved. For block phasers this would look pretty natural:</p> | |
| <pre><code>COMPILE :in { # BEGIN | |
| ... | |
| } | |
| COMPIE :out { # END | |
| ... | |
| } | |
| </code></pre> | |
| <p><code>:in</code> could be the default. This way it would also emphasize the fact that we modify the phaser behavior. Yet, <code>COMPILE :out say "End compiling"</code> still looks rather line noisy, comparing to <code>END say "End compiling";</code>. OTOH, one-word aliases are to be kept anyway.</p> | |
| <p>New control statements? Better not. Besides, <code>assert</code> neither let you specify the exception, nor it's arguments. This would limit it's usage. Yet, in a well-classified world of phasers I would consider the following for iterations:</p> | |
| <pre><code>ENTER :once { ... } | |
| ENTER :assert(* < 3) { X::MyException.new: :why("because too low") } | |
| ENTER :assert($item < 3) { X::MyException.new: :why("because too low") } | |
| </code></pre> | |
| <p>In the most extreme case, the <code>:assert</code> variant could even be shortened to:</p> | |
| <pre><code>ENTER :assert(* < 3), X::MyException, :why("because too low"); | |
| </code></pre> | |
| <p>All the <code>.new.throw</code> kitchen would be hidden then.</p> | |
| <p>Again, on things like <code>LEAVE .entry-success</code>. Since our current syntax of <code>$_ ~~ :foo</code> means <code>.foo.Bool</code>, <code>LEAVE :entry-success</code> would basically wind down to the same semantics.</p> | |
| <p>But otherwise more in-depth analysis is apparently required as one way, or another, but the idea introduces more verbosity.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47Phxu"> | |
| <div class='header'> | |
| <span class='author'>@wayland</span> commented at <time datetime="2021-12-14T19:51:24Z">2021-12-14 19:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>This is my conversion of the above PDF into Markdown (with a couple of bugfixes).</p> | |
| <h1>Phasers Mark II</h1> | |
| <p>Edition 0.3</p> | |
| <h2>Philosophy</h2> | |
| <p>One well-known part of the Raku philosophy is "Make the easy things easy, and the hard things possible". I'd like to propose a small addendum "...and the orthogonal things orthogonal".</p> | |
| <h2>Overview</h2> | |
| <p>I love phasers. I love the idea of them, anyway. Once you actually start using them, reality shows up. My experience with phasers is that:</p> | |
| <p>a) The ones that I want to use often don't exist anyway, because the orthogonal things haven't been kept orthogonal.<br /> | |
| b) There are a lot of them, and I have to look them up if I want to use them. "Set phasers to the max" sounds fun ... until you have to remember all their names.</p> | |
| <p>This proposal will make phasers much more flexible. But only if it actually gets implemented. On the down side, it will also make them more wordy. But on the up side again, instead of remembering 20 words, it will be a combination of about 10 words, and will present many more possibilities than the current phasers.<br /> | |
| The things added will be:</p> | |
| <ul> | |
| <li>An optional topicaliser (to Phasers); this means that every phaser has a built-in, implicit <code>given {}</code>.</li> | |
| <li>Some additional methods on Block</li> | |
| <li>More (optional) prefixes (to Phasers)</li> | |
| <li>A modification of 'once', and a control structure 'assert'.</li> | |
| <li>Another magic variable</li> | |
| </ul> | |
| <p>The things removed will be 18 of the 20 current phasers. While still having more flexibility than before.</p> | |
| <p>Throughout this document, I will refer to the Current Style (ie. current Raku) and the New Style (ie. my suggestion). While I'm not proposing that we eliminate the existing phasers (they can remain as aliases), I'm not against it either. I won't hold you back if people really want to ... fire the phasers!</p> | |
| <p>Given that my knowledge of Raku internals (or even asynchronous phasers) ranges from none to minimal, this proposal should be considered merely a beginning for discussion. But it may spark some ideas about orthogonality.</p> | |
| <h2>Demonstration</h2> | |
| <p>It will be useful to start by listing the Current Style Phasers, and suggesting a replacement for each in the New Style. Note that this does not demonstrate any of the newly-possible functionality. The default topic for the <code>LEAVE</code> phaser is the <code>&?BLOCK</code> variable (but see below under <em>class Block (Enhanced)</em>), to the extent that if the topicaliser starts with a '<code>.</code>' (eg. <code>.block-done</code>), then that's considered to be <code>&?BLOCK.block-done()</code>. However, the topicaliser could also be another block label, or a variable containing a block, or something like that. There's nothing ... blocking you from doing that.</p> | |
| <pre><code>BEGIN {} COMPILE ENTER {} | |
| CHECK {} COMPILE LEAVE {} | |
| INIT {} RUNTIME ENTER {} | |
| END {} RUNTIME LEAVE {} | |
| DOC * DOC * (No change) | |
| ENTER {} ENTER {} (No change) | |
| LEAVE {} LEAVE {} (No change in syntax) | |
| KEEP {} LEAVE { .success and do {} } | |
| UNDO {} LEAVE { .success or do {} } | |
| FIRST {} ENTER { once {} } | |
| NEXT {} LEAVE { when .iter-done.not {} } | |
| LAST {} LEAVE { when .iter-fine {} } | |
| PRE {} ENTER { assert {} } | |
| POST {} LEAVE { assert {} } | |
| CONTROL {} LEAVE { when .block-done ~~ X::Control {} } | |
| CATCH {} LEAVE { when .block-fine.not {} } | |
| QUIT {} LEAVE { when .iter-fine.not {} } | |
| LAST {} LEAVE { when .iter-fine(CX::Done) {} } | |
| CLOSE {} LEAVE { when .iter-done ~~ CX::Done {} } | |
| COMPOSE {} COMPOSE ENTER {} | |
| </code></pre> | |
| <p>A lot of the above is relatively self-evident in its meaning. The parts that are the least evident are the new methods on Block. So I feel like I'll clarify things the most by starting there.</p> | |
| <h2>class Block (Enhanced)</h2> | |
| <p>These methods are being added to Block to support the functionality above.</p> | |
| <h3>method block-done</h3> | |
| <p><code>method block-done(--> Bool|Exception)</code></p> | |
| <p>How was the block exited?</p> | |
| <p>Possible return values and meanings are:</p> | |
| <ul> | |
| <li><code>Bool False</code>: Not complete yet, or no entry-success (see entry-success, below)</li> | |
| <li><code>Bool True</code>: No Exception (ie. normal exit)</li> | |
| <li><code>Exception</code>: How the block exited. Note that this is not throwing an exception, but returning one.</li> | |
| </ul> | |
| <h3>method entry-success</h3> | |
| <p><code>method entry-success(--> Bool)</code></p> | |
| <p>Was the the block successfully entered?</p> | |
| <p>Returns True. Will be overridden by:</p> | |
| <ul> | |
| <li><code>Iterating</code>: see below</li> | |
| <li><code>Routine</code>: Currently, <code>LEAVE</code> blocks in a Routine currently run even if the parameter binding fails (with no currently-documented way of avoiding this). To avoid this problem, use <code>LEAVE { when .entry-success {} }</code></li> | |
| </ul> | |
| <h3>method block-fine</h3> | |
| <p><code>method block-fine(Exception @exceptions --> Bool)</code></p> | |
| <p>Did the block exit fine (if you'll pardon the English/Italian pun)?</p> | |
| <p>The funtion is trivial, but convenient. Pseudo-code is:</p> | |
| <pre><code>method block-fine(Exception @exceptions) { | |
| @exceptions or @exceptions = (X::Control); | |
| given self.block-done { | |
| when Bool { return $_; } | |
| when any(@exceptions) { return True; } | |
| default { return False; } | |
| } | |
| } | |
| </code></pre> | |
| <h3>method success</h3> | |
| <p><code>method success(--> Bool)</code></p> | |
| <p>What was the success value of the block?</p> | |
| <p>This takes the Defintion of Success (see <a href="https://design.raku.org/S04.html#Definition_of_Success">https://design.raku.org/S04.html#Definition_of_Success</a> ) and makes it no longer implementation-defined. It adds the idea that, if <code>entry-success</code> is <code>False</code>, then it's <code>False</code>. The short (pseudo-code) version is:</p> | |
| <pre><code>.block-done ~~ all(Bool, True) ?? $return-value !! False | |
| </code></pre> | |
| <h2>class Iterating</h2> | |
| <p>Apologies if this concept already exists, but I didn't see anything in the documentation. User yary on perl6-users suggested that "I think all the methods proposed for Block & Iterating should instead go on an object that exposes the control flow/program counter. Is there such a thing already?"</p> | |
| <p><code>class Iterating is Block</code></p> | |
| <p>The Iterating is a descendant of Block, and an ancestor to <code>loop</code>, <code>supply</code>, and <code>react</code> blocks. Because I intend it to be an ancestor for all loops (not just ones with an iterator) as well as <code>supply</code> and <code>react</code> blocks, possibly it should have a different name.</p> | |
| <h3>method entry-success</h3> | |
| <p><code>method entry-success(--> Bool)</code></p> | |
| <p>Was the the block successfully entered?</p> | |
| <p>Overrides the method on the parent Block. This is <code>True</code> when the Iterating has had at least one item provided to it, but is <code>False</code> if the Iterating has no items provided to it.</p> | |
| <h3>method iter-done</h3> | |
| <p><code>method iter-done(--> Bool|Exception)</code></p> | |
| <p>How was the Iterating exited?</p> | |
| <p>The possible return values are the same as for <code>Block.block-done()</code>, except that they apply to the completeness of the Iterating (loop/<code>supply</code>/<code>react</code>), and not the completeness of the block.</p> | |
| <h3>method iter-fine</h3> | |
| <p><code>method iter-fine(Exception @exceptions --> Bool)</code></p> | |
| <p>Did the Iterating exit fine?</p> | |
| <p>This is the same as <code>block-fine</code>, but based around <code>.iter-done</code> instead of <code>.block-done</code>.</p> | |
| <h2>Magic Variable</h2> | |
| <p>I'd like to propose a new Magic Variable, <code>&?ITERATING</code>, which is like <code>&?BLOCK</code> and <code>&?ROUTINE</code>, but for the nearest containing Iterating block.</p> | |
| <h2>Control Flow Structures</h2> | |
| <p>The following changes would be useful.</p> | |
| <h3>once</h3> | |
| <p>This is a modified version of <code>once</code>. It's like the current <code>once</code>, but takes a block label (or Block) as a parameter, and happens only once within that block. It will reset (to run again) after the specified block is completed (or when the next one starts).</p> | |
| <p>The default value is <code>&?ITERATING</code>. To get something like the current behaviour, we probably want to pass in something like <code>&?PACKAGE</code>. Unless there's a larger scope for the whole program that we could use instead.</p> | |
| <p>First example: how the new structure would work without a block label:</p> | |
| <pre><code>for [1, 2, 3] -> $outeritem { | |
| for <a b c> -> $inneritem { | |
| print "$outeritem" | |
| once { print "--" } | |
| print "$inneritem, "; | |
| } | |
| } | |
| say; | |
| # 1--a, 1b, 1c, 2--a, 2b, 2c, 3--a, 3b, 3c | |
| </code></pre> | |
| <p>The exact same code, but we pass a block label</p> | |
| <pre><code>OUTER: for [1, 2, 3] -> $outeritem { | |
| for <a b c> -> $inneritem { | |
| print "$outeritem" | |
| once OUTER { print "--" } | |
| print "$inneritem, "; | |
| } | |
| } | |
| say; | |
| # 1--a, 1b, 1c, 2a, 2b, 2c, 3a, 3b, 3c | |
| </code></pre> | |
| <h3>assert</h3> | |
| <p><code>assert { <expression> }</code></p> | |
| <p>This is shorthand for the following:</p> | |
| <p><code>if (<expression>) {raise Exception...}</code></p> | |
| <p>The reason for this is to simplify the Current Style PRE/POST phasers.</p> | |
| <h2>New Phaser Syntax</h2> | |
| <p>The following is pseudocode, but should get the idea across.</p> | |
| <pre><code>rule phaser { <prefix>* <phaser-name> <topic>? <block> } | |
| rule phaser-name { 'ENTER' | 'LEAVE' } | |
| rule prefix { 'DOC' | 'RUNTIME' | 'COMPILE' | 'COMPOSE' } | |
| </code></pre> | |
| <p>From this, it will be observed that remaining phasers are:</p> | |
| <ul> | |
| <li><code>ENTER</code>: When the block (or prefix-defined item) is entered.</li> | |
| <li><code>LEAVE</code>: When the block (or prefix-defined item) is left. However, just as putting a LEAVE inside a Routine that doesn't successfully bind parameters, putting a LEAVE in an Iterating should also activate if there are no iterations of the Iterating.</li> | |
| </ul> | |
| <p>Regarding execution order <em>within a queue</em>, it’s the same as declaration order. This actually gives more flexibility (especially as far as ordering goes), but is not backwards compatible.</p> | |
| <h3>Current Style</h3> | |
| <pre><code>for 1..3 -> $item { | |
| say "Item is $item"; | |
| ENTER { say "new loop"; } | |
| FIRST { say "first"; } | |
| PRE { $item < 3; } | |
| } | |
| </code></pre> | |
| <h3>New Style</h3> | |
| <pre><code>for 1..3 -> $item { | |
| say "Item is $item"; | |
| ENTER { | |
| assert { $item < 3; } | |
| once { say "first"; } | |
| say "new loop"; | |
| } | |
| } | |
| </code></pre> | |
| <p>The two code samples above are equivalent. In the Current Style, the order is fixed by the phaser ordering. In the New Style, while the order is the same as the other code sample, the option is available to change the ordering of the 3 lines in the <code>ENTER</code> block. More flexibility.</p> | |
| <h2>Prefixes</h2> | |
| <p>The prefixes are:</p> | |
| <ul> | |
| <li><code>DOC</code>: Almost exactly the same as the one already in the raku documentation. Implies <code>COMPILE</code> (unless declared <code>RUNTIME</code>)</li> | |
| <li><code>RUNTIME</code>: Makes the phaser happen at runtime, as early/late as possible</li> | |
| <li><code>COMPILE</code>: Makes the phaser happen at compile time, as early/late as possible</li> | |
| <li><code>COMPOSE</code>: Runs when a role is composed into a class</li> | |
| </ul> | |
| <p>Obviously, <code>RUNTIME</code> and <code>COMPILE</code> override each other.</p> | |
| <h2>New Features Available</h2> | |
| <p>The New Style provides a number of advantages. Some have already been shown, but a couple more examples might be useful.</p> | |
| <p>Only run the <code>LEAVE</code> code if the exit was a fallthrough, rather than a Control Exception.</p> | |
| <pre><code>for [1, 2, 3, 4, 5] -> $item { | |
| if $item == 6 { | |
| last; | |
| } | |
| LEAVE .block-done { | |
| when all(Bool, True) { say "No items match the special six"; } | |
| } | |
| } | |
| </code></pre> | |
| <p>That feature alone should practically justify the new system. However, there are many others.</p> | |
| <p>For example:</p> | |
| <pre><code>@array = (); | |
| for @array -> $item { | |
| say "Item is $item"; | |
| LEAVE { | |
| when .entry-success { say "I wannan Item! Gimmie Item! .... no Item :("; } | |
| } | |
| } | |
| </code></pre> | |
| <p>The code inside the <code>when .entry-success {}</code> only runs if there are no items in <code>@array</code>.</p> | |
| <h2>Alternative Ideas</h2> | |
| <p>Things that might need changing are:</p> | |
| <ul> | |
| <li>If we also need an <code>ASYNC</code> prefix to declare a Phaser asynchronous, that's an option too.</li> | |
| <li>If, through discussion, we establish that an Iterating should automatically nest another block inside it (and returns from the inner block are from the current iteration, whereas returns from the outer are returns from the whole thing), then we could replace <code>Block.block-(done|fine)</code> with <code>Block.(done|fine)</code> and <code>Iterating.iter-(done|fine)</code> with <code>Iterating.(done|fine)</code>. This might have advantages, but would probably also necessitate a restructure of the code, so I've avoided it.</li> | |
| </ul> | |
| <p>Because of the collapsing of most Phasers into <code>ENTER</code>/<code>LEAVE</code>, Phaser queues have become somewhat irrelevant.</p> | |
| <h2>Conclusion</h2> | |
| <p>Hopefully this will provide a starting point for a discussion about phasers, and how they might be made easier to work with.</p> | |
| <h2>Authors</h2> | |
| <pre><code>• Tim Nelson (original document) | |
| • Clifton Wood (syntax improvements) | |
| • yary (suggestion about Iterating) | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47PnQb"> | |
| <div class='header'> | |
| <span class='author'>@wayland</span> commented at <time datetime="2021-12-14T20:20:31Z">2021-12-14 20:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>@vrurg</p> | |
| <ul> | |
| <li>My manual conversion from PDF posted above, as requested -- hopefully this will make it easier for you to read the whole thing.</li> | |
| <li>The work of Xliff has been incorporated into my proposal</li> | |
| <li>I see the BASIC resemblance; I only did FORTRAN for half an hour, so no comment. Personally, I'd think more of Pascal.</li> | |
| <li>Yes, you're right, block-less phasers would probably be a thing of the past (unless there's another good way of distinguishing whether the following element is a topicaliser). On the other hand, perhaps we can do away with the topicaliser if we can really nail down how the whole <code>&?BLOCK</code> and <code>&?ITERATING</code> part works (or whatever replaces them).</li> | |
| <li>I can see the advantage of adverbs, but I was trying to change as little as possible while achieving what I wanted. If we're going the adverbs route, though, I think <code>IN:compile</code> would be the better alternative; I see <code>ENTER</code>/<code>LEAVE</code> (or <code>IN</code>/<code>OUT</code>) as the two basic phasers, and everything else is just a modification of them.</li> | |
| <li>Regarding <code>once</code>, this is something I'm keen to use regularly (and not just in phasers). It's quite often that I want to do something only the first time through the loop (and I believe that this is the itch that <code>FIRST</code> was designed to scratch), but find that I don't always want to do it at the <em>start</em> of the loop. If the extra wordiness bothers you, I can propose that we eliminate <code>FIRST</code> since it will no longer be necessary :) .</li> | |
| <li>Regarding assert, all I'm trying to do is make <code>PRE</code>/<code>POST</code> work with the new phasers scheme where there are only two phasers, <code>ENTER</code>/<code>LEAVE</code> (or <code>IN</code>/<code>OUT</code>, or whatever). The whole point of <code>PRE</code>/<code>POST</code> (if I understand) is that, if the phaser returns false, an exception is thrown. I'm assuming <code>assert {}</code> would throw the same exception. I'm not particularly attached to it since I don't really use <code>PRE</code>/<code>POST</code>. This is just keeping the orthogonal things orthogonal. The problem with your syntax is that it's a lot wordier than <code>PRE {}</code>, and a fair bit wordier than <code>ENTER { assert{} }</code>, which was my suggested alternative.</li> | |
| <li>I'm sorry, I didn't follow your last point about <code>LEAVE .entry-success</code></li> | |
| </ul> | |
| <p>Thanks for your suggestions.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47Qp9-"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-15T02:08:28Z">2021-12-15 02:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>Here my thoughts on some parts of the proposal.</p> | |
| <blockquote> | |
| <p>I'd like to propose a new Magic Variable, <code>&?ITERATING</code></p> | |
| </blockquote> | |
| <p>No need for it. If necessary, a block could be referenced via a label. This will require some support from the compiler, but then one can do:</p> | |
| <pre><code>FOO: for ^10 { | |
| say FOO.block; | |
| once FOO say "once per loop"; | |
| } | |
| </code></pre> | |
| <p>I consider this the only correct approach if functionality of <code>once</code> is to be extended. Consider the following:</p> | |
| <pre><code class="language-raku">FOO: for ^10 { | |
| when 5..7 { | |
| once "once per `when`"; | |
| once FOO "once per loop"; | |
| } | |
| } | |
| </code></pre> | |
| <p>Though since such a cardinal change of <code>once</code> semantics wouldn't be appreciated, within the adverb approach it would be more correct to use <code>ENTER</code>:</p> | |
| <pre><code class="language-raku">FOO: for ^10 { | |
| when 5..7 { | |
| ENTER :once say "once per `when`"; | |
| ENTER :once(FOO) say "once per loop"; | |
| ENTER :once(UNIT) say "once per module load"; | |
| ENTER :once(GLOBAL) say "once per run"; | |
| } | |
| } | |
| </code></pre> | |
| <p><code>ENTER :once</code> bound to the innermost block is a great way to lazy initialize something <em>only</em> when it is really needed.</p> | |
| <h3><code>assert</code></h3> | |
| <p>Unfortunately, it wouldn't be able to replace <code>PRE</code>/<code>POST</code>. The latter do not belong to loop's block:</p> | |
| <pre><code class="language-raku">CATCH { default { say "caught in the outer: $_" } } | |
| for ^10 { | |
| CATCH { default { say "caught in loop: $_" } } | |
| PRE { die "PRE died"; } | |
| } | |
| </code></pre> | |
| <p>But <code>ENTER</code> does. So, <code>PRE</code>/<code>POST</code> will be there. Any replacement would only add to verbosity with no apparent advantage.</p> | |
| <pre><code>@array = (); | |
| for @array -> $item { | |
| say "Item is $item"; | |
| LEAVE { | |
| when .entry-success { say "I wannan Item! Gimmie Item! .... no Item :("; } | |
| } | |
| } | |
| </code></pre> | |
| <p>This won't work. The block will never enter in first place. So, there will be no <code>LEAVE</code>. I barely see really common use-case scenario for this and why <code>if !@array { cry-in-sorry }</code> is so bad to be used in first place. But if there is one then it really looks like a job for <code>PRE</code>/<code>POST</code>.</p> | |
| <blockquote> | |
| <ul> | |
| <li>I see the BASIC resemblance; I only did FORTRAN for half an hour, so no comment. Personally, I'd think more of Pascal.</li> | |
| </ul> | |
| </blockquote> | |
| <p>Whatever. Extra verbosity is their common property. :)</p> | |
| <blockquote> | |
| <ul> | |
| <li>Yes, you're right, block-less phasers would probably be a thing of the past</li> | |
| </ul> | |
| </blockquote> | |
| <p>No, they won't. Taking into account how popular and useful the following is:</p> | |
| <pre><code class="language-raku">for ^10 { | |
| say now - INIT now; | |
| sleep 1; | |
| } | |
| </code></pre> | |
| <p><em>NB</em> <code>FIRST</code> would be more intuitive, but, apparently, it doesn't return a value. I don't remember wether it is intentional behavior and it looks more like a bug or an overlook.</p> | |
| <p>Yet, if a sensible topic would be considered needed then it doesn't mean a block is required. Consider <code>"foo" ~~ .say </code>. In this case the only question is what a phaser would have to topicalize around. In my view it needs to be some kind of phaser handle object, not a block.</p> | |
| <blockquote> | |
| <ul> | |
| <li>If we're going the adverbs route, though, I think <code>IN:compile</code> would be the better alternative; I see <code>ENTER</code>/<code>LEAVE</code> (or <code>IN</code>/<code>OUT</code>) as the two basic phasers, and everything else is just a modification of them.</li> | |
| </ul> | |
| </blockquote> | |
| <p>Don't forget about readability. It much easier to quickly sour out phasers when you their stage at the first glance.</p> | |
| <blockquote> | |
| <ul> | |
| <li>I'm sorry, I didn't follow your last point about <code>LEAVE .entry-success</code></li> | |
| </ul> | |
| </blockquote> | |
| <p>Consider a phaser declaration to be a kind of <code>when</code> statement. For example, with <code>when</code>:</p> | |
| <pre><code class="language-raku">class Foo { | |
| method bar1 { False } | |
| method bar2 { True } | |
| }; | |
| given Foo.new { | |
| when :bar1 { say "bar1" } | |
| when :bar2 { say "bar2" } | |
| default { say "Nah...." } | |
| } | |
| </code></pre> | |
| <p>In this context <code>LEAVE .entry-success</code> can be re-stated in in pseudo-code as <code>when $phaser.leave & $phaser.entry-success</code>. Or, in full, this would be equivalent to:</p> | |
| <pre><code class="language-raku">given $phaser { | |
| when :leave & :entry-success { ... } | |
| } | |
| </code></pre> | |
| <p>Within the rules of your proposal this can be stated as <code>LEAVE :entry-success</code>.</p> | |
| <p>Though in practice, I currently see the system of the extra methods on phaser topic (no matter if it is a block or a special object) somewhat over-engineered. Not only it is complex and hard to follow. But it would require quite a bit of supporting code to be added to blocks. It is a known fact that <code>LEAVE</code> alone is currently rather costly on performance. Additional price tag on any phaser would be inevitable with all that tracking of block outcomes.</p> | |
| <p>Oh, and BTW:</p> | |
| <blockquote> | |
| <pre><code>CONTROL {} LEAVE { when .block-done ~~ X::Control {} } | |
| CATCH {} LEAVE { when .block-fine.not {} } | |
| </code></pre> | |
| </blockquote> | |
| <p>No, and no! First of all, it is too verbose. Second, it harms readability a <em>lot</em>. And instead of using <code>when</code> to sort out exceptions one would need to have an additional <code>given</code> to topicalize <code>.block-done</code>. So, these two are most certainly untouchable.</p> | |
| <p>My last thought on the whole approach. While the idea of providing some topic to phaser code may prove be useful, relying on <code>when</code> inside the code is far from the beast approach from the optimization/performance point of view. The best is when we can give the compiler enough hints to do as much work at compile time as possible. So, that's what is good about my <code>ENTER :once(FOO)</code> example: all is known compile-time. Same applies to <code>CATCH</code>/<code>CONTROL</code>. Contrary, <code>ENTER { when ... }</code> and <code>LEAVE { when ... }</code> offload all work onto runtime shoulders, with all the slowdowns.</p> | |
| <p>Then again, it doesn't mean that the run-time approach doesn't have its use. But what is possible must be carefully considered as some scenarios would require a lot of extra tracking of block enter/leave.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47SEvs"> | |
| <div class='header'> | |
| <span class='author'>@wayland</span> commented at <time datetime="2021-12-15T09:52:59Z">2021-12-15 09:52</time> | |
| </div> | |
| <div class='body'> | |
| <ul> | |
| <li><code>&?ITERATING</code>: Regarding there being no need for it, I've had a good think, and I agree.</li> | |
| <li><code>once</code>: it's a good point about such a change not being appreciated. I'd be happy if it were called <code>once-per</code> or something like that (with <code>once</code> being then an alias for once+parameter). My objection to the adverb approach is that it's then tied to the ordering of the phaser (or am I making a mistake here?), rather than giving freedom of ordering, as I was hoping to achieve here (as another piece of flexibility).</li> | |
| <li>Regarding block-less phasers still being possible, I'm glad to hear it and, while I don't quite see how it would work at the moment, I think that's something that can be sorted out later.</li> | |
| <li>Regarding the performance ramifications of adding the methods to the block-or-other object, I don't feel qualified to comment, other than to say I'm happy to hear alternatives</li> | |
| <li>Regarding LEAVE .entry-success, I think I follow</li> | |
| </ul> | |
| <h3>assert {}</h3> | |
| <p>You're probably aware, but just clarifying, PRE was designed to be used as follows (current working Raku code):</p> | |
| <pre><code>CATCH { default { say "caught in the outer: $_" } } | |
| for ^10 { | |
| CATCH { default { say "caught in loop: $_" } } | |
| PRE { 1 == 3 } | |
| } | |
| # caught in the outer: Precondition '{ 1 == 3 }' failed | |
| </code></pre> | |
| <p>I'm suggesting this be replaced by (proposed Raku code):</p> | |
| <pre><code>CATCH { default { say "caught in the outer: $_" } } | |
| for ^10 { | |
| CATCH { default { say "caught in loop: $_" } } | |
| ENTER { assert { 1 == 3 } } | |
| } | |
| # caught in the outer: asserted condition '{ 1 == 3 }' failed | |
| </code></pre> | |
| <p>My point is kind of hat you don't need <code>die</code> in a PRE block -- it does it itself.</p> | |
| <p>While you're right that it adds verbosity, I think it has two advantages:</p> | |
| <ul> | |
| <li>It keeps orthogonal things orthogonal</li> | |
| <li>It means we only have to remember 2 phasers, not 20 (or at least, we can forget PRE/POST)</li> | |
| <li>assert {} can be used in other places</li> | |
| <li>It gives you flexibility with ordering; this can be seen in my example above in the New Phasers section, where I compare <em>Current Style</em> with <em>New Style</em>. The ordering in the two examples is the same, but in the <em>New Style</em>, it's possible to change the ordering, whereas in the <em>Current Style</em> it's not.</li> | |
| </ul> | |
| <p>OK, that's 4 advantages. <em>Mea cupla</em>.</p> | |
| <h3>CATCH/CONTROL</h3> | |
| <p>The original syntax I had (I changed it after @Xliff's comments) was:</p> | |
| <pre><code>CONTROL {} LEAVE .block-done { when X::Control {} } | |
| CATCH {} LEAVE .block-fine { when False {} } | |
| </code></pre> | |
| <p>My theory was that the second one would smartmatch .block-fine against False, and match, but that may not be correct. According to the following quote from my document, that would eliminate the need for a <code>given {}</code> :</p> | |
| <blockquote> | |
| <p>The default topic for the <code>LEAVE</code> phaser is the <code>&?BLOCK</code> variable, to the extent that if the topicaliser starts with a '<code>.</code>' (eg. <code>.block-done</code>), then that's considered to be <code>&?BLOCK.block-done()</code>.</p> | |
| </blockquote> | |
| <p>If we return to my original suggestion for the replacements for <code>CONTROL</code>/<code>CATCH</code>, that'd eliminate at least the complaint about the extra <code>given {}</code>. It may not be quite as readable, but given that <code>CATCH</code> is the only phaser I use on the regular (because it's one of the few whose use I remember), let me just re-iterate that I'm suggesting that we keep the existing phasers as aliases of the new ones.</p> | |
| <p>Hmm. Maybe the solution (just thinking out loud here) is to add new <code>IN</code>/<code>OUT</code> phasers as the only two phasers that take topics and require blocks. Then the existing syntax could remain, but if it's useful (as decided by the language implementors), could be rewritten into the new phasers. Then, if people want to stick to the existing phasers, they can, and if they want to just use IN/OUT for everything, that'd work too.</p> | |
| <p>Thanks for taking the time to engage with what I'm suggesting here.</p> | |
| <p>HTH,</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47S3TL"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2021-12-15T13:39:29Z">2021-12-15 13:39</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't have time to look closely at this and critique it, but will note that:</p> | |
| <ol> | |
| <li>Phasers in some cases chime with a more broadly used concept. <code>BEGIN</code> runs at "begin time", for example, which we use to refer to many other things that happen within the parse phase, ditto for <code>CHECK</code> and "check time".</li> | |
| <li>Any proposal that wants to eliminate widely used existing syntax is not likely to go anywhere.</li> | |
| </ol> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47UD3h"> | |
| <div class='header'> | |
| <span class='author'>@wayland</span> commented at <time datetime="2021-12-15T19:20:56Z">2021-12-15 19:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>@jnthn</p> | |
| <ol> | |
| <li>That probably should have been obvious (but it wasn't to me!) Thanks very much for this info.</li> | |
| <li>I suspected as much. I'm expecting that we retain most, if not all, of existing syntax, at least in the short-to-medium term (and in the long term I have no idea/expectations :) ).</li> | |
| </ol> | |
| <p>Thanks for your input!</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47UuRl"> | |
| <div class='header'> | |
| <span class='author'>@Xliff</span> commented at <time datetime="2021-12-15T23:14:20Z">2021-12-15 23:14</time> | |
| </div> | |
| <div class='body'> | |
| <p>@vrurg</p> | |
| <p>On:</p> | |
| <pre><code>CONTROL {} LEAVE { when .block-done ~~ X::Control {} } | |
| CATCH {} LEAVE { when .block-fine.not {} } | |
| </code></pre> | |
| <p>You wrote:</p> | |
| <pre><code>No, and no! First of all, it is too verbose. Second, it harms readability a lot. | |
| And instead of using when to sort out exceptions one would need to have | |
| an additional given to topicalize .block-done. So, these two are most certainly | |
| untouchable. | |
| </code></pre> | |
| <p>From a purely syntactical standpoint, the <code>when .block-done ~~ CX::Control</code> is fine, since the topic is to be set for &?BLOCK, which... in1 most cases is &?ROUTINE. No additional given is necessary.</p> | |
| <p>Given that CONTROL and CATCH would <em>not</em> be going away, this should not affect readability. However in situations when .block-done is not an X::Control, this might give someone try()-adverse a different option.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47U_tp"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-16T01:33:34Z">2021-12-16 01:33</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>You're probably aware, but just clarifying, PRE was designed to be used as follows (current working Raku code):</p> | |
| </blockquote> | |
| <p>You seemingly missed the point I was actually making: the scoping. <code>PRE</code>/<code>POST</code> semantics is outer to loop's block despite of syntax being about inner declaration. So, when <code>PRE</code> throws for whatever reason it the outer <code>CATCH</code> which gains control.</p> | |
| <p>Contrary, the proposed <code>ENTER</code> is inner both syntactically and semantically. <code>assert</code>, as <code>ENTER</code> subsidiary, is also lexically scoped in loop's block. Hence it can't be <code>PRE</code> replacement.</p> | |
| <p>Speaking of <code>CATCH</code>/<code>CONTROL</code>: @wayland, @Xliff what would be your proposal to replace the following:</p> | |
| <pre><code class="language-raku">CATCH { | |
| when X::Method::NotFound { ... } | |
| when MyException { ... } | |
| when X::AdHoc { ... } | |
| default { ... } | |
| } | |
| </code></pre> | |
| <blockquote> | |
| <p>Hmm. Maybe the solution (just thinking out loud here) is to add new <code>IN</code>/<code>OUT</code> phasers as the only two phasers that take topics and require blocks.</p> | |
| </blockquote> | |
| <p>And here we're starting to look for ways to get around our own mistakes. Lately when I see myself in a position like this, the next thing to do is usually to step back and re-consider the whole concept. Good when it is a mental model, and there is nothing to be re-done yet...</p> | |
| <p>Anyway, I'd like to remind you, that topicalization is not necessarily bound to a block. If you read carefully about <a href="https://docs.raku.org/language/operators#infix_~~">the smartmatch op</a>, you'll find out that it topicalizes over its LHS, so RHS can use it. The topic exists only for the time to complete the operation and then reverts back to the lexical topic:</p> | |
| <pre><code class="language-raku">given "foo" { | |
| "bar" ~~ .say; | |
| .say; | |
| } | |
| </code></pre> | |
| <p>Hope it'd help you to re-consider some points.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47VAuN"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-16T01:44:16Z">2021-12-16 01:44</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <ol> | |
| <li>Phasers in some cases chime with a more broadly used concept. <code>BEGIN</code> runs at "begin time", for example, which we use to refer to many other things that happen within the parse phase, ditto for <code>CHECK</code> and "check time".</li> | |
| </ol> | |
| </blockquote> | |
| <p>@jnthn Basically, I don't see why <code>BEGIN</code> cannot be an alias for <code>COMPILE :in</code>, and <code>CHECK</code> - for <code>COMPILE :out</code>.</p> | |
| <p>It's more about other shortcomings of the proposal which are currently making it unreasonable to be considered as a realistic candidate. And while the idea of orthogonalization of the phasers is appealing, but the number of different modifiers and methods, required to cover all possible cases, leads back to about the same complexity, the author tries to avoid.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47YM2Q"> | |
| <div class='header'> | |
| <span class='author'>@wayland</span> commented at <time datetime="2021-12-16T21:16:12Z">2021-12-16 21:16</time> | |
| </div> | |
| <div class='body'> | |
| <p>@vrurg :</p> | |
| <h3>PRE/POST</h3> | |
| <p>Huh, interesting point about the PRE/POST and scope (thanks for clarifying!). On my local Rakudo, I get:</p> | |
| <pre><code>CATCH { default { say "caught in the outer: $_" } } | |
| for ^10 { | |
| CATCH { default { say "caught in loop: $_" } } | |
| ENTER { die "ENTER died"; } | |
| } | |
| # caught in the outer: ENTER died | |
| </code></pre> | |
| <p>So that means that either I've misunderstood you again, or that Rakudo doesn't follow the spec. Most likely I've misunderstood you.</p> | |
| <h3>Catch Example</h3> | |
| <p>My initial reaction is something like:</p> | |
| <pre><code>LEAVE .block-done { | |
| when X::Method::NotFound { ... } | |
| when MyException { ... } | |
| when X::AdHoc { ... } | |
| if(! &?OUTER::BLOCK.block-fine) { ... } | |
| } | |
| </code></pre> | |
| <p>That does highlight another weakness in my plan; if the topic isn't the parent block, then the parent block is hard to get at (this is a problem with the current CATCH too, but since these block-methods aren't used in existing phasers, it's not as much of a problem). There should definitely be a good solution to this. Options I can see include:</p> | |
| <ul> | |
| <li>Have a magic variable for the phaser-parent defined inside phasers (solves the larger topic-block problem)</li> | |
| <li>Add another method called .normal that's basically like .block-fine, but returns the exception instead of False (solves just the current problem).</li> | |
| <li>Change .block-fine to return the exception instead of False (solves just the current problem). In that case, it'd be:</li> | |
| </ul> | |
| <pre><code>LEAVE .block-fine { | |
| when X::Method::NotFound { ... } | |
| when MyException { ... } | |
| when X::AdHoc { ... } | |
| when Exception { ... } | |
| } | |
| </code></pre> | |
| <p>That's probably the solution. That's probably acceptable. .block-fine by itself will filter out the X::Control exceptions. But if there's another solution you like better, I'd be interested in hearing it.</p> | |
| <p>Regarding this leading back to the same complexity, while that may well be true (there are fewer syntactic elements, but of a wider variety of kinds), I think the extra flexibility is worth it.</p> | |
| <p>If you (currently) deem it "unreasonable to be considered as a realistic candidate", I have a question: are there any parts of this proposal that you <em>do</em> like? I ask because we might be able to take these parts and turn them into something else.</p> | |
| <p>HTH,</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47YaEd"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-16T22:50:28Z">2021-12-16 22:50</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>So that means that either I've misunderstood you again, or that Rakudo doesn't follow the spec. Most likely I've misunderstood you.</p> | |
| </blockquote> | |
| <p>Likely not, but it rather seems like a bug in implementation. This semantics is neither specced nor documented. But following quote from the original synopses makes me think that my interpretation of <code>ENTER</code> as lexical of the surrounding block is correct:</p> | |
| <blockquote> | |
| <p>An exception thrown from an <code>ENTER</code> phaser will abort the <code>ENTER</code> queue, but one thrown from a <code>LEAVE</code> phaser will not. The exceptions thrown by failing <code>PRE</code> and <code>POST</code> phasers cannot be caught by a <code>CATCH</code> in the same block, which implies that <code>POST</code> phaser are not run if a <code>PRE</code> phaser fails.</p> | |
| </blockquote> | |
| <p>There would be no point of focusing on the outer <code>CATCH</code> for <code>PRE</code> unless exceptions from <code>ENTER</code>/<code>LEAVE</code> are to be handled by the inner <code>CATCH</code>.</p> | |
| <blockquote> | |
| <p>If you (currently) deem it "unreasonable to be considered as a realistic candidate", I have a question: are there any parts of this proposal that you <em>do</em> like?</p> | |
| </blockquote> | |
| <p>I like the general idea of orthogonalization. But considering all the special cases, each of which would require extra modifiers or alike, I'm not sure there is any concise solution.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47ZDom"> | |
| <div class='header'> | |
| <span class='author'>@wayland</span> commented at <time datetime="2021-12-17T04:17:17Z">2021-12-17 04:17</time> | |
| </div> | |
| <div class='body'> | |
| <ul> | |
| <li><strong>PRE/POST:</strong> Interesting; I interpret the part about the <code>PRE</code>/<code>POST</code> focus as a preamble to the rest of the sentence, that "<code>POST</code> phasers are not run if a <code>PRE</code> phaser fails". But looking carefully at the Exection Order, especially the words immediately before the <code>PRE</code> and <code>ENTER</code> lines, you may be correct.</li> | |
| </ul> | |
| <p>(and incidentally, @JJ , the original doco and vrurg both wrote "<code>POST</code> phaser", rather than "<code>POST</code> phasers"; alternately, it should be "<code>POST</code> phaser is...").</p> | |
| <p>I still feel like Phasers are at a lower level of orthogonality, but it may require someone smarter than me to come up with the solution. Or at least someone who gets one more interesting idea to throw into the mix. Or maybe in Rakudo version 20 when we have 128 phasers, the solution will become obvious :-p .</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c47ZsKo"> | |
| <div class='header'> | |
| <span class='author'>@wayland</span> commented at <time datetime="2021-12-17T10:04:06Z">2021-12-17 10:04</time> | |
| </div> | |
| <div class='body'> | |
| <p>OK, I did some thinking (thanks @vrurg ), and realised that the one time people don't mind wordiness is when they're writing code (ie. they don't care how long the code is as long as it provides a new class/routine/whatever). So with that thought, I rewrote the document to instead just allow user-defined phasers. Welcome to version 1.0 (up from 0.3).</p> | |
| <h1>Phasers Mark II</h1> | |
| <p>Edition 1.0</p> | |
| <h2>Philosophy</h2> | |
| <p>One well-known part of the Raku philosophy is "Make the easy things easy, and the hard things possible". I'd like to propose a small addendum "...and the orthogonal things orthogonal".</p> | |
| <h2>Overview</h2> | |
| <p>I love phasers. I love the idea of them, anyway. Once you actually start using them, reality shows up. My experience with phasers is that the ones that I want to use often don't exist anyway, because the orthogonal things haven't been kept orthogonal.</p> | |
| <p>This proposal will make phasers much more flexible. But only if it actually gets implemented. The things added will be:</p> | |
| <ul> | |
| <li>User-defined phasers</li> | |
| <li>Info about various Phasables such as <code>BLOCK</code> (new methods, etc)</li> | |
| <li>A new control structure: <code>once-per</code></li> | |
| <li>An additional (optional) parameter to <code>throw</code></li> | |
| </ul> | |
| <p>Note that I'm not proposing that we eliminate the existing phasers. It may be advantageous to rewrite some(but probably not all) in the new syntax.</p> | |
| <p>Given that my knowledge of Raku internals (or even asynchronous phasers) ranges from none to minimal, this proposal should be considered merely a beginning for discussion. But it may spark some ideas about orthogonality.</p> | |
| <h2>Proposal</h2> | |
| <p>It should be possible for a user to define their own phasers.</p> | |
| <p>Unlike the previous proposal, this does not propose any new phasers, merely a phaser definition syntax.</p> | |
| <h2>Demonstration</h2> | |
| <p>None of the existing phasers will be ... phased out. But it might be illustrative to define existing phasers using the newly-proposed syntax.</p> | |
| <pre><code>phaser CATCH(Block &passed-block) trigger BLOCK Exception { | |
| when .fine.not { | |
| &passed-block(.done) | |
| } | |
| } | |
| phaser PRE(Block &passed-block) trigger BLOCK Entry { | |
| if ! &passed-block() { | |
| X::Phaser::PrePost.new(phaser => "PRE", condition => "\{ 1 == 3 }").throw(OUTER); | |
| } | |
| } | |
| </code></pre> | |
| <p>I'm not proposing that we actually do such a rewrite, merely noting that it's possible.</p> | |
| <p>In the examples above, you will have noticed the new keyword 'trigger', followed by a Phasable and a queue type.</p> | |
| <h2>Queue types</h2> | |
| <p>The following queue types may be deemed useful:</p> | |
| <ul> | |
| <li>Entry -- This happens right after the entry to the setting, and before anything else.</li> | |
| <li>Exit -- this happens just before the exit from the block.</li> | |
| </ul> | |
| <p>Note that each of these types intersects with all the Phasables below, so that the actual queues have names like "The BLOCK Entry queue".</p> | |
| <h2>Phasables</h2> | |
| <p>The Phasable is one of the following:</p> | |
| <ul> | |
| <li>Many of the Pseudo-packages mentioned at https://docs.raku.org/language/packages#index-entry-OUTER_(package) including: | |
| <ul> | |
| <li><code>UNIT</code>: The module</li> | |
| <li><code>GLOBAL</code>: The entire execution (ie. runtime)</li> | |
| <li><code>COMPILING</code>: The compile phase</li> | |
| <li><code>OUTER</code>: The next outer scope</li> | |
| <li>Comments: | |
| <ul> | |
| <li>Some of the others may also be useful, but that's probably a detail best left for later</li> | |
| <li>Yes, I know this wasn't the intended use of the Pseudo-packages; I'm suggesting expanding that in some cases</li> | |
| </ul> | |
| </li> | |
| </ul> | |
| </li> | |
| <li>Derived from these, we have: | |
| <ul> | |
| <li><code>DOC-COMPILE</code>: Like COMPILE, but in doco mode</li> | |
| <li><code>DOC-GLOBAL</code>: Like GLOBAL, but in doco mode</li> | |
| </ul> | |
| </li> | |
| <li>The following additional Phasables can also be used: | |
| <ul> | |
| <li><code>BLOCK</code>: The block</li> | |
| <li><code>LOOP</code>: The loop that wraps around a block. This also includes supply and react blocks.</li> | |
| <li><code>ROUTINE</code>: The current routine</li> | |
| <li><code>COMPOSE</code>: A role being composed into a class</li> | |
| </ul> | |
| </li> | |
| </ul> | |
| <p>There may be other Phasables. These Phasables are also the topic for the phaser definition block. This is why <code>CATCH</code>, in the above example, can use .fine, for example (which is <code>BLOCK.fine</code>).</p> | |
| <p>It may be useful to break down the Phasables and their methods.</p> | |
| <h3>The BLOCK Phasable</h3> | |
| <p>To support the necessary functionality, the following methods will be useful on the <code>BLOCK</code> Phasable.</p> | |
| <h4>method done</h4> | |
| <p><code>method done(--> Bool|Exception)</code></p> | |
| <p>How was the block exited?</p> | |
| <p>Possible return values and meanings are:</p> | |
| <ul> | |
| <li><code>Bool False</code>: Not complete yet, or no entry-success (see entry-success, below)</li> | |
| <li><code>Bool True</code>: No Exception (ie. normal exit)</li> | |
| <li><code>Exception</code>: How the block exited. Note that this is not throwing an exception, but returning one.</li> | |
| </ul> | |
| <h4>method entry-success</h4> | |
| <p><code>method entry-success(--> Bool)</code></p> | |
| <p>Was the the block successfully entered? This is necessary because LEAVE routines can run even if a block was never entered.</p> | |
| <p>Returns True for BLOCK.</p> | |
| <h4>method fine</h4> | |
| <p><code>method fine(Exception @exceptions --> Bool)</code></p> | |
| <p>Did the block exit fine (if you'll pardon the English/Italian pun)?</p> | |
| <p>The funtion is trivial, but convenient. Pseudo-code is:</p> | |
| <pre><code>method fine(Exception @exceptions) { | |
| @exceptions or @exceptions = (X::Control); | |
| given self.done { | |
| when Bool { return $_; } | |
| when any(@exceptions) { return True; } | |
| default { return False; } | |
| } | |
| } | |
| </code></pre> | |
| <h4>method success</h4> | |
| <p><code>method success(--> Bool)</code></p> | |
| <p>What was the success value of the block?</p> | |
| <p>This takes the Defintion of Success (see <a href="https://design.raku.org/S04.html#Definition_of_Success">https://design.raku.org/S04.html#Definition_of_Success</a> ) and makes it no longer implementation-defined. It adds the idea that, if <code>entry-success</code> is <code>False</code>, then it's <code>False</code>. The short (pseudo-code) version is:</p> | |
| <pre><code>.done ~~ all(Bool, True) ?? $return-value !! False | |
| </code></pre> | |
| <h3>The LOOP Phasable</h3> | |
| <h4>method done</h4> | |
| <p><code>method done(--> Bool|Exception)</code></p> | |
| <p>How was the LOOP exited?</p> | |
| <p>The possible return values are the same as for <code>BLOCK.done()</code>, except that they apply to the completeness of the LOOP, and not the completeness of the block.</p> | |
| <h4>method entry-success</h4> | |
| <p><code>method entry-success(--> Bool)</code></p> | |
| <p>Was the the block successfully entered?</p> | |
| <p>This is <code>True</code> when the LOOP has had at least one item provided to it, but is <code>False</code> if the LOOP has no items provided to it.</p> | |
| <h4>method fine</h4> | |
| <p><code>method fine(Exception @exceptions --> Bool)</code></p> | |
| <p>Did the LOOP exit fine?</p> | |
| <p>This is the same as <code>BLOCK.fine</code> (but on LOOP).</p> | |
| <h3>The ROUTINE Phasable</h3> | |
| <p>Same as BLOCK, but with the following exception:</p> | |
| <h4>method entry-success</h4> | |
| <p><code>method entry-success(--> Bool)</code></p> | |
| <p>Currently, <code>LEAVE</code> blocks in a Routine currently run even if the parameter binding fails (with no currently-documented way of avoiding this). To avoid this problem, use <code>LEAVE { when .entry-success {} }</code></p> | |
| <h3>once-per</h3> | |
| <p>This is a modified version of <code>once</code>. It's like <code>once</code>, but takes a block label or Phasable as a parameter, and happens only once within that block. It will reset (to run again) after the specified block is completed (or when the next one starts).</p> | |
| <p>The default value is <code>&?LOOP</code>.</p> | |
| <p>First example: how the new structure would work without a block label:</p> | |
| <pre><code>for [1, 2, 3] -> $outeritem { | |
| for <a b c> -> $inneritem { | |
| print "$outeritem" | |
| once-per { print "--" } | |
| print "$inneritem, "; | |
| } | |
| } | |
| say; | |
| # 1--a, 1b, 1c, 2--a, 2b, 2c, 3--a, 3b, 3c | |
| </code></pre> | |
| <p>The exact same code, but we pass a block label</p> | |
| <pre><code>OUTER: for [1, 2, 3] -> $outeritem { | |
| for <a b c> -> $inneritem { | |
| print "$outeritem" | |
| once-per OUTER { print "--" } | |
| print "$inneritem, "; | |
| } | |
| } | |
| say; | |
| # 1--a, 1b, 1c, 2a, 2b, 2c, 3a, 3b, 3c | |
| </code></pre> | |
| <h3>throw/rethrow</h3> | |
| <p>They should take an extra parameter that's a phasable, and indicate that we should drop out to that scope before throwing the exception. I can't see any good uses for this except OUTER (for the PRE and POST phasers).</p> | |
| <h2>New Features Available</h2> | |
| <p>The Phaser Definition Syntax provides a number of advantages. Some have already been shown, but a couple more examples might be useful.</p> | |
| <p>Only run the <code>LEAVE</code> code if the exit was a fallthrough, rather than a Control Exception.</p> | |
| <pre><code>phaser NATURAL_LEAVE(Block &passed-block) trigger BLOCK Exit { | |
| when .done ~~ all(Bool, True) { | |
| &passed-block() | |
| } | |
| } | |
| for [1, 2, 3, 4, 5] -> $item { | |
| if $item == 6 { | |
| last; | |
| } | |
| NATURAL_LEAVE { | |
| say "No items match the special six"; | |
| } | |
| } | |
| </code></pre> | |
| <p>That feature alone should practically justify the new system. However, there are many others.</p> | |
| <p>For example:</p> | |
| <pre><code>phaser INSTEAD(Block &passed-block) trigger LOOP Exit { | |
| .entry-success or do { &passed-block() } | |
| } | |
| @array = (); | |
| for @array -> $item { | |
| say "Item is $item"; | |
| INSTEAD { | |
| say "I wannan Item! Gimmie Item! .... no Item :("; | |
| } | |
| } | |
| </code></pre> | |
| <p>The code inside the <code>INSTEAD</code> only runs if there are no items in <code>@array</code>.</p> | |
| <h2>Alternative Ideas</h2> | |
| <p>Things that might need changing are:</p> | |
| <ul> | |
| <li>If we also need an <code>is ASYNC</code> modifier to declare a Phaser asynchronous, that's an option too.</li> | |
| </ul> | |
| <h2>Conclusion</h2> | |
| <p>Hopefully this will provide a starting point for a discussion about phasers, and how they might be made easier to work with.</p> | |
| <h2>Authors</h2> | |
| <ul> | |
| <li>Tim Nelson: original document (0.1) & 1.0 rewrite</li> | |
| <li>Clifton Wood: syntax improvements</li> | |
| <li>yary: suggestion about LOOP</li> | |
| <li>Vadim Belman (vrurg): Extensive criticism of early versions of the propsal, resulting in a rewrite of the majority of it</li> | |
| </ul> | |
| <h2>Appendix A: Phasers in the Phaser Definition Syntax</h2> | |
| <p>I'm not going to do the COMPILING/GLOBAL/COMPOSE ones (such as BEGIN/END/INIT/CHECK/COMPOSE) because they're probably best left alone. And again note that I'm not saying the following should be rewritten this way, just that it's illustrative to see how they could be rewritten.</p> | |
| <pre><code>phaser ENTER(Block &passed-block) trigger BLOCK Entry { | |
| &passed-block(); | |
| } | |
| phaser LEAVE(Block &passed-block) trigger BLOCK Leave { | |
| &passed-block(); | |
| } | |
| phaser KEEP(Block &passed-block) trigger BLOCK Leave { | |
| when .success { &passed-block(); } | |
| } | |
| phaser UNDO(Block &passed-block) trigger BLOCK Leave { | |
| when not(.success) { &passed-block(); } | |
| } | |
| phaser FIRST(Block &passed-block) trigger LOOP Entry { | |
| once-per $_ { &passed-block(); } | |
| } | |
| phaser NEXT(Block &passed-block) trigger LOOP Exit { | |
| when not(.done) { &passed-block(); } | |
| } | |
| # Synchronous LAST | |
| phaser LAST(Block &passed-block) trigger LOOP Exit { | |
| when .fine { &passed-block(); } | |
| } | |
| phaser PRE(Block &passed-block) trigger BLOCK Entry { | |
| if ! &passed-block() { | |
| X::Phaser::PrePost.new(phaser => "PRE", condition => &passed-block.raku).throw(OUTER); | |
| } | |
| } | |
| phaser POST(Block &passed-block) trigger BLOCK Exit { | |
| if ! &passed-block() { | |
| X::Phaser::PrePost.new(phaser => "POST", condition => &passed-block.raku).throw(OUTER); | |
| } | |
| } | |
| phaser CONTROL(Block &passed-block) trigger BLOCK Exit { | |
| when .done ~~ X::Control { | |
| &passed-block(.done) | |
| } | |
| } | |
| phaser CATCH(Block &passed-block) trigger BLOCK Exit { | |
| when .fine.not { | |
| &passed-block(.done) | |
| } | |
| } | |
| # Not sure about this one | |
| phaser QUIT(Block &passed-block) trigger BLOCK Exit { | |
| if not(.fine) and .done ~~ X::Proc::Async { | |
| &passed-block(.done) | |
| } | |
| } | |
| # Asynchronous LAST | |
| phaser LAST(Block &passed-block) trigger BLOCK Exit { | |
| if .fine(CX::Done) { | |
| &passed-block(.done) | |
| } | |
| } | |
| phaser CLOSE(Block &passed-block) trigger BLOCK Exit { | |
| if .done ~~ CX::Done { | |
| &passed-block(.done) | |
| } | |
| } | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c48BsrX"> | |
| <div class='header'> | |
| <span class='author'>@FCO</span> commented at <time datetime="2022-01-07T01:58:40Z">2022-01-07 01:58</time> | |
| </div> | |
| <div class='body'> | |
| <p>While I was reading your example I was thinking that maybe a phaser creator should work kind like a macro, I mean using AST (maybe RakuAST). I thought something like this might be cool (please ignore the faço I don't know the RakuAST classes names and I've invented some methods on it and probably some other things as well).</p> | |
| <pre><code class="language-raku">phaser PRE(AST::Block $in, AST::Statement $condition) { | |
| $in.add-before: quasi( unless {{{ $condition }}} { die "PRE error" } ) | |
| } | |
| phaser CATCH(AST::Block $in, AST::Block $block) { | |
| $in.on-exception: $block | |
| } | |
| </code></pre> | |
| <p>Does that make any sense?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c48CebN"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2022-01-07T10:00:30Z">2022-01-07 10:00</time> | |
| </div> | |
| <div class='body'> | |
| <p>@FCO I think that is indeed how some phasers (like ENTER, FIRST, PRE) will be implemented in RakuAST. Others will still need some mechanism in the runtime to get fired, though.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c48C3eg"> | |
| <div class='header'> | |
| <span class='author'>@FCO</span> commented at <time datetime="2022-01-07T12:53:11Z">2022-01-07 12:53</time> | |
| </div> | |
| <div class='body'> | |
| <p>But if the suggestion is to have a custom phaser creator, wouldn't make sense to it be something like that (just adding an option to add something to runtime)? That way we could, for example create a phaser that is only allowed to be used inside a for block and not a while block, for example, allowing someone to create a FOR-ELSE parser for example.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="307"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/307"><span class='number'>307</span></a> - <span class='title'>Destructuring assignment lhs has different semantics from the corresponding literal</span></div> | |
| <div class='author'>[open]<span class='author'>@2colours</span> opend this issue at <time datetime="2021-12-04T13:42:39Z">2021-12-04 13:42</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>Consider the following scenario. | |
| <code>my @a = <1 2>;</code> | |
| <code>my $b = 3;</code> | |
| <code>dd (@a, $b);</code> | |
| this yields <code>([1, 2], 3)</code> so the array of @a is embedded into the list. | |
| However: | |
| <code>my (@a, $b) = ([1, 2], 3);</code> | |
| <code>dd @a, $b</code> | |
| <code># Array @a = [[1, 2], 3]</code> | |
| <code># Any $b = Any</code> | |
| <code># Nil</code> | |
| The destructuring flattened and @a ate all the right handside as one array. Nothing is left for $b. The same would happen if we had @b so (@a, @b) = (@b, @a) itself could led to a crazy result - @a containing everything and @b nothing, even though the right handside was still a list of arrays.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>I don't know if there is a clear rationale behind this behavior but it's WTF-worthy in any programming language presentation. Other than being ugly and useless in this particular scenario, it can cause serious headache to the developer. I couldn't find anything about it and after all, I'm nothing but a newbie to Raku - first off, it would be good to know about this behavior. However, I have to say I can't imagine any acceptable reason for this behavior to stay because it's <strong>inconsistent. If it flattens on the left side, it should on the right side as well or vice versa. I suppose both can be reasoned but the inconsistency cannot.</strong></p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c46xa-o"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-12-04T14:09:49Z">2021-12-04 14:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>That's actually working as intended (though it's not currently documented very well; see <a href="https://github.com/Raku/doc/pull/3962">Raku/doc#3962</a> for WIP efforts to improve the related docs).</p> | |
| <p>This is a kind of tricky corner of Raku and took me a while to get my head around (see <a href="https://github.com/rakudo/rakudo/pull/4536">Rakudo/rakudo#4536</a> and the links in it for all the gory details). But here's the short version:</p> | |
| <p><code>my (@a, $b) = ([1, 2], 3);</code> is <strong>not</strong> "destructuring assignment" – it's <a href="https://docs.raku.org/language/variables#Item_and_list_assignment">list assignment</a>.</p> | |
| <p><code>my (@a, $b) := ([1, 2], 3);</code> is closer to "destructuring assignment" (though I believe the plan is for the docs to call it just "destructuring", since it really operates by binding to a signature and then destructuring that signature). Whatever we call it, though, it gets the results that it sounds like you were expecting: <code>@a</code> is <code>[1, 2]</code> and <code>$b</code> is <code>3</code>.</p> | |
| <p>I agree that this behavior can lead to a <a href="https://docs.raku.org/language/glossary#index-entry-WAT">WAT</a> at first and 100% needs to be more clearly explained in the docs.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46xbUw"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-12-04T14:19:34Z">2021-12-04 14:19</time> | |
| </div> | |
| <div class='body'> | |
| <p>Oh, and I also initially found the way list assignment flattens about as surprising as you do, which lead me to pose the question <a href="https://stackoverflow.com/questions/69226223/why-does-list-assignment-flatten-its-left-hand-side"><em>why</em> does list assignment flatten its left hand side?</a> on StackOverflow. jnthn gave a helpful answer, though I'm still not entirely sure if I would have supported the flattening semantics for list assignment if I'd been involved in that decision. (Though I might; as jnthn points out, since we <em>can</em> destructure with <code>:=</code>, there's something to be said for giving <code>=</code> different semantics if people find those useful).</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46xfIn"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2021-12-04T16:07:19Z">2021-12-04 16:07</time> | |
| </div> | |
| <div class='body'> | |
| <p>No matter what we call it, actually I don't think people would find this semantics useful - and if there is one argument for it, it's simply to stay, again, consistent.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46xfk7"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2021-12-04T16:20:09Z">2021-12-04 16:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>Actually, even that <a href="https://docs.raku.org/language/variables#Item_and_list_assignment">list assignment</a> says:</p> | |
| <blockquote> | |
| <p>The last two examples above are simple destructuring assignments that select the first item of the right-hand side list. See for a more elaborate discussion of destructuring assignments in the context of variable declarations the section on declaring a list of variables with lexical or package scope.</p> | |
| </blockquote> | |
| <p>Even though it doesn't mention @-sigilled variables explicitly, this is more than confusing because this still hints that there should be no fundamental difference. (If you ask me, having separate list assignment and item assignment <em>with different precedence</em> is just confusing enough, no need to add to that...)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46x0FE"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-04T23:48:58Z">2021-12-04 23:48</time> | |
| </div> | |
| <div class='body'> | |
| <p>Whichever way is chosen for <code>my</code> it would be confusing to somebody. The current approach is the least confusing path when it comes to array assignment. Just try this:</p> | |
| <pre><code class="language-raku">my @a; | |
| @a = [1, 2], 3; | |
| @a = ([1, 2], 3); | |
| </code></pre> | |
| <p>Both cases give you the same result. So, one would expect <code>my @a = [1, 2], 3</code> to do the same as the first assignment above. Why having it like <code>my (@a, $b)</code> must change the way the assignment happens drastically? As long as we draw no difference between <code>[1,2],3</code> and <code>([1,2],3)</code> in most other situations, what'd be the reason for the latter one to be an exception? Once again, as @codesections noticed, we talk about assignment here. In either case, the assignment receives a list.</p> | |
| <p>Apparently, use of a scalar in place of <code>@a</code> puts things into a different perspective. It enforces "singular" context, let's name it so. So, <code>$a = [1,2],3</code> results in a warning about use of 3 in sink context as only <code>[1,2]</code> array goes into <code>$a</code>. Yet, use of braces enforces the content between them to be treated as a singular entity. Thus, <code>$a = ([1,2],3)</code> will entirely become the content of <code>$a</code>.</p> | |
| <p>With this respect the fact that <code>($a, $b) = ([1, 2], 3)</code> gets kind of destructured might seem confusing until we step back a little and see the braces on the LHS. They give us a list of scalars, and thus we get a case of list assignment again.</p> | |
| <p>Then again, <a href="https://docs.raku.org/language/variables#Item_and_list_assignment">the documentation</a> still have a lot of interesting details.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46yEy-"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2021-12-05T10:36:37Z">2021-12-05 10:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't think the parallel you drew is valid. <code>my @a = [1, 2], 3</code> doesn't flatten - it contains two elements, one of which is an array. However, <code>my (@a, $b)</code> <strong>does flatten and this is exactly the inconsistency I'm talking about</strong>. Your parallel would be okay if we talked about writing <code>my @a, $b</code> for <code>my (@a, $b)</code> but that's not the thing.</p> | |
| <p>Also, correct me if I'm wrong but I also noticed that the "quasi-destructuring-assignment" @codesections showed won't work for swapping variables in place because you cannot reassign references.</p> | |
| <p>This means: <strong><code>($a, $b) = ($b, $a)</code> will work for swapping variables but <code>(@a, @b) = (@b, @a)</code> won't and there isn't even an easy way to get around this.</strong></p> | |
| <p>This is not the first problem I've encountered with using the @ sigil (anything but $ or \, to be frank).</p> | |
| <p>So far, the only argument I see is from @jnthn under that SO question of @codesections and I have to say it's anything but convincing:</p> | |
| <blockquote> | |
| <p>List assignment could, of course, have been defined in a structure-respecting way instead. These things tend to happen for multiple reasons, but for one but the language already has binding for when you do want to do structured things, and for another my ($first, @rest) = @all is just a bit too common to send folks wanting it down the binding/slurpy power tool path.</p> | |
| </blockquote> | |
| <p>Even Jonathan proposes a perfectly reasonable workaround for <code>my ($first, @rest) = @all</code> (more reasonable than this syntax in the first place) - what do we have for swapping @-sigilled variables?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46yG6E"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-12-05T11:40:16Z">2021-12-05 11:40</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>what do we have for swapping @-sigilled variables?</p> | |
| </blockquote> | |
| <p>The idiom I've seen for that is <code>(@a, @b) Z= (@b, @a)</code> (or sometimes with <code>«=»</code> instead of <code>Z=</code>).</p> | |
| <p>That's not to say that I entirely disagree with your point of view, just that we can handle that use case - and all it takes is one more character.</p> | |
| <p>(I tentatively think that, if I'd been around when this decision was made, I would have argued for <code>my ($first, @rest) = @all</code> to be non-flattening and to have handled flattening with a slurpy: <code>my ($first, *@rest) = @all</code>. Wild speculation: I wonder if the thinking at the time was that we'd have more Perl programmers around and that syntax might look confusingly like <a href="https://docstore.mik.ua/orelly/perl2/advprog/ch03_02.htm">perl's typeglobs</a>?)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46yMhN"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2021-12-05T14:09:47Z">2021-12-05 14:09</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I don't think the parallel you drew is valid. <code>my @a = [1, 2], 3</code> doesn't flatten - it contains two elements, one of which is an array. However, <code>my (@a, $b)</code> does flatten and this is exactly the inconsistency I'm talking about.</p> | |
| </blockquote> | |
| <p>Yes, but assigning into an array and list assignment are two very distinct things (as in, these are two different types, each with their own <code>STORE</code> implementation). An <code>Array</code> creates new <code>Scalar</code> containers for each array element. A <code>List</code> is in itself immutable, so the only way it can have assignment semantics is when the <code>List</code> was created with assignable things.</p> | |
| <blockquote> | |
| <p><code>my ($first, *@rest) = @all</code></p> | |
| </blockquote> | |
| <p>When we have an assignment, the LHS is just a <code>List</code>, and so there is no way to convey the <code>*</code>.</p> | |
| <p>In general, assignment is a relatively late-bound thing. Any aggregate type can implement how it wants to react to an assignment by implementing the <code>STORE</code> method. So <code>($first, @rest) = @all</code> compiles into <code>($first, @rest).STORE(@all)</code>. So what's really being argued over here is the semantics of <code>List.STORE</code>.</p> | |
| <p>By contrast, binding is a compiler special form. Types don't get to control how binding to them works. <code>my ($first, *@rest) = @all</code> works because what's on the LHS is a <code>Signature</code> and thus it compiles into a signature bind (with <code>@all</code> first coerced into a <code>Capture</code>). In Raku, destructuring and signature binding are the same thing, meaning that the entire power of the signature language is available.</p> | |
| <p>I suspect the docs probably do mention "destructuring assignment" somewhere, but I think destructuring should only ever really be used to talk about the binding form.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46yTxo"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2021-12-05T17:09:21Z">2021-12-05 17:09</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Yes, but assigning into an array and list assignment are two very distinct things</p> | |
| </blockquote> | |
| <p>Please keep in mind that you brought up "assigning into an array", I was trying to talk about lists (or something that appears to be lists) on the two sides of assignment.</p> | |
| <p>What you just mentioned with STORE makes stuff even more interesting - if <code>($first, @rest) = @all</code> indeed boils down to <code>($first, @rest).STORE(@all)</code>, does that mean that a non-flattening list implements STORE with flattening semantics?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46yZzX"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-12-05T20:04:15Z">2021-12-05 20:04</time> | |
| </div> | |
| <div class='body'> | |
| <p>@2colours You probably mean something different, not flattening. Just consider:</p> | |
| <pre><code>sub foo(*@a) { dd @a }; foo [1,2],3; | |
| my @a is List = [1,2],3; dd @a; dd @a.flat; | |
| </code></pre> | |
| <blockquote> | |
| <p>However, <code>my (@a, $b)</code> <strong>does flatten and this is exactly the inconsistency I'm talking about</strong>.</p> | |
| </blockquote> | |
| <p>It doesn't because RHS ends up in <code>@a</code> exactly as it is.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46yfgS"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2021-12-05T22:45:06Z">2021-12-05 22:45</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Please keep in mind that you brought up "assigning into an array"</p> | |
| </blockquote> | |
| <p>No, I just used the standard Raku terminology. You wrote <code>my @a = [1, 2], 3</code>. <code>@a</code> is an <code>Array</code>. It is being assigned into. Desugared, it's approximately <code>my @a := Array.new; @a.STORE(([1, 2], 3));</code>.</p> | |
| <blockquote> | |
| <p>I was trying to talk about lists</p> | |
| </blockquote> | |
| <p>But "lists" is just some hand-wavy term; if we want to discuss language semantics, precision would be helpful. You wrote one example where the target of the assignment operation is an <code>Array</code> (<code>my @a = ...</code>) and another that alluded to the target of the assignment operation being a <code>List</code> (<code>my (@a, $b) = ...</code>).</p> | |
| <blockquote> | |
| <p>does that mean that a non-flattening list implements STORE with flattening semantics?</p> | |
| </blockquote> | |
| <p>There's no such concept as a non-flattening <code>List</code> (nor a flattening <code>List</code>); flattening or not is a property of an operation. There's just the semantics of <code>List.STORE</code>, which are:</p> | |
| <ul> | |
| <li>Obtain an iterator over the data source, and then... | |
| <ul> | |
| <li>If the target is a <code>Scalar</code> container, pull one value from the iterator and assign it</li> | |
| <li>Otherwise, pass what remains to the <code>STORE</code> of the target</li> | |
| </ul> | |
| </li> | |
| </ul> | |
| <p>And the semantics of <code>Array.STORE</code>, which are:</p> | |
| <ul> | |
| <li>Discard the current content of the <code>Array</code>, if any</li> | |
| <li>Obtain an iterator over the data source, and then... | |
| <ul> | |
| <li>Pull a value from the iterator, assign it into a <code>Scalar</code> container, and bind that into the next array element</li> | |
| </ul> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46yizG"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2021-12-06T00:01:48Z">2021-12-06 00:01</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>No, I just used the standard Raku terminology</p> | |
| </blockquote> | |
| <p>At this point, I'm not even sure what you are talking about. Please let's just agree about the fact that <code>@a = [1, 2], 3;</code> and ˙@a = ([1, 2], 3);<code>do the same thing has nothing to do with the semantics of</code>(@a, $b)<code>or</code>(@a, @b)` either on the left handside or the right handside of an assignment. The rest is besides the point.</p> | |
| <blockquote> | |
| <p>You wrote one example where the target of the assignment operation is an Array (my @a = ...) and another that alluded to the target of the assignment operation being a List (my (@a, $b) = ...).</p> | |
| </blockquote> | |
| <p>Again, I have a hard time believing that you really don't know what I mean. Sorry that I haven't spent years of designing and implementing language backends and Raku in particular and in before, I'm not an English native, either. However, it seems to me that @codesections managed to understand my point just fine after having wondered about the same thing earlier.<br /> | |
| <em>In the context of <code>dd (@a, $b)</code>, <code>(@a, $b)</code> means a nested list and in the context of <code>(@a, $b) = =([1, 2], 3)</code>, the same <code>(@a, $b)</code> means a flat list. Am I being clear enough?</em></p> | |
| <blockquote> | |
| <p>There's no such concept as a non-flattening List (nor a flattening List); flattening or not is a property of an operation</p> | |
| </blockquote> | |
| <p>Again, I feel this might be a bit unnecessary. <code>(@a, $b)</code> doesn't flatten when accessed as data. This means that the list itself has the data with the structure preserved.<br /> | |
| The latter is the important point. From what I can tell, at the point of calling STORE, the structure is still preserved - what I take from this with a bit of a stretch is: the flattening behavior happens at a relatively high level and hence it's mostly a design decision, not a technical constraint. Blantly put: it works like this not because it has to but because this option won.</p> | |
| <p>Anyways, I don't want to appear thankless - in fact I appreciate your pointers about the implementation of list assignment and the STORE method. This can help me understand the language better either way.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c46yk29"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2021-12-06T00:31:48Z">2021-12-06 00:31</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>It doesn't because RHS ends up in @a exactly as it is.</p> | |
| </blockquote> | |
| <p>Actually this is just a different matter of phrasing: you phrased it as someone who knows the implementation that Jonathan explained while I phrased it like codesections in the Stackoverflow question - as someone who tries to describe the experienced semantics. I hope this clears things up.</p> | |
| <p>This is a bit like talking about "sunrise". From what we know scientifically. The Sun doesn't "rise" even according to the obsolete terms of mechanics but the experience is the same as if it rose.</p> | |
| <p>I never regret knowing more about how these assignments actually work - it also makes me think that there aren't serious technical constraints to consider when choosing the semantics of these assignments. Therefore I would stick to the original question: what other arguments lead to accepting this behavior as intended?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c460Ec9"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2021-12-06T12:24:07Z">2021-12-06 12:24</time> | |
| </div> | |
| <div class='body'> | |
| <p>@codesections I tried Z= and «=», they don't work: | |
| <code>my @a = 1,2;</code> | |
| <code>my @b = 3,4;</code> | |
| <code>(@a, @b) Z= (@b, @a);</code> | |
| <code>dd @a, @b;</code> | |
| yields | |
| <code>Array @a = [3, 4]</code> | |
| <code>Array @b = [3, 4]</code> | |
| I assume this is the same issue why you can't just write <code>@a = @b; @b = @a;</code></p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5ODmRx"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-10T00:06:04Z">2022-11-10 00:06</time> | |
| </div> | |
| <div class='body'> | |
| <p>Almost a year passed, and I'm thinking what to do with this issue.</p> | |
| <p>Even though I still think it would be easier to live without any "list assignment" but I did see some useful properties of Array containers (like being able to present the same underlying containers in different ways while maintaining mutability of the very same data) so I'm rather thinking on the next step than "fixing" the current <code>(@a, @b) = (@b, @a)</code> semantics.</p> | |
| <p>I have the impression that the simplest and most consistent solution would be to support "itemized non-scalar" as a first class thing, different from a non-scalar container inside a scalar container. The name is not important - the important thing is that it STOREs into the underlying non-scalar on assignment, however, it exposes this operation as an "item/scalar assignment". Now, there could be a syntax (e.g a sigil) for wrapping a <code>@variable</code> (or a <code>%variable</code>) into this dummy so that something like <code>(§@a, §@b) = (@b, @a)</code> could work exactly as I originally wished for <code>(@a, @b) = (@b, @a)</code>.</p> | |
| <p>To be honest, I'm not sure if the proposal is worth it but it would be nice to have. Maybe I could take on it if I learned something about the internals of Rakudo. I wonder if a demo implementation could be created using pure Raku and proxies.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OEAW6"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-10T02:13:48Z">2022-11-10 02:13</time> | |
| </div> | |
| <div class='body'> | |
| <p>Let me show you a simple way of locally "switch" your variables (using "binding" not "assignment"):</p> | |
| <pre><code class="language-raku">my @a = <a b c d>; | |
| my @b = 1,2,3,4; | |
| for @a, @b -> @b, @a { | |
| say "a:", @a; | |
| say "b:", @b; | |
| } | |
| # a:[1 2 3 4] | |
| # b:[a b c d] | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OEIwC"> | |
| <div class='header'> | |
| <span class='author'>@2colours</span> commented at <time datetime="2022-11-10T03:08:41Z">2022-11-10 03:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>Binding does work indeed but it comes with some gotchas even in the plain <code>(@a, @b) := (@b, @a)</code> form. The syntax looks nice but the semantics is too different from swapping the content of two arrays.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5OEQej"> | |
| <div class='header'> | |
| <span class='author'>@salortiz</span> commented at <time datetime="2022-11-10T04:03:49Z">2022-11-10 04:03</time> | |
| </div> | |
| <div class='body'> | |
| <p>Long before <code>(@a, @b) := (@b, @a)</code> can work, you'd need to be able to rebound an already bounded variable. But as soon as you <em>declare</em> a variable in any lexical scope it is bounded:</p> | |
| <pre><code class="language-raku">my @a; | |
| @a := <a b c>; # Error at compile time: Cannot bind to '@a' because it was bound… | |
| </code></pre> | |
| <p>At raku´s high level, a "binding" is a one time operation (at lexical scope entering/cloning).</p> | |
| <p>But nothing forbids you to implement, using raku's low level machinery, an slang where you can play dirty with the lexpad. :-)</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="306"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/306"><span class='number'>306</span></a> - <span class='title'>No easy way to inspect distributions</span></div> | |
| <div class='author'>[open]<span class='author'>@skaji</span> opend this issue at <time datetime="2021-11-29T16:45:13Z">2021-11-29 16:45</time></div> | |
| </div> | |
| <div class='body'> | |
| <h2>a short description of the problem</h2> | |
| <p>I think there is no easy way to inspect distributions.</p> | |
| <h2>more details</h2> | |
| <p>Let's say we use <code>Module</code> in our script:</p> | |
| <pre><code class="language-raku">use Module; | |
| my $mod = Module.new; | |
| ... | |
| </code></pre> | |
| <p>Sometimes I want to inspect the distribution which <code>Module</code> belongs to. | |
| Especially I want to know:</p> | |
| <ul> | |
| <li>distribution name</li> | |
| <li>version and auth of distribution</li> | |
| <li>resource files of distribution</li> | |
| </ul> | |
| <p>But currently there is no easy way to do it, I think.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c5CyXZO"> | |
| <div class='header'> | |
| <span class='author'>@coke</span> commented at <time datetime="2022-05-08T22:39:41Z">2022-05-08 22:39</time> | |
| </div> | |
| <div class='body'> | |
| <pre><code>$ zef info App::Uni | |
| - Info for: App::Uni | |
| - Identity: App::Uni:ver<1.0.2> | |
| - Recommended By: Zef::Repository::LocalCache | |
| - Installed: No | |
| Description: command-line utility to find or display Unicode characters | |
| License: Artistic-2.0 | |
| Source-url: git://github.com/coke/p6-uni.git | |
| Provides: 1 modules | |
| Depends: 0 items | |
| </code></pre> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="305"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/305"><span class='number'>305</span></a> - <span class='title'>Semi-predicate situation with `is required` and defaults on native attributes</span></div> | |
| <div class='author'>[open]<span class='author'>@jnthn</span> opend this issue at <time datetime="2021-11-11T15:59:44Z">2021-11-11 15:59</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Example for <code>is required</code>:</p> | |
| <pre><code>class C { | |
| has int $.x is required; | |
| } | |
| say C.new(x => 1); # C.new(x => 1) | |
| say C.new(x => 0); # Dies: The attribute '$!x' is required, but you did not provide a value for it. | |
| </code></pre> | |
| <p>Example for defaults:</p> | |
| <pre><code>class C { | |
| has int $.x = -1 | |
| } | |
| say C.new(x => 1); # C.new(x => 1) | |
| say C.new(x => 0); # C.new(x => -1) | |
| </code></pre> | |
| <p>I noticed this while working on <a href="https://github.com/rakudo/rakudo/pull/4633">elimination of the mechanism currently used for required/defaults</a>, and have preserved current semantics in that PR (because I'm primarily working on it to save myself some epic headaches when working on upcoming escape analysis improvements, and also for a smaller performance and JITted code size win on attribute access).</p> | |
| <p>Natively typed attributes are represented in memory as the value, stored directly in the memory allocated for the object body. That's it. No <code>Scalar</code> container we can hang a descriptor off or use nullness of as a sentinel for "not initialized", for example, unlike with object attributes. Thus currently the default value and <code>is required</code> features go on the value itself, resulting in - taking <code>int</code> as an example - a situation where <code>0</code> indicates both "unassigned" but is itself a valid value. This feels worth a review and decision about what we want.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c45mpkY"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2021-11-11T16:16:28Z">2021-11-11 16:16</time> | |
| </div> | |
| <div class='body'> | |
| <p>Some reasonable (in that I can argue for each of them) options that come to mind:</p> | |
| <ol> | |
| <li>Deprecate <code>is required</code> and defaults on attribute values in 6.e, on the basis that we'd prefer language users don't get caught out by this behavior. It seems use of <code>is required</code> on native attributes in modules is very rare. Defaults are far more common, so this would hurt a bit.</li> | |
| <li>Leave it alone, on the basis that natively typed attributes are relatively rarely used anyway, that native types always have edges, and/or that the current semantics are the only ones that a language user who understands what natively typed attributes in Raku are could expect anyway.</li> | |
| <li>Only support them in the case where there is no user-defined <code>BUILD</code>, in which case we can determine whether it was missing by looking at the incoming construction parameters (it's thanks to <code>BUILD</code> and anything it calls being able to assign to attributes that we need a means to determine if they were assigned). This makes for a more complicated edge case, but perhaps nicely blends non-regression of existing code and usefulness with an avoidance of exposing a feature vulnerable to the semi-predicate issue. It's a mild extra complication in build plan handling.</li> | |
| </ol> | |
| <p>An unreasonable option I'll argue against: try to represent native types differently if the have an <code>is required</code> or a default, e.g. adding an extra, secret, attribute that we also assign to indicate it was set. If language users are using native types it's probably for better control over memory size, so sneaking in more memory usage is unhelpful. Further, it'd be a nuisance to implement even inefficiently.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45ms8m"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-11-11T16:34:54Z">2021-11-11 16:34</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>Deprecate <code>is required</code> and defaults on attribute values in 6.e</p> | |
| </blockquote> | |
| <p>I assume ^^^ was a typo for "on natively typed attribute values"? On that assumption, I can see merits in all three options but might opt for an option 1.5 – namely, make <code>is required</code> with native types a warning in 6e.</p> | |
| <p>One reason a warning seems preferable to a ban is that, due to the limited expressiveness of native types, sometimes a zero value is signalling an error/missing value in user code as well (or, said differently, user code also faces the semi-predicate problem). It would be a shame for a user to have code where they'd really like to require a non-zero <code>int</code> and have Raku not let them require an <code>int</code> because it'd give them exactly what they want!</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45mvrM"> | |
| <div class='header'> | |
| <span class='author'>@jnthn</span> commented at <time datetime="2021-11-11T16:50:22Z">2021-11-11 16:50</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>I assume ^^^ was a typo for "on natively typed attribute values"?</p> | |
| </blockquote> | |
| <p>Yes, everything suggested is only about natively typed attributes.</p> | |
| <blockquote> | |
| <p>On that assumption, I can see merits in all three options but might opt for an option 1.5 – namely, make is required with native types a warning in 6e.</p> | |
| </blockquote> | |
| <p>And presumably to defaults (<code>has int $.x = 0;</code>) also, given it's the same situation?</p> | |
| <blockquote> | |
| <p>One reason a warning seems preferable to a ban is that, due to the limited expressiveness of native types, sometimes a zero value is signalling an error/missing value in user code as well (or, said differently, user code also faces the semi-predicate problem). It would be a shame for a user to have code where they'd really like to require a non-zero int and have Raku not let them require an int because it'd give them exactly what they want!</p> | |
| </blockquote> | |
| <p>I wonder if we could let the language user suppress the warning by providing an <code>is default</code> to specify the value that they consider to be the error/missing value. So <code>has int $.x is required is default(-1);</code> would have the value set to be <code>-1</code> right at object creation time, and use that as the basis for comparison of whether the attribute was assigned or not. Effectively, allowing the user to specify a value that they consider not vulnerable to the semi-predicate issue.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45m4e_"> | |
| <div class='header'> | |
| <span class='author'>@Kaiepi</span> commented at <time datetime="2021-11-11T17:41:09Z">2021-11-11 17:41</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm not sure <code>is required</code> on a native attribute should do anything ordinarily. The absence of any bits is a value in and of itself for these types, and attempting to type them to have a definiteness of sorts blurs the lines between them and their boxings. Doing nothing allows the trait to serve as a hint to the reader when values are being forwarded from <code>new</code>. If the absence of a value is desired, the boxing is desired, so a warning would stiil be OK, but moreso in cases where the boxing would be more appropriate inferrably, e.g. a forwarded <em>object</em> with an insufficient typing.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45nOXH"> | |
| <div class='header'> | |
| <span class='author'>@patrickbkr</span> commented at <time datetime="2021-11-11T19:57:22Z">2021-11-11 19:57</time> | |
| </div> | |
| <div class='body'> | |
| <p>Is native attributes a thing used so often we should try to huffmanize / provide convenience for? | |
| One could always just do:</p> | |
| <pre><code>class B { | |
| has int $.foo is built(False); | |
| submethod TWEAK(int :$foo!) { $!foo = $foo } | |
| } | |
| </code></pre> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="304"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/304"><span class='number'>304</span></a> - <span class='title'>INIT blocks in module does not behave nicely</span></div> | |
| <div class='author'>[open]<span class='author'>@Skarsnik</span> opend this issue at <time datetime="2021-11-08T21:10:39Z">2021-11-08 21:10</time></div> | |
| </div> | |
| <div class='body'> | |
| <!--- Write a short description of the problem here. --> | |
| <p>INIT block in an exported sub inside a module file is called even if the sub is called inside a BEGIN phaser. | |
| Note that this does not happen if the module and the caller code are in the same file.</p> | |
| <!--- Provide more details here. *Do not* propose a solution. You can propose a solution later in the comments. --> | |
| <p>Example Piko.rakumod. I added other phasers to see how they behave too. I stumble across this trying to forbid a sub to be run at compile time.</p> | |
| <pre><code>module Piko { | |
| sub foo is export { | |
| say "Piko::foo"; | |
| my $run-time; | |
| CHECK {say "CHECK : ", defined $run-time} | |
| BEGIN {say "BEGIN : ", defined $run-time} | |
| INIT { say "INIT : ", defined $run-time; | |
| $run-time = True; }; | |
| ENTER {say "ENTER : ", defined $run-time} | |
| LEAVE {say "LEAVE : ", defined $run-time} | |
| say "Before the test for defined", defined $run-time; | |
| die "Compile time" unless defined $run-time; | |
| say $run-time; | |
| } | |
| } | |
| </code></pre> | |
| <p>If I use the module for example like that. (Note the BEGIN foo();)</p> | |
| <pre><code>[skarsnik@localhost perl6-gumbo]$ ../../rakudo-2021.09/install/bin/rakudo -I ~/rakudo/lib/ -I ./ -M Piko -e 'BEGIN foo();' | |
| INIT : False | |
| ENTER : True | |
| Piko::foo | |
| Before the test for definedTrue | |
| True | |
| LEAVE : True | |
| [skarsnik@localhost perl6-gumbo]$ | |
| </code></pre> | |
| <p>We can see that the INIT phaser gets called. I am not very familiar with the precompilation process but it could probably be the correct behaviour too since we are in the running phase of the module when we do <code>use Module</code>? BEGIN and CHECK are only called at the module pre-comp phase (not sure if that is also correct?)</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c45eKVL"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-11-09T14:34:14Z">2021-11-09 14:34</time> | |
| </div> | |
| <div class='body'> | |
| <p>My (perhaps incorrect/incomplete) understanding is that this behavior is correct and is a consequence of the way Raku allows nesting of compile times and run times. (E.g., <code>EVAL</code> is a nested compile time inside the program's run time – which is why it can say that it's <code>===SORRY!===</code>, indicating a compile-time error). So, even though the module is being executed inside the run time of your program, it has it's own nested compile and run times and triggers the corresponding phasers for each.</p> | |
| <p>… or, at least, I think that's what's happening. The idea of nested compile times isn't currently well-documented, and I'm not 100% certain of the details.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="303"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/303"><span class='number'>303</span></a> - <span class='title'>Signature parameter introspection for type smileys/signature modifiers</span></div> | |
| <div class='author'>[open]<span class='author'>@CIAvash</span> opend this issue at <time datetime="2021-10-09T12:52:25Z">2021-10-09 12:52</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>I see no way of finding if a parameter is definite, in roast, unless I missed it. Raku docs don't have any information about it either.</p> | |
| <p>The only way I found that works(I think!) is smartmatching against a <code>Parameter</code>. Maybe there is another way that I'm not aware of.</p> | |
| <p>Example:</p> | |
| <pre><code class="language-raku">sub f (Int:D $x) {}; | |
| say :(Int:D).params[0] ~~ &f.signature.params[0] # True | |
| </code></pre> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c43_HjO"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2021-10-09T12:56:08Z">2021-10-09 12:56</time> | |
| </div> | |
| <div class='body'> | |
| <p>I don't know if this is the solution, but Rakudo has a <code>modifier</code> method for <code>Parameter</code> class:</p> | |
| <pre><code class="language-raku">sub f (Int:D $x) {}; | |
| say &f.signature.params[0].modifier # :D | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45eGj3"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-11-09T14:17:40Z">2021-11-09 14:17</time> | |
| </div> | |
| <div class='body'> | |
| <p>+1 to the idea of adding Rakudo's <code>Parameter.modifier</code> to Roast. It's been present (and fairly stable) <a href="https://github.com/rakudo/rakudo/commit/231b898b722dbcc44b00c5d80909e742b68549d9">since 2016</a>, it's not marked as an implementation detail, and it's consistent with the other <code>Parameter</code> methods.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="302"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/302"><span class='number'>302</span></a> - <span class='title'>API reconciliation between Blob/Buf, CArray, and native array</span></div> | |
| <div class='author'>[open]<span class='author'>@japhb</span> opend this issue at <time datetime="2021-10-04T22:44:13Z">2021-10-04 22:44</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>The APIs of <code>Blob</code>/<code>Buf</code>, <code>CArray</code>, and native <code>array</code> overlap, but still have significant differences that aren't obviously related to their different purposes. In fact they seem to be simply <a href="https://logs.liz.nl/raku-dev/2021-10-03.html#20:06">accidents of history</a>.</p> | |
| <p>For example, <code>Blob</code>/<code>Buf</code> has both 1- and 2-argument <a href="https://github.com/rakudo/rakudo/blob/master/src/core.c/Buf.pm6#L78"><code>allocate</code></a>, <code>CArray</code> only has 1-argument <a href="https://github.com/rakudo/rakudo/blob/master/lib/NativeCall/Types.rakumod#L114"><code>allocate</code></a>, and native <code>array</code> has neither.</p> | |
| <p>We should <em>intentionally</em> decide which API bits should be supported by all (or most) of them, and which are truly unique to the purposes of each. We should then fill in any missing methods of each group, and use the fastest known implementation style for all instances of each common method.</p> | |
| <p>Finally, for cases where it is meaningful to see the same data through a different "API lens", there ought to be both zero-copy and fast single-copy ways to access that data in the other APIs.</p> | |
| </div> | |
| <div class='comments'> | |
| </div> | |
| </div> | |
| <div class='issue' id="301"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/301"><span class='number'>301</span></a> - <span class='title'>Issues with the design of `assuming` method</span></div> | |
| <div class='author'>[open]<span class='author'>@CIAvash</span> opend this issue at <time datetime="2021-10-03T11:35:19Z">2021-10-03 11:35</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>While I was working on my <a href="https://github.com/CIAvash/Curry">Curry</a> module, I stumbled upon things that I consider issues. Now, some of them might be bugs, but most of them seem to be by design, if you look at <a href="https://github.com/Raku/roast/tree/master/S06-currying">roast</a>; although they might be against the <a href="https://design.raku.org/S06.html#Priming">design documents</a>(if I've interpreted it correctly), though that is not what defines the language.</p> | |
| <p>In short, it changes function's signature and loses information and data. | |
| Maybe I don't know the reasons behind its current design, but I'll list them here to know what others think.</p> | |
| <p><code>assuming</code></p> | |
| <ol> | |
| <li>loses the default value of optional positional parameters | |
| <pre><code class="language-raku">sub f1 ($a, $b = 2) { | |
| $a + $b; | |
| } | |
| say &f1.assuming(1).signature.raku; | |
| # :($b?) | |
| say &f1.assuming(1).signature.params[0].default.defined; | |
| # False | |
| say &f1.assuming(1)(); | |
| # Use of Nil in numeric context | |
| # ... | |
| # 1 | |
| </code></pre> | |
| </li> | |
| <li> | |
| <ol> | |
| <li>removes default value of named parameters from signature of functions, but keeps its default value | |
| <pre><code class="language-raku">sub f2 ($a, :$b = 2) { | |
| $a + $b; | |
| } | |
| say &f2.signature.raku; | |
| # :($a, :$b = 2) | |
| say &f2.assuming(1).signature.raku; | |
| # :(:$b) | |
| say &f2.assuming(1).signature.params[0].default.defined; | |
| # False | |
| say &f2.assuming(1)(); | |
| # 3 | |
| </code></pre> | |
| </li> | |
| <li>loses default value of definite named parameters: | |
| <pre><code class="language-raku">sub f2_2 ($a, Int:D :$b = 2) { | |
| $a + $b; | |
| } | |
| say &f2_2.signature.raku; | |
| # :($a, Int:D :$b = 2) | |
| say &f2_2.assuming(1).signature.raku; | |
| # :(Int:D :$b) | |
| say &f2_2.assuming(1).signature.params[0].default.defined; | |
| # False | |
| say &f2_2.assuming(1)(); | |
| # Parameter '$b' of routine '__PRIMED_ANON' must be an object instance of | |
| # type 'Int', not a type object of type 'Int'. Did you forget a '.new'? | |
| # ... | |
| </code></pre> | |
| </li> | |
| </ol> | |
| </li> | |
| <li>keeps the named parameter, even though the named argument was applied (roast says "Since you can override named params .assuming does not alter sig") | |
| <pre><code class="language-raku">sub f3 ($a, :$b) { | |
| $a + $b; | |
| } | |
| say &f3.assuming(:b(2)).signature.raku; | |
| # :($a, :$b) | |
| say &f3.assuming(:b(2))(1, :b(3)); | |
| # 4 | |
| sub f4 ($a, :$b!) { | |
| $a + $b; | |
| } | |
| say &f4.assuming(1).signature.raku; | |
| # :(:$b!) | |
| say &f4.assuming(:b(2)).signature.raku; | |
| # :($a, :$b) | |
| say &f4.assuming(:b(2))(1, :b(3)); | |
| # 4 | |
| </code></pre> | |
| </li> | |
| <li>removes parameter constraints from signature, but constraints are applied when partial function is called | |
| <pre><code class="language-raku">sub f5 ($a, @b where .all ~~ Int) { | |
| [×] $a, |@b; | |
| } | |
| say &f5.signature.raku; | |
| # :($a, @b where { ... }) | |
| say &f5.signature.params[1].constraints.raku; | |
| # all(-> ;; $_ { #`(Block|73998640) ... }) | |
| say &f5.assuming(2).signature.raku; | |
| # :(@b) | |
| say &f5.assuming(2).signature.params[0].constraints.raku; | |
| # all() | |
| sub f6 ($a, &b:(Int :$c!)) { | |
| b c => $a; | |
| } | |
| say &f6.signature.raku; | |
| # :($a, &b where { ... }) | |
| say &f6.signature.params[1].constraints; | |
| # all(-> ;; $_ { #`(Block|77388240) ... }) | |
| say &f6.assuming(2).signature.raku; | |
| # (&b) | |
| say &f6.assuming(2).signature.params[0].constraints; | |
| # all() | |
| </code></pre> | |
| </li> | |
| <li>doesn't set the type of a parameter whose type has been captured (roast mentions the design being incomplete), but its type will actually be checked | |
| <pre><code class="language-raku">sub f7 (::T $a, T $b) { | |
| [×] $a, $b; | |
| } | |
| say &f7.assuming(2).signature.raku; | |
| # ($b) | |
| say &f7.assuming(2).signature.params[0].type; | |
| # (Any) | |
| </code></pre> | |
| </li> | |
| <li>removes sub-signature from parameters, but type check will be done | |
| <pre><code class="language-raku">sub f8 ($a, @b (Int $c, Str $d)) { | |
| [×] $a, $c, $d; | |
| } | |
| say &f8.signature.raku; | |
| # :($a, @b (Int $c, Str $d)) | |
| say &f8.signature.params[1].sub_signature.raku; | |
| # :(Int $c, Str $d) | |
| say &f8.assuming(2).signature.raku; | |
| # (@b) | |
| say &f8.assuming(2).signature.params[0].sub_signature.raku; | |
| # Signature | |
| </code></pre> | |
| </li> | |
| </ol> | |
| <p>There might be other things I have not tried.</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c43_E_4"> | |
| <div class='header'> | |
| <span class='author'>@CIAvash</span> commented at <time datetime="2021-10-09T11:38:32Z">2021-10-09 11:38</time> | |
| </div> | |
| <div class='body'> | |
| <p>Another case:</p> | |
| <p>2.2. loses default value of definite named parameters:</p> | |
| <pre><code class="language-raku">sub f2_2 ($a, Int:D :$b = 2) { | |
| $a + $b; | |
| } | |
| say &f2_2.signature.raku; | |
| # :($a, Int:D :$b = 2) | |
| say &f2_2.assuming(1).signature.raku; | |
| # :(Int:D :$b) | |
| say &f2_2.assuming(1).signature.params[0].default.defined; | |
| # False | |
| say &f2_2.assuming(1)(); | |
| # Parameter '$b' of routine '__PRIMED_ANON' must be an object instance of | |
| # type 'Int', not a type object of type 'Int'. Did you forget a '.new'? | |
| # ... | |
| </code></pre> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45eHbF"> | |
| <div class='header'> | |
| <span class='author'>@codesections</span> commented at <time datetime="2021-11-09T14:21:22Z">2021-11-09 14:21</time> | |
| </div> | |
| <div class='body'> | |
| <p>In my view, these are all bugs – and should get much easier to solve with Raku AST (<code>.assuming</code> really <em>wants</em> to be a macro!) See <a href="https://stackoverflow.com/questions/66626104/what-is-the-difference-between-using-rakus-code-assuming-method-and-using-an-an">this stack overflow question</a> for some related discussion.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="299"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/299"><span class='number'>299</span></a> - <span class='title'>Edge cases of nominalizable typeobjects interactions</span></div> | |
| <div class='author'>[open]<span class='author'>@vrurg</span> opend this issue at <time datetime="2021-09-22T21:01:28Z">2021-09-22 21:01</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Let me start with an example where the problem is most apparent:</p> | |
| <pre><code class="language-raku">class C { | |
| method Int { 42 } | |
| } | |
| subset Foo of Int(); | |
| subset Bar of Foo:D; | |
| my Bar $x = C; # This must work | |
| C ~~ Bar; # Is it True or False? | |
| </code></pre> | |
| <p>The straightforward approach tells that the assignment must be ok because the class coerces into a concrete value. But what about the smartmatch outcome?</p> | |
| <p>rakudo/rakudo#1405 can be used as an example of another similar edge case:</p> | |
| <pre><code class="language-raku">subset Foo of Numeric(Cool) where Num:D|Rat:D; | |
| "42" ~~ Foo | |
| </code></pre> | |
| <p>The only way for this smartmatch to be <em>True</em> is to coerce the LHS first. This is what subsets currently do: they match LHS against the coercion first, then coerce, then match against <code>where</code>. This approach results in a somewhat unexpected side effect:</p> | |
| <pre><code class="language-raku">class C { method Int { Int } } | |
| subset Foo of Int() where *.defined; | |
| subset Bar of Int:D(); | |
| C ~~ Foo; # False | |
| C ~~ Bar; # True | |
| </code></pre> | |
| <p>Though this behavior is explainable exactly in terms of <code>where</code> being applied to the coercion result as a final refinement of subset constraint. Contrary, the second case is interpreted as the coercion accepting a value but not guaranteeing it to be successfully coerced.</p> | |
| <p>By getting back to the chained subsets, one can use another approach to get similar result:</p> | |
| <pre><code class="language-raku">constant Foo = Int(); | |
| constant Bar = Foo:D; | |
| </code></pre> | |
| <p>But where a <code>subset</code> could be considered as a threshold at which one could expect the matching value to be coerced, this case is more akin to <code>Int():D</code> declaration (even though we don't have this syntax). In other words, when <code>Foo</code> and <code>Bar</code> are subsets we can expect <code>Foo</code> being applied to smartmatch LHS, and then <code>Bar</code> – to the outcome of coercion performed by <code>Foo</code>. But in the <code>constant</code> case we have pure aliasing where the compiler can't clearly determine if coercion must be done without hints from the grammar about the context in which <code>Bar</code> was created.</p> | |
| <p>The whole issue arose from rakudo/rakudo#4531 which is rather simple, but still has its own value in this case.</p> | |
| <pre><code class="language-raku">my Int:D() $x; | |
| </code></pre> | |
| <p>It'd be natural to expect this to result in <em>Variable definition of type Int:D() needs to be given an initializer</em> error. But it is not because the implicit default <code>Int</code> is accepted by the coercion typeobject. And because we don't assign the default to container but only typecheck it, we end up with <code>Int</code> in <code>$x</code>. But this is clearly goes against the constraint. Theoretically, the current implementation of Rakudo allows just to check if the type constraint requires a definite because container descriptor default would be set to the nominal typeobject (<code>Int</code> in the above case). But there is a non-zero chance that a trait would mangle with the default and set it to something that coerces into <code>Int:D</code> (see the class <code>C</code> at the top).</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c43J3Fr"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-09-22T21:08:58Z">2021-09-22 21:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>I have had to put a work on fix for 4531 on hold due to the above stated uncertainties. What seems to be the correct approach would require quite a number of extra invocations of the coercion protocol which isn't cheap. I hope <code>new-disp</code> would make it much faster, but it's only a hope.</p> | |
| <p>@jnthn, may I request your expertise?</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="298"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/298"><span class='number'>298</span></a> - <span class='title'>Consider renaming default branch from master to main</span></div> | |
| <div class='author'>[closed]<span class='author'>@coke</span> opend this issue at <time datetime="2021-09-16T02:05:35Z">2021-09-16 02:05</time></div> | |
| </div> | |
| <div class='body'> | |
| <p>Please consider renaming the default branch for existing Raku-related repositories from master to main.</p> | |
| <p>https://sfconservancy.org/news/2020/jun/23/gitbranchname/</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c424IUX"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-09-16T08:08:32Z">2021-09-16 08:08</time> | |
| </div> | |
| <div class='body'> | |
| <p>FWIW, I think the plan is to have the RakuAST branch become "main" at some point for rakudo/rakudo.</p> | |
| <p>But generally the problem is really the number of outstanding PRs that would get invalidated by the default branch change, no?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c425TKf"> | |
| <div class='header'> | |
| <span class='author'>@coke</span> commented at <time datetime="2021-09-16T15:11:35Z">2021-09-16 15:11</time> | |
| </div> | |
| <div class='body'> | |
| <p>I think GitHub automatically fixes those.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c425hzR"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-09-16T16:26:41Z">2021-09-16 16:26</time> | |
| </div> | |
| <div class='body'> | |
| <p>They do? That would be excellent. It was my impression that they didn't, so a reason not to just move forward on this.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c4258da"> | |
| <div class='header'> | |
| <span class='author'>@coke</span> commented at <time datetime="2021-09-16T18:54:18Z">2021-09-16 18:54</time> | |
| </div> | |
| <div class='body'> | |
| <p>https://github.com/github/renaming#renaming-existing-branches</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c5QMakx"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2022-12-11T01:51:28Z">2022-12-11 01:51</time> | |
| </div> | |
| <div class='body'> | |
| <p>Closing as resolved. #356</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class='issue' id="297"> | |
| <div class='header'> | |
| <div class='title'><a href="https://github.com/Raku/problem-solving/issues/297"><span class='number'>297</span></a> - <span class='title'>"In general, the left side of `~~` should not be auto-threading"</span></div> | |
| <div class='author'>[closed]<span class='author'>@raiph</span> opend this issue at <time datetime="2021-09-07T22:29:02Z">2021-09-07 22:29</time></div> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>In general, the left side of <code>~~</code> should not be auto-threading</p> | |
| </blockquote> | |
| <p>Larry Wall, from https://www.nntp.perl.org/group/perl.perl6.users/2021/06/msg9966.html in May.</p> | |
| <p>This seems like a very serious issue.</p> | |
| <p>Please read Larry's two comments, taking on board the ramifications he outlines for both optimization and correctness/craziness if we let the LHS of <code>~~</code> autothread.</p> | |
| <hr /> | |
| <p><strong>Update</strong> I should have qualified that last sentence with "if the RHS is not a type object". Instead I did effectively the opposite, writing the following misleading comment, which I've struck out to reduce further confusion:</p> | |
| <p>~~And then consider this extremely popular (wrong!?!) idiom:~~</p> | |
| <pre><code>where .all ~~ Foo | |
| </code></pre> | |
| <p>~~(which I recently discovered doesn't work for a lot of cases I hoped it would work for.)~~</p> | |
| <p>In summary this issue was intended to be "just" about Larry's comments, treating them with the respect their due, and considering how to respond to them to fix existing problems in Rakudo hinted at in the email thread to which Larry contributed.</p> | |
| <p>(Thanks to codesections for his first comment which brought my attention to the fact that Larry had specifically enabled the <code>.all ~~ Foo</code> idiom in 2015 and I now realize it looks like he was <em>not</em> arguing in his comments this year that it should be deprecated -- even if the outcome of this issue is that it does actually end up being deprecated in <code>6.e</code>.)</p> | |
| </div> | |
| <div class='comments'> | |
| <div class='comment' id="IC_kwDOCkcG5c45TWlc"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-11-04T20:02:29Z">2021-11-04 20:02</time> | |
| </div> | |
| <div class='body'> | |
| <p>It appears I already created an exception to handle this in 2019 https://github.com/rakudo/rakudo/commit/b5d529c7e9 but it appears not to actually be in use.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45TaL2"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-11-04T20:23:50Z">2021-11-04 20:23</time> | |
| </div> | |
| <div class='body'> | |
| <p>Also related: https://github.com/rakudo/rakudo/pull/3849</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45To_C"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-11-04T21:39:32Z">2021-11-04 21:39</time> | |
| </div> | |
| <div class='body'> | |
| <p>Whatever we decide to do, I think we will need to make that a language level change, so most likely deprecate it now for 6.e, and disallow altogether in a future version.</p> | |
| <p>Some research shows that we need to decide:</p> | |
| <ol> | |
| <li>do we only disallow left-hand side of <code>~~</code>, or do we only throw on the <code>.ACCEPT(Junction:D)</code>? The latter would perhaps mean a less clear error message, or we just need to mention "smartmatching".</li> | |
| <li>What do we recommend users as an alternative??</li> | |
| </ol> | |
| <p>In any case, <code>die</code>ing in either a special <code>infix:<~~>(Junction:D, ...)</code> candidate, or in a <code>method ACCEPT(Mu:D, Junction:D)</code> candidate, both create <strong>significant</strong> spectest fallout.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45Tpk9"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-11-04T21:42:44Z">2021-11-04 21:42</time> | |
| </div> | |
| <div class='body'> | |
| <p>@niner @vrurg @ugexe @japhb @JJ @codesections ping :-)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45TuIJ"> | |
| <div class='header'> | |
| <span class='author'>@lizmat</span> commented at <time datetime="2021-11-04T22:09:22Z">2021-11-04 22:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>Related: https://github.com/rakudo/rakudo/pull/4618</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45T2Le"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2021-11-04T23:18:37Z">2021-11-04 23:18</time> | |
| </div> | |
| <div class='body'> | |
| <p>(This comment edited down to this line as I've decided it's noise. Click Edited beside my name if you want to see what it was.)</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45UawM"> | |
| <div class='header'> | |
| <span class='author'>@JJ</span> commented at <time datetime="2021-11-05T06:20:24Z">2021-11-05 06:20</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <pre><code>2. What do we recommend users as an alternative?? | |
| </code></pre> | |
| </blockquote> | |
| <p>hyperoperators and/or reduce will probably work nicely</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45WlFj"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-11-05T21:07:08Z">2021-11-05 21:07</time> | |
| </div> | |
| <div class='body'> | |
| <p>I'm not pretending to fully understand all the problems with junctions and <code>ACCEPTS</code>. My preferred way of using junctions is to have them on RHS as it mostly makes things more readable. This is especially true since the moment I realized that smartmatching is not commutative.</p> | |
| <p>Yet, at least one place I see things done wrong and some of us trying to make conclusions based on that. @raiph refers to rakudo/rakudo#2676 and otherwise related issues. So, I started there. First, I wanted to see things in action. So, I done this:</p> | |
| <pre><code class="language-raku">class C { | |
| method ACCEPTS(\topic) { | |
| say "ACCEPTS(", topic, ")"; | |
| (1..9).ACCEPTS(topic); | |
| } | |
| } | |
| say (0,3).one ~~ C.new; | |
| say (0,3).one ~~ 1..9; | |
| </code></pre> | |
| <p>The class wrapper does what is expected despite falling back to the same <code>Range.ACCEPTS</code>. So, I pulled up the source:</p> | |
| <pre><code class="language-raku"> multi method ACCEPTS(Range:D: Mu \topic) { | |
| (topic cmp $!min) > -(!$!excludes-min) | |
| and (topic cmp $!max) < +(!$!excludes-max) | |
| } | |
| </code></pre> | |
| <p>Of course we get wrong outcome. With rakudo/rakudo#4618 this should complain, as to my understanding. But at the moment it's not the autothreading which breaks the smartmatch, but rather lack of it.</p> | |
| <p>I was somewhat curious as to what happens if I enforce threading by introducing <code>multi sub infix:<~~>(Junction:D \topic, Mu \matcher)</code> candidate. It doesn't work out of the box due to the compiler stepping in first and optimizing the case. But cutting the compiler off by wrapping the smartmatch into a sub happens to also produce correct behaviour with the <code>Range</code>. So, here is the "fixed" version of smartmatch:</p> | |
| <pre><code class="language-raku">multi sub infix:<~~>(Junction:D \topic, Mu \matcher) { | |
| (topic.THREAD: { matcher.ACCEPTS: $_ }).Bool | |
| } | |
| </code></pre> | |
| <p>And then the test code:</p> | |
| <pre><code class="language-raku">sub match(Mu \topic, Mu \matcher) { | |
| topic ~~ matcher | |
| } | |
| say so match((0,3).one, 1..9); # True | |
| </code></pre> | |
| <p>Tests with <code>any</code>, <code>all</code>, and <code>none</code> produce expected results too.</p> | |
| <h1>rakudo/rakudo#2814</h1> | |
| <p>I've got @lizmat golf:</p> | |
| <pre><code class="language-raku">say <a>.classify: * eq "a"|"b"; # {False => [a], True => [a]} | |
| </code></pre> | |
| <p>What happens here is rather understandable and expected: we autothread over <code>classify</code>. In the current paradigm I see nothing wrong with it, event though it's a WAT case. Then it came to my mind to test a thing I never tried before:</p> | |
| <pre><code class="language-raku">say ("a"|"b" => "c").raku; # any("a", "b") => "c" | |
| </code></pre> | |
| <p>So, why can't this be the answer? I mean, wouldn't it look reasonable to get <code>{ any(True, False) => ["a"] }</code>?</p> | |
| <p>At this point I must admit the experiments took too much of my time and I can't look into other problematic points. But I rather convinced myself that what is needed is thorough clarification of signatures and use cases. Perhaps and likely there will be individual cases where use of junctions just doesn't make sense. But so far I consider the deprecation as overkill.</p> | |
| <p>BTW, talking about things not making sense:</p> | |
| <pre><code class="language-raku">say so 1 cmp 0; # True | |
| say so 1 cmp 1; # False | |
| say so 1 cmp 2; # True | |
| </code></pre> | |
| <p>Really??? ;) Either <code>Order</code> must not boolify whatsoever, or enum values must boolify against the rules for numerics.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45WyZ7"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2021-11-05T23:20:24Z">2021-11-05 23:20</time> | |
| </div> | |
| <div class='body'> | |
| <p>@vrurg</p> | |
| <p>Thank you for doing some initial analysis of the issues I listed.</p> | |
| <pre><code>say (0,3).one ~~ C.new; | |
| say (0,3).one ~~ 1..9; | |
| </code></pre> | |
| <blockquote> | |
| <p>at the moment it's not the autothreading which breaks the smartmatch, but rather lack of it</p> | |
| </blockquote> | |
| <p>But, aiui, per (@)Larry (including jnthn), it <em>needs</em> to not autothread. So this would remain broken, which would be "fine".</p> | |
| <pre><code>say <a>.classify: * eq "a"|"b"; # {False => [a], True => [a]} | |
| </code></pre> | |
| <blockquote> | |
| <p>so far I consider the deprecation as overkill.</p> | |
| </blockquote> | |
| <p>By "the deprecation" do you mean the use of junctions with <code>classify</code> as discussed in 2814 or the deprecation that is implicit in what (@)Larry (including jnthn) say needs to occur for things to work sanely and properly performantly (and which I think liz and myself and presumably at least some others already tentatively anticipate is going to happen at <code>6.e</code>)?</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45Xsws"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-11-06T21:44:05Z">2021-11-06 21:44</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>By "the deprecation" do you mean</p> | |
| </blockquote> | |
| <p>The general deprecation of junctions on smartmatch LHS, first of all.</p> | |
| <p><code>classify</code> is a different case. BTW, it currently goes against more or less common rule of the core that a <code>Junction</code> in an argument would either be collapsed or the return value would be junctional.</p> | |
| <p>After sleeping over with it, I'm now even in doubt of rakudo/rakudo#4618 making real sense. It would effectively disable elementary operations of <code>"a" cmp "a"|"b"</code> and <code>"a"|"b" cmp "a"</code> which are nothing at all special or confusing! With this respect I'd rather consider <a href="https://github.com/rakudo/rakudo/pull/4618#issuecomment-961715681">moon-chilled comment</a> as an option, especially that I came to this very same idea independently this morning. :) Though it makes it hard to manage cases of several junctional elements as they must result in nested junctions. But then again, if it is feasible to implement then a user must be warned about performance implications of such arrays. Otherwise we'd stay in line with "junction in, junction out" rule.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45XtO8"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-11-06T22:04:08Z">2021-11-06 22:04</time> | |
| </div> | |
| <div class='body'> | |
| <blockquote> | |
| <p>But, aiui, per (@)Larry (including jnthn), it <em>needs</em> to not autothread. So this would remain broken, which would be "fine".</p> | |
| </blockquote> | |
| <p>BTW, rakudo/rakudo#2676 is another example of where decision is taken not because of some kind of conceptual problem with junctions on LHS, but rather due to a technical issue in the core implementation. I went same path as @lizmat did (without knowing that's been done previously) and hit about the same issue with wrong dispatching.</p> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45XvRp"> | |
| <div class='header'> | |
| <span class='author'>@raiph</span> commented at <time datetime="2021-11-06T23:36:21Z">2021-11-06 23:36</time> | |
| </div> | |
| <div class='body'> | |
| <p>Thanks for following up @vrurg,</p> | |
| <blockquote> | |
| <p>so far I consider [The general deprecation of junctions on smartmatch LHS] as overkill.</p> | |
| </blockquote> | |
| <p>It would help me if you addressed Larry's specific points.</p> | |
| <p>You should read his two comments in full if you haven't already done so by clicking the link I provided at the start of this issue, but I'll include excerpts from them below, starting with his first comment:</p> | |
| <blockquote> | |
| <p>In general, the left side of <code>~~</code> should not be auto-threading, or we revert to the suboptimal Perl semantics of smartmatching.</p> | |
| <p>The reason we broke the symmetry of smartmatch is so that we can optimize based on the type of the right-hand argument, and allowing auto-threading of the other argument prevents that.</p> | |
| <p>"when 3" is supposed to be optimizable to a jump table, but how do you calculate a jump from a junction?</p> | |
| <p>So we biased smartmatching in the direction of coercion-first semantics rather early on (though, alas, not early enough to prevent Perl adoption of the earlier design).</p> | |
| <p>In any case, the documentation says <code>~~</code> is defined underlyingly by <code>.ACCEPTS</code>, and for a <code>Numeric</code> pattern, that says: <code>multi method ACCEPTS(Numeric:D: $other)</code> "Returns <code>True</code> if <code>$other</code> can be coerced to <code>Numeric</code> and is numerically equal to the invocant (or both evaluate to <code>NaN</code>)".</p> | |
| <p>And I'd be awfully surprised if <code>any(4,3)</code> can be coerced to <code>Numeric</code> in any meaningful way...</p> | |
| </blockquote> | |
| <p>Afaict his fundamental issue is optimizing Raku's switch statement. So afaict you are arguing that it doesn't matter to you if Raku's switch statement is slow. Please tell me I'm misunderstanding!</p> | |
| <hr /> | |
| <blockquote> | |
| <p><code>classify</code> is a different case.</p> | |
| </blockquote> | |
| <p>Agreed. I thank you for your analysis, and hope it will continue, but given that you've concluded it's not related to this one, please write any further commentary about it in its own issue, not this one. TIA.</p> | |
| <blockquote> | |
| <p>in doubt of rakudo/rakudo#4618 making real sense.</p> | |
| </blockquote> | |
| <p>Again, I thank you for your analysis and ask that further discussion of it is from here on kept in its own issue.</p> | |
| <hr /> | |
| <blockquote> | |
| <p>BTW, rakudo/rakudo#2676 is another example of where decision is taken not because of some kind of conceptual problem with junctions on LHS</p> | |
| </blockquote> | |
| <p>Larry's main point is about optimizability/optimization of Raku's switch statement, a <em>critically</em> important aspect of Raku's overall performance, not any conceptual problem.</p> | |
| <p>That said, he <em>also</em> points out that the very simple scheme he described, while primarily justified today by the big and <em>necessary</em> performance improvement it brings, will <em>also</em> eliminate in one fell swoop lots of bugs with things as they are now in Rakudo when junctions are used as the topic of a smartmatch.</p> | |
| <p>And he <em>also</em> points out there's a nice clear different way to express the same thing. Excerpting from his second comment in the email thread:</p> | |
| <blockquote> | |
| <p>sugar for <code>.ACCEPTS</code> ... should not introduce special cases either. If you want to make use of a junction like that, you must write</p> | |
| </blockquote> | |
| <pre><code>when 3 ~~ $_ {...} | |
| </code></pre> | |
| <blockquote> | |
| <p>or</p> | |
| </blockquote> | |
| <pre><code>when 3 == $_ {...} | |
| </code></pre> | |
| <blockquote> | |
| <p>or so. This is enough to tell the optimizer not to make a jump table. (Though conceivably spesh could still do that for cases where <code>$_</code> is provably an integer, I guess.)</p> | |
| </blockquote> | |
| </div> | |
| </div> | |
| <div class='comment' id="IC_kwDOCkcG5c45Xxg-"> | |
| <div class='header'> | |
| <span class='author'>@vrurg</span> commented at <time datetime="2021-11-07T01:09:28Z">2021-11-07 01:09</time> | |
| </div> | |
| <div class='body'> | |
| <p>So, we draw no difference between "switch" statement and smartmatch? Pardon me, I'm not going this route. Taking functionality away from one construct simply because this is performance-costly for another one? After all, the subject of this issue is about the smartmatch op itself. From this point of view � |
View raw
(Sorry about that, but we can’t show files that are this big right now.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment