Re: [perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks
On Thu, Aug 18, 2016 at 6:21 PM, Patrick R. Michaud via RT <
perl6-bugs-follo...@perl.org> wrote:
> On Thu, Aug 18, 2016 at 10:38:57AM -0400, Brandon Allbery wrote:
> > On Thu, Aug 18, 2016 at 9:13 AM, Claudio
> > wrote:
> >
> > > Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter
> for
> > > now) to report syntax errors. Because "perl6 -c" executes code (BEGIN
> and
> > > CHECK blocks as documented), this is a security concern for external
> code.
> >
> > The problem is that you probably can't parse the code successfully if you
> > can't run BEGIN blocks. While this is currently less true of perl 6 code
> in
> > the wild, it's actually even worse in potential than perl 5's ability to
> > mutate its parser because a module can implement entire new languages.
>
> Also, many things in Perl 6 get executed at BEGIN time even if they're
> not explicitly in a BEGIN block. Constant and class declarations come
> to mind, but I'm sure there are more.
>
> For example:
>
> $ cat xyz.p6
> use v6;
>
> say "1: mainline";
> constant $a = say "2: constant";
> BEGIN { say "3: BEGIN"; }
>
> $ ./perl6 xyz.p6
> 2: constant
> 3: BEGIN
> 1: mainline
>
> Patrick,
Taking Brandon's answer in considiration, does this mean that no perl6 code
could be parsed as correct without (implicit) BEGIN blocks or that it will
only work in -let's say- 99% of the time (file without a begin block)?
C.
Re: [perl #128983] Feature request: output errors as JSON
Hi Zoffix, You indeed have a point. More abstraction is always the right answer :). Some generic framework exposing the necessary information is a very elegant solution. WIth two buts: 1. For something as basic and fundamental as simple syntax checking it's preferably -imho- not to ask the user to install a lot of external dependencies and track their releases (are they in sync with the latest Rakudo release?). If a default/model implementation is part of core (let's say JSON or whatever), you can have your cake and eat it too. 2. I suspect that the JSON-only addition was a quick-fix to give tools a simple and stable interface to errors today. A more elegant solution may take a lot of time? Regards, C. On Fri, Aug 19, 2016 at 2:37 PM, Zoffix Znet via RT < perl6-bugs-follo...@perl.org> wrote: > On Thu Aug 18 06:08:06 2016, nxadm wrote: > > As jnthn suggested on irc, maybe an additional JSON error output would > > be great solution for this. This would make error parsing for external > > tooling very easy and stable. > > I rather not add anything specific like that and dream bigger (or smaller, > depending on how you look at it). It should be possible to expose to > module-space the point where all of our Exception objects > currently get flattened into the text the user sees on the screen. > > So then I could write a module Exceptions::JSON that will convert received > Exception objects to JSON and have all of the exceptions dumped as JSON. Or > write Exceptions::Rollbar and have the exceptions be shipped off to > rollbar.com. Or write Exceptions::Rust and output Rust-like exceptions > with expressive pointers to code. Or write Exceptions::Russian and have all > of the errors be translated to Russian language. > > There are far many more desired options for exceptions output. We should > make it possible for module-space to implement all of those options rather > than add a specific one in core. >
Re: [perl #128984] Feature request (wontfix?): perl -c executes BEGIN and CHECK blocks
Thank you for the clarification. That means that at the moment, most files (i.e. the ones written in OO) will have a have errors without a BEGIN block (i.e. the use of self). As 'perl6 -c' being for now the *only* way to check the syntax of a code file, the security concerns should not be easily disregarded. In the best case, users will have to jump through loops to have the functionality enabled 'at their own risk', in the worst case people will blame Perl 6 for stupid/dangerous done to their environment while "reading a code file with their editor". I am just thinking out loud, but could a different restricted core binary with only a subset of the code provide the necessary parsing capabilities? An alternative could be external tools implementing the parsing/linting of code (maybe something using DrForr's future Perl6::Tidy?), but in that case we would risk to have something playing catch-up to new Perl 6 releases. C. On Fri, Aug 19, 2016 at 1:25 AM, Brandon Allbery via RT < perl6-bugs-follo...@perl.org> wrote: > On Thu, Aug 18, 2016 at 6:18 PM, Claudio wrote: > > > Taking Brandon's answer in considiration, does this mean that no perl6 > > code could be parsed as correct without (implicit) BEGIN blocks or that > it > > will only work in -let's say- 99% of the time (file without a begin > block)? > > > I did say "while this is less true for perl 6 code in the wild" --- in perl > 5, disabling BEGIN blocks means losing all "use" directives. But for perl > 6, you still have to worry about classes not being defined properly because > their definitions are run (!) at compile time. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > >
