Re: Syntax checks in perl

[Martin von Gagern]

Hi Stefano.

On 15.09.2011 21:08, Stefano Lattarini wrote:
> Perl versions from 5.8 onwards should have a threading interface too,
> if I'm not mistaken.  I don't know how powerful or easy-to-use it is,
> though.

Afaik ithreads support is an optional feature, not sure how distros out
there handle it. I've got it installed here on my Gentoo, but had to
explicitely enable it.

"perldoc threads" has docs on this, looks reasonably simple.

>> - clean exception handling, allowing checks to fail in deeply nested
>>   code and still recover to proceed with the next check
>>
> That is possible in perl too (even if it requires various hoops, while
> being very natural in python).

OK, emphasis on CLEAN. Perl hoops look less than clean, and I guess we
don't want to depend on third party modules like Exception::Class,
TryCatch or Try::Tiny. Plain die/eval should be sufficient here, though.

> Good!  But consider that it might take some time before I post something
> usable though (a month or two isn't an unreasonable guess).

No worry, as long as I know things are progressing, I'm very patient on
this.

>> To add some flexibility for future extensions, I believe that it would
>> be good to use some OOP approach, i.e. have test classes.
>>
> Good idea (but let's call those "check classes", please :-)

For give a native German speaker, I tend to mix those two up unless I
make a conscious effort.

> Two caveats though, if we go down this road:
>   - We should be careful not to over-engineer, especially in the earlier
>     phases.

Not over-engineer, but still keep future requirements in mind and make
sure we're not too narrow-minded in our engineering either.

>   - We should have a testsuite for the new code; since this new code would
>     mostly be intended for in-house use at first, we don't need a really
>     "industrial-strenght" coverage, but some automated testing will be
>     definitely required.

Sounds reasonable, as long as the suite has no impact on projects
importing gnulib.

>> Perhaps the regular expressions could operate on the whole file by
>> default,
>>
> Or we should provide a config varible to decide the "default matching
> unit" -- file or line.

Optional config var, sure, why not. But there should be a sane default,
so that at most half the (currently envisioned) tests need an explicit
configuration.

> At least, for check intended for C files.  Things might be different for
> checks aimed at makefile fragments or shell scripts.

Not that different, I guess. Compiling a regexp with the 'm' flag and
without the 's' flag should ensure that ., ^ and $ behave just as they
would for single-line matches. So as long as checks use [^ \t] or
similar instead of \s, they should probably be on the safe side even if
executed on the file as a whole.

> The code could operate adaptively: if the "list of files" is an actual
> list reference, just use it; if it's a scalar, pass it to the 'glob()'
> builtin to obtain a list of files; if it is a code reference, call it
> (with args, and if yes, which ones? that's to be decided) to fetch the
> list of files; and so on (we could devise semantics also for hash
> references, regular expression objects, or custom objects, maybe).

Sounds reasonable. Again, we should have a sane default, which should
represent the list of all versioned files. And we should have separate
filtering rules, to select parts of that list. This gives us three layers:
1. Source list: glob, vc-list, explicitely named, or similar.
2. Check-driven filters, e.g. by file extension or by directory
3. Project-configured filters, blackliting some of the remaining files

> The tricky part will be to decide how to operate properly under VPATH
> builds ...

As syntax checks do check for source-level issues, I guess we could live
with requiring an in-tree build, at least for now.

Greetings,
 Martin

signature.asc
Description: OpenPGP digital signature