02:15 mahafyi left 04:14 mahafyi joined 04:30 gfldex left, gfldex joined 07:53 dakkar joined
mfiano What does the root object Mu stand for/mean? 09:23
lizmat Most Undefined 09:25
mfiano Thanks. Also what does the U type smiley stand for?
lizmat Undefined
I guess that's really a holdover from Perl :-) 09:26
mfiano The docs mention not to confused defined with definite. So does the D smiley stand for Defined then? I had assumed Definite
lizmat I guess nowadays it would be a :T for type object, and :I for instantiated :-)
definite 09:27
m: sub a(Failure:D) { }; a Failure.new
well, that works :-)
say Failure.new.defined # False 09:28
mfiano Right, Failure is a special case. I just find it odd that :U is not symmetrical like :I[ndefinite] :)
lizmat any class can be a special case, if they override the .defined and .Bool methods :-)
mfiano Right
Nemokosch what's the difference between defined and definite then? 09:29
lizmat basically, definite means that it is not a type object, that it is an instance 09:30
.defined is *usually* the same, but can be overridden
mfiano docs.raku.org/type/Signature
search for "definedness"
lizmat say Failure.new.DEFINITE # True
say Failure.new.defined # False 09:31
Nemokosch what is a "type object" then?
lizmat class Foo {} # Foo is a type object 09:32
class Foo { }; my $foo = Foo.new; # $foo is an instantiated object of type Foo
everything in Raku is an object, or has an object representing it (e.g. in the case of native integers) 09:33
Nemokosch hm, this terminology doesn't sound too helpful or even useful 09:34
mfiano An instance and a type smartmatch to a type. This is not always what you want in a signature object, so you can use type smiley's to choose either definite or indefinite objects. 09:38
# Str ~~ Str # True 09:42
# Str ~~ Str:D # False 09:43
If you add a type constraint to an optional parameter for example, and it is not supplied as an argument and doesn't have a default value, it receives the type object as its value
There are many cases where this is not what you want 09:44
09:51 mahafyi left
Nemokosch > If you add a type constraint to an optional parameter for example, and it is not supplied as an argument and doesn't have a default value, it receives the type object as its value 10:26
what the hell, why?
mfiano Because all parameters have values, even if they are un-used in the body block 10:29
This goes in hand with the Smalltalk inspiration of everything being an object
Nemokosch "everything is an object" fundamentally applies to Python and Javascript as well, I don't think it follows that an unused value should get an incompatible random value 10:36
In this regard, the None and undefined values seem much more fitting
mfiano Sure, but they came a few decades later :-) 10:37
Nemokosch Raku also came a few decades later šŸ˜„ 10:38
mfiano and Smalltalk got it from Lisp
Nemokosch I mean, just because it's in Smalltalk, I don't think it automatically turns into reasonable behavior
and the quoted part (about the type object being implicitly the default value) sounds like plain madness to me 10:39
mfiano Maybe lizmat or somebody can explain why it is reasonable. My opinion is probably too biased to explain it properly, having used Lisp for more than 20 years. 10:40
Nemokosch It would make more sense in Javascript as a prototype based language but then again, "undefined means missing" still makes more sense than shifting between an "instance object" and a "type object" back and forth which are conceptionally different 10:41
lizmat my Int $a; say $a; # Nemokosch: what do you expect that to say ?
Nemokosch either 0 or an equivalent to undefined, I leave this up to one's temperament 10:42
mfiano I guess my Lispy answer to that would be: Nil
But I know its (Int)
lizmat say Int.defined # what do you expect that to say
Nemokosch I don't feel like I need that so I can't answer 10:43
lizmat well, Int is "an equivalent to undefined" in Raku 10:44
as are all type objects
Nemokosch the question is: why? it's on a different conceptual level
the Int type shouldn't be of Int type 10:45
and that's what it suggests
let's approach this differently, from the pragmatic side 10:46
when is this the behavior that one wants for a lacking Int value? 10:47
lizmat well, actually, Int is an instance of Perl6::Metamodel::ClassHOW
well, it expresses an unfulfilled expectation 10:48
mfiano If you supply a type constraint it can't be undefined, or the bottom type, or anything by definition.
If you don't supply a type constraint, it becomes Any
lizmat my Int $a; say $a # if that would say anything but (Int), it would mean that type checking is broken, as you've indicated you wanted to constrain to Int types 10:49
if you really want to make lack of a value an issue, you should constrain to instances
my Int:D $a # Variable definition of type Int:D needs to be given an initializer 10:50
mfiano Well said
Nemokosch > well, it expresses an unfulfilled expectation 10:51
That's what None, Nil, undefined all express without setting an unintuitive type structure
lizmat my Int:D $a = Nil # Type check failed in assignment to $a; expected Int:D but got Int (Int) (perhaps Nil was assigned to a :D which had no default?) 10:53
Nemokosch I've never been a big fan of static typing "for the sake of it", I feel we are bumping into conceptional issues again 10:54
lizmat my Int:D $a is default(42) = Nil; say $a # 42
my Int:D $a is default(42); say $a # 42
Nemokosch: I guess we can agree that we disagree on the sensibility of of Raku types / constraints / signature binding works 10:55
but I think you're about 18 years late in this discussion
Nemokosch it's important to draw attention to questionable decisions as well though 10:56
> if that would say anything but (Int), it would mean that type checking is broken, as you've indicated you wanted to constrain to Int types 10:57
this seems to be the only argument and well, this argument is very implementation-oriented
lizmat Nemokosch: a Pull Request tells more than a thousand words
if you think it should be different, please make an issue in the problem solving repo 10:58
github.com/raku/problem-solving
Nemokosch so just to get this straight 11:02
```perl 11:03
my Int $a;
```
on this, I can call .new
lizmat yes 11:04
Nemokosch that's pretty interesting by itself if this isn't a prototype-based language but okay, apparently you can call .new on any integer value
11:04 samebchase joined
lizmat you can call .new on anything in Raku, even native types :-) 11:05
Nemokosch ```perl
> $a.^name
Int
```
wait for a second
mfiano True.new # False :-) 11:06
Nemokosch do instance objects straight up cover the whole interface of a type object then?
lizmat well, enums are special in that respect :-)
mfiano: but that's effectively Bool.new 11:07
Nemokosch if they do, it can work consistently at the end of the day
lizmat instance objects *can* cover up the whole interface if they want to, yes 11:08
it all depends whether the class has different multi-methods for instantiated invocants and type object as the invocant
(or handles that in code inside an only method)
Nemokosch I mean, it seems like the approach is the other way around than I imagined 11:11
it's much more like everything is a kind of prototype 11:12
lizmat you could argue that, yes 11:13
Nemokosch or maybe it's more fitting to say given the context, value objects can "collapse into" the corresponding type object? 11:16
when True.new works and returns False, is it more like a conversion from True to Bool or True itself "does Bool"? 11:18
lizmat actually, I never considered calling .new on Enums... so I would need to think a out that 11:19
mfiano Hmm, I could use some clarification on a section of the class tutorial: docs.raku.org/language/classtut#Th...declarator 11:32
In reading that, it is unclear to me what prefixing "also" actually does, or if it is no different than simply "is ..." 11:33
11:34 camelia joined
mfiano Oh I see, it is inside the block 11:34
Hmm, not sure what this solves.
m: say "Hi, camelia!" 11:35
camelia Hi, camelia!
lizmat mfiano: I don't recall why "also" still exists, but I think it has to do with giving you some compile time flexibility in deciding on class hierarchy 11:38
mfiano That makes sense.
lizmat morirz++
11:48 mahafyi joined
Morfent m:``` 11:51
role Lazy {
# use ...;
also is #`[...] Int;
};
say Lazy.new;
```
lazy module loading in the case of roles
lizmat if you call .new on a Role, It will get punned into an anonymous class with the same name, and have .new called on that 11:52
Morfent i wonder if i can take advantage of this in `Data::Record`... 11:58
that module takes forever to precomp
another way to defer module loading is `role ...[::T] does T` parameterized by a `require`d type 13:29
that helps according to `raku --stagestat`, but parsing still takes a long time 13:30
maybe the module's too monolithic
that helps according to `raku --stagestats`, but parsing still takes a long time 13:32
14:39 mjgardner_ is now known as mjgardner 16:51 dakkar left
gfldex mfiano, Nemokosch#9980 please note that (almost) any assumption can be broken in Raku 18:25
consider: (my $oddject = Metamodel::ClassHOW.new_type(name => "")).&{.^add_method('FALLBACK', method ($name) { 'cheating' }); .^compose};
Nemokosch oddject xD 19:30
23:14 colemanx joined
colemanx Hello everyone. I've written a grammar, and it seems to have pinned a cpu, and my program doesn't finish. 23:15
Here is the github gist: envs.sh/AN 23:16
There is some sample data attached there, as well. I am familiar with regex, but not sure why the program doesn't finish. 23:17
[Coke] what are you passing as the path? 23:20
oh, data. 23:22
I recommend using Grammar::Debugger. 23:30
if you install that and use it in your program, you can see that it matches the first sep, and then tries to match an item and immediately goes into the weeds
also: "item" is apparently special, don't use that as a name. 23:40
once it starts parsing, you start getting errors about wrong number of args because it's trying to give it to a different item. 23:41
gist.github.com/coke/f1d594983af0a...3cbc235608 23:42
colemanx Thank you, I was afk for a bit, but I'll install Grammar:Debugger 23:56

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!