Re: Object design revisions
On Tuesday 14 November 2006 22:28, Allison Randal wrote: > I've added responses after each recommendation, if you have any > questions or comments pull them onto the mailing list. Properties: I don't remember what problem these try to solve. It's difficult to discuss one way or the other without an example. STATIC_SELF: It has an ugly name so as not to tempt people to use it. My understanding is that the best use of this is in accessor methods, where you know it's okay to violate encapsulation because the only way you could get to the method is if someone did not override it. Composition: Jonathan suggested meeting on IRC next week after #parrotsketch. It's fine with me. VTABLE split: It seems that this may depend on the ideas of the former. -- c
Object design revisions
I just finished reviewing docs/dev/pmc_object_design_meeting_notes.pod, which is a summary of a design discussion I asked particle to lead at the hackathon last weekend. It's a fantastic piece of work, and nicely organizes the ideas we've been kicking around the past few months. Thanks to particle and everyone else who contributed. I've added responses after each recommendation, if you have any questions or comments pull them onto the mailing list. Thanks all, Allison
Re: How do I associate methods with a compiler?
On Tue, Nov 14, 2006 at 08:52:47PM -0800, Allison Randal wrote: > > Also for the record from the weekly meeting (which was actually today, > just a very long today): Yes, compilers are objects and compilation is a > method call. The compiler for TGE tree grammars is implemented this way, > and it's a very usable interface. Our messages crossed in the mail. > We might want to resurrect the 'compile' opcode as an indirect syntax > for making the 'compile' method call. Maybe, but I can't see that this is worthy of a special opcode (and presumably a vtable slot?). There's just not a lot of difference between: $P0 = compile mycompiler, code# compile opcode $P0 = mycompiler.'compile'(code) # Parrot convention Another advantage of using (true) method calls is that it's easy to pass options and additional arguments to the compiler: $P0 = mycompiler.'compile'(code, 'target'=>'parse') Pm
Re: How do I associate methods with a compiler?
On 11/9/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Opinions welcome. Personally I think I favor the "a compiler is
> an object with a 'compile' method" model, and that C gives
> us back a compiler object as opposed to a subroutine-like thing.
For the record, it was decided (Allison++) during today's
#parrotsketch meeting that the convention would be to have
the 'compreg' opcode return an object with a 'compile' method,
as opposed to returning an invokable sub.
Of course, individual language implementors may choose to
defy convention, and for the forseeable future the "PIR"
and "PASM" compilers that come with Parrot will continue
to be subroutine-like. All of this just means that
callers to compreg need to know what they are getting back
or else figure it out at runtime.
I'm hoping to formalize some of the details for creating
compilers into a "compilers pdd" at some not-too-distant date.
Comments and suggestions welcomed. At the moment we have
the following:
- There's a HLLCompiler class (loadlib 'Parrot/HLLCompiler.pbc')
that can be used to quickly create compiler objects.
- To register a new compiler using HLLCompiler:
load_bytecode 'Parrot/HLLCompiler.pbc'
.local pmc compile_sub, mycompiler
## get the compilation subroutine
compile_sub = get_global 'compile'
## create a new compiler object
mycompiler = new [ 'HLLCompiler' ]
## register the language and compiler subroutine
mycompiler.'register'('MyCompiler', compile_sub)
- To perform a compile:
mycompiler = compreg 'MyCompiler'
$P0 = mycompiler.'compile'('...source code...')
In addition, HLLCompiler provides a 'command_line' method
for acting as a standalone compiler; thus a .pir/.pbc can
simply have its :main sub delegate control directly
to HLLCompiler. For example:
.sub main :main
.param pmc args
.local pmc mycompiler
mycompiler = compreg 'MyCompiler'
mycompiler.'command_line'(args)
.end
When invoked in this manner, compiler object will compile
and execute any source file given on the command line, or
enter an interactive mode if no source file is given.
The result of the compilation can be controlled by the
--target command line (assuming the compilers involved
support this):
--target=parse # output parse tree
--target=past# output ast (PAST)
--target=post# output opcode tree (POST)
--target=pir # output PIR
HLLCompiler also understands '--encoding' (for languages that
have specific character encoding requirements), and '--output'
to specify a file where the output should be placed.
Comments and other feedback are greatly appreciated.
Thanks!
Pm
Re: How do I associate methods with a compiler?
Patrick R. Michaud wrote: > Or, in claiming that compilers have an API, should we instead say that the canonical compilation sequence is to use compreg to obtain a compiler object (not an invokable sub), and then compile the source via a 'compile' method on the compiler object? For example: perl6_compiler = compreg 'Perl6' $P0 = perl6_compiler.'compile'(perl6_source) Also for the record from the weekly meeting (which was actually today, just a very long today): Yes, compilers are objects and compilation is a method call. The compiler for TGE tree grammars is implemented this way, and it's a very usable interface. We might want to resurrect the 'compile' opcode as an indirect syntax for making the 'compile' method call. In asking the above questions I'm purposely avoiding, because Parrot doesn't seem to support it yet, the possibility that the object obtained via compreg is both invokable in its own right (like a sub) and has methods attached to it. Possible, but agreed that it's more complex than we need, without enough added gain to be worth it. Allison
Re: set_pmc + setref/deref: anyone using them?
Matt Diephouse wrote: Would anyone be inconvenienced if the set_pmc vtable and the setref and deref opcodes were removed? Note that if you are using set _pmc but are not using assign_pmc, then you may not be inconvenienced because right now the default assign_pmc vtable calls set_pmc. These opcodes were added to make transparent references possible, but they weren't really specced out or desisign ed properly. As such, they're a little broken and we'd like to remove them. Removing opcodes because they're a little broken sounds odd. What problem were they designed to solve, and what's our replacement strategy for solving the problem? Allison
Re: [perl #40823] Win32 vs. the world - length for sprintf('%e') - what's right?
jerry gay wrote: ick -- that feels wrong for parrot. we've always tried to make parrot act in a consistent way across platforms wherever possible, so i'd rather see the fix in Parrot_sprintf rather than in t/op/sprintf.t. For the record: we decided in the weekly meeting yesterday to go with a platform-independent implementation with consistent behavior. Allison
List assignment question
Hello everyone, I was toying around with Pugs and I tried the following Perl 5 list assignment my ($a, undef, $b) = 1..3; Which gave me the following error message: Internal error while running expression: *** Unexpected "," expecting word character, "\\", ":", "*" or parameter name at line 1, column 14 I had a quick discussion on #perl6 with TimToady++ during my lunch hour, and he said that assignment to undef was no longer valid. His suggestion was to use the whatever operator (*) instead. Now, this isn't implemented and my Haskell skills and knowledge of Pugs' internals aren't really advanced enough to implement this feature, however I can surely contribute the tests. Here's what I have right now in my working copy, let me know if this seems reasonable. my @a = 1..3; my ($one, *, $three) = @a; is(~($one, $three), "1 3", "list assignment my ($, *, $) = @ works"); my (*, $two) = @a; is($two, 2, "list assignment my (*, $) = @ works"); my (*, *, $three) = @a; is($three, 3, "list assignment my (*, *, $) = @ works"); my (*, @b) = @a; is([EMAIL PROTECTED], "2 3", "list assignment my (*, @) = @ works"); Any input would be very much appreciated (and some links to documents that could help me contribute to the internals of Pugs), Vincent.
[perl #40884] [TODO] update parrothist.pod from email archives
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #40884] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40884 > All those cute release names seem to have been lost to history. Please somebody check the email archives for release announcements and update docs/parrothist.pod with the names. adTHANKSvance -- Chip Salzenberg <[EMAIL PROTECTED]>
Release: Parrot 0.4.7, "Caique"
[ I'll post this to use.perl.org when CPAN has had a chance to mirror. ]
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.7, "Caique"!
What is Parrot? Parrot is a virtual machine aimed at running all dynamic
languages. The Parrot project home page is parrotcode.org.
You may now (or soon) grab Parrot 0.4.7 from:
http://www.cpan.org/authors/id/CHIPS/parrot-0.4.7.tar.gz
New in Parrot 0.4.7:
* New languages: PHP ("Plumhead"), Forth
* Updated languages: Ruby ("Cardinal"), Tcl, Lua
* Active Python language development is hosted at pirate.tangentcode.com
* Compilers:
+ PGE updated with more expressions, latest changes to S05
+ new Perl6 grammar compiler
* Integration:
+ Perl 5 module "Parrot::Embed" allows easy embedding of a Parrot
runtime into a Perl 5 program
* PIR:
+ new :init pragma for subs that must run before the main function
+ new :vtable pragma to identify subs that override PMC vtable methods,
eliminating the need for special subroutine names
+ PIR parser/compiler does not stop on first syntax error
+ Vanilla register allocator ("register alligator") greatly improves
performance compiling large functions
+ Eliminated limit on number of PIR macros
* PMCs:
+ hash lookups return null instead of None for missing keys
* Design:
+ PDD13 "Bytecode files: format and manipulation" - new
+ PDD10 "Embedding" - new
+ PDD25 "Concurrency" - rewritten
+ PDD15 "Objects" - new section on redesign requirements
+ PDD07 "Coding standards" - significant updates and automated tests
* Test Suite:
+ Many many more new tests
* Build Process:
+ autoconf compatible install options
* Misc:
+ Namespace refinements
+ Coroutine improvements
+ An impressive swarm of other bugfixes and enhancements
If you'd like to develop on Parrot (or help develop Parrot itself), we
recommend that you keep up with the latest and best Parrot code by using
Subversion or SVK to access our source code repository; see instructions at
http://www.parrotcode.org/source.html .
Thanks to all our contributors for making this possible, and our sponsors
for supporting this project.
Share & Enjoy!
--
Chip Salzenberg <[EMAIL PROTECTED]>
Fwd: Re: [pirate] Re: languages/python - any plans?
I don't know if this was cc'ed to p2p, so just in case. leo --- Begin Message --- Leo, We have PMCs in the pirate repo at the moment. They are based off of the python pmcs in parrot's repo, but work with recent versions of parrot. Not all features are enabled at the moment, but I haven't had a lot of time lately :-( I had meant to get them cleaned up and try to submit patches to parrot for them but have never gotten around to it. So I would say remove languages/python. If I ever get more time (school/work eating up all time) hopefully I will get them cleaned up further and add more features. If anyone is interested in looking at the updated python pmcs go to http://pirate.tangentcode.org and the link to the pirate-pmcs is there. Keep in mind they are currently a bit nasty (ok maybe an understatement :-) Thanks for all your great work on parrot, Tyler Coumbes On 11/12/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: Am Sonntag, 12. November 2006 06:59 schrieben Sie: > Can we remove languages/python from the trunk? The history will still hold > it if you want to resurrect it.. I don't know, if the Pirate folks are using these PMCs or if they have their own. Michal? leo ___ pirate mailing list pirate@cornerhost.com http://cornerhost.com/mailman/listinfo/pirate ___ pirate mailing list pirate@cornerhost.com http://cornerhost.com/mailman/listinfo/pirate --- End Message ---
Re: [svn:parrot] r15517 - in trunk: . src
Am Dienstag, 14. November 2006 07:27 schrieb chromatic: > Does this patch do anything for you? I sort of really hate it, but I'm > curious about the results. I've now ci'ed that, as it obviosly fixes x86_64 so far. Thanks for invetigating it. leo
[svn:parrot-pdd] r15527 - in trunk: . docs/pdds
Author: chip
Date: Tue Nov 14 09:40:26 2006
New Revision: 15527
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Incremental improvement to pdd07 "coding standards":
* Prefer "char *p" to "char* p".
* Prefer that structures have both tags and typedefs.
* Add "Portability" and "Defensive programming" sections.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Nov 14 09:40:26 2006
@@ -145,6 +145,11 @@
=item *
+Pointer types should be written with separation between the star and the base
+type, e.g. C, but not e.g. .
+
+=item *
+
There should be one space between C keywords and following open parentheses,
e.g. C.
@@ -232,9 +237,13 @@
=item *
-All functions must have prototypes in scope at the point of use. Prototypes
-for extern functions must appear only in header files. If static functions
-are defined before use, their definitions serve as prototypes.
+Structure types must have tags.
+
+=item *
+
+Functions must have prototypes in scope at the point of use. Prototypes for
+extern functions must appear only in header files. If static functions are
+defined before use, their definitions serve as prototypes.
=item *
@@ -255,6 +264,14 @@
=item *
+Structure types should have typedefs with the same name as their tags, e.g.:
+
+typedef struct Foo {
+...
+} Foo;
+
+=item *
+
Avoid double negatives, e.g. C<#ifndef NO_FEATURE_FOO>.
=item *
@@ -262,7 +279,7 @@
Do not compare directly against NULL, 0, or FALSE. Instead, write a boolean
test, e.g. C.
-(Note: C values should be checked for nullity with the C
+(Note: C values should be checked for nullity with the C
macro, unfortunately leading to violations of the double-negative rule.)
=item *
@@ -313,6 +330,110 @@
list of typedefs, and parrot.el should read it or contain it. }}
+=head2 Portability
+
+Parrot runs on many, many platforms, and will no doubt be ported to ever more
+bizarre and obscure ones over time. You should never assume an operating
+system, processor architecture, endian-ness, size of standard type, or
+anything else that varies from system to system.
+
+Since most of Parrot's development uses GNU C, you might accidentally depend
+on a GNU feature without noticing. To avoid this, know what features of gcc
+are GNU extensions, and use them only when they're protected by #ifdefs.
+
+
+=head2 Defensive Programming
+
+=head3 Use Parrot data structures instead of C strings and arrays
+
+C arrays, including strings, are very sharp tools without safety guards, and
+Parrot is a large program maintained by many people. Therefore:
+
+Don't use a C when a Parrot STRING would suffice. Don't use a C array
+when a Parrot array PMC would suffice. If do use a C or C array,
+check and recheck your code for even the slightest possibility of buffer
+overflow or memory leak.
+
+Note that efficiency of some low-level operations may be a reason to break
+this rule. Be prepared to justify your choices to a jury of your peers.
+
+=head3 Pass only C to C and C
+
+Pass only values in the range of C (and the special value -1,
+a.k.a. C) to the isxxx() and toxxx() library functions. Passing signed
+characters to these functions is a very common error and leads to incorrect
+behavior at best and crashes at worst. And under most of the compilers Parrot
+targets, C I signed.
+
+=head3 The C keyword on arguments
+
+Use the C keyword as often as possible on pointers. It lets
+the compiler know when you intend to modify the contents of something.
+For example, take this definition:
+
+int strlen(const char *p);
+
+The C qualifier tells the compiler that the argument will not be
+modified. The compiler can then tell you that this is an uninitialized
+variable:
+
+char *p;
+int n = strlen(p);
+
+Without the C, the compiler has to assume that C is
+actually initializing the contents of C.
+
+=head3 The C keyword on variables
+
+If you're declaring a temporary pointer, declare it C, with the
+const to the right of the C<*>, to indicate that the pointer should not
+be modified.
+
+Wango * const w = get_current_wango();
+w->min = 0;
+w->max = 14;
+w->name = "Ted";
+
+This prevents you from modifying C inadvertantly.
+
+new_wango = w++; /* Error */
+
+If you're not going to modify the target of the pointer, put a C
+to the left of the type, as in:
+
+const Wango * const w = get_current_wango();
+if (n < wango->min || n > wango->max) {
+/* do something */
+}
+
+=head3 Localizing variables
+
+Declare variables in the innermost scope possible.
+
+if (foo) {
+int i;
+for (i = 0; i < n; i++)
+do_something(i);
+}
+
+Don't reuse unrelated variables. Localize as much as possibl
[svn:perl6-synopsis] r13477 - doc/trunk/design/syn
Author: pmichaud Date: Tue Nov 14 09:07:04 2006 New Revision: 13477 Modified: doc/trunk/design/syn/S04.pod Log: Correct punctuation. Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podTue Nov 14 09:07:04 2006 @@ -273,7 +273,7 @@ } Since the loop executes once before evaluating the condition, the -bound parameter will be undefined that first time through the loop, +bound parameter will be undefined that first time through the loop. =head2 The general loop statement
Re: generic ordinal-relevant operators
HaloO,
Smylers wrote:
BTW, could we define that the arithmetic shift ops do just that,
whereas the string ones do logical shift? And in addition that for
the bit inversion +^$a == -1 - $a holds? Note that -1 == +^0.
Does that assume a two's complement system? Is that a safe assumption
to make about everywhere Perl 6 will run? (Is it even a safe assumption
to make about Perl 5?)
Well, there are two ways of conduct. Either the spec prescribes the
behavior on the language level or it leaves it undefined. The former
should go with the equalities I gave, the latter is a bad idea for a
high level language. I mean letting platform details shine through
only makes it convenient for the implementor but harder for users.
Note further that in infinite precision the arithmetic shift left
maintains the sign ...
Do we expect Perl 6 to be running on infinite-precision systems?
Well, IIRC the Int type is conceptually infinite. IOW,
my Int $i = 0;
while ++$i { say $i}
should die because of memory exhaustion not end up in a tight
endless loop that wraps around at the max integer. So arithmetic
shift left should preserve sign.
There are other arithmetic properties that I would expect from
a high level language: absence of zero divisors, proper modulo
and integer division including remainder, etc.
Regards,
--
Re: [svn:parrot] r15517 - in trunk: . src
On Mon, Nov 13, 2006 at 10:27:19PM -0800, chromatic wrote: > On Monday 13 November 2006 21:49, Patrick R. Michaud wrote: > > On Mon, Nov 13, 2006 at 07:33:18PM -0800, [EMAIL PROTECTED] wrote: > > > Log: > > > Fix size mismatch errors, at least on Linux/PPC. If this breaks > > > other platforms, there's a deeper bug somewhere and we need to > > > rethink t/tools/pbc_merge.t for the release. > > > > Alas, it seems to break Linux/x86_64 -- output of 'make' is below. > > Too bad; I was aiming for 32-bit x86. > > Does this patch do anything for you? I sort of really hate it, but I'm > curious about the results. With the patch everything seems to work okay, but I agree it's not pretty and that we're probably just masking something deeper. Pm
Re: named sub-expressions, n-ary functions, things and stuff
Smylers schreef:
> my $whatever
> = do { my $baz = $bar * 17; my $quux = $baz - 3; $baz / $quux };
($bar better not be 3/17)
Just a rewrite:
my $whatever
= do { my $quux = (my $baz = $bar * 17) - 3; $baz / $quux };
And maybe even something like:
my $whatever
= do { $.quux = ($.baz = $bar * 17) - 3; $.baz / $.quux };
(where quux and baz are topicals of the embracing do)
--
Affijn, Ruud
"Gewoon is een tijger."
