Re: Wikipedia example
On Tuesday 03 October 2006 13:41, Aaron Sherman wrote: > This contains the Makefile, README, .pg grammar, a -harness.pir that > executes the parser on a sample string and dumps the parse tree and a > -stress.pir that runs 50,000 trial runs to see how fast PGE is (not too > shabby is the answer, as it comes in at about 1/2 the time of a P::RD > version for the simple example, and gets a bigger lead the more complex > the input expression). I can't get this to work. If I run 'make' in the target directory, I get a PASM file (with the .pir) extension. Then if I run either of the PIR files, I get: $ parrot wptest-harness.pir error:imcc:syntax error, unexpected LABEL, expecting $end in file 'wptest.pir' line 3 Parsing simple expression: 1+(1+1) Null PMC access in get_bool() current instr.: 'main' pc 24 (wptest-harness.pir:21) -- c
RFC: Reduce closure magic
To my surprise, I found a 'ctx' member in struct Parrot_sub. It
appears that this is only used for the "autoclose" feature, which AFAICS
is not documented. The only place it is mentioned is in four
t/op/lexicals.t cases (though it is also used in three t/pmc/exception.t
cases; see the patch). The 'package-scoped closure 6 - autoclose' test
(the next-to-last one in t/op/lexicals.t) implements this Perl 6
snippet:
sub f ($x) {
sub g () { print "$x\n" };
}
f(10);
g();
in the following curious way:
.sub '&f'
.param pmc x
.lex '$x', x
.end
.sub '&g' :outer('&f')
.local pmc x
x = find_lex '$x'
print x
print "\n"
.end
.sub '&main' :main :anon
'&f'(10)
'&g'()
.end
Note that &f doesn't explicitly create a closure. Through the magic of
"autoclose," &g becomes a valid closure merely by invoking &f, and &main
prints "10" as a result.
The very fact of having a 'ctx' member in struct Parrot_sub bothers
me, but I haven't figured out how to make it fail yet, so my case
against it is purely esthetic. It seems cleaner to create the closure
and define the sub explicitly:
.sub '&f'
.param pmc x
.lex '$x', x
.local pmc sub_g, closure_g
.const .Sub sub_g = "raw_&g"
closure_g = newclosure sub_g
store_global '&g', closure_g
.end
.sub 'raw_&g' :outer('&f')
.local pmc x
x = find_lex '$x'
print x
print "\n"
.end
This also seems more natural for compilers to generate, especially when
presented with a variation like this [1]:
sub f ($x) {
if $x > $too_big {
sub g () { print "$x is too big\n" };
}
else {
sub g () { print "$x\n" };
}
}
The explicit solution also leaves &g undefined if no "sub g () { ... }"
statement is ever executed.
So it looks like "autoclose" is a convenience for writing PIR by
hand, whereas I personally think it is cleaner to create closures
explicitly. The attached patch changes all the affected test cases to
do so, and disables the feature. Is there anyone who would like to
argue that I shouldn't apply it? And if so, would you be willing to
document it?
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] But I wouldn't swear that this is valid Perl 6 -- syntactically or
semantically.
Index: src/pmc/closure.pmc
===
--- src/pmc/closure.pmc (revision 14848)
+++ src/pmc/closure.pmc (working copy)
@@ -92,46 +92,13 @@
outer_sub = sub->outer_sub;
if (sub->outer_ctx) {
/* during newclosure, outer's ctx was stored in
- * sub->outer_ctx
+ * sub->outer_ctx. we need to copy it into our ctx.
*/
-sub->ctx->outer_ctx = sub->outer_ctx;
+CONTEXT(INTERP->ctx)->outer_ctx = sub->outer_ctx;
}
-else if ((PObj_get_FLAGS(outer_sub) & SUB_FLAG_IS_OUTER) &&
-PMC_sub(outer_sub)->ctx) {
-/* the sub was invoked earlier - it still has the context
- * due to the SUB_FLAG_IS_OUTER flag
- */
-sub->outer_ctx = sub->ctx->outer_ctx = PMC_sub(outer_sub)->ctx;
-}
else {
-/* closure is just invoked - located :outer's ctx */
-parrot_context_t *caller = sub->ctx->caller_ctx;
-while (caller) {
-if (caller->current_sub == outer_sub) {
-cont = caller->current_cont;
-cont->vtable =
-interpreter->vtables[enum_class_Continuation];
-sub->outer_ctx = sub->ctx->outer_ctx = caller;
-caller->ref_count++;
-return next;
-}
-caller = caller->caller_ctx;
-}
-if (!caller) {
-/* outer has never been invoked, we fake a subroutine call
- * which builds the LexPad and return immediately
- * this will usually just lead to a Null PMC access
- * exception
- */
-INTERP->current_cont = NEED_CONTINUATION;
-(void)VTABLE_invoke(INTERP, sub->outer_sub, next);
-caller = CONTEXT(INTERP->ctx);
-cont = caller->current_cont;
-cont->vtable = interpreter->vtables[enum_class_Continuation];
-sub->outer_ctx = sub->ctx->outer_ctx = caller;
-caller->ref_count++;
-(void)VTABLE_invoke(INTERP, cont, next);
-}
+real_exception(interpreter, NULL, 1,
+
Re: Exceptions and Internationalization
Yes please! On Oct 6, 2006, at 4:27 PM, chromatic wrote: A thread on p5p recently brought up the idea of multi-language exceptions. That is, instead of throwing exceptions with English C-strings embedded in the source code, use a localization system. If there'll soon be a push to clean up all of the uses of exceptions in the source code (to make them catchable where possible), is it also a good time to make them multi-lingual? -- c -- Will "Coke" Coleda [EMAIL PROTECTED]
Exceptions and Internationalization
A thread on p5p recently brought up the idea of multi-language exceptions. That is, instead of throwing exceptions with English C-strings embedded in the source code, use a localization system. If there'll soon be a push to clean up all of the uses of exceptions in the source code (to make them catchable where possible), is it also a good time to make them multi-lingual? -- c
Re: class interface of roles
TSa wrote:
I'm not familiar with the next METHOD syntax.
It's simple: if a multi method says "next METHOD;" then execution of
the current method gets aborted, and the next MMD candidate is tried;
it uses the same parameters that the current method used, and it
returns its value to the current method's caller. In effect, "next
METHOD" is an aspect of MMD that allows an individual method to say
"I'm not the right guy for this job", and to punt to whoever's next in
line. If not for the possibility of side effects that occur before
the punt, one could pretend that the current method was never tried in
the first place.
I see that quite different: roles are the primary carrier of type
information! Dispatch depends on a partial ordering of roles. I
think all roles will form a type lattice that is available at
runtime for type checks.
True: the relationships between various roles and classes ("who does
what?") is needed for runtime type checking. However, the _contents_
of the roles are only important for composing classes and for the
occasional runtime introspection of a role. If roles are never
composed or inspected at runtime, the only details about them that
need to be kept are "who does what?" - and if all type-checking takes
place at compile-time, not even this is needed.
But now we're getting dangerously close to perl6internals territory...
--
Jonathan "Dataweaver" Lang
[OT] Unicode fonts (was: Re: Hash composers and code blocks)
Mark J. Reed: > Aaron Sherman: >> Proposal: A sigil followed by [...] is always a composer for that type. >> >> %[...] - Hash. Unicode: ?...? >> @[...] - Array. Unicode: [...] >> ? - Seq. Unicode: ?...? >> &[...] - Code. Unicode: ?...? >> |[...] - Capture. Identical to \(...). Unicode: ?...? >> $[...] - Scalar. Identical to item(value). Unicode: ?...? >> #[...] - A comment. Just seeing if you're paying attention ;) > > Are those supposed to be question marks up there (meaning "up for > discussion"), or did something go awry in the email encoding (possibly > on my end)? It took me a while to find a font that displays them: Code2000. http://en.wikipedia.org/wiki/Code2000 (shareware) See also: http://en.wikipedia.org/wiki/Free_software_Unicode_fonts http://en.wikipedia.org/wiki/Unicode_typefaces http://www.alanwood.net/unicode/fonts_windows.html -- Affijn, Ruud "Gewoon is een tijger."
Re: class interface of roles
HaloO,
Stevan Little wrote:
On 10/2/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
This notion of exclusionary roles is an interesting one, though. I'd
like to hear about what kinds of situations would find this notion
useful; but for the moment, I'll take your word that such situations
exist and go from there.
Well to be honest, I haven't found a real-world usage for it yet (at
least in my travels so far), but the Fortress example was this:
trait OrganicMolecule extends Molecule
excludes { InorganicMolecule }
end
trait InorganicMolecule extends Molecule end
Wouldn't that be written in Perl6 the other way around?
role OrganicMolecule {...}
role InorganicMolecule {...}
role Molecule does OrganicMolecule ^ InorganicMolecule {...}
Which is a nice usage of the xor role combinator.
And from that I could see that given a large enough set of roles you
would surely create roles which conflicted with one another on a
conceptual level rather then on a methods/attribute (i.e. - more
concrete) level.
I don't abide to that. If roles are conceptually modelling the same
entity their vocabulary should conflict also. Well unless some
differing coding conventions accidentally produce non-conflicting
roles. The whole point of type systems relies on the fact that
concrete conflicts indicate conceptual ones!
Regards,
--
Re: class interface of roles
HaloO, Stevan Little wrote: As for how the example in the OP might work, I would suspect that "super" would not be what we are looking for here, but instead a variant of "next METHOD". I'm not familiar with the next METHOD syntax. How does one get the return value from it and how are parameters passed? Would the respective line in the equal method then read: return next METHOD($p) and self.x == $p.x and self.y == $p.y; I think that a super keyword might be nice syntactic sugar for this. > However, even with that an ordering of some > kind is implied The only ordering I see is that the class is "up" from the role's perspective. When more then one role is combined and all require the presence of an equal method I think the roles can be combined in any order and the super refers to the class combined so far. IOW, at any given time in the composition process there is a current version of the class' method. The final outcome is a method WALK or however this is called in composition order. Conceptually this is method combination: seen from outside the class has just one type correct method equal. Theoretical background can be found in http://www.jot.fm/issues/issue_2004_01/column4 I suppose this is again where the different concepts of classes are roles can get very sticky. I have always look at roles, once composed into the class, as no longer needing to exist. In fact, if it weren't for the idea of runtime role compostion and runtime role introspection, I would say that roles themselves could be garbage collected at the end of the compile time cycle. I see that quite different: roles are the primary carrier of type information! Dispatch depends on a partial ordering of roles. I think all roles will form a type lattice that is available at runtime for type checks. With parametric roles there will be dynamic instanciations as needed. Regards, --
Re: Bytecode PDD
Leopold Toetsch wrote: Indeed. But we probably want to have an UUID to identify loaded .pasm/.pir/.pbc to avoid loading duplicates. The UUID as proposed was intended for that; I just hashed up the definition in the PDD. Er, no pun intended. As a side note: distinct PBC segments for checksum and/or UUID is probably simpler to handle. How so? At least if it's in the header you can just read it in and know if you've already loaded the file without having to unpack a directory segment and so on. Thanks, Jonathan
Re: Bytecode PDD
Bernhard Schmalhofer wrote: One thing that I noticed is the naming of the new field UUID. ||| The UUID is | ||| computed by applying the hash function specified in| ||| the UUID type field over the entire packfile not | ||| including this header and the trailing zero padding Shouldn't this field be renamed to something like 'checksum' ? The term 'UUID' already has a specific meaning, http://en.wikipedia.org/wiki/UUID. Yup, and I meant for that field to be a UUID. In the article you linked to it does mention the use of hash functions to create a UUID, but yes, it ain't the only way. So a clarification that using a hash function isn't the only way to create a UUID would be good; I'll get it in there. (When I manage to nab some time to do stuff...working quite a few hours at $day_job, on-site and abroad at the moment...) Thanks, Jonathan
