Re: [svn:parrot-pdd] r17312 - trunk/docs/pdds/draft

[Sam Vilain]

[EMAIL PROTECTED] wrote:
> (When you extend an existing class, it actually creates
> +a new class, that replaces the old class in the Namespace, but the old
> +class can't be thrown away if it has objects instantiated in it. The old
> +objects still point to the old class and do their method resolution and
> +attribute lookup through that class. If a class hasn't been
> +instantiated, adding a method doesn't create a new class. If it has been
> +instantiated, the it creates a new class the first time its extended,
> +and then doesn't create a new class until it is instantiated again.)

Is it intended that if languages need to make changes to the behaviour
of existing obejcts through their type, that something may follow up
after this and replace the old objects with objects of the new type?

Sam.

Re: AIX 5.3

[Allison Randal]

Theodore Katseres wrote:

I managed to get parrot to build on aix-ppc-gcc4.0.0
smoked too ;)


Excellent! :)

Allison

[svn:parrot-pdd] r17321 - trunk/docs/pdds/draft

[allison]

Author: allison
Date: Sun Mar  4 01:33:33 2007
New Revision: 17321

Modified:
   trunk/docs/pdds/draft/pdd15_objects.pod

Log:
[pdd]: Notes on container type in Objects PDD.


Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==
--- trunk/docs/pdds/draft/pdd15_objects.pod (original)
+++ trunk/docs/pdds/draft/pdd15_objects.pod Sun Mar  4 01:33:33 2007
@@ -315,10 +315,6 @@
 
 =item 2
 
-The container type
-
-=item 2
-
 The object attribute hash. Keys are the attribute names and the values
 are the attribute values. (The "hash" may be implemented as a typed
 structure following the CStruct proposal.)
@@ -337,6 +333,24 @@
 information about the object, method call functionality, etc. See the
 sections below on L and L.
 
+[stream-of-consciousness again]
+In addition to a value type, objects can have a containter type. The
+container type can't be stored in the object itself, because a single
+object may live within multiple containers. So, the container type (when
+it exists) is stored in the LexPad or Namespace entry for a particular
+variable.
+
+In a static language like C#.Net:
+B isa A
+A o1 = new B();
+B o2 = new B();
+
+o1.x; # retrieves A's attribute
+o2.x; # retrieves B's attribute
+
+o1.foo(); # call's B's method
+o2.foo(); # call's B's method
+
 =head2 Role PMC API
 
 An instance of the Role PMC has four attributes, which are:

[BUG]: Test failures in t/pmc/smop_attribute.t and t/pmc/smop_class.t

[James Keenan]

See attached output of prove -v.  I have not encountered these  
failures before tonight.
Updated to revision 17318.
[parrot] 526 $ prove -v t/pmc/smop_*.t 
t/pmc/smop_attribute1..5

# Failed test (t/pmc/smop_attribute.t at line 26)
#  got: 'sh: line 1: ./parrot: No such file or directory
# '
# expected: ''
# './parrot   "/Users/jimk/work/parrot/t/pmc/smop_attribute_1.pir"' failed with 
exit code 127
not ok 1 - create a SMOP_Attribute

# Failed test (t/pmc/smop_attribute.t at line 33)
not ok 2 - test the SMOP_Attribute name method
#  got: 'sh: line 1: ./parrot: No such file or directory
# '
# expected: 'TestClass1
# TestClass1
# '
# './parrot   "/Users/jimk/work/parrot/t/pmc/smop_attribute_2.pir"' failed with 
exit code 127
not ok 3 - test the SMOP_Attribute type method

# Failed test (t/pmc/smop_attribute.t at line 48)
#  got: 'sh: line 1: ./parrot: No such file or directory
# '
# expected: 'TestTypeClass1
# TestTypeClass1
# '
# './parrot   "/Users/jimk/work/parrot/t/pmc/smop_attribute_3.pir"' failed with 
exit code 127
not ok 4 - test the SMOP_Attribute type method with a ResizableIntegerArray

# Failed test (t/pmc/smop_attribute.t at line 63)
#  got: 'sh: line 1: ./parrot: No such file or directory
# '
# expected: '[ 1, 2, 3 ]
# [ 1, 2, 3 ]
# '
# './parrot   "/Users/jimk/work/parrot/t/pmc/smop_attribute_4.pir"' failed with 
exit code 127
not ok 5 - test the SMOP_Attribute class method with a FixedIntegerArray

# Failed test (t/pmc/smop_attribute.t at line 85)
#  got: 'sh: line 1: ./parrot: No such file or directory
# '
# expected: '[ 1, 2, 3 ]
# [ 1, 2, 3 ]
# '
# './parrot   "/Users/jimk/work/parrot/t/pmc/smop_attribute_5.pir"' failed with 
exit code 127
# Looks like you failed 5 tests of 5.
dubious
Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED tests 1-5
Failed 5/5 tests, 0.00% okay
t/pmc/smop_class1..1
not ok 1 - create a SMOP_Class

# Failed test (t/pmc/smop_class.t at line 26)
#  got: 'sh: line 1: ./parrot: No such file or directory
# '
# expected: ''
# './parrot   "/Users/jimk/work/parrot/t/pmc/smop_class_1.pir"' failed with 
exit code 127
# Looks like you failed 1 test of 1.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed TestStat Wstat Total Fail  List of Failed
---
t/pmc/smop_attribute.t5  1280 55  1-5
t/pmc/smop_class.t1   256 11  1
Failed 2/2 test scripts. 6/6 subtests failed.
Files=2, Tests=6,  4 wallclock secs ( 0.30 cusr +  0.28 csys =  0.58 CPU)
Failed 2/2 test programs. 6/6 subtests failed.


myconfig
Description: Binary data

[svn:parrot-pdd] r17322 - trunk/docs/pdds/draft

[jonathan]

Author: jonathan
Date: Sun Mar  4 02:19:10 2007
New Revision: 17322

Modified:
   trunk/docs/pdds/draft/pdd15_objects.pod

Log:
Describe new class and object layout for objects. We now push a lot into the 
class and make objects really lightweight, since you will usually instantiate 
many objects per class.

Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==
--- trunk/docs/pdds/draft/pdd15_objects.pod (original)
+++ trunk/docs/pdds/draft/pdd15_objects.pod Sun Mar  4 02:19:10 2007
@@ -18,7 +18,7 @@
 
 =head2 Object
 
-An object is kind a variable that incorporates both data and behavior
+An object is a variable that incorporates both data and behavior
 related to that data.
 
 =head2 Class
@@ -194,12 +194,35 @@
 An array PMC of the methods defined in the class or composed into the
 class
 
-
 =item 6
 
-The class attribute hash. Keys are the attribute names and the values
-are a hash of attribute characteristics, including name, type, and the
-class they're associated with.
+The v-table for the class. The order of dispatch used when building the
+v-table should follow the MRO, and it should be invalidated when the MRO
+changes. Essentially, it is a cache.
+
+=item 7
+
+The class attribute metadata hash. Keys are the attribute names and the
+values are a hash of attribute characteristics, including name, type, the
+class they're associated with and any flags (for example, private). Note
+that this only stores metadata for the attributes defined in this class,
+and not for attributes inherited from its parents.
+
+=item 8
+
+The full attribute lookup table. This includes all attributes defined in
+the current class and every other class that it inherits from either
+directly or indirectly. The table is keyed on the name of the class the
+attribute is defined in along with the attribute name. The value is an
+index into the per-object attribute store.
+
+=item 9
+
+The attribute cache. While the attribute lookup table defines every
+attribute, whether it is visible or not with the current MRO, the cache
+maps the names of the visible attributes directly to an index in the per-
+object attribute store. That saves a more costly lookup in the full
+attribute lookup table.
 
 =back
 
@@ -209,13 +232,11 @@
 The inheritance rules for a particular HLL will determine which child
 class attributes override which parent class attributes. 
 
-We may also add a cache to the class object: a hash that contains all
-child and parent attribute characteristcs. Whether this is useful
-largely depends on how slow it is to scan through the list of parent
-classes, and how dynamic we want the system to be. (If a parent class
-changes its set of attributes, should that change appear in later
-instantiations of objects from child classes? Probably, in which case
-caching parent attributes is an obstacle.)
+(If a parent class changes its set of attributes, should that change
+appear in later instantiations of objects from child classes? If so, all
+of these classes would need to be re-constructed as a result of the
+change; note that any already instantiated objects would refer to the old
+class.)
 
 Class PMCs also have the "I am a class" flag set on them.
 
@@ -311,20 +332,15 @@
 
 =item 1
 
-The class name
-
-=item 2
-
-The object attribute hash. Keys are the attribute names and the values
-are the attribute values. (The "hash" may be implemented as a typed
-structure following the CStruct proposal.)
+The object attribute store. This is simply an array of PMCs that
+provide the values for the attributes. It may be a resizable PMC array
+to provide lazy growth rather than allocating all needed memory for
+all attributes. We find the indexes into this array from the attribute
+cache or lookup table in the class.
 
 =back
 
-A list of the object's attributes is accessible by extracting the keys
-from the object attribute hash. This direct introspetive capability may
-not be directly exposed in the HLLs (preserving the boundaries of an
-opaque object).
+A list of the object's attributes is accessible from the class.
 
 Note that Object PMCs have the "I am an object" flag set on them.
 

[svn:parrot-pdd] r17323 - trunk/docs/pdds/draft

[allison]

Author: allison
Date: Sun Mar  4 02:30:36 2007
New Revision: 17323

Modified:
   trunk/docs/pdds/draft/pdd15_objects.pod

Log:
[pdd]: Objects, a few clarifications.


Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==
--- trunk/docs/pdds/draft/pdd15_objects.pod (original)
+++ trunk/docs/pdds/draft/pdd15_objects.pod Sun Mar  4 02:30:36 2007
@@ -88,11 +88,11 @@
 
 =item - Classes have an associated namespace. (Which may be anonymous)
 
-=item - Classes have one or more immediate parent classes
+=item - Classes may have one or more immediate parent classes
 
-=item - Classes have a catalog of attribute names.
+=item - Classes may have a catalog of attribute names.
 
-=item - Classes have a list of roles they implement
+=item - Classes may have a list of roles they implement
 
 =item - Classes can instantiate an object of their class
 
@@ -105,7 +105,7 @@
 =item - Classes are instances of a meta-class and have their own sets of
 class methods and class attributes
 
-=item - Objects have an array of attributes. Attribute values may be
+=item - Objects may have an array of attributes. Attribute values may be
 PMCs or a low-level type.
 
 =item - Objects have an associated class.
@@ -313,8 +313,8 @@
 to that namespace object.
 
 A class can be garbage collected when it has no instantiatated objects
-referencing it. When a class is garbage collected, it should remove itself
-from the registry.
+and no Namespace object referencing it. When a class is garbage
+collected, it should remove itself from the registry.
 
 =head2 Object PMC API
 

Re: [perl #41583] Tail calls from within vtable methods broken

[Jonathan Worthington]

Bram Geron (via RT) wrote:

Tail calls from within v-table methods are broken, the tail-called sub
(or method) will not return correct values.

When method A tailcalls sub B, B's set_returns stores its opcode
number (and with it, which registers should be returned), but the
low-level vtable code gets the registers from A's context.
(Runops_args stores a pointer to A's context just before it is called,
wrongly assuming A has the final set_returns. Runops_args returns the
context to a function that then does return value passing on it.)

Maybe the solution is to store the current context in a new field in
the interp structure; I don't know, I'm rather bad at C.

Example:
This should print 2, but it prints 13.

  
The problem is that when we make a call over the C boundary (e.g. call 
back into PIR), we do that by getting the invoke v-table method of the 
sub PMC to create the context etc. for the call for us, and then capture 
that context. We then return that context after the sub has executed, 
and in theory can get the parameters from it.


Enter tail calls. The assumption that the context of the sub we called 
is the context with the results we want in it is now invalid, since a 
tailcall now replaces the context. That means we end up holding a 
reference to a freed context (essentially, freed memory!)


My attempt at fixing this is to construct a fake context for the sub we 
call to set_returns into. Even if it does a tail call, then it will 
still end up putting the return values there - it's just normal calling 
semantics.


Happily, the attached patch makes your program work. Unfortunately, it 
breaks other stuff and I'm having a hard time seeing why right now. The 
breakage includes PGE. So something I've done is quite wrong somehow, 
but I'm not sure where. So I'm throwing the patch out on the list in 
hope someone may stop something stupid I've done. Perhaps someone who's 
more familiar with the whole contexts thing than I.


Thanks,

Jonathan


Index: src/ops/core.ops
===
--- src/ops/core.ops(revision 17321)
+++ src/ops/core.ops(working copy)
@@ -564,14 +564,9 @@
 ctx = CONTEXT(interp->ctx);
 ccont = ctx->current_cont;
 
-if (PMC_cont(ccont)->address) {
-/* else it's from runops_fromc */
+/* If we have a context to put the return values in... */
+if (PMC_cont(ccont)->to_ctx) {
 parrot_context_t * const caller_ctx = PMC_cont(ccont)->to_ctx;
-if (! caller_ctx) {
-/* there is no point calling real_exception here, because
-   PDB_backtrace can't deal with a missing to_ctx either. */
-internal_exception(1, "No caller_ctx for continuation %p.", ccont);
-}
 
 src_indexes = interp->current_returns;
 dest_indexes = caller_ctx->current_results;
@@ -581,6 +576,13 @@
 
 parrot_pass_args(interp, ctx, caller_ctx, src_indexes, dest_indexes, 
PARROT_PASS_RESULTS);
 }
+else if (!PMC_cont(ccont)->address) {
+/* Problem - we have a return bytecode address, but no context! There
+ * is no point calling real_exception here, because PDB_backtrace
+ * can't deal with a missing to_ctx either. */
+internal_exception(1, "No caller_ctx for continuation %p.", ccont);
+}
+
 argc = SIG_ELEMS(signature);
 goto OFFSET(argc + 2);
 }
Index: src/inter_run.c
===
--- src/inter_run.c (revision 17321)
+++ src/inter_run.c (working copy)
@@ -29,6 +29,7 @@
 runops(Interp *interp, size_t offset)>
 
 Run parrot ops. Set exception handler and/or resume after exception.
+This is the low level run ops routine that just takes an offset.
 
 =cut
 
@@ -156,18 +157,74 @@
 opcode_t offset, *dest;
 parrot_context_t *ctx;
 parrot_context_t *old_ctx;
+INTVAL *fake_context_registers;
+opcode_t fake_return_bytecode[1] = { 0 };
+int i;
+
 /*
  * FIXME argument count limited - check strlen of sig
  */
 char new_sig[10];
 const char *sig_p;
 
+/* Set the object we're calling with, if any. */
+interp->current_object = obj;
+
+/* We set up a new return continuation with a NULL address, so we will
+ * eventually fall back out of the runloop to here. */
 old_ctx = CONTEXT(interp->ctx);
-interp->current_cont  = new_ret_continuation_pmc(interp, NULL);
-interp->current_object = obj;
+interp->current_cont = new_ret_continuation_pmc(interp, NULL);
+
+/* We may need to capture the return values too. We set up a fake register
+ * frame within a context to put them in to - one register of each type. */
+fake_context_registers = mem_sys_allocate(4 * sizeof(INTVAL));
+for (i = 0; i < 4; i++)
+fake_context_registers[i] = 1;
+ctx = Parrot_alloc_context(interp, fake_context_registers);
+ctx->caller_ctx = NULL;
+ctx->current_sub = NULL;
+ctx->current_resul

[svn:parrot-pdd] r17326 - trunk/docs/pdds/draft

[allison]

Author: allison
Date: Sun Mar  4 03:40:00 2007
New Revision: 17326

Modified:
   trunk/docs/pdds/draft/pdd15_objects.pod

Log:
[pdd]: Review of updates from 2am design session on object structures.


Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==
--- trunk/docs/pdds/draft/pdd15_objects.pod (original)
+++ trunk/docs/pdds/draft/pdd15_objects.pod Sun Mar  4 03:40:00 2007
@@ -86,7 +86,8 @@
 implement a core set of dynamic languages (Perl 6, Ruby, Python, etc).
 Other class systems may be implemented later to support other languages.
 
-=item - Classes have an associated namespace. (Which may be anonymous)
+=item - Classes may have an associated namespace. (Anonymous classes are
+not associated with a namespace.)
 
 =item - Classes may have one or more immediate parent classes
 
@@ -191,14 +192,12 @@
 
 =item 5
 
-An array PMC of the methods defined in the class or composed into the
+An hash PMC of the methods defined in the class or composed into the
 class
 
 =item 6
 
-The v-table for the class. The order of dispatch used when building the
-v-table should follow the MRO, and it should be invalidated when the MRO
-changes. Essentially, it is a cache.
+An hash PMC of the overloaded PMC vtable entries for the class.
 
 =item 7
 
@@ -210,33 +209,46 @@
 
 =item 8
 
-The full attribute lookup table. This includes all attributes defined in
-the current class and every other class that it inherits from either
-directly or indirectly. The table is keyed on the name of the class the
-attribute is defined in along with the attribute name. The value is an
-index into the per-object attribute store.
+The full attribute lookup table. This associates attribute names with an
+index into the object's attribute storage (an array). It includes all
+attributes defined in the current class and every other class that it
+inherits from either directly or indirectly. The table is keyed on the
+name of the class where the attribute is defined, along with the
+attribute name. The value is an index into the per-object attribute
+store.
 
 =item 9
 
 The attribute cache. While the attribute lookup table defines every
-attribute, whether it is visible or not with the current MRO, the cache
-maps the names of the visible attributes directly to an index in the per-
-object attribute store. That saves a more costly lookup in the full
-attribute lookup table.
+attribute, whether it is visible or not with the current method
+resolution order (MRO), the cache maps the names of the visible
+attributes directly to an index in the per- object attribute store. That
+saves a more costly lookup in the full attribute lookup table.
 
 =back
 
 The attribute catalog holds only the attributes defined in a particular
-class. When instantiating an object, it is necessary to scan all parent
+class. When instantiating an object, the object data store is created as
+a ResizablePMCArray, so doesn't need any specific details of the class's
+attribute structure. As attributes are set in the object (based on the
+index in the lookup table), the Array expands to accomodate the
+attribute indexes that are actually used. In the common case, a
+relatively small set near the lower index range is all that will be
+used.
+
+When setting the attribute cache it is necessary to scan all parent
 classes as well as the instantiated class for attributes defined there.
-The inheritance rules for a particular HLL will determine which child
-class attributes override which parent class attributes. 
+The inheritance rules (MRO) for a particular HLL will determine which
+child class attributes override which parent class attributes.  The
+cache is only set on individual accesses to a particular attribute.
 
 (If a parent class changes its set of attributes, should that change
 appear in later instantiations of objects from child classes? If so, all
 of these classes would need to be re-constructed as a result of the
-change; note that any already instantiated objects would refer to the old
-class.)
+change; note that any already instantiated objects would refer to the
+old class. NOTE: flag old classes with an "updated" status, to notify
+objects of the old class that they should rebless themselves into the
+new class next time they access the old class?)
 
 Class PMCs also have the "I am a class" flag set on them.
 
@@ -293,7 +305,7 @@
 [Stream-of-consciousness to be cleaned up later]
 The class registry has a much diminished role in this implementation.
 Its only responsibility is maintaining a mapping of unique IDs to class
-objects throught the system. (We may eventually be able to eliminate the
+objects throughout the system. (We may eventually be able to eliminate the
 registry altogether.) It can't be used for looking up classes by name,
 because it's possible to have multiple classes with the same name in the
 same namespace. (When you extend an existing class, it actually creates
@

Re: [svn:parrot-pdd] r17312 - trunk/docs/pdds/draft

[Allison Randal]

Sam Vilain wrote:


Is it intended that if languages need to make changes to the behaviour
of existing obejcts through their type, that something may follow up
after this and replace the old objects with objects of the new type?


Yes. Some languages will want that behavior, and some won't, so Parrot 
can't decide for them. I added a note to the latest edition of the PDD.


Allison

Parrot won't build on cygwin

[Klaas-Jan Stol]

hi,

I'm trying to compile parrot on cygwin, but it won't compile:


mpilers/imcc/parser_util.o compilers/imcc/pcc.o -lcrypt -lgmp -lreadline
compilers/imcc/main.c
/usr/bin/perl.exe tools/build/parrot_config_c.pl --mini > \
   src/null_config.c
src/null_config.c
gcc -o miniparrot.exe compilers/imcc/main.o \
-L/home/KJS/parrot/blib/lib -lparrot  -lcrypt -lgmp -lreadline -s 
-L/usr/lo

cal/lib   src/null_config.o
Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross 
your fing

ers
./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
make: *** [runtime/parrot/include/config.fpmc] Error 53


Trying again, gives:


$ make
Compiling with:
xx.c
gcc -I./include -pipe -I/usr/local/include -g -W -Wall 
-Wstrict-prototypes -Wmis
sing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual 
-Wwrite-strings -W
aggregate-return -Winline -Wno-unused -Wsign-compare 
-falign-functions=16 -Wform
at-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization 
-Wno-shadow -DH

AS_JIT -DI386 -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c
/usr/bin/perl.exe tools/build/parrot_config_c.pl > \
   src/parrot_config.c
'runtime/parrot/include/config.fpmc' is truncated. Remove it and rerun make
make: *** [src/parrot_config.c] Error 255
===

And indeed, if I check runtime/parrot/include/config.fpmc, it's empty. 
The file src\parrot_config.c contains:


===
[...]
void
Parrot_set_config_hash_internal (const unsigned char* parrot_config,
unsigned int parrot_config_size);


static const unsigned char parrot_config[] = {
No mini!


But, there *is* a miniparrot.

regards,
kjs

Re: for ... else

[herbert breunung]

> Von: Thomas Wittek <[EMAIL PROTECTED]>
> That's, well, elegant! Yes.
> Because and but it's tricky.
> Nothing where I'd say "wow, thats an easy solution to my problem!".
> It's a bit complicated, because you have to understand and combine
> several concepts. That's elegant. But not easy, I think.
> I think it's not simple enough for this simple kind of problem.
> 

exactly, my full support to thomas with this, perl was always about
keep simple things simple too.

herbert breunung
proton-ce.sf.net
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=0066

Re: for ... else

[Jonathan Lang]

herbert breunung wrote:

> Von: Thomas Wittek <[EMAIL PROTECTED]>
> That's, well, elegant! Yes.
> Because and but it's tricky.
> Nothing where I'd say "wow, thats an easy solution to my problem!".
> It's a bit complicated, because you have to understand and combine
> several concepts. That's elegant. But not easy, I think.
> I think it's not simple enough for this simple kind of problem.

exactly, my full support to thomas with this, perl was always about
keep simple things simple too.


Seconded.  I would favor allowing an "else" block to be attached
following any loop block, with the semantics being that the else block
only gets triggered if the loop block doesn't run at least once.  I'd
do this instead of a block trait (such as FIRST or LAST) because of
the either-or relationship between the loop block and the else block.

--
Jonathan "Dataweaver" Lang

Re: for ... else

[Jonathan Lang]

Jonathan Lang wrote:

Seconded.  I would favor allowing an "else" block to be attached
following any loop block, with the semantics being that the else block
only gets triggered if the loop block doesn't run at least once.  I'd
do this instead of a block trait (such as FIRST or LAST) because of
the either-or relationship between the loop block and the else block.


The one exception would be the "repeat" statement, because attaching
an "else" block to it would be as confusing semantically as attaching
an "else" block to an "unless" statement.

--
Jonathan "Dataweaver" Lang

Re: for ... else

[Thomas Wittek]

Darren Duncan schrieb:
> At 11:17 PM +0100 3/3/07, Thomas Wittek wrote:
>> Larry Wall:
>>>  : if ($item = 'foobar') {
>>
>> == of course ;)

>>>  If you actually wrote that, then you'll always find that the first
>>  > item has the value 'foobar'.  :)
> 
> Care to try a third time?
> 
> I don't think the numeric-casting == will do what you want either.

Shame on me. I confused my examples. Read the 42 thing and wrote above.
Must be > of course, to leave the gag running ;)
Next time I should write my messages with "use warnings;"...

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

[svn:parrot-pdd] r17322 - trunk/docs/pdds/draft

[Bob Rogers]

   From: [EMAIL PROTECTED]
   Date: Sun,  4 Mar 2007 02:19:16 -0800 (PST)

   Author: jonathan
   Date: Sun Mar  4 02:19:10 2007
   New Revision: 17322

   Modified:
  trunk/docs/pdds/draft/pdd15_objects.pod

   . . .

   Modified: trunk/docs/pdds/draft/pdd15_objects.pod
   
==
   --- trunk/docs/pdds/draft/pdd15_objects.pod  (original)
   +++ trunk/docs/pdds/draft/pdd15_objects.pod  Sun Mar  4 02:19:10 2007
   @@ -18,7 +18,7 @@

=head2 Object

   -An object is kind a variable that incorporates both data and behavior
   +An object is a variable that incorporates both data and behavior
related to that data.

=head2 Class
   . . .

??  Not "An object is a value . . ."?

-- Bob Rogers
   http://rgrjr.dyndns.org/

[perl #41695] [CAGE]: Refactor Parrot::Distribution

[via RT]

# New Ticket Created by  James Keenan 
# Please include the string:  [perl #41695]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=41695 >


I am opening this ticket as a way of logging various Parrot hackers'  
efforts to re-factor Parrot::Distribution, its ancestors and its  
tests.  Discussion in this ticket should respond, among other things,  
to issues raised in the Perl 6 internals thread "What is intended use  
of Parrot::Distribution?" begun by Elizabeth Mattijsen on March 3  
2007:  http://www.nntp.perl.org/group/perl.perl6.internals/2007/03/ 
msg36616.html.

I have posted in that thread and will post additional notes I've made  
since then to this ticket.  But I don't yet have a particular  
approach to this refactoring for which I'm advocating.  Let's hear  
everybody's suggestions.

kid51

[perl #41693] [PATCH] STM article reference corrected

[via RT]

# New Ticket Created by  Elizabeth Mattijsen 
# Please include the string:  [perl #41693]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=41693 >


Robert Ennals' paper doesn't live at the indicated link anymore, even 
his own website now has a
dead link to that location.  Found the article somewhere else and 
refer to that location now.

Liz

stm_internals.patch
Description: Binary data

[perl #41693] [PATCH] STM article reference corrected

[Bob Rogers]

   From: Elizabeth Mattijsen (via RT) <[EMAIL PROTECTED]>
   Date: Sun, 04 Mar 2007 05:15:43 -0800

   # New Ticket Created by  Elizabeth Mattijsen 
   # Please include the string:  [perl #41693]
   # in the subject line of all future correspondence about this issue. 
   # http://rt.perl.org/rt3/Ticket/Display.html?id=41693 >


   Robert Ennals' paper doesn't live at the indicated link anymore, even 
   his own website now has a
   dead link to that location.  Found the article somewhere else and 
   refer to that location now.

   Liz

Committed; thank you!

-- Bob Rogers
   http://rgrjr.dyndns.org/

Re: AIX 5.3

[jerry gay]

On 3/3/07, Theodore Katseres <[EMAIL PROTECTED]> wrote:

I managed to get parrot to build on aix-ppc-gcc4.0.0
smoked too ;)


indeed, wonderful news. is this something that can be set up more
regularly so we can track portability there?

also, i can't seem to find the smoke results at
http://smoke.parrotcode.org/smoke. am i missing something or did the
smoke results fail to submit correctly? i'd like to update PLATFORMS
with this valuable info. patches to PLATFORMS and pointers to smoke
results most welcome.

~jerry

Re: [perl #41602] [TODO] MS VS 2005 deprecates strdup

[Klaas-Jan Stol]

[EMAIL PROTECTED] via RT wrote:

Hi,

Applied in 17281, thanks.

For your question, strdup is fine since these are not garbage
collectable strings (STRING*), just normal C char*'s. There is loads of
them used in IMCC. Unfortunately though, there is an issue in that we
don't free a load of 'em, or at least hadn't used to and I doubt that's
been fixed. So that may hurt us with eval'd code in the future...

Jonathan
  

hi,
I still get the warning. On further inspection the file I added through 
the patch (win32/string.h) is not added. The
#define of strdup as _strdup is in there. So, in order to resolve this 
issue, the file should be added. (it's included in the original patch)


regards,
kjs

Re: for ... else

[Andy Armstrong]

On 3 Mar 2007, at 00:39, Thomas Wittek wrote:
I'd like the For::Else behaviour more. Especially as I remember  
numerous
times writing an if clause to check if a list is empty before  
processing it.


That's crazy. If the list is empty foreach still does the right thing  
- there's no benefit in guarding a foreach with a conditional.



I don't remember many cases where I wrote something like this:

  my $found;
  foreach my $item (@items) {
if ($item = 'foobar') {
  $found = 1;
  last;
}
  }
  unless ($found) {
..
  }


I'd say that or a close variation of it was a pretty common idiom.

--
Andy Armstrong, hexten.net

Re: [perl #41619] [PATCH] add add_attr, rem_attr, and rem_attr_str vtable methods

[Alek Storm]

For the same reason we have set_attr, set_attr_str, get_attr, and
get_attr_str, even though they're only used by ParrotObject - it allows for
multiple, concurrent object systems.  This goal is mentioned in PDD 15, in
"What The Bytecode Sees".  Why tie programmers into the default way of doing
things?  In Smalltalk, objects and classes work very differently, to the
point where I have a wrapper object around every class.  It would be a whole
lot easier if I could define my own class implementation.

On 3/2/07, Allison Randal <[EMAIL PROTECTED]> wrote:


Alek Storm (via RT) wrote:
>
> This patch adds the add_attr, rem_attr, and rem_attr_str vtable
> methods.  These will come in handy for Ruby's metaclasses or
> Smalltalk's class objects.  The only PMC currently affected by this is
> ParrotClass, and the rem_attr and rem_attr_str methods are still
> unimplemented.

It's more of a design question than a code question. Why make add_attr,
rem_attr, and rem_attr_str vtable methods rather than simply methods on
the Class class (the metaclass)? They only affect ParrotClass, which
means we're defining vtable entries for functionality that will be used
by one PMC type.

Allison

Re: [perl #41583] Tail calls from within vtable methods broken

[Alek Storm]

I'm almost done with a different patch that preserves the parent context for
the purpose of returning values into it.  All further tailcalled contexts
are freed as normal.  That's pretty vague, but it's easier just to see the
code.  I just haven't had time to finish and release it.

Thanks,
Alek Storm

On 3/4/07, Jonathan Worthington <[EMAIL PROTECTED]> wrote:


Bram Geron (via RT) wrote:
> Tail calls from within v-table methods are broken, the tail-called sub
> (or method) will not return correct values.
>
> When method A tailcalls sub B, B's set_returns stores its opcode
> number (and with it, which registers should be returned), but the
> low-level vtable code gets the registers from A's context.
> (Runops_args stores a pointer to A's context just before it is called,
> wrongly assuming A has the final set_returns. Runops_args returns the
> context to a function that then does return value passing on it.)
>
> Maybe the solution is to store the current context in a new field in
> the interp structure; I don't know, I'm rather bad at C.
>
> Example:
> This should print 2, but it prints 13.
>
>
The problem is that when we make a call over the C boundary (e.g. call
back into PIR), we do that by getting the invoke v-table method of the
sub PMC to create the context etc. for the call for us, and then capture
that context. We then return that context after the sub has executed,
and in theory can get the parameters from it.

Enter tail calls. The assumption that the context of the sub we called
is the context with the results we want in it is now invalid, since a
tailcall now replaces the context. That means we end up holding a
reference to a freed context (essentially, freed memory!)

My attempt at fixing this is to construct a fake context for the sub we
call to set_returns into. Even if it does a tail call, then it will
still end up putting the return values there - it's just normal calling
semantics.

Happily, the attached patch makes your program work. Unfortunately, it
breaks other stuff and I'm having a hard time seeing why right now. The
breakage includes PGE. So something I've done is quite wrong somehow,
but I'm not sure where. So I'm throwing the patch out on the list in
hope someone may stop something stupid I've done. Perhaps someone who's
more familiar with the whole contexts thing than I.

Thanks,

Jonathan



Index: src/ops/core.ops
===
--- src/ops/core.ops(revision 17321)
+++ src/ops/core.ops(working copy)
@@ -564,14 +564,9 @@
 ctx = CONTEXT(interp->ctx);
 ccont = ctx->current_cont;

-if (PMC_cont(ccont)->address) {
-/* else it's from runops_fromc */
+/* If we have a context to put the return values in... */
+if (PMC_cont(ccont)->to_ctx) {
 parrot_context_t * const caller_ctx = PMC_cont(ccont)->to_ctx;
-if (! caller_ctx) {
-/* there is no point calling real_exception here, because
-   PDB_backtrace can't deal with a missing to_ctx either. */
-internal_exception(1, "No caller_ctx for continuation %p.",
ccont);
-}

 src_indexes = interp->current_returns;
 dest_indexes = caller_ctx->current_results;
@@ -581,6 +576,13 @@

 parrot_pass_args(interp, ctx, caller_ctx, src_indexes,
dest_indexes, PARROT_PASS_RESULTS);
 }
+else if (!PMC_cont(ccont)->address) {
+/* Problem - we have a return bytecode address, but no context!
There
+ * is no point calling real_exception here, because PDB_backtrace
+ * can't deal with a missing to_ctx either. */
+internal_exception(1, "No caller_ctx for continuation %p.",
ccont);
+}
+
 argc = SIG_ELEMS(signature);
 goto OFFSET(argc + 2);
}
Index: src/inter_run.c
===
--- src/inter_run.c (revision 17321)
+++ src/inter_run.c (working copy)
@@ -29,6 +29,7 @@
runops(Interp *interp, size_t offset)>

Run parrot ops. Set exception handler and/or resume after exception.
+This is the low level run ops routine that just takes an offset.

=cut

@@ -156,18 +157,74 @@
 opcode_t offset, *dest;
 parrot_context_t *ctx;
 parrot_context_t *old_ctx;
+INTVAL *fake_context_registers;
+opcode_t fake_return_bytecode[1] = { 0 };
+int i;
+
 /*
  * FIXME argument count limited - check strlen of sig
  */
 char new_sig[10];
 const char *sig_p;

+/* Set the object we're calling with, if any. */
+interp->current_object = obj;
+
+/* We set up a new return continuation with a NULL address, so we
will
+ * eventually fall back out of the runloop to here. */
 old_ctx = CONTEXT(interp->ctx);
-interp->current_cont  = new_ret_continuation_pmc(interp, NULL);
-interp->current_object = obj;
+interp->current_cont = new_ret_continuation_pmc(interp, NULL);
+
+/* We may need to capture the return values too. We set up a fake
register
+   

Re: [perl #41364] [PATCH] Fixed object vtable method overrides in PIR

[Alek Storm]

That's because the patch refers to a function that is now outdated because
of #41549.  I've attached an updated version of the patch.

Thanks,
Alek Storm

On 3/2/07, [EMAIL PROTECTED] via RT <[EMAIL PROTECTED]> wrote:


On Sun Feb 25 20:10:00 2007, [EMAIL PROTECTED] wrote:
> Now that 0.4.9 has been released, can this be committed?
>
I just tried, but I get:

/home/default/jnthn.net/dev/parrot/blib/lib/libparrot.so: undefined
reference to `find_vtable_meth'
collect2: ld returned 1 exit status

After applying it. Any ideas?

Jonathan

Weekly Perl 6 mailing list summary for 18-24 March, 2007

[Ann Barcomb]

 This week on the Perl 6 mailing lists

"'Course, if someone goes ahead and adds the Y combinator, one must
naturally begin to wonder what the YY combinator would be... :-) "

-- Larry Wall

"Obviously it generates a function so anonymous that it can't even
refer to itself. I call it the depressed existentialist solipsist
operator."

-- chromatic, in 'Y not '


 Language

  Y not 

Larry Wall announced the demise of ` ?? `, which was not much lamented.
Thomas Wittek suggested calling it `zip` and there was some discussion
of whether it is better to use terms like `minmax` and `zip`, or to
use symbols like `MM` and `ZZ`. Several jokes were made along the way.

  [svn:perl6-synopsis] r13699 - doc/trunk/design/syn 

A commit by Larry Wall replaced ?? is replaced by Z. There was also a
change with the `XX` operator, which became `X`.

  Relief for rw/ro 

Steve Lukas remarked that Larry Wall had asked for ideas about good
names for various states of write access. He offered a proposal which
involves indicating that the writeability can be described as
variable, constant, or final. Dr. Ruud added a brief comment about the
length of the term `variable`, which he didn't find to be too long.

  [svn:perl6-synopsis] r13703 - doc/trunk/design/syn 

A commit from Larry Wall clarified that a named argument may name
either a label or a variable.

Blair Sutton asked if the synopsis repository is publicly available,
and if it is part of the Parrot or Pugs repository. The URL of the
repository  was posted.

 Parrot Porters

  [perl #29994] [BUG] "loadlib $P0, varname" not working correctly
  

Some time ago, in ticket [perl #29994] , Jens
Rieks reported an error in `imcc/parser_util.c`. Klaas-Jan Stol
updated the ticket and noted that the loadlib op works on windows.
However, another error was found: when loading a non-existent library,
no exception is raised.

  [perl #41235] [PATCH] Add get_name() Method to Namespaces
  

Earlier, chromatic created a patch for `get_name`, which Jerry Gay
forwarded to RT to create ticket [perl #41235] .
Jerry wanted to apply the patch before 0.4.8, but chromatic said that
he had been waiting because Allison Randal wanted a deprecation cycle
for the rename of `name()` to `get_name()`. Allison replied that she
had made a note that it was deprecated (r17030) and said that the
patch could be applied after the release.

  [perl #41237] [TODO] PMC Class name IDs will require a dot in front
  

Klaas-Jan Stol reminded people that an issue had not been decided.

Earlier, Jerry Gay created ticket [perl #41237] 
to address an item in DEPRECATED.pod about PMC Class name IDs. He felt
that either it should use one syntax or the other, but not both.

Allison Randal preferred eliminating the dot in classname IDs. Matt
Diephouse, on the other hand, liked the dot. Klaas-Jan Stol added that
the dot indicates that it is PIR not pure PASM.

Allison thought that if Matt used it to disambiguate between types and
local variables, it was a matter of sigils. She asked why put sigils
on types instead of putting them in variables, and if a dot was the
ideal sigil for types.

  [perl #41529] [BUG]: t/perl/Parrot_Distribution.t test failure
  

In ticket [perl #41529] , James Keenan reported
that there was a new failure in `Parrot_Distribution.t`. Jerry Gay
explained that the test exposes a bug in Parrot::Distribution, which
classifies files as Perl even when they are not. He noted that failing
tests had been used as a reminder of things which needed to be fixed,
and this was still used to some extent, although there was a movement
towards RT.

The problem was resolved in r17069.

There was some discussion about the difficulty of identifying the
problem. Jerry Gay mentioned that he was working on refactoring
Parrot::Distribution.

  in PIR, a BigInt is turning into a string against my will -- what am I
  doing wrong? 

Eric Hanchrow reported a problem in r16999. Patrick R. Michaud offered
some suggestions for correcting the code in question.

  [PATCH] #39615: [TODO] get_outer op not defined in PDDs
  

Klaas-Jan Stol submitted a patch which adds the description of
`get_outer()` to PDD20.

  [PATCH] updates for docs/faq.pod 

Klaas-Jan Stol made some updates to `faq.pod` which related to ticket
[perl #41312] .

  :anon flag bug? 

Klaas-Jan Stol had a question relating to a fix for [perl #39

Re: for ... else

[Steve Lukas]

I vote against this proposal.

More exceptional rules in a language are bad in itself. 
Those exceptions force people to more to learn more stuff
and lead to confusion for those who don't know every detail 
of this language. So, there should be an important reason 
for that or it's a silly idea.

I think your proposal is conflicting with the common meaning 
of 'else' and I fear that this would discourage many 
professional programmers that are used to other languages, 
to give perl6 a try. In other words: Features are good but 
breaking conventions is bad.

On the other hand, there is no important reason for it because C<

for @rray -> $el {}
if ! @rray {}

>
should work. It's short and easy to understand. 
So, I think there is no problem at all with the 
currently specced syntax.

Kind Regards
 Stefan



 
-
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.

Re: for ... else

[Daniel Brockman]

What about this?

   given @foo {
 for $_ -> $x { ... }
 when .empty { ... }
   }

You can reverse the order if you want:

   given @foo {
 when .empty { ... }
 for $_ -> $x { ... }
   }

I don't like C<$_>, but I can't think of a way to get rid of it.

-- 
Daniel Brockman <[EMAIL PROTECTED]>

Re: for ... else

[Jonathan Lang]

Daniel Brockman wrote:

What about this?

   given @foo {
 for $_ -> $x { ... }
 when .empty { ... }
   }

You can reverse the order if you want:

   given @foo {
 when .empty { ... }
 for $_ -> $x { ... }
   }


Actually, you'd be better off using the second order; the "when"
statement would drop you out of the "given" block if triggered, and
you'd never get to the loop.  In the first order, you'd be triggering
both the loop and the "when" every time the "given" block executes.

--
Jonathan "Dataweaver" Lang

Re: for ... else

[Smylers]

Andy Armstrong writes:

> On 3 Mar 2007, at 00:39, Thomas Wittek wrote:
> 
> > I'd like the For::Else behaviour more. Especially as I remember
> > numerous times writing an if clause to check if a list is empty
> > before  processing it.
> 
> That's crazy. If the list is empty foreach still does the right thing  
> - there's no benefit in guarding a foreach with a conditional.

The purpose of the C test is not to guard the loop but to attach an
C clause to (hence the above mention of C), so that
some code can be run only in the case where the list is empty.

I have many times wanted this: either list the results or display a
message saying that there aren't any results; process each invoice, or
throw an error complaining there aren't any invoices.

Oooh, "or", now there's an idea.  In Perl 6 the return value of C
is the list of values that successfully completed an iteration.  In the
case of their not being any items in the list to start with that will be
an empty list, which is false.  So I think this will work:

  for @invoice
  {
.process;
  } or fail 'No invoices to process';

> > I don't remember many cases where I wrote something like this:
> > 
> >  my $found;
> >  foreach my $item (@items) {
> >if ($item = 'foobar') {
> >  $found = 1;
> >  last;
> >}
> >  }
> >  unless ($found) {
> >..
> >  }
> 
> I'd say that or a close variation of it was a pretty common idiom.

I've many times wanted a better way of doing that too.  Basically you
want an C to attach to the C but only be activated if none of
the.  Larry's suggestion of using C for this looks good.

Smylers

[perl #41695] [CAGE]: Refactor Parrot::Distribution

[James Keenan via RT]

Here are some notes which I have made which may prove useful in the
refactoring of Parrot::Distribution.  I hope that I have grepped and
acked accurately, but I'm not guaranteeing 100% accuracy.

kid51


NAME
Parrot::Distribution refactoring notes

ANALYSIS OF PACKAGE
* used by:

* packages:

* Parrot::Docs::POD2HTML
* Parrot::Docs::Section::C
* Parrot::Docs::Section::Compilers
* Parrot::Docs::Section::Config
* Parrot::Docs::Section::Parrot
* Parrot::Docs::Section::PMCs

* tests:

* t/codingstd/c_code_coda.t
* t/codingstd/c_indent.t
* t/codingstd/c_parens.t
* t/codingstd/c_struct.t
* t/codingstd/cppcomments.t
* t/codingstd/cuddled_else.t
* t/codingstd/fixme.t
* t/codingstd/perlcritic.t
* t/codingstd/tabs.t
* t/codingstd/trailing_space.t
* t/distro/manifest_skip.t
* t/perl/Parrot_Distribution.t

* tools

* tools/dev/gen_manifest_skip.pl

ANALYSIS OF PACKAGES IN INHERITANCE TREE
  Parrot::Docs::Directory
* inherits from:

* Parrot::IO::Directory

* uses:

* Parrot::Docs::File
There are no current calls to this package. It's only mentioned
inside the currently unused file_class() subroutine.

* used by:

* packages:

* Parrot::Distribution
* Parrot::Docs::Item
* Parrot::Docs::Section

* tests:

* t/perl/Parrot_Distribution.t
* t/perl/Parrot_Docs.t

* tools

* tools/docs/pod_errors.pl

* comments:

*   Has two apparently unused subroutines: file_class() and
directory_class(). These are not methods, are not listed in any
@EXPORT (there is none), and are not called elsewhere within the
package. Why retain them?

*   Has no constructor of its own, so it must use
Parrot::IO::Directory (or one of that package's ancestors).

*   Has only one method: files_of_type(), which takes one argument.
This method calls methods from other packages, including:

* files()
* is_of_type()
* directories()
* name()
* directories()
* files_of_type()

  Parrot::Docs::File
* inherits from:

* Parrot::IO::File

* uses:

* Pod::Simple::Checker
One fully qualified call to Pod::Simple::Checker::new inside
check_pod().

* Parrot::Docs::POD2HTML
One fully qualified call to Parrot::Docs::POD2HTML::new inside
pod_as_html().

* methods:

* type_for_suffix()
* type_for_name()
* type()
* is_of_type()
* check_pod()
* contains_pod()
* num_pod_errors()
* pod_errors()
* pod_as_html()
* is_docs_link()
* title()
* short_description()

* used by

* packages:

* Parrot::Docs::Directory

* tests:

* t/perl/Parrot_Docs.t

  Parrot::Docs::POD2HTML
* inherits from:

* Pod::Simple::HTML

* uses:

* Parrot::Docs::HTMLPage
One fully qualified call to each of
Parrot::Docs::HTMLPage::header and ::footer.

* methods:

* type_for_suffix()
* type_for_name()
* type()
* is_of_type()
* check_pod()
* contains_pod()
* num_pod_errors()
* pod_errors()
* pod_as_html()
* is_docs_link()
* title()
* short_description()

* used by:

* packages:

* Parrot::Docs::File
* Parrot::Docs::HTMLPage
* Parrot::Docs::Item

* tests

* t/perl/Parrot_Docs.t

  Parrot::Docs::HTMLPage
* inherits from:
Does not inherit -- but doesn't have its own constructor, either!

* methods

* header()
* footer()

* used by:

* packages:

* Parrot::Docs::POD2HTML
* Parrot::Docs::Section

* comment
There is no current rationale for these functions to be methods.
They could simply be functions exported by this package and imported
by other packages on request.

  Parrot::IO::Directory
* inherits from:

* Parrot::IO::Path

* uses:

* Parrot::IO::File
Imports_unspecified, but file_with_class calls
Parrot::IO::File::new().

* methods:

* directory_with_path()
* file_with_path()
* tmp_directory()

* instance methods:

* create_path()
* relative_path()
* parent()
* file_and_directory_names()
* file_and_directory_paths()
* file_paths()
* directory_paths()
* file_exists_with_name()
* 

Re: [perl #41619] [PATCH] add add_attr, rem_attr, and rem_attr_str vtable methods

[Joshua Isom]

On Mar 4, 2007, at 12:40 PM, Alek Storm wrote:


For the same reason we have set_attr, set_attr_str, get_attr, and
get_attr_str, even though they're only used by ParrotObject - it 
allows for
multiple, concurrent object systems.  This goal is mentioned in PDD 
15, in
"What The Bytecode Sees".  Why tie programmers into the default way of 
doing
things?  In Smalltalk, objects and classes work very differently, to 
the
point where I have a wrapper object around every class.  It would be a 
whole

lot easier if I could define my own class implementation.


But part of the point of parrot is dynamic language interoperability.  
Will perl6 and tcl be able to use that new class implementation without 
a problem, and could you use perl6 and tcl classes and objects?  This 
of course assumes the language gets the added functionality to import 
stuff across HLL's.  There are times where different languages make 
coding different aspects of a large program easier, so people might 
want to use, say, perl for the string comparison, tcl for the gui, and 
java for communicating over the network with a binary protocol.  It's 
just a rough example, but nevertheless, that is the potential of 
parrot, without using weird embedding stuff.

Re: for ... else

[Thomas Wittek]

Steve Lukas schrieb:
> More exceptional rules in a language are bad in itself.
> Those exceptions force people to more to learn more stuff

I guess that most people would understand the for/empty(/start/end) code
without having ever written any line of Perl.
They won't understand first/Any/gather directly, I think.

> On the other hand, there is no important reason for it because C<
> 
> for @rray -> $el {}
> if ! @rray {}
> 
> should work. It's short and easy to understand. 

Agree, this looks good indeed.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: [PATCH]: tools for using Subversion branches; ops2c.pl refactored

[Sam Vilain]

James Keenan wrote:
> The patch attached is really two patches in one:
>
> 1.  A resubmission in patch form of my refactoring of tools/build/ 
> ops2c.pl into lib/Parrot/Ops2c/Utils.pm and lib/Parrot/Ops2c/ 
> Auxiliary.pm, along with a test suite in t/tools/ops2cutils/.
>
> 2.  4 new files which provide an argument for more use of Subversion  
> branches in Parrot development and some tools to make using branches  
> easier.  The files being submitted for the first time are:
>   

Why are these two changes tied together?  Surely if you have a capable
feature branching system this is not necessary.

> docs/svn_branching.pod
> lib/Parrot/Subversion/BranchManager.pm
> tools/util/svn_new_branch.pl
> tools/util/svn_synch.pl
>   

The method of tracking which branch has been merged does not follow best
practices.

Several best practices have emerged with SVN and branching, when copying
changes from one branch to another:

1. best (if the UUID matches the repository it is being stored in) -
insert a property called "svk:merge" into the merge commit which refers
to the SVN repo UUID and revision number of the other parent commit
which Subversion was incapable of representing.

2. second best - copy revisions individually from one branch to the
other, such as "svk smerge -Il" does.

3. crappy and crack fueled -the Subversion manual's recommendation that
you should note in the commit message which revisions you are "merging"
when you copy changes from one part of subversion repositories to another.

4. Option 1, except that the UUID and revision number are not related to
the repository they are being stored in, so end up having no meaning at
all (unless the repository they refer to is also published, and even
then it's not exactly turn-key to get history information)

Even looking at the tags that have recently been created nearby to your
changes it is difficult to see what value this entirely novel system adds.

Sam.

> While I'm pretty certain the first two of these four files are in the  
> correct directories, I'm less certain about the last two.  They are  
> utilities intended for use by Parrot developers but, since they're  
> not used by Configure.pl, make, or make test, they're not necessary  
> for Parrot itself.
>
> Comments?  I would particularly welcome tryouts of the two utilities  
> on Windows and Linux.
>
> kid51
>   

[svn:parrot-pdd] r17336 - trunk/docs/pdds/draft

[jonathan]

Author: jonathan
Date: Sun Mar  4 14:47:00 2007
New Revision: 17336

Modified:
   trunk/docs/pdds/draft/pdd15_objects.pod

Log:
s/variable/value/ - bob rogers++

Modified: trunk/docs/pdds/draft/pdd15_objects.pod
==
--- trunk/docs/pdds/draft/pdd15_objects.pod (original)
+++ trunk/docs/pdds/draft/pdd15_objects.pod Sun Mar  4 14:47:00 2007
@@ -15,10 +15,9 @@
 
 =head1 DEFINITIONS
 
-
 =head2 Object
 
-An object is a variable that incorporates both data and behavior
+An object is a value that incorporates both data and behavior
 related to that data.
 
 =head2 Class

Re: [PATCH]: tools for using Subversion branches; ops2c.pl refactored

[James Keenan]

On Mar 4, 2007, at 5:15 PM, Sam Vilain wrote:


James Keenan wrote:

The patch attached is really two patches in one:

1.  A resubmission in patch form of my refactoring of tools/build/
ops2c.pl into lib/Parrot/Ops2c/Utils.pm and lib/Parrot/Ops2c/
Auxiliary.pm, along with a test suite in t/tools/ops2cutils/.

2.  4 new files which provide an argument for more use of Subversion
branches in Parrot development and some tools to make using branches
easier.  The files being submitted for the first time are:



Why are these two changes tied together?  Surely if you have a capable
feature branching system this is not necessary.



I submitted individual patches and new files last week for the  
refactoring of ops2c.pl.  Following the instructions in docs/ 
submission.pod, I edited MANIFEST to include the new files and paths.


Those patches and new files haven't been reviewed yet.  When I went  
to my next round of submissions, I wanted to get it done quickly  
(I've been dealing with eye infections the last several days and am  
tiring easily) and decided to submit a single patch.  The MANIFEST  
had entries for both submissions.



docs/svn_branching.pod
lib/Parrot/Subversion/BranchManager.pm
tools/util/svn_new_branch.pl
tools/util/svn_synch.pl



The method of tracking which branch has been merged does not follow  
best

practices.

Several best practices have emerged with SVN and branching, when  
copying

changes from one branch to another:

1. best (if the UUID matches the repository it is being stored in) -
insert a property called "svk:merge" into the merge commit which  
refers

to the SVN repo UUID and revision number of the other parent commit
which Subversion was incapable of representing.

2. second best - copy revisions individually from one branch to the
other, such as "svk smerge -Il" does.

3. crappy and crack fueled -the Subversion manual's recommendation  
that
you should note in the commit message which revisions you are  
"merging"
when you copy changes from one part of subversion repositories to  
another.


4. Option 1, except that the UUID and revision number are not  
related to
the repository they are being stored in, so end up having no  
meaning at

all (unless the repository they refer to is also published, and even
then it's not exactly turn-key to get history information)

Even looking at the tags that have recently been created nearby to  
your
changes it is difficult to see what value this entirely novel  
system adds.




It's not novel with me.  I solicited advice on Perlmonks (http:// 
perlmonks.org/?node_id=597867) on how to synchronize a Subversion  
branch with trunk.  The scripts I wrote implemented one of the  
options described in that Perlmonks thread, which was provided from a  
fellow Perl hacker who has never steered me wrong.


My main point is this:  At this point in Parrot's development, a lot  
more of that development should be going on in branches rather than  
in direct commits to trunk.  People need tools to manager branches  
effectively and, AFAICT, no one else had addressed this problem.   
particle asked me to come up with something that would reflect my  
experience so far with branches and that other people would find  
useful.  The four files I've submitted represent my attempt to  
respond to particle's request.


I freely concede that what I've submitted is a hack -- and have so  
conceded in the documentation.  Perhaps what we should provide our  
fellow Parrot hackers is a menu of choices for how to manage  
branches.  If so, then instead of my suggestion of lib/Parrot/ 
Subversion/, we should have lib/Parrot/VersionControl:  a directory  
which would enable people to manage branches in the Parrot repository  
(a) in a variety of ways using Subversion as their client; and/or (b)  
using other clients such as svk.  If you would like to code up such a  
tool (either (a) or (b)), then code away!  After all, (i) these are  
just developers' tools; they're not essential to Parrot itself; (ii)  
this is Perl:  TIMTOWTDI.


If we took that approach, then we could accommodate a variety of ways  
to manage branches in our repository, all with the goal of getting  
people to develop more in branches.


Jim Keenan

Re: [PATCH]: tools for using Subversion branches; ops2c.pl refactored

[Sam Vilain]

James Keenan wrote:
>> Why are these two changes tied together?  Surely if you have a capable
>> feature branching system this is not necessary.
> I submitted individual patches and new files last week for the  
> refactoring of ops2c.pl.  Following the instructions in docs/ 
> submission.pod, I edited MANIFEST to include the new files and paths.
>
> Those patches and new files haven't been reviewed yet.  When I went  
> to my next round of submissions, I wanted to get it done quickly  
> (I've been dealing with eye infections the last several days and am  
> tiring easily) and decided to submit a single patch.  The MANIFEST  
> had entries for both submissions.
>   

Mixing things together is everything that you are attempting to resolve.
Why are you making excuses for not achieving this?

> It's not novel with me.  I solicited advice on Perlmonks (http:// 
> perlmonks.org/?node_id=597867) on how to synchronize a Subversion  
> branch with trunk.  The scripts I wrote implemented one of the  
> options described in that Perlmonks thread, which was provided from a  
> fellow Perl hacker who has never steered me wrong.
>   

Sorry. Of the four first responses to that thread, you picked the one
with the worst advice.

> My main point is this:  At this point in Parrot's development, a lot  
> more of that development should be going on in branches rather than  
> in direct commits to trunk.  People need tools to manager branches  
> effectively and, AFAICT, no one else had addressed this problem.   
> particle asked me to come up with something that would reflect my  
> experience so far with branches and that other people would find  
> useful.  The four files I've submitted represent my attempt to  
> respond to particle's request.
>
> I freely concede that what I've submitted is a hack -- and have so  
> conceded in the documentation.  Perhaps what we should provide our  
> fellow Parrot hackers is a menu of choices for how to manage  
> branches.  If so, then instead of my suggestion of lib/Parrot/ 
> Subversion/, we should have lib/Parrot/VersionControl:  a directory  
> which would enable people to manage branches in the Parrot repository  
> (a) in a variety of ways using Subversion as their client; and/or (b)  
> using other clients such as svk.  If you would like to code up such a  
> tool (either (a) or (b)), then code away!  After all, (i) these are  
> just developers' tools; they're not essential to Parrot itself; (ii)  
> this is Perl:  TIMTOWTDI.
>   

I appreciate that, but with all due respect this system is unworkable
and needs addressing - somebody would come along later, decypher the
ad-hoc system that you or your advisors have invented and convert it to
something standard.

> If we took that approach, then we could accommodate a variety of ways  
> to manage branches in our repository, all with the goal of getting  
> people to develop more in branches.
>   

I agree with this goal.

Sam.

Re: [PATCH]: tools for using Subversion branches; ops2c.pl refactored

[chromatic]

On Sunday 04 March 2007 15:41, Sam Vilain wrote:

> James Keenan wrote:

> > Those patches and new files haven't been reviewed yet.  When I went  
> > to my next round of submissions, I wanted to get it done quickly  
> > (I've been dealing with eye infections the last several days and am  
> > tiring easily) and decided to submit a single patch.  The MANIFEST  
> > had entries for both submissions.

> Mixing things together is everything that you are attempting to resolve.
> Why are you making excuses for not achieving this?

I don't think that's entirely fair.  James's experiment here is an experiment, 
and if it fails we can learn something from it.

Personally, I find that using SVK and creating local branches saves me from 
this trouble, but I have commit access to Parrot and that might not be the 
easiest solution for other people.

Perhaps an alternate solution is to document how people can create and update 
their own local branches effectively even if they don't have commit access 
(or whether they prefer SVK or Git).

-- c

Re: [PATCH]: tools for using Subversion branches; ops2c.pl refactored

[Sam Vilain]

chromatic wrote:
>> Mixing things together is everything that you are attempting to resolve.
>> Why are you making excuses for not achieving this?
>> 
>
> I don't think that's entirely fair.  James's experiment here is an 
> experiment, 
> and if it fails we can learn something from it.
>   

Yes, sorry if it wasn't clear - I commend the goal and effort but
ultimately this particular experiment should be declared a dead end.

> Personally, I find that using SVK and creating local branches saves me from 
> this trouble, but I have commit access to Parrot and that might not be the 
> easiest solution for other people.
>   

Right, and SVK tracks the merge progress with its merge tickets - so
long as you're merging between mirror paths.  Otherwise its merge
tickets refer to your local repository.

> Perhaps an alternate solution is to document how people can create and update 
> their own local branches effectively even if they don't have commit access 
> (or whether they prefer SVK or Git).
>   

For sure.

Sam.

Re: for ... else

[Smylers]

Steve Lukas writes:

> On the other hand, there is no important reason for it because C<
> 
> for @rray -> $el {}
> if ! @rray {}
> 
> >
> should work. It's short and easy to understand.

But it involves repeating C<@rray> -- which for more complex expressions
(results from function calls, delving deep into very nested data
structures, whatever) could be tedious.  Repetition is certainly poor
style and makes the code more prone to errors being introduced.

Also, it relies on the contents of C<@rray> not being cleared inside the
loop.

Smylers

Re: for ... else

[Rick Delaney]

On Mar 04 2007, Smylers wrote:
>   for @invoice
>   {
> .process;
>   } or fail 'No invoices to process';

If that actually works then I'm happy.

-- 
Rick Delaney
[EMAIL PROTECTED]

Re: for ... else

[Jonathan Lang]

Rick Delaney wrote:

Smylers wrote:
>   for @invoice
>   {
> .process;
>   } or fail 'No invoices to process';

If that actually works then I'm happy.


It's dependent on .process not returning a false on the final iteration.

--
Jonathan "Dataweaver" Lang

statement modifiers

[Jonathan Lang]

The text of S02, S03, and S04 still contain references to the
now-defunct "statement_modifier" grammatical category.

Also, what's the reasoning behind specifically disallowing _all_
statement modifiers to "do" blocks (as opposed to forbidding just
looping statement modifiers)?  Is this legacy from when the
distinction wasn't being made, or is there still a valid reason for
forbidding conditional modifiers?

Finally: when used as a statement modifier, is "given" considered to
be conditional or looping?  (Gut instinct: conditional.)

Re: for ... else

[Larry Wall]

On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: Rick Delaney wrote:
: >Smylers wrote:
: >>   for @invoice
: >>   {
: >> .process;
: >>   } or fail 'No invoices to process';
: >
: >If that actually works then I'm happy.
: 
: It's dependent on .process not returning a false on the final iteration.

Er, these days 'for' is more like 'map', and hence returns a list.
So it's dependent on at least one iteration returning a non-() value.
In fact, if the final iteration returned False, the list would be
considered true.

Larry

Re: [perl #41619] [PATCH] add add_attr, rem_attr, and rem_attr_str vtable methods

[Alek Storm]

The same questions are solved for all PMCs - the vtable provides an
abstracted interface that everyone can use seamlessly.  Because tcl
and Java use the same interface (opcodes), there's no problem.  I
honestly cannot see a difference between these and any other vtable
method.  The fact that Perl strings work differently than Python
strings is cited as one of the reasons why Parrot is so useful for
interoperating between languages, and the object system is a logical
addition to this.

In fact, these vtable methods *encourage* the use of many languages in
a single application.  For example, without these methods, programmers
have to be aware of the semantics of the Smalltalk object system and
use extra code when dealing with Smalltalk objects, breaking
abstraction.  With them, however, interoperability is complete, and
the Smalltalk object semantics are still satisfied.

Thanks,
Alek Storm

On 3/4/07, Joshua Isom <[EMAIL PROTECTED]> wrote:

On Mar 4, 2007, at 12:40 PM, Alek Storm wrote:

> For the same reason we have set_attr, set_attr_str, get_attr, and
> get_attr_str, even though they're only used by ParrotObject - it
> allows for
> multiple, concurrent object systems.  This goal is mentioned in PDD
> 15, in
> "What The Bytecode Sees".  Why tie programmers into the default way of
> doing
> things?  In Smalltalk, objects and classes work very differently, to
> the
> point where I have a wrapper object around every class.  It would be a
> whole
> lot easier if I could define my own class implementation.

But part of the point of parrot is dynamic language interoperability.
Will perl6 and tcl be able to use that new class implementation without
a problem, and could you use perl6 and tcl classes and objects?  This
of course assumes the language gets the added functionality to import
stuff across HLL's.  There are times where different languages make
coding different aspects of a large program easier, so people might
want to use, say, perl for the string comparison, tcl for the gui, and
java for communicating over the network with a binary protocol.  It's
just a rough example, but nevertheless, that is the potential of
parrot, without using weird embedding stuff.

Re: [perl #41619] [PATCH] add add_attr, rem_attr, and rem_attr_str vtable methods

[chromatic]

On Sunday 04 March 2007 19:13, Alek Storm wrote:

> In fact, these vtable methods *encourage* the use of many languages in
> a single application.  For example, without these methods, programmers
> have to be aware of the semantics of the Smalltalk object system and
> use extra code when dealing with Smalltalk objects, breaking
> abstraction.  With them, however, interoperability is complete, and
> the Smalltalk object semantics are still satisfied.

Are you intending to use these to store instance attributes?  I thought the 
point of these was to store annotations on PMCs--something very different 
from member variables.

Perhaps the discussion would be clearer if you were to sketch out the specific 
behavior you would like to enable in the HLL.

-- c

Re: [perl #41364] [PATCH] Fixed object vtable method overrides in PIR

[Alek Storm]

Just kidding!  Here's the patch, for real this time.

On 3/4/07, Alek Storm <[EMAIL PROTECTED]> wrote:

That's because the patch refers to a function that is now outdated because
of #41549.  I've attached an updated version of the patch.

Thanks,
Alek Storm

On 3/2/07, [EMAIL PROTECTED] via RT <[EMAIL PROTECTED]> wrote:
>
> On Sun Feb 25 20:10:00 2007, [EMAIL PROTECTED] wrote:
> > Now that 0.4.9 has been released, can this be committed?
> >
> I just tried, but I get:
>
> /home/default/jnthn.net/dev/parrot/blib/lib/libparrot.so: undefined
> reference to `find_vtable_meth'
> collect2: ld returned 1 exit status
>
> After applying it. Any ideas?
>
> Jonathan
>

diff -ur --exclude=.svn CREDITS CREDITS
--- CREDITS	2007-01-26 22:48:41.0 +
+++ CREDITS	2007-01-26 23:09:27.0 +
@@ -553,3 +553,7 @@
 N: Vishal Soni
 E: [EMAIL PROTECTED]
 D: Bug fixes in IMCC, ECMAScript
+
+N: Alek Storm
+E: [EMAIL PROTECTED]
+D: Fixed object vtable method overrides in PIR
diff -ur --exclude=.svn src/ops/object.ops src/ops/object.ops
--- src/ops/object.ops	2007-01-26 22:47:16.0 +
+++ src/ops/object.ops	2007-01-26 22:56:20.0 +
@@ -54,14 +54,14 @@
   object = $1;
   meth = $2;
   next = expr NEXT();
-  interp->current_object = object;
-  interp->current_cont = NEED_CONTINUATION;
-  interp->current_method = meth;
   method_pmc = VTABLE_find_method(interp, object, meth);
   if (!method_pmc) {
 real_exception(interp, next, METH_NOT_FOUND,
 "Method '%Ss' not found", meth);
   }
+  interp->current_object = object;
+  interp->current_cont = NEED_CONTINUATION;
+  interp->current_method = meth;
   dest = (opcode_t *)VTABLE_invoke(interp, method_pmc, next);
   goto ADDRESS(dest);
 }
@@ -92,14 +92,14 @@
   object = $1;
   meth = $2;
   next = expr NEXT();
-  interp->current_object = object;
-  interp->current_cont = $3;
-  interp->current_method = meth;
   method_pmc = VTABLE_find_method(interp, object, meth);
   if (!method_pmc) {
 real_exception(interp, next, METH_NOT_FOUND,
 "Method '%Ss' not found", meth);
   }
+  interp->current_object = object;
+  interp->current_cont = $3;
+  interp->current_method = meth;
   dest = (opcode_t *)VTABLE_invoke(interp, method_pmc, next);
   goto ADDRESS(dest);
 }
@@ -128,15 +128,15 @@
 
   object = $1;
   meth = $2;
-  interp->current_cont = CONTEXT(interp->ctx)->current_cont;
-  PObj_get_FLAGS(interp->current_cont) |= SUB_FLAG_TAILCALL;
-  interp->current_object = object;
-  interp->current_method = meth;
   method_pmc = VTABLE_find_method(interp, object, meth);
   if (!method_pmc) {
 real_exception(interp, next, METH_NOT_FOUND,
 "Method '%Ss' not found", meth);
   }
+  interp->current_cont = CONTEXT(interp->ctx)->current_cont;
+  PObj_get_FLAGS(interp->current_cont) |= SUB_FLAG_TAILCALL;
+  interp->current_object = object;
+  interp->current_method = meth;
   dest = (opcode_t *)VTABLE_invoke(interp, method_pmc, next);
   goto ADDRESS(dest);
 }
diff -ur --exclude=.svn src/pmc/parrotobject.pmc src/pmc/parrotobject.pmc
--- src/pmc/parrotobject.pmc	2007-01-26 22:47:23.0 +
+++ src/pmc/parrotobject.pmc	2007-01-27 11:56:15.0 +
@@ -202,39 +202,90 @@
 
 PMC* find_method(STRING* name) {
 PMC *class = VTABLE_get_class(INTERP, SELF);
-return VTABLE_find_method(INTERP, class, name);
+STRING *meth = CONST_STRING(interp, "__find_method");
+STRING *meth_v = CONST_STRING(interp, "find_method");
+PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
+if (PMC_IS_NULL(sub))
+sub = find_meth(interp, SELF, meth);
+if (PMC_IS_NULL(sub))
+return VTABLE_find_method(INTERP, class, name);
+return (PMC*) Parrot_run_meth_fromc_args(interp, sub,
+SELF, meth, "PS", name);
 }
 
 PMC* get_attr(INTVAL idx) {
-return Parrot_get_attrib_by_num(INTERP, SELF, idx);
+STRING *meth = CONST_STRING(interp, "__get_attr");
+STRING *meth_v = CONST_STRING(interp, "get_attr");
+PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
+if (PMC_IS_NULL(sub))
+sub = find_meth(interp, SELF, meth);
+if (PMC_IS_NULL(sub))
+return Parrot_get_attrib_by_num(INTERP, SELF, idx);
+return (PMC*) Parrot_run_meth_fromc_args(interp, sub,
+SELF, meth, "PI", idx);
 }
 
 PMC* get_attr_str(STRING* idx) {
-return Parrot_get_attrib_by_str(INTERP, SELF, idx);
+STRING *meth = CONST_STRING(interp, "__get_attr_str");
+STRING *meth_v = CONST_STRING(interp, "get_attr_str");
+PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
+PMC* r;
+if (PMC_IS_NULL(sub))
+sub = find_meth(interp, SELF, meth);
+if (PMC_IS_NULL(sub))
+r = Parrot_get_attrib_by_str(INTERP, SELF, idx);
+else r = (PMC*) Parrot_run_meth_fromc_args(interp, sub,
+SELF, meth, "PS", idx);
+retur

Re: [perl #41619] [PATCH] add add_attr, rem_attr, and rem_attr_str vtable methods

[Alek Storm]

Hmm, no, these deal with normal object attributes.  I believe you're
thinking of properties.  I'll put together some sketch code with what
I already have and post that.

Thanks,
Alek Storm

On 3/5/07, chromatic <[EMAIL PROTECTED]> wrote:

On Sunday 04 March 2007 19:13, Alek Storm wrote:

> In fact, these vtable methods *encourage* the use of many languages in
> a single application.  For example, without these methods, programmers
> have to be aware of the semantics of the Smalltalk object system and
> use extra code when dealing with Smalltalk objects, breaking
> abstraction.  With them, however, interoperability is complete, and
> the Smalltalk object semantics are still satisfied.

Are you intending to use these to store instance attributes?  I thought the
point of these was to store annotations on PMCs--something very different
from member variables.

Perhaps the discussion would be clearer if you were to sketch out the
specific
behavior you would like to enable in the HLL.

-- c

Compound grammar

[Jonathan Lang]

AFAICT, there's nothing in the documentation to explain how one would
define a statement or operator with syntax along the lines of "if ...
else ..." or "... ?? ... :: ..."  Admittedly, the only cases I know of
where this is still an issue are the two listed above: for statements,
all other perl 5 parallels have been replaced by the use of closure
traits; and the operator listed above is the only more-than-binary
operator that I've ever heard of which uses different delimiters.
That said, for the sake of future customization, it would be nice to
have a way to do these things.  (Or is this what macros are for?)

In the latter case, I find myself thinking about expanding on
"infix:<>" to allow for a list of tokens, much like "circumfix:<>"
does:

 infix: ($condition, $true, $false) #< $condition ?? $true :: $false >

...and I'm wondering if something like this could be done in the
former case as well:

 statement_control: ($condition, &true, &false?) #< if
$condition { ... } else { ... } >

Although this wouldn't cleanly handle an "if ... elsif ... elsif ...
else ..." statement.

--
Jonathan "Dataweaver" Lang

Re: for ... else

[Tom Lanyon]

Larry Wall wrote:

On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: Rick Delaney wrote:
: >Smylers wrote:
: >>   for @invoice
: >>   {
: >> .process;
: >>   } or fail 'No invoices to process';
: >
: >If that actually works then I'm happy.
: 
: It's dependent on .process not returning a false on the final iteration.


Er, these days 'for' is more like 'map', and hence returns a list.
So it's dependent on at least one iteration returning a non-() value.
In fact, if the final iteration returned False, the list would be
considered true.

Larry
  


The situation the thread is referring to has @invoice empty so no 
iterations are taking place and all this is a non-issue. :)


--
Tom Lanyon

Re: for ... else

[Larry Wall]

On Mon, Mar 05, 2007 at 03:56:16PM +1030, Tom Lanyon wrote:
: Larry Wall wrote:
: >On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: >: Rick Delaney wrote:
: >: >Smylers wrote:
: >: >>   for @invoice
: >: >>   {
: >: >> .process;
: >: >>   } or fail 'No invoices to process';
: >: >
: >: >If that actually works then I'm happy.
: >: 
: >: It's dependent on .process not returning a false on the final iteration.
: >
: >Er, these days 'for' is more like 'map', and hence returns a list.
: >So it's dependent on at least one iteration returning a non-() value.
: >In fact, if the final iteration returned False, the list would be
: >considered true.
: >
: >Larry
: >  
: 
: The situation the thread is referring to has @invoice empty so no 
: iterations are taking place and all this is a non-issue. :)

You would still get a false positive on a non-null list if all of
the iterations return ().

Larry

Re: statement modifiers

[Larry Wall]

On Sun, Mar 04, 2007 at 08:55:28PM -0800, Jonathan Lang wrote:
: The text of S02, S03, and S04 still contain references to the
: now-defunct "statement_modifier" grammatical category.

Yes, there are several similar issues that need to be cleared up
as soon as http://svn.pugscode.org/pugs/src/perl6/Perl-6.0.0-STD.pm
settles down.

: Also, what's the reasoning behind specifically disallowing _all_
: statement modifiers to "do" blocks (as opposed to forbidding just
: looping statement modifiers)?  Is this legacy from when the
: distinction wasn't being made, or is there still a valid reason for
: forbidding conditional modifiers?

In addition to not confusing people with differing Perl 5 semantics, it also
discourages people from violating the endweight principle.  If the front
is heavy enough to need a block, why not go ahead and use a regular if?

: Finally: when used as a statement modifier, is "given" considered to
: be conditional or looping?  (Gut instinct: conditional.)

Why does it have to be one or the other?  It's just a topicalizer.

Larry

Re: Compound grammar

[Larry Wall]

On Sun, Mar 04, 2007 at 09:25:31PM -0800, Jonathan Lang wrote:
: AFAICT, there's nothing in the documentation to explain how one would
: define a statement or operator with syntax along the lines of "if ...
: else ..." or "... ?? ... :: ..."  Admittedly, the only cases I know of
: where this is still an issue are the two listed above: for statements,
: all other perl 5 parallels have been replaced by the use of closure
: traits; and the operator listed above is the only more-than-binary
: operator that I've ever heard of which uses different delimiters.
: That said, for the sake of future customization, it would be nice to
: have a way to do these things.  (Or is this what macros are for?)
: 
: In the latter case, I find myself thinking about expanding on
: "infix:<>" to allow for a list of tokens, much like "circumfix:<>"
: does:
: 
:  infix: ($condition, $true, $false) #< $condition ?? $true :: $false 
:  >
: 
: ...and I'm wondering if something like this could be done in the
: former case as well:
: 
:  statement_control: ($condition, &true, &false?) #< if
: $condition { ... } else { ... } >
: 
: Although this wouldn't cleanly handle an "if ... elsif ... elsif ...
: else ..." statement.

Please see http://svn.pugscode.org/pugs/src/perl6/Perl-6.0.0-STD.pm for
the current definitions of those syntactic constructs.  The point of
doing grammars the way we're doing is to allow you to derive from this
grammar and override the rules as you see fit.  Macros and user-defined
are just convenient ways to define bits of grammar without actually
adding or modifying any rules, at least not overtly.

Larry

Re: Compound grammar

[Larry Wall]

On Sun, Mar 04, 2007 at 09:38:05PM -0800, Larry Wall wrote:
: grammar and override the rules as you see fit.  Macros and user-defined

s/user-defined/user-defined operators/

Larry

Re: for ... else

[Tom Lanyon]

Larry Wall wrote:

On Mon, Mar 05, 2007 at 03:56:16PM +1030, Tom Lanyon wrote:
: Larry Wall wrote:
: >On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: >: Rick Delaney wrote:
: >: >Smylers wrote:
: >: >>   for @invoice
: >: >>   {
: >: >> .process;
: >: >>   } or fail 'No invoices to process';
: >: >
: >: >If that actually works then I'm happy.
: >: 
: >: It's dependent on .process not returning a false on the final iteration.

: >
: >Er, these days 'for' is more like 'map', and hence returns a list.
: >So it's dependent on at least one iteration returning a non-() value.
: >In fact, if the final iteration returned False, the list would be
: >considered true.
: >
: >Larry
: >  
: 
: The situation the thread is referring to has @invoice empty so no 
: iterations are taking place and all this is a non-issue. :)


You would still get a false positive on a non-null list if all of
the iterations return ().

Larry
  


I stand corrected. Is there a way to avoid the false positive case?

Sounds like the following will work, but it doesn't seem 'nice'.

for @invoice
{
 .process;
 1;
} or fail 'No invoices to process';

--
Tom Lanyon

Re: statement modifiers

[Jonathan Lang]

Larry Wall wrote:

: Finally: when used as a statement modifier, is "given" considered to
: be conditional or looping?  (Gut instinct: conditional.)

Why does it have to be one or the other?  It's just a topicalizer.


One implication of replacing "statement_modifier" with
"statement_mod_cond" and "statement_mod_loop" is that every statement
modifier has to be defined as one or the other.

--
Jonathan "Dataweaver" Lang

Re: statement modifiers

[Larry Wall]

On Sun, Mar 04, 2007 at 09:44:59PM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: >: Finally: when used as a statement modifier, is "given" considered to
: >: be conditional or looping?  (Gut instinct: conditional.)
: >
: >Why does it have to be one or the other?  It's just a topicalizer.
: 
: One implication of replacing "statement_modifier" with
: "statement_mod_cond" and "statement_mod_loop" is that every statement
: modifier has to be defined as one or the other.

Ah, in that sense 'given' is currently considered a loop, and 'when'
is considered a conditional, so it's legal to say

say "halt" when 42 given $answer;

That follows from the recent decision to allow a condition inside a loop
to make it easy to write list comprehensions.  (The same decision that
turned 'for' into a map clone, by the way, and made 'if' return () when
false, at least in the absence of an 'else'.)

Larry

Re: statement modifiers

[Jonathan Lang]

Larry Wall wrote:

Jonathan Lang wrote:
: Larry Wall wrote:
: >: Finally: when used as a statement modifier, is "given" considered to
: >: be conditional or looping?  (Gut instinct: conditional.)
: >
: >Why does it have to be one or the other?  It's just a topicalizer.
:
: One implication of replacing "statement_modifier" with
: "statement_mod_cond" and "statement_mod_loop" is that every statement
: modifier has to be defined as one or the other.

Ah, in that sense 'given' is currently considered a loop, and 'when'
is considered a conditional, so it's legal to say

say "halt" when 42 given $answer;

That follows from the recent decision to allow a condition inside a loop
to make it easy to write list comprehensions.  (The same decision that
turned 'for' into a map clone, by the way, and made 'if' return () when
false, at least in the absence of an 'else'.)


Nice.  Thank you.

--
Jonathan "Dataweaver" Lang

Re: for ... else

[Larry Wall]

On Mon, Mar 05, 2007 at 04:13:16PM +1030, Tom Lanyon wrote:
: Sounds like the following will work, but it doesn't seem 'nice'.
: 
: for @invoice
: {
:  .process;
:  1;
: } or fail 'No invoices to process';

Still think if there's no invoices it logically should be tested first.
If you don't want to repeat mentioning the array, how 'bout:

@invoice or fail 'No invoices to process'
==> for @() {
.process
}

or equivalently

@invoice or fail 'No invoices to process'
==> map {
.process
}

all assuming you don't like my original

for @invoice || fail 'No invoices to process'
{
.process
}

Larry

Re: for ... else

[Tom Lanyon]

Larry Wall wrote:

Still think if there's no invoices it logically should be tested first.
If you don't want to repeat mentioning the array, how 'bout:

@invoice or fail 'No invoices to process'
==> for @() {
.process
}

or equivalently

@invoice or fail 'No invoices to process'
==> map {
.process
}

all assuming you don't like my original

for @invoice || fail 'No invoices to process'
{
.process
}

Larry
  


Ah, I missed that last one when you originally posted it.

All three of those are quite sufficient solutions in my mind.

p.s. Could the latter 'for @foo || fail { }' cause confusion with 'for 
@foo {} or fail' ?


--
Tom Lanyon