Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Special case allomorph coercion everywhere #6322

Open
p6rt opened this issue Jun 4, 2017 · 3 comments
Open

Special case allomorph coercion everywhere #6322

p6rt opened this issue Jun 4, 2017 · 3 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Jun 4, 2017

Migrated from rt.perl.org#131505 (status was 'open')

Searchable as RT131505$

@p6rt
Copy link
Author

p6rt commented Jun 4, 2017

From @zoffixznet

(found in discussion in https://rt-archive.perl.org/perl6/Ticket/Display.html?id=131493 )

We have some special casing for coercion of allomorphs in some instances, which
is done so there'd be some way to force one of the two types to fall out of it,
since we have types where to whom object identity matters a bunch​:

  <Zoffix__> m​: <1>.Str.^name.say
  <camelia> rakudo-moar 7344a3​: OUTPUT​: «Str␤»
  <Zoffix__> m​: <1>.Int.^name.say
  <camelia> rakudo-moar 3755c0​: OUTPUT​: «Int␤»

However, allomorphs don't get coerced with parameter coercers and possibly some
other places. There's no special casing here done. The coercer coerces to Str type
and IntStr allomorph is already it.

  <Zoffix__> m​: -> Str() $_ { .^name.say }(<1>)
  <camelia> rakudo-moar 7344a3​: OUTPUT​: «IntStr␤»
  <Zoffix__> m​: -> Int() $_ { .^name.say }(<1>)
  <camelia> rakudo-moar 7344a3​: OUTPUT​: «IntStr␤»

So the question becomes​: do we special case allomorphs everywhere?

- If yes, any place we special case them will have a caveat and surprising behaviour
  where type don't get coerced to exact asked type if it's a subclass of it
- If no, we get surprising special cased behaviour like above, but only in one case
- Or we could remove the coercion to one of the two types and have <1>.Str return the same
  IntStr; in that case I'm unsure what would be a way to "collapse" an allomorph into
  numeric or string parts, since many ops use these methods to coerce stuff.

@p6rt
Copy link
Author

p6rt commented Jun 5, 2017

From @coke

On Sat, 03 Jun 2017 21​:20​:49 -0700, cpan@​zoffix.com wrote​:

(found in discussion in
https://rt-archive.perl.org/perl6/Ticket/Display.html?id=131493 )

We have some special casing for coercion of allomorphs in some
instances, which
is done so there'd be some way to force one of the two types to fall
out of it,
since we have types where to whom object identity matters a bunch​:

<Zoffix__> m​: <1>.Str.^name.say
<camelia> rakudo-moar 7344a3​: OUTPUT​: «Str␤»
<Zoffix__> m​: <1>.Int.^name.say
<camelia> rakudo-moar 3755c0​: OUTPUT​: «Int␤»

However, allomorphs don't get coerced with parameter coercers and
possibly some
other places. There's no special casing here done. The coercer coerces
to Str type
and IntStr allomorph is already it.

<Zoffix__> m​: -> Str() $_ { .^name.say }(<1>)
<camelia> rakudo-moar 7344a3​: OUTPUT​: «IntStr␤»
<Zoffix__> m​: -> Int() $_ { .^name.say }(<1>)
<camelia> rakudo-moar 7344a3​: OUTPUT​: «IntStr␤»

So the question becomes​: do we special case allomorphs everywhere?

No. The current behavior seems correct to me.

- If yes, any place we special case them will have a caveat and
surprising behaviour
where type don't get coerced to exact asked type if it's a
subclass of it

If you want something coerced to the exact type, this can be done outside of the signature.

I would just document the behavior for coercions clearly, in that if the value already satisfy the type in the coercer, your value is passed through unchanged.

- If no, we get surprising special cased behaviour like above, but
only in one case
- Or we could remove the coercion to one of the two types and have
<1>.Str return the same
IntStr; in that case I'm unsure what would be a way to "collapse"
an allomorph into
numeric or string parts, since many ops use these methods to coerce
stuff.

--
Will "Coke" Coleda

@p6rt
Copy link
Author

p6rt commented Jun 5, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt added the at_larry label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant