This page was generated by Text::SmartLinks v0.01 at 2017-03-23 11:48:07 GMT.
(syn eccde78)
  [ Index of Synopses ]

TITLE

Plans for Perl 6 version 6.d

VERSION

    Created: 09 Aug 2016
    Last Modified: 16 Dec 2016
    Version: 3

This documents contains planned changes for v6.d, and who wants to do them.

Please list yourself as stakeholder so we'd know whom to contact if we need clarification. If possible, find a volunteer willing to implement your proposal (it could be you).

Sigils imply :D

In a declaration, the @ sigil for example implies a type constraint to Positional. I want the sigil to imply the type constraint Positional:D instead, so that it constrains the variable to defined values.

The same applies to the % sigil, and possibly the & sigil.

Current behavior:

    sub f(@x) { say @x.perl }; f Array;     # Array

New behavior:

    sub f(@x) { say @x.perl }; f Array;
    # dies with
    # Parameter '@x' requires an instance of type Array, but a type object was passed.  Did you forget a .new?

Rationale

I've never seen anybody write code as if they expected an array or hash variable to contain a type object, yet the type checker silently allows this, which usually leads to much worse error messages when using the type object as if it were an instance.

Since normal variables are typically used with assignment, not binding, constraining the types of parameters is of higher importance.

It is quite easy to write code that waits for multiple promises in parallel, which can lead to the full thread pool begin tied up in blocking waits, leading to a deadlock.

Examples of this happening have showed up in the past.

Stakeholder

Moritz Lenz

Jonathan Worthington

Samantha McVey (samcv)

Oh, I thought you said steak... (Zoffix)

Zoffix

Zoffix

Zoffix

Non-blocking await

In v6.c, waiting for a promise, either with an explicit `await` or by using its `.result` method, currently uses up a thread just for the blocking wait.

After this proposed change has been implemented, waiting doesn't tie up a whole thread for each wait.

Rationale

I've never seen anybody write code as if they expected an array or hash variable to contain a type object, yet the type checker silently allows this, which usually leads to much worse error messages when using the type object as if it were an instance.

Since normal variables are typically used with assignment, not binding, constraining the types of parameters is of higher importance.

It is quite easy to write code that waits for multiple promises in parallel, which can lead to the full thread pool begin tied up in blocking waits, leading to a deadlock.

Examples of this happening have showed up in the past.

Stakeholder

Moritz Lenz

Jonathan Worthington

Samantha McVey (samcv)

Oh, I thought you said steak... (Zoffix)

Zoffix

Zoffix

Zoffix

Formal Rules for Defining Matched Delimiters/Brackets

In v6.d we should formalize which brackets we support. How do we decide which delimiters should be added on future updates to the Unicode standard? We should look to the Unicode standard to help us define matching delimiters and brackets for Perl 6.

All delimiters we support should conform to two simple rules for the sake of uniformity, elegance and clairity.

Rules

1. Delimiter's Unicode General_Category must match one of these:

  Pi -> Pf ( Punctuation, initial quote -> Punctuation, final quote)
  Ps -> Pe (Punctuation, start -> Punctuation, end)

2. The delimiters must be matching BidiBrackets and/or BidiMirroring characters.

Bidirectional brackets are specified here

Non brackets have their matching glyph specified in this file

Possible issues

The only possible issue, is what to do with ornate parens.

BidiBrackets.txt states:

“For legacy reasons, the characters U+FD3E ORNATE LEFT PARENTHESIS and U+FD3F ORNATE RIGHT PARENTHESIS do not mirror in bidirectional display and therefore do not form a bracket pair.

In v6.c, roast includes tests for 'ornate left parens' and 'ornate right parens' for doing things like q[ ] type contructs and such. I think that we should not allow these parenthesis because firstly, Unicode states they do not form a matching pair of brackets. Secondly, the ornate parenthesis also do not have mirror glyphs. To make matters even worse, their Unicode general categories are the opposite of every matched bracket we support, the opening brackets tested for in v6.c open with "Pe"(End) and close with is "Ps"(Start). They break both of these proposed rules.

In practice this is already implement with the exception of the ornate parenthesis, but I propose this be made an official part of the Perl 6 standard.

Stakeholder

Moritz Lenz

Jonathan Worthington

Samantha McVey (samcv)

Oh, I thought you said steak... (Zoffix)

Zoffix

Zoffix

Zoffix

Remove deprecated Test::is_approx

This is mostly a reminder so we don't forget. Test::is_approx is currently marked as deprecated (replaced by `is-approx`). It was decided to leave it in until 6.d, so that we can still use it in 6.c-errata without any changes.

Stakeholder

Moritz Lenz

Jonathan Worthington

Samantha McVey (samcv)

Oh, I thought you said steak... (Zoffix)

Zoffix

Zoffix

Zoffix

Properly reserve all :sym<> colonpairs on subroutines

This is mostly a reminder so we don't forget. As previously discussed, We want to make :sym<> colonpairs on subroutines reserved. However, there is a 6.c-errata test that expects sub foo:sym<bar> {} to throw X::Syntax::Extension::Category exception instead of X::Syntax::Reserved we desire. The code implementing this already exists. It just needs to be uncommented for 6.d and corresponding tests unfudged.

Stakeholder

Moritz Lenz

Jonathan Worthington

Samantha McVey (samcv)

Oh, I thought you said steak... (Zoffix)

Zoffix

Zoffix

Zoffix

Use IEEE 754-2008 semantics for num/Num infix:</>, infix:<%>, and infix:<%%>

(Sidenote: be sure to check log(42, 1) does not explode when this is implemented. If it's decided not to implement this; change log(42, 1) to give a better error)

Currently, division and related modulus operations with Nums return Failure if the divisor is zero. By IEEE rules, those would instead produce a NaN for 0e0/0e0 and Inf with the sign of the divident. Note: Division and related modulus operations where at least one operanad is a Num or num coerce both operands to Num

The proposed behaviour has TimToady's nod of approval but is blocked by three 6.c-errata tests.

Untested, but the implementation likely just involves removing all of the checks for 0 divisors, as NQP ops already Do The Right Thing for nqp::div_n(). For nqp::mod_n() more examination is needed, the primary problem being that we don't do IEEE's remainder() operation with it, so what it's supposed to do in these edge cases is not declared by IEEE.

    multi sub infix:</>(Num:D \a, Num:D \b) {
        nqp::p6box_n(nqp::div_n(nqp::unbox_n(a), nqp::unbox_n(b)))
    }
    multi sub infix:</>(num $a, num $b) returns num {
        nqp::div_n($a, $b)
    }
    multi sub infix:<%>(Num:D \a, Num:D \b) {
        nqp::p6box_n(nqp::mod_n(nqp::unbox_n(a), nqp::unbox_n(b)))
    }
    multi sub infix:<%>(num $a, num $b) returns num {
        nqp::mod_n($a, $b)
    }

Stakeholder

Moritz Lenz

Jonathan Worthington

Samantha McVey (samcv)

Oh, I thought you said steak... (Zoffix)

Zoffix

Zoffix

Zoffix

Remove dummy precision parameters from Rational/Int .Rat and .FatRat coercers

They're dummy parameters that offser more confusion than usefulness. The roast itself seems confused. There are a whole bunch of trig tests that use these coercers with a precision arg for no good reason; almost feels like the writer assumed `1.5` is a Num and not a Rat.

Stakeholder

Moritz Lenz

Jonathan Worthington

Samantha McVey (samcv)

Oh, I thought you said steak... (Zoffix)

Zoffix

Zoffix

Zoffix

[ Top ]   [ Index of Synopses ]