On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wrote:
> having used NQP a bit, I feel like I'm missing a few things. I'm not
> entirely sure what the fate of NQP is; will it always be a bootstrap
> stage for Perl 6,or is it a tool for now and will it be discarded
> later on.
Neither! It's important to be wary of viewing NQP solely in the
context of Rakudo and Perl 6 -- NQP is designed to be a tool that
many Parrot HLLs can use to build tools, not just Rakudo and/or Perl 6.
So, it's entirely possible that Rakudo will stop using NQP as part
of its build process at some point, but NQP will still be around
for other translators to use (as many of them are). As noted
in README.pod:
The key feature of NQP is that it's designed to be a very
small compiler (as compared with, say, perl6) and is focused
on being a high-level way to create transformers for Parrot
(especially hll compilers). In addition, unlike perl6, NQP
attempts to restrict itself to generating code that can run
in Parrot without the existence of any NQP-specific runtime
libraries.
> [...] I understand that NQP is designed to be small, but these
> features won't clutter the implementation that much, and are pretty
> easy to implement, I think.
>
> * other relational operators, such as <, <=, > and >=. I keep writing
> these, but NPQ only has == and !=.
> * postincrement/decrement ops, or at least +=. Often you need syntax
> like $index := $index + 1; Writing += 1 is so much nicer.
One of the overarching principles behind NQP is to add features
and operators only as they are actually needed, as opposed to
"would be nice to have". And since I haven't really needed
the relational ops, I haven't put them into NQP. But if you
really need them we can certainly add them.
> * the ternary operator ?: This allows for shorter/easier notation when
> both the Then and Else part of an ifstatement are 1 line.
Adding the ternary operator is no problem, except remember that it's
??!! and not ?: . The tricky part for the ternary op is getting it
into the grammar. We can either use PGE's built-in "ternary:"
category, or we can try to follow STD.pm's approach.
> * list ops ( I think this is meant by list ops? )
> All languages that have some kind of scope mechanism now have to
> define a class "List", which has an unshift and shift method, which
> are just wrappers for the equally named parrot ops.
I don't quite understand what is meant by "have to define a class
'List'". Can you give an example?
> Being able to write
> unshift @?BLOCK, $?BLOCK;
> would be useful, as it prevents the need for creating the List class
> over and over again.
> I feel that these ops are so basic, it would be well worth it to have
> them around.
Thus far NQP has avoided most forms of listop parsing (i.e., functions
w/o parens), so the above really ought to be written as
unshift(@?BLOCK, $?BLOCK);
Now that listop parsing is available in Rakudo, we could see about
backporting it into NQP and using that. But even if we allow
the listop form, having something like "unshift" work means that we
need a mechanism to map specific function names into equivalent
inline PIR instructions. On the whole this would probably be
a very good thing to have... still, going back to the earlier
principle -- I haven't run across a case where it's really needed,
so it hasn't been added yet.
Perhaps I'll understand better when I understand the "all languages ...
have to define a class 'List'" comment above.
> * MAIN support: this feature is a nice-to-have, but not that important.
> I don't think it's there already: when writing an NQP script, I'd like
> to have access to the command line options. To be precise, I'd like to
> write the compiler driver in NQP instead of in PIR.
This is explicitly a goal for NQP, and you're correct that we
haven't gotten there yet. The likely answer is that any subroutine
named 'MAIN' will automatically get Parrot's ':main' flag added
to the sub. The command line arguments are then just
a parameter to that subroutine:
sub MAIN ( @args ) {
...
}
Hope this helps,
Pm
