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

array is a type #1949

Closed
Juerd opened this Issue Jun 22, 2018 · 6 comments

Comments

Projects
None yet
6 participants
@Juerd

Juerd commented Jun 22, 2018

The Problem

array is a type

Expected Behavior

array constructs an array, just like hash constructs a hash and list constructs a list.

.say for hash, list, array;  # expected: {}  ()  []

Actual Behavior

.say for hash, list array;  # actual: {}  ()  (array)

@AlexDaniel AlexDaniel added the RFC label Jun 22, 2018

@lizmat

This comment has been minimized.

Show comment
Hide comment
@lizmat

lizmat Jun 22, 2018

Contributor
Contributor

lizmat commented Jun 22, 2018

@AlexDaniel

This comment has been minimized.

Show comment
Hide comment
@AlexDaniel

AlexDaniel Jun 22, 2018

Member

I’m afraid we’re past fixing that now -(

I think there's no need to be pessimistic about this. I can totally see how array can be tweaked to do something else in future language releases (maybe after a couple of them), of course if that's something we decide to do.

Member

AlexDaniel commented Jun 22, 2018

I’m afraid we’re past fixing that now -(

I think there's no need to be pessimistic about this. I can totally see how array can be tweaked to do something else in future language releases (maybe after a couple of them), of course if that's something we decide to do.

@zoffixznet

This comment has been minimized.

Show comment
Hide comment
@zoffixznet

zoffixznet Jun 22, 2018

Contributor

A broader list of the inconsistencies:

  • Method form coercer— can call $foo.thing
  • Sub form coercer— can call thing $foo
  • Mandatory parens for no arg call— can't call thing;, must use thing();
  • Type—is thing a type that can be used as, say, sub (thing) {}
  • Is Native—is thing a native type (if it's not a type, is the thing it returns a native thing)
  • Can .new—is thing.new a valid construct that returns thing in some form or shape
Name Method form coercer Sub form coercer Mandatory parens for no arg call Type Is Native Can .new
set ✓ (indirectly, by calling on return type)
bag ✓ (indirectly, by calling on return type)
mix ✓ (indirectly, by calling on return type)
hash ✓ (indirectly, by calling on return type)
pair N/A ✓ (indirectly, by calling on return type)
list
array ✗ (tries to call method) N/A ✓ (if parametarized)
int ✗ (REPR error) N/A
int8 ✗ (REPR error) N/A
int16 ✗ (REPR error) N/A
int32 ✗ (REPR error) N/A
int64 ✗ (REPR error) N/A
num ✗ (REPR error) N/A
num32 ✗ (REPR error) N/A
num64 ✗ (REPR error) N/A
str ✗ (REPR error) N/A
Contributor

zoffixznet commented Jun 22, 2018

A broader list of the inconsistencies:

  • Method form coercer— can call $foo.thing
  • Sub form coercer— can call thing $foo
  • Mandatory parens for no arg call— can't call thing;, must use thing();
  • Type—is thing a type that can be used as, say, sub (thing) {}
  • Is Native—is thing a native type (if it's not a type, is the thing it returns a native thing)
  • Can .new—is thing.new a valid construct that returns thing in some form or shape
Name Method form coercer Sub form coercer Mandatory parens for no arg call Type Is Native Can .new
set ✓ (indirectly, by calling on return type)
bag ✓ (indirectly, by calling on return type)
mix ✓ (indirectly, by calling on return type)
hash ✓ (indirectly, by calling on return type)
pair N/A ✓ (indirectly, by calling on return type)
list
array ✗ (tries to call method) N/A ✓ (if parametarized)
int ✗ (REPR error) N/A
int8 ✗ (REPR error) N/A
int16 ✗ (REPR error) N/A
int32 ✗ (REPR error) N/A
int64 ✗ (REPR error) N/A
num ✗ (REPR error) N/A
num32 ✗ (REPR error) N/A
num64 ✗ (REPR error) N/A
str ✗ (REPR error) N/A
@pmichaud

This comment has been minimized.

Show comment
Hide comment
@pmichaud

pmichaud Jun 22, 2018

Contributor

I don't know the current state of things, but originally hash and list were deemed "contextualizers", not "constructors". So I wouldn't necessarily expect them to do the same as array , nor did they necessarily "construct" a List or a Hash.

So part of the difference (and confusion) may be that the same words ("hash / list") are used to refer to both a context and a type.

Pm

Contributor

pmichaud commented Jun 22, 2018

I don't know the current state of things, but originally hash and list were deemed "contextualizers", not "constructors". So I wouldn't necessarily expect them to do the same as array , nor did they necessarily "construct" a List or a Hash.

So part of the difference (and confusion) may be that the same words ("hash / list") are used to refer to both a context and a type.

Pm

@jnthn

This comment has been minimized.

Show comment
Hide comment
@jnthn

jnthn Jun 22, 2018

Member

What @pmichaud said: hash and list are contextualizers. That's why .list on an Array and .hash on a Map are both identity. It's also why there's a set sub (also seen as a contextualizer), but not a sethash sub.

Many types come in a mutable and shallow-immutable form (List/Array, Map/Hash, Set/SetHash), and in all of these cases there's a single conextualizer. If there's an odd one out, it's hash, which is named after the mutable thing. For obvious reasons, we couldn't use map for that. It does, however, produce by default the type you'd think that it would from the name (a Hash), if it isn't in an identity situation.

There's also a consistent pattern of the boxed/object form of a type, say Int, having its native form in lowercase (int). The Array/array is also a case of this.

Thus asking for array to be a sub that creates an array is asking for two other consistent patterns to be broken. This doesn't strike me as a win.

Member

jnthn commented Jun 22, 2018

What @pmichaud said: hash and list are contextualizers. That's why .list on an Array and .hash on a Map are both identity. It's also why there's a set sub (also seen as a contextualizer), but not a sethash sub.

Many types come in a mutable and shallow-immutable form (List/Array, Map/Hash, Set/SetHash), and in all of these cases there's a single conextualizer. If there's an odd one out, it's hash, which is named after the mutable thing. For obvious reasons, we couldn't use map for that. It does, however, produce by default the type you'd think that it would from the name (a Hash), if it isn't in an identity situation.

There's also a consistent pattern of the boxed/object form of a type, say Int, having its native form in lowercase (int). The Array/array is also a case of this.

Thus asking for array to be a sub that creates an array is asking for two other consistent patterns to be broken. This doesn't strike me as a win.

@lizmat

This comment has been minimized.

Show comment
Hide comment
@lizmat

lizmat Jul 26, 2018

Contributor

I feel this ticket can be closed.

Contributor

lizmat commented Jul 26, 2018

I feel this ticket can be closed.

@zoffixznet zoffixznet closed this Jul 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment