🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel! Set by lizmat on 6 September 2022. |
|||
00:00
reportable6 left
00:02
reportable6 joined
00:10
lichtkind left
00:34
Homer_Simpson joined
|
|||
Homer_Simpson | can I treat '+' (i.e a string) as an operator | 00:34 | |
I have my $operand = '+'; | |||
I coudl like to use $operand to add two numbers | |||
in my function addnums | 00:35 | ||
[Coke] | the cheat-iest way to do this is with EVAL. | ||
lizmat | m: my $a = "+"; my &op = ::("&infix:<$a>"); say op(42,666) | 00:38 | |
camelia | 708 | ||
Homer_Simpson | @lizmat can I use that to make user defined literals | 00:52 | |
so if I do say 2 it prints 2, but if I make a user define literal called L which is "*= 20" and do say (2L) it would print 40 | 00:53 | ||
i tried but I got a weird error saying 'confused; | 00:54 | ||
Nemokosch | can you show the code? | 00:58 | |
ngl I'm a bit worried that you basically want to add C macros into Raku | |||
rf | Can I return from a catch? For example | 01:09 | |
m: say { return 'abc'.IO.slurp; CATCH { return 'abc'; } }; | 01:10 | ||
camelia | -> ;; $_? is raw = OUTER::<$_> { #`(Block|6187875189600) ... } | ||
rf | m: say { return 'abc'.IO.slurp; CATCH { return 'abc'; } }(); | ||
camelia | Attempt to return outside of any Routine in block at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
rf | You get what I mean oops lol | ||
01:10
melezhik joined
|
|||
melezhik | . | 01:10 | |
tellable6 | 2023-01-27T23:27:10Z #raku <rf> melezhik It only seems to support G++, so that is fine. I am using latest Rakudo. | ||
rf | I want to catch then return in that catch | ||
01:10
TieUpYourCamel left
|
|||
melezhik | rf the same issue with g++ - ci.sparrowhub.io/report/2792 | 01:11 | |
rf | Can you install locally with zef? | 01:12 | |
I'm hoping this package doesn't only work on my machine | |||
melezhik | I will try to install later on VM, not on docker and let you know | 01:15 | |
01:15
melezhik left
|
|||
Homer_Simpson | my $l = "*= 20"; | 01:17 | |
my &L = ::("&postfix:<$l>"); | |||
say 2L; | |||
@Nemokosch | 01:18 | ||
Nemokosch | rf: pretty sure you can - however, you cannot return from a block | 01:19 | |
Homer_Simpson: yeah, that's not an operator... | 01:20 | ||
with RakuAST, one might be able to write such macros, though | |||
rf | You could always use QAST and write a slang I think | 01:22 | |
Nemokosch | yes but hopefully that won't be needed quite soon 🙂 | 01:23 | |
Homer_Simpson | does rakuAST make raku into assembler | 01:52 | |
since QAST makes raku into bytecode | |||
02:15
linkable6 left,
evalable6 left
02:16
linkable6 joined
02:17
evalable6 joined
02:18
razetime joined
|
|||
ugexe | no | 02:27 | |
:(**@args, *%kwargs) | what does it mean by Cannot dump this object; no dump method | 02:28 | |
im trying to conpile to mbc | |||
02:29
jpn left
|
|||
ugexe | compile what to mbc? | 02:32 | |
github.com/Raku/nqp/blob/bbe28e24d...r.nqp#L316 | |||
its coming from one of the 4 instances of 'dumper' in there, whatever that means | 02:33 | ||
02:33
gatito joined
|
|||
gatito | ugexe: i mean like 'raku --target=mbc hello.raku' | 02:33 | |
ugexe | does it do that for any code? | ||
gatito | it gives `Cannot dump this object; no dump method` | ||
ugexe | yes it seems it does | 02:34 | |
gatito | what is the solution | 02:35 | |
02:35
Guest53 joined
|
|||
ugexe | dunno. someone with a bunch of raku version should probably try to figure out what release it stopped working in | 02:36 | |
i tried on 2022.07 and it didnt work | |||
02:36
Guest53 left
|
|||
gatito | this is 2022.12 | 02:37 | |
i mean mine | |||
ugexe | well figure out when in rakudo it broke, look at the changelog to try and figure out what exactly broke it, then fix it in rakudo, wait for the next release, and use that | 02:39 | |
it doesn't have to be you, but thats the only way to get it to work for anyone | |||
gatito | hmm... | 02:45 | |
ugexe | ah nevermind | 02:48 | |
you need to pass --output=somefile.mbc | 02:49 | ||
02:49
jpn joined
|
|||
gatito | thx | 02:51 | |
why are mbc and qast dumps so bloated? i can't find the actual code logic, its buried in loads of boilerplate | 02:54 | ||
02:56
kjp left
03:00
kjp joined
03:05
ispyhumanfly left
03:27
gatito left
03:44
jpn left
03:57
Xliff joined
|
|||
Xliff | \o | 03:57 | |
m: role A { method b { }; }; class B does A { has $.c; method d { self.^lookup("b"). ).package.^attributes.gist.say }; }; A.d | 03:58 | ||
camelia | ===SORRY!=== Error while compiling <tmp> Unsupported use of . to concatenate strings. In Raku please use: ~. at <tmp>:1 ------> has $.c; method d { self.^lookup("b"). ⏏).package.^attributes.gist.say }; }; A.d |
||
Xliff | m: role A { method b { }; }; class B does A { has $.c; method d { self.^lookup("b").package.^attributes.gist.say }; }; A.d | ||
camelia | No such method 'd' for invocant of type 'A'. Did you mean 'b'? in block <unit> at <tmp> line 1 |
||
Xliff | m: role A { method b { }; }; class B does A { has $.c; method d { self.^lookup("b").package.^attributes.gist.say }; }; B.d | 03:59 | |
camelia | () | ||
Xliff | Is there a way to get method d() to pull out the attributes in B? | ||
Correction. | 04:00 | ||
I need to pull the attributes from B via a lookup on method b() | |||
But instead of getting the composed class, I get the role. | |||
04:05
Homer_Simpson left
04:06
ispyhumanfly joined
04:08
falsifian left
04:10
razetime left
04:12
ispyhumanfly left
04:59
kybr left
05:08
razetime joined
05:25
ispyhumanfly joined,
razetime1 joined
05:27
razetime left,
razetime1 is now known as razetime
05:41
kybr joined
05:42
ispyhumanfly left
06:00
reportable6 left
06:02
reportable6 joined
06:07
ispyhumanfly joined
06:11
Sauvin left,
Sauvin joined
06:12
ispyhumanfly left
06:14
ispyhumanfly joined
06:21
ispyhumanfly left
06:26
razetime left
06:31
razetime joined
06:34
ispyhumanfly joined
06:43
ispyhumanfly left
06:56
ispyhumanfly joined
07:00
ispyhumanfly left
07:15
ispyhumanfly joined
07:20
ispyhumanfly left
07:47
ispyhumanfly joined
07:48
jpn joined
07:53
ispyhumanfly left
08:05
ispyhumanfly joined
08:06
razetime left
08:10
ispyhumanfly left
08:32
razetime joined
08:37
jpn left,
MoC joined
08:52
rf left,
rf_ joined
09:18
rf__ joined
09:19
Xliff left,
rf_ left
09:21
jpn joined
09:25
sena_kun joined
|
|||
Nemokosch | Re why are QAST and mbc so bloated | 09:29 | |
Because they are much like the assembly of the runtime | |||
Xliff: why do you need that? What does the "lookup on method b" contribute to the solution? | 09:40 | ||
10:16
Sgeo left
10:18
jpn left
10:40
razetime left
10:52
NemokoschKiwi joined
|
|||
NemokoschKiwi | .seen patrickb | 10:52 | |
tellable6 | NemokoschKiwi, I saw patrickb 2023-01-21T15:59:45Z in #raku-dev: <patrickb> I'm off for today. Have a nice weekend everyone! o/ | ||
NemokoschKiwi | patrickb: can I get a little help with rakubrew development if you're available 🥺 | 10:53 | |
11:02
ispyhumanfly joined
11:03
rf__ left
11:04
rf__ joined
11:07
ispyhumanfly left
11:21
NemokoschKiwi left
|
|||
Nemokosch | aaargh how do I even run this for myself | 11:29 | |
11:33
ab5tract joined
11:34
snonux joined
11:58
ab5tract left,
ab5tract joined
12:00
reportable6 left
12:02
reportable6 joined
|
|||
Geth | App-Rakubrew: 2colours++ created pull request #70: Implementing version toggling with `rakubrew switch` |
12:05 | |
Nemokosch | seems like I survived after all | ||
12:23
bartolin joined
12:24
ispyhumanfly joined
12:26
rf_ joined,
rf__ left
12:34
ab5tract left
12:59
lichtkind joined
13:13
snonux left
13:15
jpn joined
13:19
jpn left
13:20
jpn left
13:27
ispyhumanfly left
13:33
jpn joined
|
|||
:(**@rest, *%rest) | still python bytecode is much more compact than this prbly because mbc is much lower level or raku just has a lot more work to do than python | 13:34 | |
Nemokosch | could be both at the same time | 13:35 | |
I've never seen Python bytecode so I wouldn't know | 13:36 | ||
but I do know that QAST already contains scoping considerations | |||
I'd guess mbc is completely dealing with that kind of stuff, symbol lookup and all | 13:37 | ||
13:38
jpn left
|
|||
:(**@rest, *%rest) | glot.io/snippets/ghpgg5fha2 | 13:38 | |
13:38
NemokoschKiwi joined
|
|||
literally just 4 instructions | 13:39 | ||
13:41
NemokoschKiwi left
|
|||
Nemokosch | woah this seems MUCH higher level xD | 13:42 | |
but then this seems to act on statements, not a complete program | 13:43 | ||
:(**@rest, *%rest) | it work that way with a complete module too glot.io/snippets/ghpgojmxdk | 13:47 | |
Nemokosch | this is still more like just a sequence of statements though... but ultimately, the big thing is that it just announces things like "look up this name" xD | 13:50 | |
like... by what rules? | |||
patrickb | NemokoschKiki: Is there still help needed? | ||
Nemokosch | what will that name even contain? | ||
patrickb: the help changed a bit... github.com/Raku/App-Rakubrew/pull/70 please check out this pull request 🙂 | 13:51 | ||
patrickb | :-P I'll have a look. | 13:52 | |
:(**@rest, *%rest) | - LOAD_NAME and LOAD_GLOBAL lookup the name from the global (module-level) namespace. the global namespace is a dictionary, so LOAD_NAME is just dict lookup - LOAD_FAST is fast because its an array lookup | 13:55 | |
13:55
abraxxa-home joined,
dogbert17 left
13:59
dogbert17 joined
|
|||
Nemokosch | dict lookup - but where do you get a dict from? | 14:00 | |
is Python written in Python? | |||
14:00
abraxxa-home left
|
|||
:(**@rest, *%rest) | PyDictObject from the C backend ig | 14:01 | |
which basically means python dict | 14:02 | ||
14:02
abraxxa-home joined
14:10
jpn joined,
spacekookie left
14:20
SqrtNegInf joined
14:21
jpn left
14:23
jpn joined
14:26
ispyhumanfly joined
14:27
SqrtNegInf left
|
|||
Nemokosch | seems kinda magic | 14:29 | |
14:30
ispyhumanfly left
|
|||
rf_ | Morning folks | 14:33 | |
14:33
abraxxa-home left
14:34
jpn left
|
|||
:(**@rest, *%rest) | the PyDictObject is already available in cpython backend prior to runtime it can just instantiate it and use as the namespace or it can be statically allocated (most likely the case) | 14:35 | |
rf_: good morning | |||
14:36
ispyhumanfly joined
|
|||
Nemokosch | so does CPython have no precompilation | 14:36 | |
:(**@rest, *%rest) | it is precompiled in .pyc files | 14:38 | |
14:40
ispyhumanfly left,
razetime joined
14:43
kylese joined
|
|||
Nemokosch | and what do those contain | 14:43 | |
14:45
raschip joined
|
|||
raschip | . | 14:49 | |
14:50
jpn joined
14:54
jpn left
|
|||
rf_ | I believe Cython is just python with access to .so | 14:54 | |
:(**@rest, *%rest) | marshalled code object | 15:00 | |
patrickb | Nemokosch: I pondered the PR a bit and left a comment. Feedback welcome! | ||
tellable6 | patrickb, I'll pass your message to Nemokosch | ||
15:04
ispyhumanfly joined
|
|||
rf_ | github.com/rawleyfowler/Humming-Bird/pull/31 | 15:06 | |
Working on adding error handlers and route advice to Humming-Bird, if anyone wants to look at that PR would be appreciated :) | 15:07 | ||
Leave comments on PR I am a little slow on IRC | |||
Nemokosch | patrickb: to be honest, I don't feel I'd have much constructive thoughts | 15:08 | |
15:09
ispyhumanfly left
|
|||
:(**@rest, *%rest) | and code objects are probably underlyingly just c structs | 15:09 | |
15:30
snonux joined
15:44
ispyhumanfly joined
15:48
ispyhumanfly left
16:13
spacekookie joined
16:25
rf joined,
rf left,
rf_ left,
rf joined,
rf_ joined,
rf_ left
16:27
snonux left
16:31
snonux joined
16:37
jpn joined
16:40
lichtkind left
16:43
snonux left
16:45
jpn left
17:05
ispyhumanfly joined
17:10
ispyhumanfly left
17:16
razetime left
17:31
jpn joined
17:35
jpn left
17:41
linkable6 left
|
|||
rf | How prepared is Raku for y2k38? | 17:41 | |
17:41
lichtkind joined
17:43
linkable6 joined
|
|||
raschip | I don't think there's even 32 bit builds for Rakudo... | 17:43 | |
rf | I know a lot of perl packages are marked as having issues | ||
17:44
jpn joined
|
|||
Voldenet | m: DateTime.new("2040-01-01T01:01:01Z").posix.say | 17:46 | |
camelia | 2208992461 | ||
Voldenet | I do wonder if there's something not prepared for y2k38 | 17:49 | |
17:50
jpn left,
lichtkind left
|
|||
raschip | m: DateTime.new(2208992461).say | 17:51 | |
camelia | 2040-01-01T01:01:01Z | ||
rf | nice | 17:52 | |
Raku wins again :D | 17:53 | ||
17:53
Air4x joined
17:54
jpn joined
|
|||
Voldenet | m: DateTime.new(DateTime.new("9007199254740992-01-01T01:01:01Z").posix).say | 17:56 | |
camelia | -194090211667-09-06T21:31:57Z | ||
raschip | Well, it does wins unless one needs 32 bit support. I found a 32 bit system still running in the basement the other day. | 17:58 | |
rf | You can have 64 bit values on a 32 bit machine | ||
Whether raku does what it needs to do this not sure | 17:59 | ||
raschip | Sure, but one can't have Raku on a 32 bit machine as far as I can tell... | ||
18:00
reportable6 left
18:01
reportable6 joined
|
|||
Voldenet | m: DateTime.new(DateTime.new(2 ** 38 ~ "-01-01T01:01:01Z").posix).say | 18:02 | |
camelia | +274877906944-01-01T01:01:01Z | ||
Voldenet | m: DateTime.new(DateTime.new(2 ** 39 ~ "-01-01T01:01:01Z").posix).say | 18:03 | |
camelia | -34798235366-02-22T18:00:45Z | ||
Voldenet | you'd need to refactor your software in 274877904922 years | ||
18:29
Homer_Simpson joined
|
|||
Homer_Simpson | is this legal: my $format = ("%d" , "%1.1f" , "%d" , "%s"); my $data = ( 9 , 8.2 , 7 , "hi"); loop (my $i = 0 ; $i <= 3 ; $i++) { printf("$format[$i]\n", $data[$i]); } | 18:30 | |
raschip | m: my $format = ("%d" , "%1.1f" , "%d" , "%s"); my $data = ( 9 , 8.2 , 7 , "hi"); loop (my $i = 0 ; $i <= 3 ; $i++) { printf("$format[$i]\n", $data[$i]); } | ||
camelia | 9 8.2 7 hi |
||
Homer_Simpson | it works yes but I was just wondering if its a "thing" that people do | 18:31 | |
raschip | Yes, it is an 'idiom' | 18:32 | |
18:38
ab5tract joined
|
|||
Nahita | why are you using a C-style loop though | 18:41 | |
you can zip instead | |||
18:41
swaggboi left
|
|||
m: my @formats = ("%d", "%1.1f", "%d", "%s"); my @data = ( 9, 8.2, 7, "hi"); for @formats Z @data -> ($f, $d) { printf "$f\n", $d } | 18:41 | ||
p6steve | using @ and Arrays for multiple things helps to avoid some surprises | 18:43 | |
Nahita | so i don't think that loop-based way of doing is an idiom | 18:44 | |
p6steve | ++ Z in the | 18:45 | |
Homer_Simpson | I like fairly self explanatory code | ||
p6steve | example | 18:46 | |
Homer_Simpson | is Z a constant? | ||
raschip | That's the opposite of self-explanatory, it's almost all about the HOW, not the WHAT | ||
Homer_Simpson | or an operator? | ||
raschip | Z is a meta-operator | ||
Homer_Simpson | the how is just as important | 18:47 | |
computers are not magic | |||
raschip | Right, but communicating to other programmers is even more important. Of course the computer needs to figure out the code at the end of the day, but only write explicit instructions if you need to. | 18:48 | |
Well, that's the Raku way, anyway. | 18:49 | ||
18:49
Air4x left
|
|||
Nemokosch | Yes, I mean... not to chase anybody away but you do seem to have misconceptions about what Raku is for. | 18:50 | |
If you essentially want C, write C code, or chose from the gazillion of "C killer" languages. | |||
p6steve | welll - loop is in raku for a reason | 18:51 | |
Nemokosch | more like - loop is called loop rather than for, for a reason | ||
Homer_Simpson | im happy using raku like C | ||
but also not like C | |||
Nemokosch | this itself was an expression of "only use this if you need to but most of the time you shouldn't need to" | ||
this itself was an expression of "only use this if you need to but most of the time you shouldn't need to" | 18:52 | ||
p6steve | if there were (say) 17 arrays that all needed indexing in step (or i,j,k type multi dimensions) then why not | ||
raku does have c heritage | |||
I think that using loop to index a single array would certainly be unidioamtic | |||
Nemokosch | I don't really get the supposed task but I'm pretty sure there will be a better and simpler way | ||
p6steve | but HS example with 2 arrays, I think that gentlefolk can differ | 18:53 | |
Homer_Simpson | I use raku like a "C but with a string type, smarter printf/scanf functions and some more nice features | 18:54 | |
dynamic typing | |||
though you can also do static typing | |||
it makes what I find hard in c easier | |||
Nemokosch | "C with a string type" and then you complained that strings work like strings, not array of bytes 😆 | 18:55 | |
p6steve | personally I like that Pairs and Zip (Z) can be used to make handling two arrays or a hash as concise as a single array with a for loop | ||
Homer_Simpson | yes sometimes | ||
sometimes I want a string type, sometimes I want an array of chars | |||
I hate using malloc in C | 18:56 | ||
so I just use a string type | |||
is it possible to have a fixed size anonymous list? | |||
Nemokosch | if by array of chars, you actually mean array of bytes, there is something like that as well: blob8 (and the writeable buf8) | ||
Homer_Simpson | (0,2,3,60)[4]; | 18:57 | |
raschip | Homer_Simpson You're of course free to use Raku in the way that suits you, but the language has a style behind it, and you just asked how people used it, so it was interesting to tell you your code isn't idiomatic overall. | ||
p6steve | m: (0,2,3,60)[4].say; | ||
Nemokosch | there is also utf8 which is a kind of blob8 with special considerations for UTF8 usage | ||
Homer_Simpson | I tried buf but .. | ||
p6steve | m: 0,2,3,60.say; | 18:58 | |
Nemokosch | I think a "fixed size anonymous list" would need to use the right constructor | 18:59 | |
Homer_Simpson | m: my $lst = (0,2,4,7)[4]; say($lst[0]); say($lst[4]); | 19:01 | |
camelia | (Any) (Any) |
||
Nemokosch | > Array.new(:shape(10,), [Any, Any, Any, Any, Any, Any, Any, Any, Any, Any]) | ||
this is what my @asd[10]; creates for you under the hood | |||
p6steve | nemokosch++ | ||
(another good reason to reach for @sigil and Arrays, not lists. | 19:02 | ||
) | |||
Nemokosch | tbh I'm really not sure whether plain Lists support shapes - the way they don't support typing | 19:03 | |
p6steve | m: dd my@[3]; | ||
19:03
ab5tract left
|
|||
raschip | m: dd my@[3]; | 19:04 | |
camelia | Array.new(:shape(3,), [Any, Any, Any]) | ||
Nemokosch | I think Array.new(:shape(3,)) is enough, it's just .raku is not smart enough to know the literal is redundant in the constructor | ||
p6steve | m: say List.new(:shape(3,)) | 19:05 | |
raschip | p6steve, Camelia in IRC isn't executing code you post with m:, it's not recognizing messages comming from the discord gate since it includes your nick and Homer_Simpson isn't seeing the output. | ||
p6steve | raschip: thanks (I see my own output fine - thus the confusion) | 19:06 | |
raschip | Yeah, I think discord has it's own Camelia | ||
m: say List.new(:shape(3,)) | |||
camelia | () | ||
p6steve | docs.raku.org/type/Array says that shape is a method provided by Array | 19:07 | |
imo, the type graph is quite interesting docs.raku.org/type/Array#Type_Graph | 19:08 | ||
since everything in raku is an object | |||
this is why I recommend to use Array (and @) because that is the most evolved form of Positional type | 19:09 | ||
Nemokosch | yes, tbh it's less that "Array is a mutable List", although that's also true | 19:17 | |
but the situation is better described as: "List is a degenerate Array that doesn't provide ... [typing, mutation, dimension, etc.]" | |||
p6steve | ^^that | 19:18 | |
Nemokosch | that's why it would be nice to have an immutable data structure that is analogous to Array | 19:19 | |
not just lacks features, one of which happens to be mutation | |||
p6steve | you could say that raku makes the easy stuff easy and the hard stuff possible | 19:21 | |
although I now think of it as several gears ... anyone coming to raku can get a hell of a lot from 1st gear - that means the four sigils ($,@,%,&), and leveraging all the features that the designers bothered to put in to the main built ins like Scalar, Array, Hash | 19:24 | ||
I do get that immutables are helpful in (i) performance with large data structures and (ii) pure functions ... but this is around 3rd gear for me | 19:25 | ||
Nemokosch | also, immutables aren't implemented effectively, as things stand | 19:27 | |
19:28
ispyhumanfly joined
|
|||
that's something codesections has been working on, supposedly | 19:28 | ||
p6steve | what do you want to use them for? | ||
Nemokosch | tbh it's a bit like Columbo's wife at this point | ||
19:29
jpn left
|
|||
well, what do you mean | 19:29 | ||
p6steve | what is your use case for immutables? | ||
Nemokosch | better performance would never hurt, now would it | 19:31 | |
and I do kinda write functional style quite a lot | |||
19:32
ispyhumanfly left
|
|||
p6steve | my guess is that the performance benefit comes at GB scale ... a deep immutable is some kind of tree that keeps a scrollable history of changes ... so lets say you go @b = @a >>+>> 1; then you end up with a new immutable @b where each element is a closure of { $_ + 1 } and a binding to the relevant element of @a ... so many/most operations are more expensive ... the speed benefits come with very large data (ie GB | 19:41 | |
scale) sets that get marginally extended (eg.a few more elements pushed from time to time) - and there are some benefits if your immutable implementation maps closely onto how hard drives work | |||
since raku performance is poor anyway, you probably are putting lipstick on the pig this way | 19:42 | ||
sorry must go for dinner | 19:43 | ||
;-( | |||
Nemokosch | I'd rather think of the number of allocations, not the memory size. And that can make a difference | 19:50 | |
If you keep having operations for allocating memory that you are going to discard within the very same expression | |||
19:52
jpn joined
19:53
ab5tract joined
19:57
jpn left
20:03
kylese left
20:10
jpn joined,
Sgeo joined
20:15
jpn left
|
|||
raschip | Homer_Simpson You know about allomorphs? | 20:15 | |
Homer_Simpson | not really | 20:27 | |
lizmat | m: dd <44> | ||
camelia | IntStr.new(44, "44") | ||
lizmat | ^^ an allomorph | ||
m: my $a = IntStr.new(42, "the Answer"); say +$a; say ~$a | |||
camelia | 42 the Answer |
20:28 | |
20:28
jpn joined
|
|||
lizmat | ^^ an artificial allomorph | 20:28 | |
20:30
MoC left,
MoC_ joined
20:33
jpn left
|
|||
Homer_Simpson | looks like a hash to me | 20:37 | |
lizmat | ? why? | 20:39 | |
20:41
MoC_ is now known as MoC
20:45
MoC left
|
|||
[Coke] | it's not a key-value pair, it's a thing with two kinds of values. | 20:45 | |
20:45
MoC joined
20:47
jpn joined
|
|||
rf | It's both Int and Str iirc | 20:54 | |
20:54
jpn left
|
|||
lizmat | indeed | 20:54 | |
Nemokosch | one traumatic design choice that I might have mentioned - prompt attempts to return allomorphs, hence biting you at a boolean check | 20:55 | |
raschip | I like that design decision very much, one can input "a number" and it will just work. | 21:02 | |
21:02
lichtkind joined
|
|||
Nemokosch | we have very different ideas of what "just works" means apparently 😄 | 21:05 | |
for me, it would have "just worked" if it didn't attempt to do any magic, just give a string from a textual input | |||
rf | I would say Raku overall is fairly "just works", doesn't get in my way much :D | ||
Nemokosch | and hence it exactly "just didn't work" when I wanted to bool check for empty input. It bit me in a way that is hard to anticipate. | 21:06 | |
21:07
raschip left
|
|||
moreover I question the overall value of Str+Numeric allomorphs overall when there are very suited coercion methods across these types | 21:07 | ||
so if I wanted to perform math on '0', that would just work | 21:08 | ||
to be honest I feel quite confident in my arguments against the current behavior of prompt | 21:09 | ||
21:09
raschip joined
|
|||
raschip | With the current behavior one can do: MAIN (Real $size) {...}, for example | 21:10 | |
lizmat | my response = prompt($msg).Str; | ||
problem solved | 21:11 | ||
raschip | solving the empty string problem is easy, like lizmat said. Getting the typechecks on input is harder to do if that design isn't the way it is. | 21:12 | |
21:12
MoC left
|
|||
Nemokosch | I think MAIN is very much a can of worms in its current form; not sure what this has to do with prompt, though | 21:13 | |
21:13
MoC joined
|
|||
lizmat - yes, that's exactly what I did. The point is, it seems to have a net negative value. | 21:13 | ||
it's a fragile (very fragile, even) approach | 21:14 | ||
lizmat | how is it fragile? | ||
21:14
ab5tract left
|
|||
Nemokosch | parsing string input from different types can be arbitrarily complex | 21:15 | |
lizmat | agree, but how does that make it fragile? Especially if you just want a Str ? | ||
Nemokosch | the same way we acknowledge turning any type into a string (with .gist and .raku), it would make sense to acknowledge parsing as a distinct step, too | ||
lizmat | m: dd val "44" | 21:16 | |
camelia | IntStr.new(44, "44") | ||
Nemokosch | and just not feed some part of it with some implementation, into prompt, that could do one thing well | ||
lizmat | that's what's happening: it's just "val" processing | ||
on whatever input from the user | |||
raschip | Well, you're just after something other than Perl-like, then? | 21:17 | |
Nemokosch | well, then I suppose it would be really easy to turn it off, too 🙊 | ||
lizmat | put .Str after it, and you're done | ||
Nemokosch | raschip: Raku was meant to fix Perl's issues, both technical and non-technical | ||
raschip | Yep, but still be a Perl | ||
Nemokosch | not to foster dark magic | ||
lizmat: we are back to, why do more for less | 21:18 | ||
when it could have "just worked", right? | |||
lizmat | parsing user input could hardly be considered hot code, so the extra cycles used for trying to create an allomorph are really not that important | ||
raschip | It has much darker magic than Perl since the beginning, sub val on user input is nothing | ||
Nemokosch | it's not about the hot code, it's that it doesn't seem justified to badly solve a problem inside reading input | 21:19 | |
even plain old C scanf, which is arguably more transparent, is long considered an antipattern from what I know | 21:20 | ||
raschip | Yes, some people think going away from Assembler has been a mistake | ||
Nemokosch | I don't know how that follows, lol | 21:21 | |
raschip | Do What I Mean has been a Raku motto since the beggining | 21:22 | |
Nemokosch | anyways, we don't have to discuss that. If we do, however, then please let's avoid these extra fallacies. | ||
the Do What I Mean ship has sunk the moment we didn't mean the same thing by the same code | 21:23 | ||
raschip | my Int $response = prompt($msg) or MAIN (Real $size) {...} ought to work | ||
Yes, every DWIM is followed by a WAT, this is part of Raku design | |||
Nemokosch | MAIN doesn't have to be based on prompt though, I don't get this assumption. And again, I have to say, MAIN requires help because it's not solid enough currently. | 21:25 | |
let me recite a couple of issues I have come across; maybe you are the one who can solve them | |||
21:26
MoC left
|
|||
rf | Main can have custom usage messages, it's very good. | 21:27 | |
Nemokosch | github.com/rakudo/rakudo/issues/5091 | ||
its twin github.com/rakudo/rakudo/issues/5090 | |||
github.com/rakudo/rakudo/issues/4889 | 21:28 | ||
21:28
MoC joined
|
|||
raschip | I don't see how having bugs or NYI has anything to do with the design... | 21:28 | |
Nemokosch | and two others I haven't checked but are fairly recent: github.com/rakudo/rakudo/issues/5159 github.com/rakudo/rakudo/issues/5100 | ||
I'm not saying it's not good, I said that it needs help to be stable enough | 21:29 | ||
21:30
sena_kun left
|
|||
rf | Stable enough is subjective lol | 21:30 | |
I can pick any piece of functionality from any language and find bugs. | |||
Nemokosch | it's not that subjective, though | ||
and for what it's worth, I also can't see what the design of MAIN has to do with the function dedicated for getting data on stdin | 21:31 | ||
raschip | Both accept numeric types as restrictions on input | 21:32 | |
Nemokosch | yes but the same arguments don't fit for both. One does this for what I would call right reasons, the other does this for what I would call superficial design | ||
CLI input is not quite like arbitrary stdin input of a process | 21:33 | ||
rf | Fork the compiler? ¯\_(ツ)_/¯ | ||
raschip | This is about making easy things easy, but hard things are still possible. If MAIN or prompt don't do what you want (returning an allomorph) you can always do it manually. | ||
Type restrictions in arguments or user input would be much less useful if the only possible type was "Str". | 21:34 | ||
Nemokosch | exactly! prompt does the easy thing harder and the fairly useless thing easier | ||
rf: one does that for pull requests 😉 | 21:35 | ||
21:35
jpn joined
|
|||
raschip | Which easy thing is harder? | 21:36 | |
Nemokosch | "pull a string from stdin until EOL" | ||
this is the common, fundamental operation, yet this requires going back and forth | 21:37 | ||
raschip | I'm sorry, how is prompt related to that? That's a slurp... | ||
Nemokosch | that would be EOF though | ||
raschip | I see, that's what get is for | 21:38 | |
Sorry by my confusion | |||
Nemokosch | now you have a point - maybe a print and a get is actually superior to prompt | 21:39 | |
raschip | > (get).WHAT3(Str) | 21:40 | |
Nemokosch | anyway, not gonna lie, I still don't get the resistance. I'm not saying this is some top priority issue (actually, the problems of MAIN are way more important), however it just seems so obvious that building this allomorph feature into taking user input (when most allomorphs are highly unnecessary anyway) comes with more drawbacks than advantages | 21:41 | |
it solves "half of a problem", and sadly the half that didn't even need a solution | 21:42 | ||
21:43
jpn left
|
|||
raschip | And your design suggestion is just returning pure Str? | 21:43 | |
Nemokosch | that would be the obvious solution, yes | 21:44 | |
the elaborate, "make a point" solution would be to make it take some customizable parser | |||
raschip | That goes against the language design goals | 21:45 | |
Nemokosch | wholeheartedly disagree | ||
lizmat | I guess we agree to disagree.... can we now look at other stuff that needs to be done ? | ||
Nemokosch | well, nobody is stopping anybody from that | 21:47 | |
I gotta take this resistance into account when one day I reach to the proposal to take this out, by default at least 🙊 | 21:48 | ||
raschip | This has been discussed 1000 times already, and the answer is always the same, lizmat is tired of this discussion | 21:49 | |
21:49
MoC left
|
|||
raschip | We could continue it, but it must be elsewhere, would that be good enough, lizmat? | 21:50 | |
Nemokosch | well if this really is discussed repeatedly, maybe the time will indeed come when those people who argued against it will be taken more seriously | ||
there are cases like that I think, and they are often related to Perl legacy | |||
there are cases like that I think, and they are often related to Perl legacy | 21:51 | ||
lizmat | \_(ツ)_/ | ||
or in Raku speak: | |||
* | |||
Nemokosch | one such thing would be this "named arguments slurpy" behavior | 21:52 | |
I believe it will go one day but it doesn't seem realistic by 6.e times to me | |||
21:55
jpn joined
22:01
jpn left
22:04
ispyhumanfly joined
22:05
shmup_ is now known as shmup
|
|||
rf | Lol lizmat, good one * | 22:06 | |
22:07
MasterDuke joined
22:13
jpn joined
22:27
jpn left
|
|||
raschip | g'night everybody | 22:33 | |
22:33
raschip left
|
|||
Nemokosch | nighty | 22:35 | |
22:40
jpn joined
22:47
jpn left
23:00
xinming__ left
|
|||
FLI: github.com/lizmat/Git-Files/pull/1 😛 | 23:14 | ||
23:17
jpn joined
23:22
jpn left
23:31
Homer_Simpson left
23:39
Homer_Simpson joined
23:40
Homer_Simpson joined
23:50
jpn joined
23:51
lichtkind left
23:57
jpn left
|