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

Meta-ticket for S07 and update of List implementation details #70

Open
pmichaud opened this issue Oct 3, 2014 · 8 comments
Open

Meta-ticket for S07 and update of List implementation details #70

pmichaud opened this issue Oct 3, 2014 · 8 comments

Comments

@pmichaud
Copy link
Contributor

pmichaud commented Oct 3, 2014

tl;dr: This is a meta-ticket collecting references to outstanding issues related to Perl 6's aggregate list types.

Full version: Next week at the 2014 Austrian Perl Workshop I'm planning to focus heavily on updating Synopsis 7 and resolving a large number of issues surrounding Lists in Perl 6.

Having done at least three or four separate List implementations in Rakudo, I can tell you that it has never been easy to isolate -- small changes to the design of List (and its related classes) often have huge impacts to large segments of the codebase. Lists seem to be incredibly fundamental to Perl 6 design, and it's vital to get the underlying structures "just right" . (By way of analogy: Perl 6 OO design required getting the underlying metamodel details "just right", as it affects the entire implementation.)

To prepare for the update, I'd like to collect as many unresolved issues and details regarding S07 and lists into this single "metaticket". These can be references to existing bug reports, IRC discussions, and the like. Code examples illustrating undesirable behaviors can also be added here.

Note: If a code example illustrates a bug or issue, find/file a separate ticket for it and then reference it here, please. Also, this ticket is simply for collecting references to issues -- discussion of issues should take place elsewhere (either in separate tickets or on #perl6, which can then be linked to here).

Topics that I know are intimately involved in Perl 6 list design include (watch this section for updates):

  • list-y types: List, Array, Parcel, LoL, Iterable, Iterator, Range, Nil
  • eager vs lazy
  • finite vs infinite
  • flattening vs non-flattening
  • hyper, race
  • core functions/methods: map sort elems eager zip tree
  • core operators: .[] ... Z* , «» []
  • statements: for gather take

So, any unresolved items relating to any of the above are fair game here.

Thanks.

@pmichaud
Copy link
Contributor Author

pmichaud commented Oct 3, 2014

Existing open synopsis tickets:
#18 - How to lazily combine elements of two lists?
#7 - List.munch specification
#6 - .perl for self-referent structures

@FROGGS
Copy link
Contributor

FROGGS commented Oct 4, 2014

@peschwa
Copy link

peschwa commented Oct 5, 2014

Hacking on m:g// (PR here) brought this discussion with it. The gist of it is that some objects want to have e.g. for iterate over .list, while others might not. The example in this case is $/ as a Match object from a multi-match, e.g. with :g, :ex, :ov, which S05 states behaves different from a Match returned from a match without those modifiers.
A notable motivation is to preserve the for m:g/$pat/ { ... } idiom.

@pmichaud
Copy link
Contributor Author

pmichaud commented Oct 8, 2014

https://rt.perl.org/Public/Bug/Display.html?id=77738 - "is rw" on slurpy parameters

@pmichaud
Copy link
Contributor Author

On #perl6 (http://irclog.perlgeek.de/perl6/2014-10-09#i_9479570), TimToady speculated on a variety of API policies:

08:07 TimToady my current list api poliices are: lazy, batch, silo, all, sink, hyper and race
08:08 the difference betwen batch and silo basically being sync vs async

@pmichaud
Copy link
Contributor Author

More RT tickets related to lists and unresolved issues surrounding the current implementation:

Particularly relevant:
77746 - »,« doesn't produce a structure of parcels
113026 - array iterator does not track a growing array
112716 - lines() isn't lazy in Rakudo (actually map)
113870 - infix:«Z^..» doesn't produce sub-parcels
111848 - storage strategy for arrays is weird in Rakudo
122715 - Returning lazy list from start { } block results in empty list
80574 - Sequence operator not flattening when generator returns parcels
120861 - list repeated once not truncating
111732 - infix:«xx» doesn't flatten per default in Rakudo
117109 - .pick doesn't flatten in Rakudo
116525 - .reverse doesn't flatten in Rakudo
122895 - list assignment to a constant doesn't flatten
117403 - .first on an infinite list generated with gather is slow
120973 - Cross product with a .map in RHS yields empty list
122306 - List non-comprehension on jvm, moar
118717 - Nil is not supposed to be an iterator anymore
121327 - Array shift in loop in loop in loop shifts from an outdated array
120992 - Nil disappears in junction lists

Other related issues:
113802 - something wrong with .tree of the result of infix:
114100 - Capture.perl flattens out elements it shouldn't
116002 - Capture.perl flattens array arguments
82812 - Rakudo doesn't do list assignment for ops with sufficiently loose precedence
121994 - Array receives an empty itemized list
122230 - Zip operator doesn't extend lists ending in a Whatever

@FROGGS
Copy link
Contributor

FROGGS commented Feb 24, 2015

Would be interesting to know how this microbenchmark will improve due to GLR:
https://p6weekly.wordpress.com/2015/02/17/2015-07-i-like-trains-fast-trains-that-is/comment-page-1/#comment-293

perl -wnl -E ‘say $1 if /\b(\w{5})\b/’ logs.txt (19Mb) / 1 sec
ruby -wnl -e ‘puts $1 if /\b(\w{5})\b/’ logs.txt (19Mb) / 1.8 secs
perl6 -n -e ‘say $0 if m/(<<\w**5>>)/’ logs.txt (19Mb) / 88 secs

@skids
Copy link
Contributor

skids commented Apr 30, 2015

FWIW, the return value of a while/until/loop statement is a longstanding NYI. And feeds have lost most of whatever laziness they may have had a while back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants