Re: mod_parrot uses string_nprintf
On Tue, 22 Apr 2008, Donald Hunter wrote: Hi, hi donald! I'm trying to build mod_parrot against Parrot 0.6.1 and have found that string_nprintf no longer exists. I see from ticket #44053 that the function was removed since it had no users. What's the preferred solution? Re-introduce string_nprintf or modify mod_parrot to use another method? hm, i thought i committed the fix for this, but apparently not. check out r334 in the mod_parrot repository. -jeff
[perl #53210] [TODO] change new_from_string to init_str
# New Ticket Created by Allison Randal
# Please include the string: [perl #53210]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53210 >
We've been kicking around the idea of removing new_from_string for a
while, but the pushback is always that it's useful to be able to create
a new PMC with some initialization data, without first creating a PMC
initializer that has to be garbage collected. So, instead of removing it
entirely, make it a standard initialization option, passing a string
argument instead of a PMC argument.
Note, this will require changes to the "new" opcode, and to the
low-level initialization functions ("pmc_new", etc). But, at least it'll
be consistent, instead of a lone crack-headed different way of
instantiating PMCs.
Allison
Re: Decrement of Numbers in Strings (Was: [svn:perl6-synopsis] r14460 - doc/trunk/design/syn)
On September 13th [EMAIL PROTECTED] committed:
> Modified: doc/trunk/design/syn/S03.pod
> ==
>
> +Perl 6 also supports C decrement with similar semantics, simply by
> +running the cycles the other direction. However, leftmost characters
> +are never removed, and the decrement fails when you reach a string like
> +"aaa" or "000".
> +
> +Increment and decrement on non- types are defined in terms of the
> +C<.succ> and C<.pred> methods on the type of object in the C
> +container.
Apologies for the delay in responding to this; however the above is
still in S03.
The algorithm for increment and decrement on strings sounds really good,
however I'm concerned that dealing with all that has made the common
case of integer decrement a little less intuitive where the integer
happens to be stored in a string, for example in this case:
perl -wle '$a = 10; $b = shift; $a--; $b--; print "$a $b"' 10
Perl 5 prints "9 9", but Perl 6 will print "9 09".
If a 'number' is read in from a file, standard input, a webpage, a
command-line argument, and possibly even a database then it's likely to
be a string to start with.
I realize there are ways to get round this, for example by declaring the
variable as numeric. But not having to worry about declaring variable
types is quite Perlish.
And the above subtlety is something I wouldn't like to have to explain
to a beginner ("The program works fine when I hardcode 10 into it, but
not when I provide 10 as input!"); treating 10 and "10" differently with
the same operator seems a little PHPish.
About C<+> S03 says:
> +Microeditorial: As with most of these operators, any coercion or type
> +mismatch is actually handled by multiple dispatch. The intent is that
> +all such variants preserve the notion of numeric addition to produce a
> +numeric result, presumably stored in suitably "large" numeric type to
> +hold the result. Do not overload the C<+> operator for other purposes,
> +such as concatenation. (And please do not overload the bitshift
> +operators to do I/O.) In general we feel it is much better for you
> +to make up a different operator than overload an existing operator for
> +"off topic" uses.
I'm wondering if something similar should apply to C<-->; that string
and numeric decrement are different, so should have different operators.
Smylers
Re: Class names are virtual
HaloO,
John M. Dlugosz wrote:
Using Dog in an expression (rather than a declaration) returns an
undefined protoobject of type Dog.
Yeah, an avatar.
But we already know that this is
supposed to work:
my ::Alias ::= Dog;
but maybe the RHS of ::= (if not :=) has its own special parsing rules.
Historical comment: I proposed to change ?? :: to ?? // and it became
?? !!. This was to reserve :: for abstraction. BTW, is :: the ASCII
circumscription of U+2237?
In the same regime I would like to snatch ::= from it's current meaning
of the compile time version of := to always mean abstraction aliasing.
Fortunately I'm also preaching the unmixability of types and values---
the "no half gods principle". This sort of preserves the idea of ::=
acting at compile time only. In particular you can't use ::= twice in a
scope with the same lhs. I.e. the single assignment principle at work.
The my in 'my ::Alias ::= Dog' looks redundant if not outright stupid.
What would 'our ::Alias ::= Dog' mean? And what's the use of 'my
::*Alias ::= Dog'? Note that there is immense power in unlimited
namespace access that must be restrictable with some form of sandboxing.
We want
I guess this we doesn't include me.
my Dog $x;
my Type $t;
Note that this means you are constraining the values of $x and $t to
the predeclared types Dog and Type respectively. This does not make $t a
type variable.
$x = Dog;
This is OK, and assigns the Dog proto to $x. This is a value
transfer. But the protoobject was in there before because this
is what the my put there. Like a dog box that already smells
like dog even when brand new.
$t = ::Dog;
This should be a syntax error, or at best the same as above under
the 'variable as view' paradigm. But it should never mean to alias
Type and Dog in the surrounding scope. This would be ::Type ::= Dog
and result in a redeclaration error of Type because the Type in
'my Type $t' was provisionally parsed as OUTER::Type.
You could never use $t in a type position anyway:
my $t $y; # syntax error
I wonder how & "variables" fare in that respect. I would expect
single assignment semantics from them as well. At least as far as
the usage as unsigiled var is concerned:
foo(); # provisionally OUTER::foo
my &foo := get_some_code_ref(); # OK?
&foo(); # sigil not optional because that violates OUTER::foo
foo(); # still OUTER::foo?
In general I expect :: and & to compete for the same slot in a
namespace's scope. But there is a sigiled slot &foo, of course.
A sigiled slot ::foo makes no sense to me.
BTW, since ::= obviously has a left and right side and it does name
binding we consequentially have lnames and rnames just as we have
lvalues and rvalues. Same with ltypes and rtypes, lkinds and rkinds
and other things.
Functions have a name and signature. The former is the nominal type
the latter the structural type. E.g.
sub trigon ( Num --> Num) {...}
sub sin (Num --> Num) does trigon {...}
sub cos (Num --> Num) does trigon {...}
sub foo (Num --> Num) {...}
Structurally they are the same. But &foo.does(trigon) is false.
OTOH, you can have
sub sin (Complex --> Complex) {...}
nominally sin, that is &sin.does(trigon) is true independent
of signature. An item variable constraint to the latter declaration
reads:
my sin:(Complex --> Complex) $sin;
That is you can bind or assign any implementation that nominally does
sin and structurally does :(Complex --> Complex). If you want to
dispatch on the signature you need sin to be a multi, of course. A
generic implementation might require its parameters to do Field[::N]
and return a Field[N], i.e. it requires Complex <: Field[Complex] and
Num <: Field[Num] in F-bounded polymorphism or CBP (constraint bounded
polymorphism) that subsumes FBP. See
Captures are also structural types. In the end this means the
Perl 6 type system is---contrary to the synopsis---structural and
nominal.
This makes more sense after reading your later message. You want
implicit generics, with the attendant specialization phase that provides
a point where these bindings can occur, rather than the virtual name
idea from the original Apocalypse.
I sort of want the functionality of a full-blown type system as part
of the runtime environment. That is there is a type computation going
on in parallel to a value computation. The meta object system is largely
part of the value system. The things the type system does at runtime is
checking assignments, checking bindings, selecting dispatch targets and
instanciating parametric types.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: Decrement of Numbers in Strings (Was: [svn:perl6-synopsis] r14460 - doc/trunk/design/syn)
HaloO,
Smylers wrote:
If a 'number' is read in from a file, standard input, a webpage, a
command-line argument, and possibly even a database then it's likely to
be a string to start with.
I realize there are ways to get round this, for example by declaring the
variable as numeric. But not having to worry about declaring variable
types is quite Perlish.
And the above subtlety is something I wouldn't like to have to explain
to a beginner ("The program works fine when I hardcode 10 into it, but
not when I provide 10 as input!"); treating 10 and "10" differently with
the same operator seems a little PHPish.
I guess we all agree that "10" ~~ Num. So this is a classical example of
a Str&Num type which should be more specific than Str and Num. Thus a
dispatch should hit a postfix:<-->:(Num Str --> Num Str) and yield the
result the Perl 5 programmer expects. The other string decrement is then
postfix:<-->:(Str where { $_ !~~ Num } --> Str). With set subtraction as
(\) this might also be postfix:<-->:(Str (\) Num --> Str). If the
programmer really wants to decrement "10" to "09" she has to cast that
to Str: ("10" as Str)--. So we have "10".HOW === Str but "10".WHAT ===
Num Str.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: use of ::?CLASS
HaloO,
I wrote:
subset Five of Int where {$_ == 5}
is the corresponding type
my Five $x; # effectively a constant
my 5$y; # syntax error or 5 in type position?
Would
my :(5) $z;
work as a type literal?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: Decrement of Numbers in Strings (Was: [svn:perl6-synopsis] r14460 - doc/trunk/design/syn)
On Wed, Apr 23, 2008 at 04:03:01PM +0100, Smylers wrote: : The algorithm for increment and decrement on strings sounds really good, : however I'm concerned that dealing with all that has made the common : case of integer decrement a little less intuitive where the integer : happens to be stored in a string, for example in this case: : :perl -wle '$a = 10; $b = shift; $a--; $b--; print "$a $b"' 10 : : Perl 5 prints "9 9", but Perl 6 will print "9 09". On the other hand, "09" has the advantage of still having the numeric value 9. But the converse is not true if the user was expecting a string decrement, since decrementing "10" in Perl 5 to get 9 is also counterintuitive if you were expecting "09". So Perl 5 just punts, which is the third option. In any case, there's always something to explain to a beginner. But I think in Perl 6 we're leaning more toward preserving information than Perl 5 did. : I'm wondering if something similar should apply to C<-->; that string : and numeric decrement are different, so should have different operators. Well, you have to strike a balance somewhere. On the one hand, as you have pointed out, the exact semantics of "predecessor" are slightly ambiguous in some cases, and type unions only sweep the problem under the rug of multiple dispatch, and you still have to teach the newbies. On the other hand, there are already arguably enough non-meta operators in standard Perl 6, and we shouldn't be looking for excuses to make new ones for operations that will seldom make a difference in practice. And Perl 6 thinks the difference between "09" and 9 is 0... :) Topping all that is that the "09" behavior can be lazily explained after the fact, while a new operator would have to be explained beforehand. Larry
[perl #53264] [PATCH] Re: [svn:parrot] r27144 - in trunk: include/parrot src src/pmc
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #53264]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53264 >
On Tue, 22 Apr 2008, [EMAIL PROTECTED] wrote:
> Log:
> [src] The PMC struct and the Stack_Chunk_t struct aren't isomorphic enough on
> non-x86 processors, so the stack chunk recycling scheme needs an explicit
> reference count rather than re-using the first int slot in the PObj union.
> This appears to fix RT #53170, reported by Seneca Cunningham.
Odd. They look pretty similar. Is this something to do with the
next_for_GC pointers?
Anyway, I had two thoughts looking at this patch:
1. Now both "Buffers" and "Stacks" have ref counts. The ref count in
the stack is an explicit member of the structure; the ref count for
"Buffers" tags along just before the buffer in memory (see the picture
in include/parrot/pobj.h). Would it make sense to make the Buffer
"refcount" explicit as well? I wonder if that would simplify some of
the header pool logic. I haven't thought deeply about this.
2. There are some casting and type-punning warnings that have, as their
ultimate cause, the STACK_DATAP() macro. Getting rid of the
type-punning warning gives rise to a cast alignment warning.
Looking up a level, the only uses for that macro are to return
Stack_Entry_t pointers. Why not be explicit about it in the definition
in include/parrot/stacks.h? The attached patch tries to do just that.
I haven't tested this, but it looks like it ought to work.
diff -r -u parrot-current/include/parrot/stacks.h
parrot-andy/include/parrot/stacks.h
--- parrot-current/include/parrot/stacks.h 2008-04-23 13:58:26.0
-0400
+++ parrot-andy/include/parrot/stacks.h 2008-04-23 16:05:48.0 -0400
@@ -34,6 +34,7 @@
union { /* force appropriate alignment of 'data'. If alignment
is necessary, assume double is good enough. 27-04-2007. */
void *data;
+Stack_Entry_t *stdata; /* Used in src/stack*.c */
#if PARROT_PTR_ALIGNMENT > 1
double d_dummy;
#endif
@@ -158,7 +159,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
PARROT_CANNOT_RETURN_NULL
-void* stack_prepare_pop(PARROT_INTERP, ARGMOD(Stack_Chunk_t **stack_p))
+Stack_Entry_t * stack_prepare_pop(PARROT_INTERP, ARGMOD(Stack_Chunk_t
**stack_p))
__attribute__nonnull__(1)
__attribute__nonnull__(2)
FUNC_MODIFIES(*stack_p);
@@ -166,7 +167,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
PARROT_CANNOT_RETURN_NULL
-void* stack_prepare_push(PARROT_INTERP, ARGMOD(Stack_Chunk_t **stack_p))
+Stack_Entry_t * stack_prepare_push(PARROT_INTERP, ARGMOD(Stack_Chunk_t
**stack_p))
__attribute__nonnull__(1)
__attribute__nonnull__(2)
FUNC_MODIFIES(*stack_p);
diff -r -u parrot-current/src/stack_common.c parrot-andy/src/stack_common.c
--- parrot-current/src/stack_common.c 2008-04-23 13:57:37.0 -0400
+++ parrot-andy/src/stack_common.c 2008-04-23 16:06:31.0 -0400
@@ -121,7 +121,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
PARROT_CANNOT_RETURN_NULL
-void*
+Stack_Entry_t *
stack_prepare_push(PARROT_INTERP, ARGMOD(Stack_Chunk_t **stack_p))
{
Stack_Chunk_t * const chunk = *stack_p;
@@ -132,7 +132,7 @@
chunk->refcount++;
-return STACK_DATAP(new_chunk);
+return new_chunk->u.stdata;
}
@@ -149,7 +149,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
PARROT_CANNOT_RETURN_NULL
-void*
+Stack_Entry_t *
stack_prepare_pop(PARROT_INTERP, ARGMOD(Stack_Chunk_t **stack_p))
{
Stack_Chunk_t * const chunk = *stack_p;
@@ -166,7 +166,7 @@
if ((*stack_p)->refcount < chunk->refcount)
(*stack_p)->refcount = chunk->refcount;
-return STACK_DATAP(chunk);
+return chunk->u.stdata;
}
/*
diff -r -u parrot-current/src/stacks.c parrot-andy/src/stacks.c
--- parrot-current/src/stacks.c 2008-04-23 13:57:38.0 -0400
+++ parrot-andy/src/stacks.c2008-04-23 15:59:28.0 -0400
@@ -60,7 +60,6 @@
mark_stack(PARROT_INTERP, ARGMOD(Stack_Chunk_t *chunk))
{
for (; ; chunk = chunk->prev) {
-void **entry_data;
Stack_Entry_t *entry;
pobject_lives(interp, (PObj *)chunk);
@@ -68,8 +67,7 @@
if (chunk == chunk->prev)
break;
-entry_data = STACK_DATAP(chunk);
-entry = (Stack_Entry_t *)entry_data;
+entry = chunk->u.stdata;
switch (entry->entry_type) {
case STACK_ENTRY_PMC:
@@ -150,7 +148,6 @@
stack_entry(PARROT_INTERP, ARGIN(Stack_Chunk_t *stack), INTVAL depth)
{
Stack_Chunk_t *chunk;
-void **entry;
size_t offset = (size_t)depth;
/* For negative depths, look from the bottom of the stack up. */
@@ -175,9 +172,7 @@
if (chunk == chunk->prev)
return NULL;
-/* this looks bad, but it avoids a type-punning warning */
-entry = STACK_DATAP(chunk);
-return (Stack_Entry_t *)e
[perl #49236] [BUG] Segfault generating config.fpmc during build
On Mon Apr 07 22:01:40 2008, coke wrote: > > > > There have been improvements to the dependencies in the past few > weeks; Can you > duplicate this error, Joseph? > Joe, does this error still persist for you? kid51
[perl #46681] [TODO] [C] Use strerror_r instead of strerror
This thread trailed off about 4 months ago. Could we get an update on its status, i.e., whether it should be applied, what OSes it's passing on, etc. Thank you very much. kid51
RT Needs Cage Tag
At ny.pm tonight, I was discussing the joys and sorrows of Parrot cage cleaning with one attendee. I just discovered that while you can search the newsgroup for the string 'cage' in a posting's subject line, there is no 'cage' tag in our RT system. So you can't construct a query string as you can for 'patch' or 'todo'. Can we remedy this? Thank you very much. kid51
Re: [perl #53082] rakudo does not use the line numbering feature of imcc. may be hllcompiler does not support it.
On Sun, Apr 20, 2008 at 12:37:32PM -0700, Jonathan Worthington via RT wrote: > Patrick R. Michaud wrote: > > Rakudo doesn't use the line numbering feature of imcc because > > the line numbering feature of imcc doesn't work. > > > > See RT#43269 - "setline is tied to PIR source". > > I wouldn't say it doesn' work per se, it just doesn't do what you want > it to do. :-) Fair enough. However, I'm in favor of Chip's remark in #40806 that says we should use setfile/setline (opcodes) for tracking HLL lines and the #line "" directive for tracking lines of PIR source. > There's something spec'd in the bytecode PDD to do what we > need for Rakudo, it's just not implemented yet. I will try and get to it > soon. That would be great. As you can tell, this is a source of great confusion for people who are writing in and developing Rakudo. Pm
Re: [perl #53082] rakudo does not use the line numbering feature of imcc. may be hllcompiler does not support it.
On Wednesday 23 April 2008 18:30:26 Patrick R. Michaud wrote: > Fair enough. However, I'm in favor of Chip's remark in #40806 that > says we should use setfile/setline (opcodes) for tracking HLL lines > and the #line "" directive for tracking lines of PIR > source. +1, as if you needed it. -- c
[perl #53270] [TODO] Rename/refactor _handle_mswin32()
# New Ticket Created by James Keenan
# Please include the string: [perl #53270]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53270 >
There are five configuration step classes where the class's runstep()
method has an internal subroutine called _handle_mswin32(). These
classes are:
config/auto//crypto.pm
config/auto//gettext.pm
config/auto//gmp.pm
config/auto//opengl.pm
config/auto//readline.pm
Attached is an example of this subroutine, in this case, from
auto::readline:
sub _handle_mswin32 {
my ($conf, $osname, $cc) = @_;
if ( $osname =~ /mswin32/i ) {
if ( $cc =~ /^gcc/i ) {
$conf->data->add( ' ', libs => '-lreadline' );
}
else {
$conf->data->add( ' ', libs => 'readline.lib' );
}
}
else {
$conf->data->add( ' ', libs => '-lreadline' );
}
return 1;
}
Since this subroutine is declared with the same structure in 5
different classes, I propose that we refactor it into a method which,
by analogy with similar subroutines, we would place in
Parrot::Configure::Step::Methods.
More importantly, I propose that this subroutine be renamed. As you
can see from the sample, its action is *not* limited to mswin32.
Rather, it behaves one way on mswin32 -- actually, two ways,
depending on gcc or not -- and a different way on all other OSes.
How about: _add_flags_to_libs()?
I'll draw up an actual patch in a day or two, but first let me ask if
this sounds like a good idea or not.
Thank you very much.
kid51
Re: [perl #53270] [TODO] Rename/refactor _handle_mswin32()
On Wed, 2008-04-23 at 18:40 -0700, James Keenan wrote:
> There are five configuration step classes where the class's runstep()
> method has an internal subroutine called _handle_mswin32(). These
> classes are:
>
> config/auto//crypto.pm
> config/auto//gettext.pm
> config/auto//gmp.pm
> config/auto//opengl.pm
> config/auto//readline.pm
> [...]
> Since this subroutine is declared with the same structure in 5
> different classes, I propose that we refactor it into a method which,
> by analogy with similar subroutines, we would place in
> Parrot::Configure::Step::Methods.
> [...]
> I'll draw up an actual patch in a day or two, but first let me ask if
> this sounds like a good idea or not.
Definitely yes. I had planned to suggest something similar myself,
before getting sidetracked by stomach flu.
Because of the very similar structure between each file, and because
they are all adding flags to the same flag group, we might want to go a
step further. It seems to me that too many hardcoded values appear in
the code blocks, when they should just be in the step's data hash, and
C be taught to extract them and do the
right thing:
sub _init {
return {
description => 'Determining if your platform supports OpenGL',
result => '',
test_file => 'config/auto/opengl/opengl.in',
headers => {
macports=> 'GL/glut.h',
fink=> 'GL/glut.h',
},
libs => {
default => '-lglut -lGLU -lGL',
mswin32_gcc => '-lglut32 -lglu32 -lopengl32',
mswin32 => 'glut.lib glu.lib gl.lib',
darwin => '-framework OpenGL -framework GLUT',
},
};
}
... or something like that. If we standardize on the naming convention
of the F path, we can drop the C key and just compute
it.
My happy place is that a library detection config step should only need
to define C<_init>, C<_evaluate_cc_run>, C<_handle_library_found>, and
the C file. An overrideable default implementation of
C in the base class should handle all the grotty repeated stuff
for you.
What think you all?
-'f
Re: RT Needs Cage Tag
On Wed, Apr 23, 2008 at 9:27 PM, James E Keenan <[EMAIL PROTECTED]> wrote: > At ny.pm tonight, I was discussing the joys and sorrows of Parrot cage > cleaning with one attendee. I just discovered that while you can search the > newsgroup for the string 'cage' in a posting's subject line, there is no > 'cage' tag in our RT system. So you can't construct a query string as you > can for 'patch' or 'todo'. > > Can we remedy this? In the advanced search setting, you can use the following search criteria: Queue = 'parrot' AND Status != 'resolved' AND Subject LIKE '[CAGE]' AND Status != 'rejected' Here's a link with those criteria. http://rt.perl.org/rt3/Search/Results.html?Page=1&Rows=100&Format='%20%20%20%3Cb%3E%3Ca%20href%3D%22%2Frt3%2FTicket%2FDisplay.html%3Fid%3D__id__%22%3E__id__%3C%2Fa%3E%3C%2Fb%3E%2FTITLE%3A%23'%2C%0A'%3Cb%3E%3Ca%20href%3D%22%2Frt3%2FTicket%2FDisplay.html%3Fid%3D__id__%22%3E__Subject__%3C%2Fa%3E%3C%2Fb%3E%2FTITLE%3ASubject'%2C%0A'__Status__'%2C%0A'__QueueName__'%2C%0A'__OwnerName__'%2C%0A'__Priority__'%2C%0A'__NEWLINE__'%2C%0A''%2C%0A'%3Csmall%3E__Requestors__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__CreatedRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__ToldRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__LastUpdatedRelative__%3C%2Fsmall%3E'%2C%0A'%3Csmall%3E__TimeLeft__%3C%2Fsmall%3E'&Query=%20Queue%20%3D%20'parrot'%20AND%20Status%20!%3D%20'resolved'%20AND%20Subject%20LIKE%20'%5BCAGE%5D'%20AND%20Status%20!%3D%20'rejected'&Order=ASC%7CASC%7CASC%7CASC&OrderBy=id%7C%7C%7C > Thank you very much. > kid51 > > -- Will "Coke" Coleda
r27153 removes user stack ops
Based on Tuesday's #parrotsketch discussion, r27153 eliminates the user stack opcodes from Parrot. DEPRECATED.pod showed that this would occur after the 0.7.0 release, but given discussions and changes relating to the other stacks it was decided that this could probably take place now. The following opcodes are now gone: save restore lookback entrytype depth rotate_up I've also updated NEWS. Problem reports, questions, comments invited! Pm
Re: Decrement of Numbers in Strings (Was: [svn:perl6-synopsis] r14460 - doc/trunk/design/syn)
On Mittwoch, 23. April 2008, Larry Wall wrote:
> On Wed, Apr 23, 2008 at 04:03:01PM +0100, Smylers wrote:
> : The algorithm for increment and decrement on strings sounds really good,
> : however I'm concerned that dealing with all that has made the common
> : case of integer decrement a little less intuitive where the integer
> : happens to be stored in a string, for example in this case:
> :
> :perl -wle '$a = 10; $b = shift; $a--; $b--; print "$a $b"' 10
> :
> : Perl 5 prints "9 9", but Perl 6 will print "9 09".
>
> On the other hand, "09" has the advantage of still having the numeric
> value 9. But the converse is not true if the user was expecting a
> string decrement, since decrementing "10" in Perl 5 to get 9 is also
> counterintuitive if you were expecting "09". So Perl 5 just punts,
> which is the third option. In any case, there's always something
> to explain to a beginner. But I think in Perl 6 we're leaning more
> toward preserving information than Perl 5 did.
But that doesn't really work for loops.
Imagine (excuse my perl5)
$a = "100";
$a-- for(1 .. 40);
So ($a eq "060")?
Then you'll have the problem that this gets (or might get) interpreted as
octal somewhere; if not in perl6 directly (because of different base
specifications), you're likely to get problems when passing that to other
programs, eg. via system().
I think that's a can of work, and I'd be +1 on TSa:
> If the programmer really wants to decrement "10" to "09" she has
> to cast that to Str: ("10" as Str)--. So we have "10".HOW === Str
> but "10".WHAT === Num Str.
Regards,
Phil
Re: Decrement of Numbers in Strings (Was: [svn:perl6-synopsis] r14460 - doc/trunk/design/syn)
On Thu, Apr 24, 2008 at 1:20 AM, Ph. Marek <[EMAIL PROTECTED]> wrote:
> On Mittwoch, 23. April 2008, Larry Wall wrote:
> > On Wed, Apr 23, 2008 at 04:03:01PM +0100, Smylers wrote:
> > : The algorithm for increment and decrement on strings sounds really good,
> > : however I'm concerned that dealing with all that has made the common
> > : case of integer decrement a little less intuitive where the integer
> > : happens to be stored in a string, for example in this case:
> > :
> > :perl -wle '$a = 10; $b = shift; $a--; $b--; print "$a $b"' 10
> > :
> > : Perl 5 prints "9 9", but Perl 6 will print "9 09".
> >
> > On the other hand, "09" has the advantage of still having the numeric
> > value 9. But the converse is not true if the user was expecting a
> > string decrement, since decrementing "10" in Perl 5 to get 9 is also
> > counterintuitive if you were expecting "09". So Perl 5 just punts,
> > which is the third option. In any case, there's always something
> > to explain to a beginner. But I think in Perl 6 we're leaning more
> > toward preserving information than Perl 5 did.
> But that doesn't really work for loops.
>
> Imagine (excuse my perl5)
> $a = "100";
> $a-- for(1 .. 40);
>
> So ($a eq "060")?
> Then you'll have the problem that this gets (or might get) interpreted as
> octal somewhere; if not in perl6 directly (because of different base
> specifications), you're likely to get problems when passing that to other
> programs, eg. via system().
snip
If you are certain to want a number then you either need to say
$a = +("100");
or use +($a) when passing it.
--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.
[perl #52842] [CORE] Remove stack.ops and user_stack
As of r27155 the user_stack data structure has been removed from the core. After removing stack.ops, the constants STACK_ENTRY_INT, STACK_ENTRY_FLOAT, STACK_ENTRY_STRING, and STACK_ENTRY_POINTER aren't used anywhere outside of src/stacks.c . Shall we remove them? After that, we should be able to close this ticket. Pm
