On Wed, Mar 26, 2008 at 6:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> 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.
>
Ok, that's clear; I didn't mean to mention Rakudo specifically.
> > [...] 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.
>
Well, I don't really need them that much, but I think they're
interesting for 2 reasons: they're so 'basic', in the sense that many
a programmer will expect them to be present, and 2) they're
"self-documenting": writing "while $i != $max" doesn't tell me whether
$i is going up or down; of course I can check out the code in the
while block, but still... Also, it feels somewhat "safer": writing
while $i < $max will make sure $i is never greater than $max; $i !=
$max doesn't express this assertion.
>
> > * 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.
Ok, i just guessed the syntax as it's written ? : in the NQP pseudo
code (Actions.pir of NQP implementation). But that's a spelling issue.
More importantly: is it worth adding, and how to implement it. Both
adding it and leaving it out has its advantages, so I will leave it to
the Powers that Be ;-) I just proposed this, and based on the first
comment in this thread, at least one other person agreed.
>
>
> > * 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?
Yes, sorry, I didn't explain the context. In order to write
@?BLOCK.shift() (and unshift() ) (for implementation of the scope
stack in pretty much all languages), @?BLOCK must be an object that
has these methods. As ResizablePMCArray doesn't have such methods, the
"trick" here is to subclass ResizablePMCArray (calling it "List") and
wrapping the shift and unshift instructions in the equally-named
methods.
>
>
> > 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);
This would work for me too. My point is, all languages I have worked
on that have scope, I had to write (well, copy/paste, but still) this
List class I mentioned above so that the @?BLOCK object (which is a
List object) can shift and unshift PAST::Blocks. I'd rather leave out
this "wrapping class" for ResizablePMCArray. What exact syntax is not
that important, but using the method invocation syntax requires
@?BLOCK to have methods.
>
> 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.
So, as a recap of what I mean: the "shift" and "unshift" methods of
@?BLOCK are just wrappers for the shift and unshift instructions. I'd
like to remove the need of writing a class ("List") that provides
these wrappers, and use "built-in" unshift and shift functions.
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 ) {
> ...
> }
This would be very useful. Ideally, IMHO, we can write the "main" file
(where the HLLCompiler is created and the grammar stuff and
commandline prompt and such is specified) for all language compilers
in NQP as well, instead of PIR. (I'm not a PIR hater, but NQP is just
nicer)
>
> Hope this helps,
>
> Pm
hope my intention gets more clear.
kjs
>
