>From the point of view of someone working through the PCT tutorial
(quite rockin', BTW!):
On Wed, 2008-03-26 at 14:25 +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.
If NQP isn't available in the long term, then something at least as cool
should be. If that's real Perl 6, so much the better. But I certainly
wouldn't be doing the PCT tutorial -- and thus in the future working on
adding or improving languages in the Parrot compiler collection -- if I
didn't feel like the language I was working in was:
A) Fun to work with,
B) Giving me skills useful for other tasks, and
C) Not tendonitis inducing.
(Note that PIR qualifies under A and B, but not C -- which is why I am
limiting my PIR work to places where it's actually necessary or clearly
superior.)
> Anyway, if NQP is to stay, the following features would come in handy,
> IMHO. 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.
Agreed.
> * other relational operators, such as <, <=, > and >=. I keep writing
> these, but NPQ only has == and !=.
Definitely agree WRT numeric ops. What about string ops?
> * postincrement/decrement ops, or at least +=. Often you need syntax
> like $index := $index + 1; Writing += 1 is so much nicer.
God yes, please. I certainly like having -- and ++, but I'm willing to
do without. Not having op= is harsh.
> * the ternary operator ?: This allows for shorter/easier notation when
> both the Then and Else part of an ifstatement are 1 line. Typical for
> this in the PCT is writing:
> [six lines]
> which could be nicely written as
>
> $scope := $?BLOCK.symbol($name) ? 'lexical' : 'package';
This one seems easy and very valuable. I hate wasting vertical real
estate in my editor. I'm willing to pay a certain amount of coding tax
for NQP < P6, but six lines instead of one is a bit excessive. Just
allowing an if statement to be used as an expression in some (presumably
Perl 6 compatible) way would be OK, if ugly.
> * 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. 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.
I disagree with the syntax, but agree with the sentiment. I'm fine with
requiring everything in NQP to use method or sub call syntax (as opposed
to adding listop syntax) -- but having to write the PIR wrappers for
array shift and unshift seemed really silly and wartish. The most basic
array methods (shift, unshift, push, pop, elems) should all just be
there, because there's no reason for every language implementor to
rewrite them.
> * 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. So, creating a new
> HLLCompiler, setting the grammar stuff and invoking the command_line
> method on it with the commandline args. How do I get access to these
> args from NQP?
MAIN support would definitely be very cool -- but that seems like a big
thing for a small language, so I'd settle for @ARGS.
-'f
