00:00 reportable6 left 00:01 reportable6 joined 01:30 nine left, nine joined 06:00 reportable6 left 06:01 reportable6 joined 07:53 finanalyst joined 08:04 finanalyst left 09:24 sena_kun joined
Geth rakudo/main: 40c7b77fc9 | (Elizabeth Mattijsen)++ | lib/NativeCall.rakumod
Streamline NativeCall (part 1/N)

  - reorganizing code with similar functionality in clear sections
  - limit the scope of the NativeCall module to parts that really
   need to be in that scope		 11:58
12:00 reportable6 left 12:03 reportable6 joined
nine *sigh* implementing Rakudo in Raku would be so much easier if Raku was a statically typed language >/ 12:12
:/ 12:13
RakuAST::Node has a type method that is supposed to return the type object of the value a node may yield. It hasn't been used for anything much yet, so nobody noticed that all those $.type attributes containing RakuAST::Type object or even just strings violate this contract. 12:14
lizmat meh :-( 12:17
nine Of course "not anything much" is also not nothing 12:26
lizmat of course not, just enough to be annoying, right ?
nine Of course. 12:29
I'm gonna rename type() to return-type()
lizmat why not "may-yield-type" 12:35
?
nine It's not a may. The value the node yields is guaranteed to check against that type. 12:36
If we don't know better we just return a Mu there.
lizmat my suggestion was based on your remark: "RakuAST::Node has a type method that is supposed to return the type object of the value a node may yield"
nine That's a "may" in the sense of "is allowed to" 12:37
lizmat ok, understood: language is hard :-)
whether natural or programming :) 12:38
nine Of course that leaves "yields-type" as an option. But "return-type" is closer to the terminology in the old frontend (where it's just "returns") and return-type is unique enough for a simple search&replace if someone feels strongly enough to rename it once more.
lizmat for me that would be a reason to call it differently from the old frontend
to ease searching for "old" behaviour and "new" behaviour 12:39
*name it differently
Geth rakudo/main: 3041066496 | (Elizabeth Mattijsen)++ | lib/NativeCall.rakumod
Streamline NativeCall (part 2/N)

  - finding the right name mangler
  - abstract checking into a helper sub for convenience		 12:42
nine But old and new frontend are completely separated in different directory trees? There cannot be any confusion what you're looking at. Using different names for the same concepts is a great way to make code harder to understand. 12:43
gfldex m: sub foo(Int() @ints) { dd @ints }; foo [1,2,3]; 12:52
camelia Type check failed in binding to parameter '@ints'; expected Positional[Int(Any)] but got Array ([1, 2, 3]). You have to
pass an explicitly typed array, not one that just might happen to
contain elements of the correct type.
in sub foo at <tmp…
gfldex Should this ^^^ DWIM?
lizmat it should probably complain at compile time, at least for now 12:54
gfldex It feels inconsitent to me. 12:55
Also, making it easy to use typed Arrays might get folk to use them. :-> 12:56
lizmat well, it feels largely as NYI to me :-)
Geth rakudo/main: bf81c62f9c | (Elizabeth Mattijsen)++ | lib/NativeCall.rakumod
Streamline NativeCall (part 3/N)

  - move "use dispatcher flag" to constant section
  - minor tweaks in non-dispatcher code (old/JVM backend)
I wonder whether this shouldn't be replaced by backend dependent pre-processing source code by now		 13:09
nine Few compile time exceptions in the RakuAST frontend contain a line number. One would have to supply a :line argument to the exception constructor to get that. Getting that line number is a few lines of code and I wouldn't want to repeat them all over the place. Luckily actually building the exception is done by build-exception. 13:21
And adding the exception to the resolver is done again by a centralized add-sorry or add-worry. Problem is: build-exception is a method on the resolver and that one doesn't have access to the node throwing the exception. 13:22
lizmat yup :-(
nine Now add-sorry and add-worry are on the node itself (provided by CheckTime role) but they only see the fully built exception
lizmat fixing that will fix a *lot* of tests
Geth rakudo/main: 4a64b3af22 | (Elizabeth Mattijsen)++ | lib/NativeCall.rakumod
Streamline NativeCall (part 4/N)

  - replace all ~~ to nqp::istype() where possible
  - replace test for Buf | Blob by just Blob as Bufs are Blobs		 13:30
rakudo/main: ee52581423 | (Stefan Seifert)++ | 6 files
RakuAST: Rename RakuAST::Node's type() to return-type()

type() is supposed to return a type object for the type of values a node may yield. However since this hasn't been used much, no one noticed that lots of subclasses have attributes called "$.type" that usually hold RakuAST::Type nodes or even just strings.
Rather than going through the whole code-base and finding new names for all these attributes rename the method in the base class to something more unique: return-type(). This uniqueness will help if someone comes up with an even better name.		 13:53
rakudo/main: fcbd5303e4 | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: detect type mismatches in assignments at compile time
nine We really have 3 ways to define the return type of a sub?! 13:54
lizmat sub a of Int
sub a(--> Int) 13:55
nine Oh wait, it's 4
lizmat sub a() returns Int
which one did I miss
?
nine my Int sub a()
lizmat TIL but yeah, that makes sense 13:56
never used that one :-)
I feel that the --> foo syntax is clearest, as it makes clear it's part of the signature of the block, not actually of the block itself 13:57
nine I'm close to refusing to implement that... 13:59
lizmat --> ? 14:00
nine It's just one of the syntactic features that need not have been. I don't see it contributing any value to the language while it's yet again a special case that the compiler has to support and one more thing a user has to learn. 14:05
When implementing all of this I often get reminded of AlexDaniel. While he was needlessly agressive and inconsiderate on the subject matter he was not always completely wrong. Raku is a huge language and that's not always a benefit for the user. 14:07
ab5tract unfortunately `-->` is also the form that I've seen most often 14:11
but yeah, four separate syntaxes is mega-YAGNI 14:12
YAGNI was perhaps an under-appreciated principle during certain phases of Raku's design :) 14:13
nine To be clear: I have no quarrel with -->. It's "my Int sub" that I don't see the point of. 14:15
Also having both of(Int) and returns(Int) seems superfluous 14:17
They do exactly the same
As to the cost for the user: besides having to know all of these variants to be able to properly read code, just look at all the checks for conflicting declarations we do. When there are multiple ways to do the same you can end up with such conflicts. So you have to disallow using multiple of these ways. Disallowing something means adding one more rule to the language 14:20
gfldex .o( approved of redundant ministry of redundancy approval )
[Coke] This seems like great items to push for cleanup in future language versions. 14:24
And for us to eventually push for dropping versions of languages from monthly compiler releases. (having last supported versions of 6.c would eventually be nice) 14:25
nine alongside has $x; (incidentally also something RakuAST does not yet support)
ugexe deprecate everything
ab5tract has $x infuriated 14:32
Infuriates me to a probably unreasonable degree
“It makes it easier to onboard people into OO” ??? No! Teaching them the actual freaking syntax makes it easier to onboard 14:34
gfldex I agree with redundant redundant redundancy to be too much of a good thing. But I would keep `my Int sub foo() {}` and `sub foo(--> Int) {}` because a) Huffman-coding and b) consistency. I acutally like `my Int` because that's the same way then declaring type constrains on containers. It also allows to put the important thing at the front (when the return value type is important). 14:40
nine Except that it actually conflicts with the use for container types. In my Int $foo; The Int is a type constraint on the declared $foo; In my Int sub foo however, the &foo declared here is still a Sub object. It's type is unaffected. Instead its signature is modified. 14:43
Geth rakudo/main: 622f58adcb | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: support my Foo sub ... syntax for return type declaration
rakudo/main: b50fb0c4a5 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: prohibit multiple type constraints on a single parameter
nine 1059
lizmat confirmed :-) 14:54
ab5tract that's a huge issue with moving forward.. each feature is appreciated by at least someone, it seems :/ 15:01
15:39 finanalyst joined
[Coke] Good thing we have a committee 15:49
ab5tract it helps, but no matter what one proposes removing there is pushback from the community. so even if it's a committee that decides, it seems that there will be > 0 people disappointed, disaffected, or disgusted 16:03
Geth ¦ rakudo: ab5tract self-assigned where-clause in subset does not work with Block/Callable github.com/rakudo/rakudo/issues/5175 16:06
lizmat fwiw, if there's one way to specify return constraint, I'd vote for the "returns" trait 16:19
it is the most verbose, it's place in the syntax is confusing, and it would simplify the grammar significantly :-) 16:20
ab5tract "it's place in the syntax is confusing," -- is that an argument for or against? :) 16:27
nine Obligatory xkcd: xkcd.com/1172/ 16:28
lizmat :-) 16:29
Geth rakudo/main: 1278c5bbb6 | (Stefan Seifert)++ | 2 files
RakuAST: don't absolutify file names of compunit

Several spectests expect file names in backtraces to be relative.		 17:34
nine 1062 # this is one of these super surprising ones
3 lines deleted, 3 more passing spec test files 17:35
m: class Foo { has $; } 17:53
camelia ===SORRY!=== Error while compiling <tmp>
Cannot declare an anonymous attribute
at <tmp>:1
------> class Foo { has $⏏; }
expecting any of:
constraint
nine Ok fair enough. But I really want to!
m: class Foo { has $!; }
camelia ( no output )
nine I guess bang is Raku's sudo 17:54
If you want to confuse people even more, adopt a healthy attitude of Whatever: 17:57
m: class Foo { has $*foo = 1; method foo() { $!foo }; }; note Foo.new.foo
camelia 1
18:00 reportable6 left 18:01 reportable6 joined
lizmat 1062 confirmed! 18:41
nine: but one fail in make test: Special compiler variable $?FILE expected "EVAL_1", got "/foo/bar/rakudo/EVAL_1" 18:50
feels like changing the test would be wrong 19:02
in t/12-rakuast/var.rakutest
nine ^^ 19:03
nine Huh....I did fix that test 19:07
ok 1 - Special compiler variable $?FILE 19:10
# Subtest: Special compiler variable $?FILE
And I'm on 2024.04-26-g1278c5bbb with no local modifications
Oh, it fails without RAKUDO_RAKUAST=1! But then "/home/nine/rakudo/EVAL_1" is clearly wrong, isn't it? 19:11
lizmat I would say so, yes 19:13
this is odd: NativeCall has: 19:14
multi sub postcircumfix:<[ ]>(CArray:D \array) is export(:DEFAULT, :types) {
array.ZEN-POS
}
but I can't find any mention of ZEN-POS in the core? 19:15
19:17 linkable6_ left, evalable6_ left 19:18 linkable6_ joined 19:19 evalable6_ joined
Geth rakudo/main: d5eb39f71b | (Elizabeth Mattijsen)++ | lib/NativeCall.rakumod
Streamline NativeCall (part 5/N)

  - streamline the Native role
  - give guess_library_name a proto as a single export point		 19:20
ugexe github.com/rakudo/rakudo/commit/53...db86fcb1c1 19:29
deleted in github.com/rakudo/rakudo/commit/ca...43e8026df1 19:31
nine lizmat giveth and lizmat taketh away 19:32
lizmat I wonder if that was intentional
as ZEN-KEY still exists
ugexe the commit message doesn't mention it being intentional, so we can only assume it wasnt 19:33
lizmat yet nobody appears to have missed it in the past 3+ years 19:34
anyways, it is about to be eradicated from NativeCall 19:36
Geth rakudo/main: 0c9e990d40 | (Elizabeth Mattijsen)++ | lib/NativeCall.rakumod
Streamline NativeCall (part 6/N)

  - replace reference to .ZEN-POS by nqp::decont(), as that was the
   original meaning of .ZEN-POS before it was removed with ca7bc91e7
  - some variable renaming for clarity
  - some variable removal		 19:55
lizmat afk&
21:05 finanalyst left
lizmat m: sub postfix:<π>($a) { $a * π }; say 2π # wonders whether that should be in core 22:04
camelia 6.283185307179586
[Coke] that opens the door to a bunch of stuff, I would start from no 22:14
m: say τ 22:16
camelia 6.283185307179586
[Coke] m: say e
camelia 2.718281828459045
22:43 sena_kun left
[Coke] eh. there's probably a way to do that consistently across constants. +1 from me. 23:15

Powered by Cro and the Raku® Programming Language.

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

Thank you!