Document contexts

[briandfoy]

#1255 As with #1223 (and #732), I find that the idea of concept of context is diffuse. I think Perl 6 needs to have a section (somewhere) devoted just to context since this is a fundamental language concept.

I don't have all the info that would need. Here are some notes I'm working on.

First, a list of words in front of context in various docs, including synopses:

• sink
• number
• string
• boolean
• item (formerly "scalar", but still "scalar" in roast)
• list
• iterable

Some other bugs this impacts, as I run across them:

• RT 131008: lcm should not work with Nums, and maybe gcd too
• RT 131041: Use of Nil in string context

[AlexDaniel]

FWIW, I don't think the concept of contexts is as fundamental as it is in Perl 5.

Even “void context” is not really a thing (it's just something returning a value nowhere).

[b2gills]

In a certain view there are as many contexts for an object as there are types that you can coerce that object to.

Str( $_ )
Numeric( $_ )

currently all of them just call a method of the same name on the object if it isn't already of that type.

There is also enum coercion, which turns a value into a value of that enum

say Order(-1).perl; # Order::Less

hyper and race just wrap an iterator in something that knows how to be hyper.

eager just tells an Iterable to go ahead and produce all of the values, in some places it can be delayed.
This is also the case when you put a sequence into an array, a hash, or a slurpy argument.

There are 4 array argument types

:(   @_ ) # readonly alias
:(  *@_ ) # flattening slurpy ( immediately eager )
:( **@_ ) # non-flattening slurpy
:(  +@_ ) # single Positional argument or non-flattening slurpy

An itemized value doesn't flatten when using flat, and I think of it as an attribute attached to the value.

[coke]

Regarding the type coercions listed above, I would say these are not actually contexts. Typically, it's an explicit coercion (+$foo, ?$bar, $baz.Str)

There are some language constructs that enforce a coercion - that could be considered a context, like the expression in "if", but I would prefer "implicit coercion", as context has some baggage coming from p5.

[briandfoy]

There are situations in which "implicit coercions" happen. That's the definition of "context". "Coercion" is the action, "context" is the situation that triggers it. The Perl 6 design docs and other docs use "context" frequently.

From S01:

Perl will continue to be a multiparadigmatic, context-sensitive language.

And, the search results for "context" in this repo: https://github.com/perl6/doc/search?utf8=✓&q=context

But, choose your term (I will continue to call it "context"). Whatever you label it, the language recognizes some situations and does different things in those situations. No matter the label, people need to know how Perl 6 is going to act on their behalf in these situations.

[thundergnat]

The concept of "context" is overloaded sightly differently between Perl 5 and Perl 6. Really, what Perl 5 calls context, is multi dispatch in Perl 6, at least for the scalar and list contexts. E.G. a subroutine can follow different code paths depending on if the passed arguments are singular or collective. That is exactly what Perl 6 multi dispatch does, it just has much finer definitions than just a single item or collection, with the ability to follow different code paths for each defined type if desired.

On the other hand, when things are said to be in a certain context in Perl 6, they are usually referring to the type of object that is expected in a certain situation rather than how an object is being interpreted.

It is perhaps confusing that void was lumped in as a 'context' in Perl 5 because is has a different connotation and effect than 'scalar' or 'list'. 'Sink' context in Perl 6 is very close to the meaning of 'void' context in Perl 5; both mean that values are being thrown away.

Coercion is often conflated with multi dispatch ( and context ) in Perl 6 but they are actually almost opposites. Coercers convert / reinterpret one type of thing to another type. Multi dispatch put constraints on what will be accepted by a particular callable and allows for the different code paths for different type parameters. It seems to be a common point of confusion that constraints are not coercers and coercers are not constraints. Adding more confusion is the fact that many CORE operators DO have built in coercers to allow things to just DWIM. (You pay for every DWIM with a WAT somewhere else.)

[coke]

See also: #732

[AlexDaniel]

So what is the right place to put this stuff into? For sink it's clear, there's a sub and it can be documented there, but what about everything else?

[rafaelschipiura]

@AlexDaniel Your question is answered just at the start of the ticket: "needs to have a section (somewhere) devoted just to context".

[AlexDaniel]

@rafaelschipiura which means? https://docs.perl6.org/language/context ? This ticket is a bit stuck, I'm trying to get better directions :)

As for language/context, I'm not entirely convinced that Perl 6 is a language that demands a page like this… Do we have any other place?

[rafaelschipiura]

@AlexDaniel What about expanding https://docs.perl6.org/language/typesystem#Coercion ?

It should also link to the multi-dispatch explanation to say that sometimes things aren't actually coerced by signatures and instead are dispatched to different places based on type, which will look like a coercion.

[JJ]

Would the last proposal by @rafaelschipiura be acceptable to everyone?

[JJ]

This is the first result when you look for "sink context perl6". We should definitely have at least that one...

[JJ]

I have eliminated a number of contexts that are no longer apparently in the documentation, or for which I could find no mention or reference. There's a .hash coercion for objects, but an explicit coercion does not imply a context, except the obvious one. So if there's any context I'm missing please add it to the issue.

[JJ]

Well, there's another context to go...

[coke]

The only reference I can find for "iterable context" (the last item unchecked on @briandfoy's original list) is an article by @JJ linking... to this ticket.

Re-closing ticket.