Skip to content

Instantly share code, notes, and snippets.

@pmichaud
Last active August 29, 2015 14:07
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pmichaud/460bc17afcc5ca93b6b1 to your computer and use it in GitHub Desktop.
Save pmichaud/460bc17afcc5ca93b6b1 to your computer and use it in GitHub Desktop.
APW2014 GLR discussion highlight summary
Since I know many people are eager for it, here's a very brief summary of GLR-related
decisions and accomplishments from #apw2014. In the next 2..3 days I plan to create
blog posts with much greater discussion of each. If any seem particularly confusing
or troubling to you, perhaps wait for the blog post(s) before panicking. :-)
* flattening rules have been revised somewhat
+ list assignment and array constructor continue to flatten their arguments (no change)
+ for (args) { ... } flattens args (no change)
+ .[] never flattens its invocant (consistency, capability, and performance wins)
+ function calls tend to flatten their arguments (e.g. "sort", "map", "pick")
+ method calls tend to not flatten their invocants (e.g., ".sort", ".map", ".pick")
+ .map will no longer flatten its invocant
+ .for will be introduced as an equivalent of .flat.map (corresponds to 'for'
statement semantic)
+ operator argument flattening depends on operator (typically grouped by
operator precedence)
+ operator return values tend to not be automatically flattened
* Parcel will likely disappear as a type
+ infix:<,> will create (immutable) List objects
+ many benefits:
+ eliminate ongoing confusion between Parcel and List (programmer win)
+ eliminating need to convert between Parcels and Lists (likely big
performance win)
+ .perl output won't need "(1,2,3).list"`
* MapIter will become LoopIter
+ for/while/until/repeat/loop will be able to produce lazy lists
+ many existing instances of gather+take will be able to be rewritten as
inexpensive lazy loops (big performance win)
+ more list comprehensions will work (language spec compliance win)
+ LoopIter will be able to operate directly from Iterator chains without an
intermediate List (big performance win)
+ significant step towards enabling GC collect of "already processed
values" (memory win, but some further work needed)
* sink context made significantly smarter, much less codegen and method calls
required (performance win)
* roadmap for hyper/race processing of Lists
* better-defined semantics of .list, .flat, .items, .values
* clear/clean API definition for List, Iterable, Iterator, LoL, etc.
(foundation for S07 rewrite)
* Nil will be updated to match current language spec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment