Announce: Rakudo compiler, Release 2020.06

[Alexander Kiryuhin]

On behalf of the Rakudo development team, I’m very happy to announce the
June 2020 release of Rakudo #136. Rakudo is an implementation of
the Raku[^1] language.

The source tarball for this release is available from
https://rakudo.org/files/rakudo.
Pre-compiled archives will be available shortly.

New in 2020.06:

   - SPECIAL NOTES:
  - Results of dir routine called with dirty base path are presented
  as cleaned up for some paths (like /// or a/../a) unlike
  before. While compatibility with most other cases is preserved
  and no ecosystem fallout was observed, be cautious of the possible
  observable changes if the code does not clean dirty paths using
  cleanup method.
  - Since this release, when you start Raku with "-" as a single
  positional parameter, it
  will now check if STDIN is connected to a terminal. If it is, then
  the REPL will be started, rather than appearing to freeze waiting
  for the user to enter something and issue an EOF. If STDIN is *not*
  connected to a terminal, then Raku will read from STDIN and process
  that as the source of a program.
  - The run routine, Proc.spawn and Proc::Async.new are
  extended with a new argument :$win-verbatim-args defaulting to
  False. If the argument is left off or set to False, the
  arguments are quoted according to the Microsoft convention. This
  is identical to Rakus previous behavior and thus backwards
  compatible. When passing True the passed arguments are
  concatenated with a single space. No other processing takes
  place. This allows to manually quote the arguments as necessary.
   - Changes:
  - Support verbatim argument handling for Proc [709941c
  

  ][9a75738
  

  ]
  - Signatures of slurp and spurt routines not accepting redundant
  arguments is
  now compile time error rather than run-time one [22f4344
  

  ]
  - The Distro.desc method now states codename for MacOS [b4b2a5e
  

  ]
  - The gist method output for multi-dimensional arrays is truncated
  now [cfc3e57
  

  ][4bfe5bd
  

  ]
  - Parametrization a variable type in form my $foo is Type[Foo, Bar]
  works for all types now [de43f19
  

  ]
  - The rotate method now returns Seq instead of List [4b501bd
  

  ]
  - Add CACHEDIR.TAG to mark cache dirs as cache [37646b8
  

  ][c3bdb61
  

  ][ef90599
  

  ]
  - Improve GNU C++ name mangling [4f672c2
  

  ]
  - Make Instant.raku output simpler [c0b5fb2
  

  ]
  - Improve smartmatching against Mu/Any/Junction types
  (Mu.new ~~ Mu does not die anymore, any(Mu, Any) ~~ Mu returns True
  now) [3b4794f
  

  ][840d3e8
  

  ]
   - Fixes:
  - Fix code objects created BEGIN time EVAL getting lost in
  precompilation [537f887
  

  ][169f63d
  

  ]
  - The is routine from Test module now handles types that cannot be
  stringified and
  compares them using raku method now [c9e9462
  

  ]
  - Fix various JVM and JS backend issues [8e5b610
  

  ][2b81f97
  

  ]
  [12f8f1e
  

  ][5b86436
  
<

junctions and parenthesis

[Joseph Brenner]

I was just playing around with junctions a bit today, and I
noticed that if you weren't religious about using parenthesis
with them you could get quietly tripped up:

say so any() eq any();   # True   (as expected)
say so any() eq any(); # False  (as expected)
say so any  eq any ; # False(something's wrong)

Basically, you need the parens on that first use of any.

Is there a reason you don't at least get a warning if you don't?

Re: junctions and parenthesis

[Patrick R. Michaud]

The "any" function is just like any other function taking an arbitrary list of 
arguments (including user-defined functions).  As such it parses with lower 
precedence than comparison operators -- so "eq" binds more tightly than "any".

Thus

   say so any  eq any ;

parses like

   say(so(any( eq any(;

which is indeed False.

I'm not exactly sure what sort of warning should go here, or how it'd be 
detected.  But perhaps others have ideas.  

Pm


On Sun, Jun 21, 2020 at 07:00:23PM -0700, Joseph Brenner wrote:
> I was just playing around with junctions a bit today, and I
> noticed that if you weren't religious about using parenthesis
> with them you could get quietly tripped up:
> 
> say so any() eq any();   # True   (as expected)
> say so any() eq any(); # False  (as expected)
> say so any  eq any ; # False(something's wrong)
> 
> Basically, you need the parens on that first use of any.
> 
> Is there a reason you don't at least get a warning if you don't?