Allomorphs are an interface drug

[0rir]

%*SUB-MAIN-OPTS<coerce-allomorphs-to> seems to address part of a problem. That problem is that allomorphs are only great when you need them, which is likely an external interface. When writing strictly typed OO they can be an unwanted type.

no allomorphs, use coerce-allomorphs numerically, and use coerce-allomorphs Str are hints to possible changes, while use allomorphs and no coerce-allomorphs could restate current behavior.

Just one scenario:

Given a bunch of multi X( Int $a) {...}; multi X( Str $a) {...} a pragma around them, and/or upstream in the data flow, could be a concise fix for multiple ambiguous calls.

In simple cases, a pragma might alter my @a = < 1 2.1 3> to either side. It is a coarsely grained approach to the generalized task.

[librasteve]

yeah, allomorphs are a shady area, I agree

imo, you have this situation:

• untyped raku (and perl before it) offers very promiscuous interchange of Stringy and Numeric
• raku let's us introduce type gradually as our code needs more discipline
• Allomorphs such as IntStr provide an answer to the question "how can we maintain the flexibility of untyped raku in a strictly typed world"

since we want to adhere to the Liskov Substitution Principle (LSP), then an IntStr Allomorph is Int and is Str since it is formally a child of Int and Str ... so actually it is well behaved in a strict type system

this best I can think of to weed out Allomorphs (if you want to suppress this flexibility) is this:

multi frob( IntStr $a) { nextwith $a.Int };

or maybe

subset NAllo of Int where * !~~ Allomorph;
multi frob(NAllo $a) { dd $a }

I do get that a coercion in the form Int(Allomorph) or maybe Int() would be nicer instead of a subset (or where clause), but I also think this would break the LSP (which is a facet of strict typing / SOLID principles after all) so I can understand that raku is compliant to that model

PS. fwiw X is not a good name for a sub

[2colours]

since we want to adhere to the Liskov Substitution Principle (LSP), then an IntStr Allomorph is Int and is Str since it is formally a child of Int and Str ... so actually it is well behaved in a strict type system

Could be that I'm misunderstanding LSP but I think Allomorphs actually violate it, quite inevitably. <0e10> represents a NumStr which is a Str. That means I can substitute it in for any part of the Str "interface", right? So I perform an empty check by calling .so and (wrongly!) conclude that it's empty. Then for good measure I call .chars and suddenly get 4. How can a string both look empty and have 4 characters?

It goes both ways: 0e10.chars would report a textual length of 1 so I could assume that something that is a number and numerically equal to 0e10 has the same length - but as we have seen, <0e10>.chars has a length of 4.

You could say that this is okay because the methods exist at least; I would say it's actually worse than not inheriting because it seems like you have a compatible interface and then it does something else.

Anyway, I'm not sure of the issue is about this.

[jubilatious1]

@0rir wrote:

That problem is that allomorphs are only great when you need them, which is likely an external interface.

So Allomorphs are really heteromorphs?

😊

[librasteve]

.so is not a check for "empty" it is a check for truthiness and surely the number zero (however you write it) is not True in raku

in your example, the Str interface is not violated (imo) since .so and .chars return valid and correct results, but it is honoured in a way that represents the weight of meaning in what you have

I agree that Allomorphs can be inconvenient as the OP says and so proposed a couple of ways that your raku API can reject Allomorph types, but that is somewhat of an uphill struggle (as it should be)

[2colours]

.so is not a check for "empty" it is a check for truthiness

for strings, yes, it absolutely is.

[0rir]

@librasteve says:

[rejecting] Allomorph types ... is somewhat of an uphill struggle (as it should be)

Why should it be a struggle? I find that at odds with explicit foundational ideas of the sisters, e.g. make the difficult easy.

Incremental typing is one of the features that attracted me to Raku. In my learning exercises, I have bumped into the problem of allomorphs in literal composite structures interfering with the typing I had designated. Understanding the basic problem, it is easiest to loosen the typing. But that delays interacting with more subtle problems with typing. That aspect can be improved by other strategies than I have offered here.

I appreciate the convenience of Raku's allomorphs, this is first time I've writtenmy $fu = IntStr( 1, "" ),

With further reflection, I think my OP "coerce" suggestions to be poor. I still see the 'allomorph' pragma as useful.

[jubilatious1]

Nota bene: R-programming language does the following (coercion rules) ...

• Logical values are converted to numbers: TRUE is converted to 1 and FALSE to 0.
• Values are converted to the simplest type required to represent all information.
• The ordering is roughly logical < integer < numeric < complex < character < list.
• Objects of type raw are not converted to other types.
• Object attributes are dropped when an object ... .

https://www.oreilly.com/library/view/r-in-a/9781449358204/ch05s08.html

Maybe useful?

[librasteve]

@2colours - I stand corrected that .so tests a Str for emptiness - til

thus we have:

> ''.so       #False   (Str)
> '0'.so     #True    (Str)
> 0.so       #False   (Int)
> 0e10.so #False   (Num)

so if you load an Allomorph with a corner case, then what is the "right" thing to do when you apply .so?

should it do the String thing or the Numeric thing?

thus, as you pointed out ...

<0e10>.so #False

I think that the main points of my case remain intact:
(i) that the Allomorph class in raku is correct to emphasize the numeric properties since it can be imagined that the number is the active value and the string is a record of the literal that was parsed originally (this is consistent with the behaviour of ACCEPTS)
(ii) provided .so returns a Bool, the LSP is not violated since this is what the API defines
(iii) this is properly documented Returns False if the invocant is numerically 0, otherwise returns True. The Str value of the invocant is not considered. https://docs.raku.org/type/Allomorph#method_Bool

[librasteve]

@jubilatious1 - in raku True == 1 and False ==0, and even True ~~ Int #True so I see the parallels with R (and perl)

in a similar vein, the Type Graph here https://docs.raku.org/type/Numeric#typegraphrelations shows how eg. Num ~~ Real #True and Num ~~ Complex #False which is a somewhat different mapping based more on common sense such as 'a Real number is not a Complex number'

now I guess that one can argue that a Real number is a Complex number (i.e. when the factor of i is 0) and one can argue that if it is Real it is not Complex ... so raku has taken a more operational approach like "if it is Complex then I have to calculate two factors when I do math operations and I don't want to encumber Real math with this overhead"

that's what I call a language design decision and I'm happy to live with Larry's judgement on that

[librasteve]

@0rir - you ask "Why should it be a struggle? `

One of the stated design values that raku has generally is that it nudges us to code in a better way[*] Which is the sort of strict interpretation of make the easy things easy and the hard things possible.

So when you have a class inheritance, the best practice is easy:

class Parent {}
class Child is Parent {}

sub fn(Parent $x) { ... }  
Child.new.&fn;   #accepts Child since Child ~~ Parent

So the easy path is that the LSP is honoured. Alternatively, it is (justifiably) more of a struggle to selectively reject some and not others like this:

class Parent {}
class Child is Parent {}

subset AdultsOnly of Parent where * !== Child;
sub fn(AdultsOnly $x) { ... } 
Child.new.&fn;   #rejects Child

Why justifiably?

Since tbh you may want to consider using role composition instead of inheritance if you want some of your children to be selectively rejected.

[*] Another example of this is the overhead needed to write a Proxy private get/set private attribute (since it is better style to go via a settor method).

[jubilatious1]

@librasteve

in raku True == 1 and False ==0, and even True ~~ Int #True so I see the parallels with R (and perl)

in a similar vein, the Type Graph here https://docs.raku.org/type/Numeric#typegraphrelations shows how eg. Num ~~ Real #True and Num ~~ Complex #False which is a somewhat different mapping based more on common sense such as 'a Real number is not a Complex number'

So the R programming language is a vector-based language. There are no scalars. Anything you might think of as a scalar is actually a vector of length == 1. What I posted above (The O'Reilly link to R in a Nutshell, 2nd Edition are coercion rules. Sorry if I wasn't clear.

@0rir specifically started this Issue (I think) to discuss coercion. I'm not even sure my Rakudo is up-to-date on the latest coercion pragmas. But this is what the R-programming language does (in the R-Console i.e. REPL), using the ubiquitous c(...) combine function (coercer):

> c(FALSE,TRUE,NA)
[1] FALSE  TRUE    NA
> c(0,1,NA)
[1]  0  1 NA
> c(0,TRUE,NA)
[1]  0  1 NA
> c(0,1.1,NA)
[1] 0.0 1.1  NA
> c(0,"1.1",NA)
[1] "0"   "1.1" NA   
> 

"This is a generic function which combines its arguments. The default method combines its arguments to form a vector. All arguments are coerced to a common type which is the type of the returned value, and all attributes except names are removed."
https://search.r-project.org/R/refmans/base/html/c.html

R decides that every vector can only be of one type, generally coerced with c(...). Above are the default coercions. You can do specific coercions such as as.numeric(...) but you risk losing data:

> as.numeric(c("-.1"," 2.7 ","B"))
[1] -0.1  2.7   NA
Warning message:
NAs introduced by coercion 
> 

Raku has obviously made different design choices (e.g. multiple Types within the same List/Array), which one might consider insanely brilliant. But it does beg the question as to how to coerce properly.

[librasteve]

cool - I guess we can Close this issue now... (I can't do that)

[jubilatious1]

@librasteve Sorry if I wasn't clear, I posted R code.

Seems like discussion on Raku Allomorphs should continue?

[librasteve]

@jubilatious1 - I understand the OP to be requesting some pragmas to squish Allomorph behaviour in raku body code

I am fundamentally against pragmas ("the best part is no part")

So I have convincingly made the case that the current Allomorph behaviour is the best design balance between (i) having Allomorphs at all, (ii) have pragmas to turn them on and off, (iii) having them as they are now where a (small) struggle is needed to suppress LSP if you don't like them

It has been an interesting discussion - and thank you for the R references

According to the OP With further reflection, I think my OP "coerce" suggestions to be poor. I still see the 'allomorph' pragma as useful.

So since there are 200 open Issues here, I propose that we agree (or at least agree to disagree) and close this one.