String Literals, take 3
This revision should be much more thorough and consistant compared to
the last 2, and also incorporates all of the major rulings handed down
by Larry in the last few days.
Remaining Issues:
- Default Object Stringification
(I'd say that defining custom stringification should go in the OO
section, even if only so we can procrastinate it and move on to
Apoc 3 soon ;)
- Reference Stringification
- Semantics for \c[]
- Default values for hash and array stringification.
- Names for hash and array stringification properties.
Joseph F. Ryan
[EMAIL PROTECTED]
=pod
=head1 Strings
A literal string is formed when text is enclosed by a quoting
operator; there are two types: interpolating and non-interpolating.
Interpolating constructs insert (interpolate) the value of an
expression into the string in place of themselves. The simplest
examples of the two types of quoting operators are strings delimited
by double (interpolating) and single (non-interpolating) quotes.
Certain characters, known as meta characters, have special
meaning within a literal string. The most basic of these is the
backslash (C<\>), it is special in both interpolated and
non-interpolated strings. The backslash makes ordinary characters
special and special characters ordinary. Non-interpolated strings
only have two meta characters, the backslash itself and the character
that is being used as the delimiter. Interpolated strings have many
more meta characters, see the section on Escaped characters below.
The most basic expression that may be interpolated is a scalar
variable. In non-interpolating constructs, a variable name that
appears within the string is used as-is. For example:
'The quick brown $animal'
"The quick brown $animal"
In the first string, perl will take each character in the first string
literally and perform no special processing. However, the value of the
variable $animal is inserted into the second string string in place of
the text $animal. If $animal had had the value "fox", then the second
string would have become "The quick brown fox".
More on the various quoting operators below.
=head2 Non-Interpolating Constructs
Non-Interpolating constructs are strings in which expressions do not
interpolate or expand. The exception to this rule is that the
backslash character, \, will escape the character that immediately
follows it.
The base form for a non-interpolating string is the single-quoted
string: 'string'. However, non-interpolating strings can also be formed
with the q[] operator. The q[] operator allows strings to be made with
any non-space, non-letter, non-digit character as the delimeter instead
of '. In addition, if the starting delimeter is a part of a paired
set, such as [, <, or {, then the closing delimeter may be the
matching member of the set. In addition, the reverse holds true;
delimeters which are the tail end of a pair may use the starting item
as the closing delimeter.
Examples:
$string = 'string' # $string = 'string'
$string = q|string| # $string = 'string'
$string = q{string} # $string = 'string'
$string = q]string[ # $string = 'string'
There are a few special cases for delimeters; specifically :, ( and #.
: is not allowed because it might be used by custom-defined quoting
operators to apply a attribute. ( is not allowed because it is used to
pass arguments to attributes. Finally, # is allowed, but there cannot
be a space between the operator and the #.
=head3 Embedding Interpolated Strings
It is also possible to embed an interpolating string within a non-
interpolating string by the use of the \qq[] construct. A string
inside a \qq[] constructs acts exactly as if it were an interpolated
string. Note that any end-brackets, "]", must be escaped within the
the \qq[] construct so that the parser can read it correctly.
Examples ( assuming C<< $var="two" >> ):
$string = 'one \qq{$var} three'# $string = 'one two three'
$string = 'one\qq{ {$var\} }three' # $string = 'one {two} three'
=head3 <<>>; expanding a string as a list.
A set of braces is a special op that evaluates into the list of words
contained, using whitespace as the delimeter. It is similar to qw[]
from perl5, and can be thought of as roughly equivalent to:
C<< "STRING".split(' ') >>
Examples:
@array = ; # @array = ('one', 'two', 'three');
@array = three>; # @array = ('one', '<>', 'three');
=head2 Interpolating Constructs
Interpolating constructs are another form of string in which certain
expressions that are embedded into the string are expanded into their
value at runtime. Interpolated strings are formed using the double
quote: "string". In addition, qq[] is a synonym for "", similarly to
q[] being a synoynm for ''. The rules for interpolation are as
follows:
=head3 Interpolation Rules
=over 3
=item Scalars: C<"$scalar">, C<"$(expression)">
Non-Reference scalars will simply interpolate as their value. $[]
forces its expression into scalar context, which is then handle
RE: seperate() and/or Array.cull
Michael G Schwern:
# You can do it with a map without much trouble:
#
# my @indexes = map { /condition/ ? $i++ : () } @stuff;
Unless I'm mistaken, that won't work, since $i only gets incremented on
matches. I think this:
my @indexes = map { $i++; /condition/ ? $i : () } @stuff;
Will work fine, though.
Or, in the spirit of use-a-foreach-like-a-for (and my favorite WTDI):
my @indexes = grep { $stuff[$_] =~ /condition/ } 0..$#stuff;
As you might guess, I'm a (not very vocal) proponent of adding a way to
get at a foreach's (or map's or grep's) current index. (Hmm, can this
be done with XS? Must research...)
# Its so rare that you work by array index in Perl. Usually
# things flow together element by element. Sort of like how
Funny, I tend to find myself working by-element fairly often, usually
when I have to remove elements in the middle of a loop--something Perl
doesn't like. :^( (Not that I don't understand *why* Perl doesn't
allow it--just that it can be an inconvenience.)
# you rarely handle strings character by character which can
# severely confuse C programmers.
Well, that's a silly way of working anyway. ;^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
For's parallel iteration (was Re: seperate() and/or Array.cull)
> From: "Brent Dax" <[EMAIL PROTECTED]>
> Date: Thu, 5 Dec 2002 00:28:52 -0800
>
> Michael G Schwern:
> # You can do it with a map without much trouble:
> #
> # my @indexes = map { /condition/ ? $i++ : () } @stuff;
>
> Unless I'm mistaken, that won't work, since $i only gets incremented on
> matches. I think this:
>
> my @indexes = map { $i++; /condition/ ? $i : () } @stuff;
>
> Will work fine, though.
> Or, in the spirit of use-a-foreach-like-a-for (and my favorite WTDI):
>
> my @indexes = grep { $stuff[$_] =~ /condition/ } 0..$#stuff;
Fantastic! One that doesn't use a variable temporary variable. We
all write too quickly to catch errors like the one above. Except
yours seems to be clean. Anyway---back to relevant topics.
> As you might guess, I'm a (not very vocal) proponent of adding a way to
> get at a foreach's (or map's or grep's) current index. (Hmm, can this
> be done with XS? Must research...)
In Perl 5 that would be nice. In Perl 6 though, it is not necessary:
for zip(@array, 0..Inf) -> $v, $c {
...
}
That parallel iteration is just getting more and more useful (although
this is a particularly ancient case). We've already been through A4,
but the idea of C has changed since then (I think). I don't like
C as a name for such a thing.
for interleave(@array, 0..Inf) {...}
Too long.
for slice (@array, 0..Inf) {...}
for collate (@array, 0..Inf) {...}
for parallel(@array, 0..Inf) {...}
for braid (@array, 0..Inf) {...}
for thread (@array, 0..Inf) {...}
for weave (@array, 0..Inf) {...}
The sequential list generator would almost certainly be C, if we
need one at all.
for @array {...}
for each @array: {...}
for each(@array, @barry) {...}
for @array, @barry {...} # Is this legal?
That last one might iterate through the arrays themselves, not their
elements, which would be useful on the blue moon nights. ??
Or is it still:
for @array ; 0..Inf -> $v ; $c { ... }
I hope not.
Not to delay the next Apocalypse, or anything <:(
Luke
Re: String Literals, take 3
The content looks great. I have a few grammatical suggestions, but nothing
serious...feel free to ignore.
> =pod
>
> =head1 Strings
>
> A literal string is formed when text is enclosed by a quoting
> operator; there are two types: interpolating and non-interpolating.
Kinda confusing. How about:
quoting operator. There are two types of quoting operators: interpolating
and non-interpolating.
> Interpolating constructs insert (interpolate) the value of an
> expression into the string in place of themselves.
Themselves refer to the constructs. How about:
Interpolating constructs insert, or interpolate, the value of an
expression into the string in place of the evaluated expression.
> The most basic expression that may be interpolated is a scalar
> variable. In non-interpolating constructs, a variable name that
> appears within the string is used as-is. For example:
>
>'The quick brown $animal'
>"The quick brown $animal"
>
> In the first string, perl will take each character in the first string
> literally and perform no special processing.
take is confusing...implies removal to me. How about
In the first string, perl treats each character literally resulting in no
special processing.
> However, the value of the
> variable $animal is inserted into the second string string in place of
> the text $animal. If $animal had had the value "fox", then the second
> string would have become "The quick brown fox".
Use has instead of had had.
Also: second string would be
> More on the various quoting operators below.
>
> =head2 Non-Interpolating Constructs
>
> Non-Interpolating constructs are strings in which expressions do not
> interpolate or expand.
Non-interpolating constructs are strings that do not interpolate or expand
expressions.
> The exception to this rule is that the
> backslash character, \, will escape the character that immediately
> follows it.
What about \ qq...is that an exception as well or just a different rule?
> The base form for a non-interpolating string is the single-quoted
> string: 'string'. However, non-interpolating strings can also be formed
Additionally instead of However
> with the q[] operator. The q[] operator allows strings to be made with
> any non-space, non-letter, non-digit character as the delimeter instead
> of '.
The q[] operator allows strings to be delimited by any non-space,
non-letter,
non-digit character instead of the single quote character (').
> In addition, if the starting delimeter is a part of a paired
> set, such as [, <, or {, then the closing delimeter may be the
> matching member of the set. In addition, the reverse holds true;
s/In addition/Furthermore/
> delimeters which are the tail end of a pair may use the starting item
> as the closing delimeter.
> There are a few special cases for delimeters; specifically :, ( and #.
> : is not allowed because it might be used by custom-defined quoting
> operators to apply a attribute.
: is not allowed because it is used to apply attributes to custom-defined
quoting operators.
( is not allowed because it is used to
> pass arguments to attributes. Finally, # is allowed, but there cannot
> be a space between the operator and the #.
> =head3 Embedding Interpolated Strings
I don't think this belongs here. You haven't talked about interpolated
strings, yet you
are going to talk about embedding them. I would move this to after the
interpolated string section.
> It is also possible to embed an interpolating string within a non-
> interpolating string by the use of the \qq[] construct.
s/the use of/using/
> A string
> inside a \qq[] constructs acts exactly as if it were an interpolated
s/constructs/construct/
> string. Note that any end-brackets, "]", must be escaped within the
> the \qq[] construct so that the parser can read it correctly.
Note that an end-bracket, ], must be escaped within the \qq[] construct.
This
allows the parser to correctly parse the construct.
> A set of braces is a special op that evaluates into the list of words
> contained, using whitespace as the delimeter. It is similar to qw[]
s/whitespace/a space character/ ??? I'm not sure on this, but whitespace is
pretty vague.
> =head2 Interpolating Constructs
>
> Interpolating constructs are another form of string in which certain
> expressions that are embedded into the string are expanded into their
> value at runtime.
Interpolating constructs expand certain embedded expressions into their
runtime values.
> Interpolated strings are formed using the double
> quote: "string". In addition, qq[] is a synonym for "", similarly to
> q[] being a synoynm for ''. The rules for interpolation are as
> follows:
The rules for interpolation follow.
> =item Scalars: C<"$scalar">, C<"$(expression)">
> Non-Reference scalars will simply interpolate as their value. $[]
s/simply//
> forces its expression into scalar context, which is then handled as
> either a scalar or a reference, depending on how expression evaluates.
s/,whi
Re: String Literals, take 3
One final change to my own fix:
> > with the q[] operator. The q[] operator allows strings to be made with
> > any non-space, non-letter, non-digit character as the delimeter instead
> > of '.
>
> The q[] operator allows strings to be delimited by any non-space,
> non-letter,
> non-digit character instead of the single quote character (').
s/ instead of the single quote character (')//
Re: [perl #18856] [PATCH] imcc: namespaces, minor fixes
On Dec-04, Leopold Toetsch wrote: > Steve Fink (via RT) wrote: > > >so that I can just use 'rx_pos' within my (possibly nested) namespace. > > > >So that's what this patch implements. A .local > >directive now creates a variable named :: > >(or just at the top level), > > Looks ok too. If no one hollers, I'll apply it. > > I don't know, if your are speaking of the current rx.c or a new regex > implementation, but the current "stateless" approach has some drawbacks: > it leaks memory (bitmap) and isn't reentrant (intstack). > There should probably be some regex PMC that can store the state of a regex. I don't use either one. For character classes, I use inclusion/exclusion lists. Maybe someday I'll add bitmaps as an optimization, but they're very charset-specific and I doubt they gain much speed over a JITted inclusion/exclusion search. For the things that the intstack could be used for, I use an IntList PMC. And the rest of the state that the regex state object was maintaining is kept in a combination of IntList PMCs, integer registers, and a string register. Different registers are used for each regex, so it is properly reentrant (and it relies on IMCC for register allocation, so it doesn't waste them either.) I don't use any of the rx_* ops at all. The engine I'm referring to is the one checked into languages/regex, although at the moment it may not work straight out of there (try a 'make test'). I'll do a commit of stuff that works with perl6 soon, now that the necessary IMCC changes are in (thanks). But the regex compiler is the same one that's been there since August; it just isn't used in anything, so is easily overlooked. :-)
[CVS ci] defined & exists keyed ops
I have checked in some missing core ops: - defined keyed - exists keyed + corrections in classes to make it work and some tests. leo
Re: [perl #18856] [PATCH] imcc: namespaces, minor fixes
Steve Fink wrote: On Dec-04, Leopold Toetsch wrote: The engine I'm referring to is the one checked into languages/regex, although at the moment it may not work straight out of there (try a 'make test'). Ah yes - works fine. Thanks for your explanation leo
[perl #18892] Perl_Parse from JNI Native code crashing...
# New Ticket Created by Tapas Samanta # Please include the string: [perl #18892] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18892 > Dear Parrot! I am building a JAPI for a perl aplication here. While calling the Perl_parse from the Native code.. the 'xs_init' is invoked successfully, but the programm is crashing while the Dynaloader is called within xs_init. I am using perl5.6.1 and J2SE ver 1.4.1 under Red Hat Linux 7.2 platform. I have searched a lot on the net but couldn't find any solution. Could you please help me out? It seems there is a collision in modifying the VM's environment variables. from Perl. How to solve it? with regards Tapas Samanta CERN, GENEVA
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On 12/04/2002 3:21 PM, Larry Wall wrote:
On Wed, Dec 04, 2002 at 11:38:35AM -0800, Michael Lazzaro wrote:
: We still need to verify whether we can have, in qq strings:
:
:\033 - octal (p5; deprecated but allowed in p6?)
I think it's disallowed.
Thank the many gods ... or One True God, or Larry, or whatever your
personal preference may be. ("So have a merry Christmas, Happy Hanukah,
Kwazy Kwanzaa, a tip-top Tet, and a solemn, dignified Ramadan.")
\0o33 - octal
\0x1b - hex
\0d123 - decimal
\0b1001- binary
\x and \o are then just shortcuts.
Can we please also have \0 as a shortcut for \0x0?
\c[^H], for instance. We can overload the \c notation to our heart's
desire, as long as we don't conflict with its use for named characters:
\c[GREEK CAPITAL LETTER OMEGA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI]
Very Cool. (BTW, for those that don't follow Unicode, this means that
everything matching /^[^A-Z ]$/ is fair game for us; Unicode limits
charachter names to that to minimize chicken-and-egg problems. We
/probably/ shouldn't take anything in /^[A-Za-z ]$/, to allow people to
say the much more readable "\c[Greek Capital Letter Omega with Pepperoni
and Pineapple]".
: There is also the question of what the bracketed format does. "Wide"
: chars, e.g. for Unicode, seem appropriate only in hex. But it would
: seem useful to allow a bracketed form for the others that prevents
: ambiguities:
:
:"\o164" ne "\o{16}4"
:"\d100" ne "\d{10}0"
:
: Whether that means you can actually specify wide chars in \o, \d, and
: \b or it's just a disambiguification of the Latin-1 case is open to
: question.
There ain't no such thing as a "wide" character. \xff is exactly
the same character as \x[ff].
Which means that the only way to get a string with a literal 0xFF byte
in it is with qq:u1[\xFF]? (Larry, I don't know that this has been
mentioned before: is that right?) chr:u1(0xFF) might do it too, but
we're getting ahead of ourselves.
Also, an annoying corner case: is "\0x1ff" eq "\0x[1f]f", or is it eq
"\0x[1ff]"? What about other bases? Is "\0x1x" eq "\0x[1]", or is it
eq "\0x[1x]" (IE illegal). (Now that I put those three questions
together, the only reasonable answer seems to be that the number ends in
the last place it's valid to end if you don't use explicit brackets.)
(BTW, in HTML and XML, numeric character escapes are decimal by default,
you have to add a # for hex. In windows and several other OSes (I
think, I like to play with Unicode but have little actual use for it),
ALT-0nnn is spelt in decimal only. Decimal Unicode ordnals are
fundimently flawed (since blocks are always on nice even hex numbers,
but ugly decimal ones), but useful anyway).
-=- James Mastros
Re: purge: opposite of grep
[EMAIL PROTECTED] (Miko O'Sullivan) writes: > FWIW, I came up with "purge" because my first inclination was to spell > "grep" backwards: "perg". :-) For reference, Ruby uses .detect and .reject. -- 3rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped
In defense of zero-indexed arrays.
I'm going to ask something that's probably going to launch off into a long, silly thread. But I'm really curious what the results will be so I'll ask it anyway. Think of it as an experiment. So here's your essay topic: Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 will benefit most users. Do not invoke legacy. [1] [1] ie. "because that's how most other languages do it" or "everyone is used to it by now" are not valid arguments. Ask any Pascal programmer. :) -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Follow me to certain death! http://www.unamerican.com/
Re: In defense of zero-indexed arrays.
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Thu, 5 Dec 2002 02:45:39 -0800 > From: Michael G Schwern <[EMAIL PROTECTED]> > Content-Disposition: inline > Sender: Michael G Schwern <[EMAIL PROTECTED]> > X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ > > I'm going to ask something that's probably going to launch off into a long, > silly thread. But I'm really curious what the results will be so I'll ask > it anyway. Think of it as an experiment. > > So here's your essay topic: > > Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 > will benefit most users. Do not invoke legacy. [1] Through years of experience: "Because it's cleaner that way." from 1:A Z ↓ ↓ +--+--+--+--+--+ $x: | "1" | "2" | "3" | "4" | "5" | | | | | | | +--+--+--+--+--+ ↑ ↑↑ ↑ from 0: a by z They're just different ways of thinking. If you start from 1, you're talking about the elements themselves; operations are [i,j] (inclusive). If you start from 0, you're talking about the positions between elements; operations are [i,j) (inclusive, exclusive). Say you have $x as above, and you wish to partition it into two strings "12" and "345". In the "1" paradigm: $part = 3; $first = substr $x, 1, $part-1; $last = substr $x, $part, 5; In the "0": $part = 2; $first = substr $x, 0, $part; $last = substr $x, $part, 5; In the former, you can call $part 2 if you want; it's equally as ugly. I'm having flashbacks to my QBASIC days, where anything that manipulated arrays seemed to be flooded with +1 and -1 in that way. They say C has off by one errors, they have not tried BASIC. I know this wasn't a strong argument, but in summary, most algorithms are more elegant when working with spaces between elements than with the indices of the elements themselves. And it only makes sense to number them from zero then (otherwise you get length+1 as the end, which doesn't make any sense). Luke
Re: In defense of zero-indexed arrays.
On Thu 05 Dec, Michael G Schwern wrote: > So here's your essay topic: > > Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 > will benefit most users. Do not invoke legacy. [1] > > [1] ie. "because that's how most other languages do it" or "everyone is > used to it by now" are not valid arguments. Ask any Pascal programmer. :) Many years ago I was involved with a project where all the software people reffered to the hardware as planes 0 and 1 (it was a duplicated system) and the hardware people always used 1 and 2. To avoid confusion we settled on using 0 and 2. Any way of indexing arrays has its proponents. Perl currently has the heavily depreciated $[ to allow playing with this base, changing it has nasty affects at a distance. Long long ago some computer languages did base their arrays at 1 rather than 0. Hopefully they are dead now - it led to confusion and bad practices. But that is a legacy argument. There was an argument when computer languages were close to the hardware, when to index an array you added the index (multiplied by the size of the element) to the base of the array to find what you wanted. This is probably insignificant and not an issue today. To conclude other than a very large legacy argument, there is probably no strong reason to base arrays at 0 rather than 1. I would not want to change. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Subroutine IMC example with problem
Below you will find a simple Jako program along with the IMC code the
Jako compiler generates. The IMC compiler generates the following error:
error:imcc:iANY file sub.imc line 36: op not found 'set_ic_ic'
(set<2>)
on the first ".arg x" instance in the .imc file. I'm not sure why that
line of code
makes imcc want to have a set_ic_ic op (although I do wonder if has
something
to do with the fact that we have a global ".local x" and a ".param x" for
the sub
we are calling)...
Regards,
-- Gregor
#
# sub.jako
#
# A program to demonstrate macros and poor-man's subroutine
# calls.
#
# Copyright (C) 2001-2003 Gregor N. Purdy. All rights reserved.
# This program is free software. It is subject to the same
# license as Perl itself.
#
# $Id: sub.jako,v 1.3 2002/12/05 04:07:26 gregor Exp $
#
var int x;
sub printit (int x) {
print("$x\n");
}
x = 42;
printit(x);
x = 1234;
printit(x);
cut here: sub.imc follows
--
###
# This Parrot intermediate code file was produced by the Jako compiler. #
# Initial comments from the source code are reproduced below.#
###
.sub __ANON_BLOCK__0
#
# sub.jako
#
# A program to demonstrate macros and poor-man's subroutine
# calls.
#
# Copyright (C) 2001-2003 Gregor N. Purdy. All rights reserved.
# This program is free software. It is subject to the same
# license as Perl itself.
#
# $Id: sub.jako,v 1.3 2002/12/05 04:07:26 gregor Exp $
#
.local int x # var int x;
printit_BEFORE: branch __ANON_BLOCK__1 # sub printit (int
x) {
.end
.sub _printit
printit_ENTER:
# var int x;
.param int x # (argument x)
print""# print(...);
printx
print"\n"
printit_LEAVE: ret# }
printit_AFTER: noop
.end
.sub __ANON_BLOCK__1
set x, 42 # x = 42
.arg x # printit(...);
call _printit
set x, 1234 # x = 1234
.arg x # printit(...);
call _printit
end
.end
[perl #18897] Error running Configure.pl
# New Ticket Created by "Venables, Robin" # Please include the string: [perl #18897] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18897 > Hi I'm trying to make Parrot 0.0.8.1 on AIX 4.3.3. When I run 'perl Configure.pl' I get the following output: $ perl Configure.pl Parrot Version 0.0.8 Configure 2.0 Copyright (C) 2001-2002 Yet Another Society Hello, I'm Configure. My job is to poke and prod your system to figure out how to build Parrot. The process is completely automated, unless you passed in the `--ask' flag on the command line, in which case it'll prompt you for a few pieces of info. Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST...done. Setting up Configure's data structures...done. Checking for --miniparrot...done. Loading platform hints file...(no hints) done. Enabling debugging...(none requested) done. Determining what C compiler and linker to use...done. Determining what types Parrot should use...done. Determining what opcode files should be compiled in...done. Setting up experimental systems...done. Determining what pmc files should be compiled in...done. Determining your minimum pointer alignment...Can't determine alignment! $ When I compile the test script, I get the following output: $ cd config/auto/alignptrs $ cp test_c.in robin.c $ cc -o robin robin.c $ for i in 64 32 16 8 4 2 1 > do > ./robin $i > done 64 OK 32 OK 16 OK 8 OK 4 OK 2 OK 1 OK $ Any suggestions? Robin Robin Venables Senior Systems Administrator Midrange Services Aquila Networks Services "You must always strive to be the best, but you must never believe that you are" Juan-Manuel Fangio Internet communications are not secure and therefore Aquila Networks does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Aquila Networks unless otherwise specifically stated. Confidentiality: This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, use of this information (including disclosure, copying or distribution) may be unlawful. Please notify [EMAIL PROTECTED] and delete the message immediately. Security: Internet e-mail is not a 100% secure communications medium. Viruses: This e-mail (and any attachments) has been checked (using Sophos Sweep 3.63 + patches) and found to be clean from any virus infection before leaving. Therefore neither Aquila Networks Services Ltd nor Midlands Electricity plc or any of their group undertakings (as defined by the Companies Act 1989) (together referred to as the "Companies") accept legal responsibility for this message or liability for the consequences of any computer viruses which may have been transmitted by this e-mail. Monitoring: All electronic communications with the Companies may be monitored in accordance with the UK Regulation of Investigatory Powers Act, Lawful Business Practice Regulations, 2000. If you do not consent to such monitoring, you should contact the sender of this e-mail. Aquila Networks Services Limited, Registered office: Whittington Hall, Whittington, Worcester, WR5 2RB Registered in England and Wales number 3600545 This e-mail may be sent on behalf of any of the Companies.
Re: String Literals, take 3
On Thu, Dec 05, 2002 at 02:59:32AM -0500, Joseph F. Ryan wrote:
> In the first string, perl will take each character in the first string
> literally and perform no special processing. However, the value of the
> variable $animal is inserted into the second string string in place of
> the text $animal. If $animal had had the value "fox", then the second
> string would have become "The quick brown fox".
One of these 'in the first string's is surplus to requirements. I'd
suggest getting rid of the first one. Getting rid of either works,
having them both doesn't.
> More on the various quoting operators below.
>
> =head2 Non-Interpolating Constructs
>
> Non-Interpolating constructs are strings in which expressions do not
> interpolate or expand. The exception to this rule is that the
> backslash character, \, will escape the character that immediately
> follows it.
I don't think this is right. A single backslash which is not followed
by the current quoting delimiter, or the characters q[ or q[[ is not
special. It will not escape the following character, it just appears in
the string. How about this:
Non-Interpolating constructs are strings in which expressions do not
interpolate or expand. The exception to this rule is the backslash
character C<\>. Most of the time it will just appear in the
non-interpolating string as is. However, it also allows you to include
the current quoting delimiter or a section which does interpolate in
the non-interpolating string.
> The base form for a non-interpolating string is the single-quoted
> string: 'string'. However, non-interpolating strings can also be
> formed with the q[] operator. The q[] operator allows strings to be
> made with any non-space, non-letter, non-digit character as the
> delimiter instead of '. In addition, if the starting delimiter is a
> part of a paired set, such as [, <, or {, then the closing delimiter
> may be the matching member of the set. In addition, the reverse holds
> true; delimiters which are the tail end of a pair may use the starting
> item as the closing delimiter.
>
> Examples:
>
>$string = 'string' # $string = 'string'
>$string = q|string| # $string = 'string'
>$string = q{string} # $string = 'string'
>$string = q]string[ # $string = 'string'
>
> There are a few special cases for delimiters; specifically :, ( and #.
>: is not allowed because it might be used by custom-defined quoting
> operators to apply a attribute. ( is not allowed because it is used to
> pass arguments to attributes. Finally, # is allowed, but there cannot
> be a space between the operator and the #.
If you're going to change that section above, then you should include
something here about escaping the current string delimiter.
As mentioned previously, it is possible to include the character you
have chosen as the delimiter by preceding it with a C<\>. For
instance:
'This string\'s delimiter is \'.'
q|This string's delimiter is \|.|
Most of the time it's probably better just to use a different
delimiter.
> A set of braces is a special op that evaluates into the list of words
I think it would be better to use the word operator rather than op here,
this makes me think <<>> is in the SAS or is a Green Beret or something
;-)
> =head2 Interpolating Constructs
>
> Interpolating constructs are another form of string in which certain
> expressions that are embedded into the string are expanded into their
> value at runtime. Interpolated strings are formed using the double
> quote: "string". In addition, qq[] is a synonym for "", similarly to
> q[] being a synonym for ''. The rules for interpolation are as
> follows:
I think this is backwards qq[] is the general form and "" is the special
case synonym.
> =item Escaped Characters
> # Basically the same as Perl5; also, how are locale semantics handled?
>
>\ttab
>\nnewline
>\rreturn
>\fform feed
>\bbackspace
We might be losing this one, in favour of \c[^H].
>\aalarm (bell)
>\eescape
>\0b10binary char
>\o33octal char
>\0o33octal char
>\x33hex char
>\0x1bhex char
>\0x[263a]wide form
>\c[expr]Named Unicode Character or special notation
>
> =item Modifiers: C<\Q[]>, C<\L[]>, C<\U[]>
>
> Modifiers apply a modification to text which they enclose; they can be
> embedded within interpolated strings.
>
>\lLowercase the following character.
>\uUppercase the following character.
>\L[]Lowercase all characters within brackets
>\U[]Uppercase all characters within brackets
>\Q[]Escape all non-alphanumerics within
>brackets (except "}")
>
> =back
>
> =head3 Embedding non-interpolated constructs: C<\q[]>
>
> It is possible to embed a non-interpolated string within an
> interpolated string usin
Re: String Literals, take 3
Joseph F. Ryan writes:
>
> The base form for a non-interpolating string is the single-quoted
> string: 'string'. However, non-interpolating strings can also be formed
> with the q[] operator. The q[] operator allows strings to be made with
Ithink it's actually opposite:
The basic ( user extensible ) form of quoting is q[ ] or qq[ ] and so
on with the sintactic sugar of freedom to choose delimiters AND
special syntacric sugar for q//='' qq//="" qw//=<> ( and qx//=`` )
> any non-space, non-letter, non-digit character as the delimeter instead
> of '. In addition, if the starting delimeter is a part of a paired
> set, such as [, <, or {, then the closing delimeter may be the
.
>
> =head2 Interpolating Constructs
>
> Interpolating constructs are another form of string in which certain
> expressions that are embedded into the string are expanded into their
> value at runtime. Interpolated strings are formed using the double
I think runtime/compile time is decided not by interpolating construct
but by the surrounding expression .
probably I can force interpolation at compile time by something
like
BEGIN{
my $line = "aaa" ;
my $a = "$line\n" ;
}
or
my $line ::= "aaa" ;
my $a ::= "$line\n" ;
by the way , what happens here ???
my $line = "aaa" ;
my $a ::= "$line\n" ;
in other words , what happens if the interpolation is forced at
compile time while not all variables inside are defined at compile
time ?
> quote: "string". In addition, qq[] is a synonym for "", similarly to
> q[] being a synoynm for ''. The rules for interpolation are as
> follows:
>
> =head3 Interpolation Rules
arcadi
Re: String Literals, take 2
Larry Wall wrote: On Mon, Dec 02, 2002 at 04:42:52PM -0500, Joseph F. Ryan wrote: [...] : As far as I know, *nothing* is special in a single quoted heredoc. Here docs is where you *most* want the \qq[] ability. It is assumed that the sequence "\qq[" will not occur by accident very often in the typical single-quoted string. For this we VMS Perlers offer many thanks... brad
Re: String Literals, take 3
On Thu, 5 Dec 2002 04:05:05 -0500, Tanton Gibbs wrote: > > A string inside a \qq[] construct acts exactly as if it were an > > interpolated string. Note that any end-brackets, "]", must be escaped > > within the the \qq[] construct so that the parser can read it correctly. > > Note that an end-bracket, ], must be escaped within the \qq[] construct. > This allows the parser to correctly parse the construct. Don't embedded qq[] strings obey the normal qq[] rules? That is, will all brackets need escaping, or just unbalanced brackets? I'd hope for the latter. -- Peter Haworth [EMAIL PROTECTED] "i've just returned after having no internet connection for the past 48+ hours (my isp had a router go down). christ, one more hour and i would've gone sane." -- alek benedict
Re: seperate() and/or Array.cull
Michael G Schwern writes: > I'd love to be able to do it with a grep like thing. > > (@switches, @args) = seperate /^-/, @ARGV; Yes. I've written that function in Perl 5, which isn't ideal, because you have to return array refs, not arrays. However, I don't think it should be called 'seperate'. I also don't think it should be called 'separate', because that word seems to be commonly misspelled... It's hard to come up with a good name, though. Bad ones I've thought of include: grepboth - The unpleasant name my Perl 5 implementation has split - Overloaded meaning -- but we could perhaps get away with scalar-split and array-split being different characterize - Or do I mean 'characterise'? partition classify - These are the two I dislike least >@switches = @ARGV.cull /^-/; > > Array.cull would remove and return a list of every element in @ARGV which > matched. I'm not so fond of that -- I don't think it's as obvious that you're doing a two-way classification. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
RE: seperate() and/or Array.cull
Aaron Crane:
> However, I don't think it should be called 'seperate'. I also don't think
> it should be called 'separate', because that word seems to be commonly
> misspelled...
That seems like an excellent argument for calling it 'separate'. Perhaps it
will be the first of many spelling-improving keywords, enforced by syntax
highlighting of course.
Philip
Disclaimer
This communication together with any attachments transmitted with it ('this E-mail')
is intended only for the use of the addressee and may contain information which is
privileged and confidential. If the reader of this E-mail is not the intended
recipient or the employee or agent responsible for delivering it to the intended
recipient you are notified that any use of this E-mail is prohibited. Addressees
should ensure this E-mail is checked for viruses. The Carphone Warehouse Group PLC
makes no representations as regards the absence of viruses in this E-mail. If you have
received this E-mail in error please notify our ISe Response Team immediately by
telephone on + 44 (0)20 8896 5828 or via E-mail at [EMAIL PROTECTED] Please then
immediately destroy this E-mail and any copies of it.
Please feel free to visit our website:
UK
http://www.carphonewarehouse.com
Group
http://www.phonehouse.com
Re: seperate() and/or Array.cull
Michael G Schwern wrote:
> and that's just entirely too much work. I'd love to be able to do
> it with a grep like thing.
>
> (@switches, @args) = seperate /^-/, @ARGV;
>
> seperate() simply returns two lists. One of elements which match,
> one of elements which don't. I think Perl 6 will allow the above
> syntax to work rather than having to play with array refs.
>
It would be nice to make it work with more than two arrays too.
Something like this:
(@upper, @lower, @mixed) = @array.sep {
when /^[A-Z]*$/ {0}
when /^[a-z]*$/ {1}
default {2}
}
But it looks a bit dangerous, because the following won't work if
@array has numbers in it:
(@false_members, @true_members) = @array.sep { $_ }; # bad
Maybe the solution is to make it hash-wise:
%hash = @array.sep {
when /^[A-Z]*$/ {'uppercase'}
when /^[a-z]*$/ {'lowercase'}
default {'mixedcase'}
}
-angel
RE: seperate() and/or Array.cull
Angel Faus:
> Maybe the solution is to make it hash-wise:
>
> %hash = @array.sep {
> when /^[A-Z]*$/ {'uppercase'}
> when /^[a-z]*$/ {'lowercase'}
> default {'mixedcase'}
> }
I agree that general partitioning is 'better' than a fixed binary proposal,
but what is gained over the full code except a tiny bit of sugar?
for (@array)
{
when /^[A-Z]+$/ { push %hash{'uppercase'}, $_ }
when /^[a-z]+$/ { push %hash{'lowercase'}, $_ }
default { push %hash{'mixedcase'}, $_ }
}
On the other hand, perhaps binary-partitioning is sufficiently common to
warrant Schwern's abbreviated syntax:
(@switches, @args) = separate /^-/, @ARGV;
Which in full would be something like:
for (@ARGV)
{
when /^-/ { push @switches, $_ }
default { push @args, $_ }
}
Philip
Disclaimer
This communication together with any attachments transmitted with it ('this E-mail')
is intended only for the use of the addressee and may contain information which is
privileged and confidential. If the reader of this E-mail is not the intended
recipient or the employee or agent responsible for delivering it to the intended
recipient you are notified that any use of this E-mail is prohibited. Addressees
should ensure this E-mail is checked for viruses. The Carphone Warehouse Group PLC
makes no representations as regards the absence of viruses in this E-mail. If you have
received this E-mail in error please notify our ISe Response Team immediately by
telephone on + 44 (0)20 8896 5828 or via E-mail at [EMAIL PROTECTED] Please then
immediately destroy this E-mail and any copies of it.
Please feel free to visit our website:
UK
http://www.carphonewarehouse.com
Group
http://www.phonehouse.com
Re: In defense of zero-indexed arrays.
> Explain how having indexes (arrays, substr, etc...) in Perl 6 start > at 0 will benefit most users. The languages which do not start their indices at 0 are dead or dying. > Do not invoke legacy. How about FUD? :-) =Austin --- Michael G Schwern <[EMAIL PROTECTED]> wrote: > I'm going to ask something that's probably going to launch off into a > long, > silly thread. But I'm really curious what the results will be so > I'll ask > it anyway. Think of it as an experiment. > > So here's your essay topic: > > Explain how having indexes (arrays, substr, etc...) in Perl 6 start > at 0 > will benefit most users. Do not invoke legacy. [1] > > > [1] ie. "because that's how most other languages do it" or "everyone > is used > to it by now" are not valid arguments. Ask any Pascal programmer. :)
Re: String Literals, take 3
On Thu, Dec 05, 2002 at 12:27:16PM +, Andrew Wilson wrote: > On Thu, Dec 05, 2002 at 02:59:32AM -0500, Joseph F. Ryan wrote: > > Non-Interpolating constructs are strings in which expressions do not > > interpolate or expand. The exception to this rule is that the > > backslash character, \, will escape the character that immediately > > follows it. > > I don't think this is right. A single backslash which is not followed > by the current quoting delimiter, or the characters q[ or q[[ is not > special. It will not escape the following character, it just appears in > the string. How about this: Actually, I think what you just said above is better. Here's that plus my own ramblings: Non-Interpolating constructs are strings in which expressions do not interpolate or expand. The exception to this rule is the backslash character C<\>. A single backslash which is followed by the current quoting delimiter, or the characters q[ or q[[ is special (more on this below). In all other cases the backslash just means "literal next character". This is so that you can easily get a backslash within your non-interpolating strings. For instance, 'backslash (\\) \test' becomes "backslash \ test". writing is hard! :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: String Literals, take 3
On Thu, Dec 05, 2002 at 09:23:09AM -0600, Jonathan Scott Duff wrote:
> On Thu, Dec 05, 2002 at 12:27:16PM +, Andrew Wilson wrote:
> > On Thu, Dec 05, 2002 at 02:59:32AM -0500, Joseph F. Ryan wrote:
> > > Non-Interpolating constructs are strings in which expressions do not
> > > interpolate or expand. The exception to this rule is that the
> > > backslash character, \, will escape the character that immediately
> > > follows it.
> >
> > I don't think this is right. A single backslash which is not followed
> > by the current quoting delimiter, or the characters q[ or q[[ is not
> > special. It will not escape the following character, it just appears in
> > the string. How about this:
>
> Actually, I think what you just said above is better. Here's that
> plus my own ramblings:
>
> Non-Interpolating constructs are strings in which expressions do
> not interpolate or expand. The exception to this rule is the
> backslash character C<\>. A single backslash which is followed
> by the current quoting delimiter, or the characters q[ or q[[ is
> special (more on this below). In all other cases the backslash
> just means "literal next character". This is so that you can
> easily get a backslash within your non-interpolating strings.
> For instance, 'backslash (\\) \test' becomes "backslash \ test".
Except that not what it does. Try this
perl -we "print '\a'.qq{\n}"
you should get:
\a
Non-Interpolating constructs are strings in which expressions do
not interpolate or expand. The exception to this rule is the
backslash character C<\>. A single backslash which is followed by
another backslash, the current quoting delimiter, or the
characters q[ or q[[ is special (more on this below). In all
other cases the backslash just means "literal backslash". This is
so that you can easily get a backslash within your
non-interpolating strings. For instance, 'backslash (\\) \test'
becomes "backslash (\) \test".
> writing is hard! :-)
Yes it is.
andrew
--
Capricorn: (Dec. 22 - Jan. 19)
Remember: Doing the right thing is nowhere near as important as whether
others think you're cool.
msg24951/pgp0.pgp
Description: PGP signature
Re: String Literals, take 3
On Thu, Dec 05, 2002 at 03:46:25PM +, Andrew Wilson wrote: > Except that not what it does. Ah, indeed. It helps if you think and write in the same context. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: String Literals, take 3
On Thu, Dec 05, 2002 at 03:46:25PM +, Andrew Wilson wrote: >Non-Interpolating constructs are strings in which expressions do >not interpolate or expand. The exception to this rule is the >backslash character C<\>. A single backslash which is followed by >another backslash, the current quoting delimiter, or the >characters q[ or q[[ is special (more on this below). In all >other cases the backslash just means "literal backslash". This is >so that you can easily get a backslash within your >non-interpolating strings. For instance, 'backslash (\\) \test' >becomes "backslash (\) \test". s/ single// Doh! but obviously only if you decide to use this rather than the first suggestion. andrew -- Cancer: (June 22 - July 22) Though you do everything you can do to save the girl's life, the only thing you can do is juggle and do a few simple card tricks. msg24953/pgp0.pgp Description: PGP signature
Re: String Literals, take 3
Jonathan Scott Duff writes: > Non-Interpolating constructs are strings in which expressions do > not interpolate or expand. The exception to this rule is the > backslash character C<\>. A single backslash which is followed > by the current quoting delimiter, or the characters q[ or q[[ is > special (more on this below). In all other cases the backslash > just means "literal next character". This is so that you can > easily get a backslash within your non-interpolating strings. > For instance, 'backslash (\\) \test' becomes "backslash \ test". > > writing is hard! :-) > > -Scott > -- > Jonathan Scott Duff > [EMAIL PROTECTED] > > my take : non interpolating construct is a sequence of characters enclosed in delimiters for which perl switch off *any* perl-programm-like interpretation of the content. since perl have to find the end of this "I-am-not-looking" phase , the delimiter itself have to appear inside the string prefixed by backslash "\" and since now "\" itself acquire special "assignment" , if it is meant to be part of the string it have to appear backslash-prefixed "\\" itself. In principle *any* character can be backslashed *inside* the string , but only for delimiter and the backslash this is absolutely necessary. in this sence interpolated string is "language inside language" . hence : * some characters ( or words ) have to be "reserved in the inner language in order for outer language to know where the inner language text stops. * this is achieved by chosing a prefix , and any character from outer language is represented in the inner languge by the same character with prefix - two character sequance * for all *except* two characters -- the delimiter and the prefix -- we can make syntactic sugar of making the character to "mean" itself . '\ \ \h\e\l\l\o\ \ ' '\'\\\ \\\ \\\h\\\e\\\l\\\l\\\o\\\ \\\ \'' arcadi
Re: String Literals, take 3
On Thu, Dec 05, 2002 at 07:54:09PM +0200, arcadi shehter wrote: > my take : > > non interpolating construct is a sequence of characters enclosed in > delimiters for which perl switch off *any* perl-programm-like > interpretation of the content. since perl have to find the end of > this "I-am-not-looking" phase , the delimiter itself have to appear inside the > string prefixed by backslash "\" and since now "\" itself acquire > special "assignment" , if it is meant to be part of the string it have to > appear backslash-prefixed "\\" itself. In principle *any* character can be > backslashed *inside* the string , but only for delimiter and the > backslash this is absolutely necessary. > > in this sence interpolated string is "language inside language" . > hence : > * some characters ( or words ) have to be "reserved in the inner >language in order for outer language to know where the inner >language text stops. > * this is achieved by chosing a prefix , and any character from outer >language is represented in the inner languge by the same character >with prefix - two character sequance > * for all *except* two characters -- the delimiter and the prefix -- >we can make syntactic sugar of making the character to "mean" >itself . > > > > > '\ \ \h\e\l\l\o\ \ ' > > '\'\\\ \\\ \\\h\\\e\\\l\\\l\\\o\\\ \\\ \'' This is wrong. '\ \ \h\e\l\l\o\ \ ' gives you a string with nine backslashes. andrew -- Capricorn: (Dec. 22 - Jan. 19) After all is said and done, no one will have said or done anything involving you in any way. msg24955/pgp0.pgp Description: PGP signature
Re: String Literals, take 3
On Thu, Dec 05, 2002 at 05:09:35PM +, Andrew Wilson wrote: > > '\ \ \h\e\l\l\o\ \ ' > > > > '\'\\\ \\\ \\\h\\\e\\\l\\\l\\\o\\\ \\\ \'' > > This is wrong. '\ \ \h\e\l\l\o\ \ ' gives you a string with nine > backslashes. I should learn to read. What you said was right. andrew -- Virgo: (Aug. 23 - Sept. 22) Your career as a plastic surgeon is in danger of coming to a premature end this week, when you confront your arch-enemy, the dreaded Steel Surgeon. msg24956/pgp0.pgp Description: PGP signature
Re: String Literals, take 3
Hi,
Most of my nitpicks have been covered by other people :)
Joseph F. Ryan said:
> =head3 Embedding Interpolated Strings
>
> Note that any end-brackets, "]", must be escaped within the the
> \qq[] construct so that the parser can read it correctly.
This is true regardless of whether the interpolated string is embedded or
not, and so should move to the general discussion about escaping in
interpolated strings. Hmm... I guess the real issue is that the
b delimiter is the one that needs escaping, whether that's the
closing delimiter of paired delimiters (c<[> of c for example) or
unpaired delimiters (c<|> of c, or even c<"> of c<"string">) .
> =head3 <<>>; expanding a string as a list.
>
> A set of braces is a special op that evaluates into the list of words
> contained, using whitespace as the delimeter. It is similar to qw[]
> from perl5, and can be thought of as roughly equivalent to:
> C<< "STRING".split(' ') >>
Hmm... should we mention the rough equivalence, or the technically correct
equivalence (which would be c<< "STRING".split(rx/\s+/) >>). The answer
to that question is the answer to this question: what is the scope of
this document? Is it for newbies (or p5 converts) or is it a language
reference (as I read mentioned somewhere else).
> Examples:
>
> @array = ; # @array = ('one', 'two', 'three');
> @array = three>; # @array = ('one', '<>', 'three');
@array = <
a and again
before beneath beyond
>;
> =head2 Interpolating Constructs
>
> =head3 C, backticks (C<``>)
=head3 Executed Interpolated Constructs
or
=head3 Executed Constructs
> A string which is (possibly) interpolated and then executed as a system
> command with /bin/sh or its equivalent.
Strings enclosed in C and C<``> are interpolated and then executed
as a system command with /bin/sh or its equivalent. (C<``> are also
known as backticks.)
Drew
Re: String Literals, take 3
On Thursday, December 5, 2002, at 09:45 AM, Drew Folta wrote: Hmm... should we mention the rough equivalence, or the technically correct equivalence (which would be c<< "STRING".split(rx/\s+/) >>). The answer to that question is the answer to this question: what is the scope of this document? Is it for newbies (or p5 converts) or is it a language reference (as I read mentioned somewhere else). Both, of course! It's a Language Reference that's detailed and complete, but still accessible to less-experienced endusers. Not that that directly answers the question... :-) In general, thoroughness is key. I'd say that if we _know_ a formal definition, put it in (either parenthetically, or as a sub-section called 'Formal Definition of [whatnot]') -- especially if we think it will make a difference for expert users, e.g. if it's explaining some nuance that the text description isn't able to describe. We can always take it out later if we find it's annoying. But always explain it the English way first and foremost, since newbies will be reading these sections too. (We're trying to create a document that will _allow_ newbies to become language experts, if they feel so inclined.) MikeL
Re: Subroutine IMC example with problem
[EMAIL PROTECTED] wrote: error:imcc:iANY file sub.imc line 36: op not found 'set_ic_ic' 2 "mistakes" here: - branches between subs are not subject to fixup - x is not declared in here: .sub __ANON_BLOCK__1 set x, 42 # x = 42 A .sub is a unit which is parsed/compiled in one piece. As I already wrote: for your code put one .sub at the begin and one .end at the end - that's all. To see, what the parser thinks run: imcc -y x.imc 2>&1 | less leo
Curses Life
Leon Brocard sent the following bits through the ether: > Now to get the hand of the signatures... Ah, well, I gave up on SDL as it was a little complicated. Instead, I played with curses. Please find attached a cute little curses life program loading and calling curses at runtime with dlfunc. Oh, and I made the shape a small spaceship as it's more interesting. [It's a bit of the pain the way it stomps over registers all the time, though ;-] Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ 43rd Law of Computing: Anything that can go wr... # # life.pasm # # Play conway's (no, not *him*. The other conway) game # of life # # Hacked by Leon Brocard <[EMAIL PROTECTED]> to use curses loadlib P1, "libcurses.so" dlfunc P0, P1, "initscr", "i" invoke dlfunc P0, P1, "curs_set", "ii" set I5, 0 invoke # First the generation count set I2, 5000 # Note the time time N5 # If true, we don't print set I12, 0 set S0, " " set S1, " " set S2, " " set S3, " " set S4, " ** " set S5, " **" set S6, " * " set S7, " * * " set S8, " ** " set S9, " " set S10, " " set S11, " " set S12, " " set S13, " " set S14, " " set S15, "" concat S15, S0 concat S15, S1 concat S15, S2 concat S15, S3 concat S15, S4 concat S15, S5 concat S15, S6 concat S15, S7 concat S15, S8 concat S15, S9 concat S15, S10 concat S15, S11 concat S15, S12 concat S15, S13 concat S15, S14 bsr dump set I0, 0 loop: ge I0, I2, getout inc I0 mod I31,I0,100 if I31, skip skip: bsr generate bsr dump branch loop getout: dlfunc P0, P1, "curs_set", "ii" set I5, 1 invoke dlfunc P0, P1, "endwin", "i" invoke end # S15 has the incoming string, S0 is scratch, S1 is scratch, S2 is scratch # # I0 is the length of the string # I1 is the current cell we're checking # I2 is the count for that cell # I3 is the offset to the neighbor generate: pushi length I0, S15 set S1, "" set I1, 0 genloop: set I2, 0 NW: set I3, -16 add I3, I3, I0 add I3, I3, I1 mod I3, I3, I0 substr S0, S15, I3, 1 ne S0, "*", North inc I2 North: set I3, -15 add I3, I3, I0 add I3, I3, I1 mod I3, I3, I0 substr S0, S15, I3, 1 ne S0, "*", NE inc I2 NE: set I3, -14 add I3, I3, I0 add I3, I3, I1 mod I3, I3, I0 substr S0, S15, I3, 1 ne S0, "*", West inc I2 West: set I3, -1 add I3, I3, I0 add I3, I3, I1 mod I3, I3, I0 substr S0, S15, I3, 1 ne S0, "*", East inc I2 East: set I3, 1 add I3, I3, I0 add I3, I3, I1 mod I3, I3, I0 substr S0, S15, I3, 1 ne S0, "*", SW inc I2 SW: set I3, 14 add I3, I3, I0 add I3, I3, I1 mod I3, I3, I0 substr S0, S15, I3, 1 ne S0, "*", South inc I2 South: set I3, 15 add I3, I3, I0 add I3, I3, I1 mod I3, I3, I0 substr S0, S15, I3, 1 ne S0, "*", SE inc I2 SE: set I3, 16 add I3, I3, I0 add I3, I3, I1 mod I3, I3, I0 substr S0, S15, I3, 1 ne S0, "*", check inc I2 check: substr S0, S15, I1, 1 eq S0, "*", check_alive # If eq 3, put a star in else a space check_dead: eq I2, 3, star branch space check_alive: lt I2, 2, space gt I2, 3, space branch star space: concat S1, " " branch iter_done star: concat S1, "*" iter_done: inc I1 lt I1, I0, genloop done: set S15, S1 popi ret # S15 has the incoming string, S0 is scratch dump: saveall dlfunc P0, P1, "move", "iii" set I5, 0 set I6, 0 invoke restoreall if I12, dumpend save I0 save I1 saveall save I0 dlfunc P0, P1, "addstr", "it" set S5, "Generation: " invoke restore I0 dlfunc P0, P1, "addstr", "it" set S5, I0 invoke dlfunc P0, P1, "refresh", "i" invoke restoreall set I0, 0 set I1, 14 printloop: substr S0, S15, I0, 15
Re: Subroutine IMC example with problem
Leo -- Thats going to be a problem for Jako. Can't nest .sub, so I can't have a bracketing .sub for the whole script, with my real subs' .subs inside. So, I have to choose (I think) from these options in order to leverage IMCC: * Bracket with one big .sub ... .end, and don't use .sub for my real subs (yuck -- I want to use .param, .arg, etc for subs and calls) * Use the anonymous blocks to bracket all non-sub linear code in the script as I have done (yuck -- results in the problems I've reported) * Change the Jako language to require all linear code to be either before or after all the subs (yuck -- Perl doesn't force this, and I don't want to, either) * Change the Jako compiler to collect all linear code into a single segment and emit it at the end, inside .sub ... .end, with a preamble ..sub; goto __COLLECTED_LINEAR_CODE; .end at the beginning of the .imc file (yuck -- To date, the Jako compiler has gotten away with doing its job as a single pass essentially in filter mode, and I'd like to retain that feature) Given these 4 choices, I choose #5: try to change the rules of the game. :) I suggest that imcc should allow code outside .sub ... .end brackets, which should be good for Jako, Perl and other languages. I don't know how popular that will be, but it seems reasonable to me... Regards, -- Gregor Leopold Toetsch <[EMAIL PROTECTED]> 12/05/2002 11:34 AM To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject:Re: Subroutine IMC example with problem [EMAIL PROTECTED] wrote: > > error:imcc:iANY file sub.imc line 36: op not found 'set_ic_ic' 2 "mistakes" here: - branches between subs are not subject to fixup - x is not declared in here: > .sub __ANON_BLOCK__1 > set x, 42 # x = 42 A .sub is a unit which is parsed/compiled in one piece. As I already wrote: for your code put one .sub at the begin and one .end at the end - that's all. To see, what the parser thinks run: imcc -y x.imc 2>&1 | less leo
IMCC -c, logical ops
I'd been looking for an option to IMCC to generate the PBC directly,
figuring from list postings that it was there, but didn't find it (-c) until
reading the recently updated ChangeLog. It's not in the syntax message IMCC
prints (with no args or -h or bad args), probably should be added.
Any answers forthcoming to my logical ops questions ("Re: logical_not
issue", Dec 3)? (even "you're wrong and this is why..." would be fine.)
Thanks,
Dave
Isa. 40:31
Re: [perl #18897] Error running Configure.pl
At 12:54 PM + 12/5/02, "Venables, Robin" (via RT) wrote: I'm trying to make Parrot 0.0.8.1 on AIX 4.3.3. When I run 'perl Configure.pl' I get the following output: Determining your minimum pointer alignment...Can't determine alignment! Any suggestions? Can you grab the latest semi-daily snapshot from http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz and see if that works? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String Literals, take 3
Drew Folta wrote:
=head3 <<>>; expanding a string as a list.
A set of braces is a special op that evaluates into the list of words
contained, using whitespace as the delimeter. It is similar to qw[]
from perl5, and can be thought of as roughly equivalent to:
C<< "STRING".split(' ') >>
Hmm... should we mention the rough equivalence, or the technically correct
equivalence (which would be c<< "STRING".split(rx/\s+/) >>). The answer
to that question is the answer to this question: what is the scope of
this document? Is it for newbies (or p5 converts) or is it a language
reference (as I read mentioned somewhere else).
Again, C<< "STRING".split(' ') >> is different than
C<< "STRING".split(/\s+/) >>. The latter will add an empty element to
the beginning of the string if there is leading whitespace, which is
not the behaivor <<>> will have (if it acts like qw(), at any rate.)
Re: String Literals, take 3
Peter Haworth wrote:
On Thu, 5 Dec 2002 04:05:05 -0500, Tanton Gibbs wrote:
A string inside a \qq[] construct acts exactly as if it were an
interpolated string. Note that any end-brackets, "]", must be escaped
within the the \qq[] construct so that the parser can read it correctly.
Note that an end-bracket, ], must be escaped within the \qq[] construct.
This allows the parser to correctly parse the construct.
Don't embedded qq[] strings obey the normal qq[] rules? That is, will
all brackets need escaping, or just unbalanced brackets? I'd hope for
the latter.
With all of the new crazy quoting shenanagains, I'm not sure that the
"balenced brackets are fine" rule will still be possible; and thus end
delimeters will always need to be escaped. For instance, imagine
what a nightmare this would be to parse:
$var = qq[blah [\q[blah [\qq[%hash{qq[[hi]]} blah];
Sure, anyone who writes something like this deserves to be shot;
however, if the "balanced brackets are ok" rule still stands, the
above code would be legal. (And I really, really, really don't
want the above code to be legal ;)
Re: String Literals, take 3
> There are a few special cases for delimeters; specifically :, ( and #.
> : is not allowed because it might be used by custom-defined quoting
> operators to apply a attribute. ( is not allowed because it is used to
> pass arguments to attributes.
But if there is no attribute, then qw(this is not ambiguous), so why
disallow it?
> =head3 Embedding Interpolated Strings
>
> It is also possible to embed an interpolating string within a non-
> interpolating string by the use of the \qq[] construct. A string
> inside a \qq[] constructs acts exactly as if it were an interpolated
> string. Note that any end-brackets, "]", must be escaped within the
> the \qq[] construct so that the parser can read it correctly.
They only need to be escaped if they are not balanced.
perl5 -le 'print q{ q{ q{} } }'
does just what you expect it to do, and I don't think perl6 will be less
dwimmish.
> =item Default Object Stringification C<"$obj">
> # Behavior not defined
It should be defined as "whatever $obj.as_string returns".
> Also note that with single quoted here-docs, backslashes are not
> special, and are taken for a literal backslash, a behaivor that is
> different from normal single-quoted strings. However, \qq[] will
> still work.
That's self-contractidictory: "backslashes are not special" and
"\qq[] is special"
Isn't there any way to say "none of the following characters are special
until I say so" left in perl6?
~ John Williams
Re: String Literals, take 3
On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
> Peter Haworth wrote:
> >On Thu, 5 Dec 2002 04:05:05 -0500, Tanton Gibbs wrote:
> >>>A string inside a \qq[] construct acts exactly as if it were an
> >>>interpolated string. Note that any end-brackets, "]", must be escaped
> >>>within the the \qq[] construct so that the parser can read it correctly.
> >>>
> >>Note that an end-bracket, ], must be escaped within the \qq[] construct.
> >>This allows the parser to correctly parse the construct.
> >
> >Don't embedded qq[] strings obey the normal qq[] rules? That is, will
> >all brackets need escaping, or just unbalanced brackets? I'd hope for
> >the latter.
>
> With all of the new crazy quoting shenanagains, I'm not sure that the
> "balenced brackets are fine" rule will still be possible; and thus end
> delimeters will always need to be escaped. For instance, imagine
> what a nightmare this would be to parse:
>
> $var = qq[blah [\q[blah [\qq[%hash{qq[[hi]]} blah];
>
> Sure, anyone who writes something like this deserves to be shot;
> however, if the "balanced brackets are ok" rule still stands, the
> above code would be legal. (And I really, really, really don't
> want the above code to be legal ;)
Well, just don't do it then. With or without balanced brackets, the
obfuscating programmer can do the above; he just needs more or less
backslashes. '\qq[]' is the real source of evil here.
Actually the apocalypse says:
> RFC 226: Selective Interpolation in Single Quotish Context.
>
> This proposal has much going for it, but there are also difficulties,
> and I've come close to rejecting it outright simply because the
> single-quoting policy of Perl 5 has been successful.
Maybe if we pushed Larry a bit, he could reject it after all?
Personally I like 'not interpolated'_"interpolated"_'not interpolated'
much better than 'not interpolated\qq[interpolated]not interpolated'.
~ John Williams
Re: String Literals, take 3
John Williams wrote:
On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
Peter Haworth wrote:
On Thu, 5 Dec 2002 04:05:05 -0500, Tanton Gibbs wrote:
A string inside a \qq[] construct acts exactly as if it were an
interpolated string. Note that any end-brackets, "]", must be escaped
within the the \qq[] construct so that the parser can read it correctly.
Note that an end-bracket, ], must be escaped within the \qq[] construct.
This allows the parser to correctly parse the construct.
Don't embedded qq[] strings obey the normal qq[] rules? That is, will
all brackets need escaping, or just unbalanced brackets? I'd hope for
the latter.
With all of the new crazy quoting shenanagains, I'm not sure that the
"balenced brackets are fine" rule will still be possible; and thus end
delimeters will always need to be escaped. For instance, imagine
what a nightmare this would be to parse:
$var = qq[blah [\q[blah [\qq[%hash{qq[[hi]]} blah];
Sure, anyone who writes something like this deserves to be shot;
however, if the "balanced brackets are ok" rule still stands, the
above code would be legal. (And I really, really, really don't
want the above code to be legal ;)
Well, just don't do it then. With or without balanced brackets, the
obfuscating programmer can do the above; he just needs more or less
backslashes.
Saying "Just don't do it" doesn't stop someone from doing it. True,
the example was an obfuscated one, but it was to prove a point. This is
just as obfuscated in my opinion:
$var = qq[[[%hash{qq[one]}{qq[next]}],[],[%hash{qq[hi]}{qq[there]}]]];
Adding backslashes to the first example helps clear up some of the
confusion:
$var = qq[blah [\q[blah [\qq[%hash{qq[[hi\]]}]\]]\]blah];
Maybe it should be required that opening and closing delimiters should
be backslashed (even if the string can be parsed without the opening
delimiter escaped) just for legibility? Then the first example becomes
even clearer:
$var = qq[blah \[\q[blah \[\qq[%hash{qq[\[hi\]]}]\]]\]blah];
Really, I think that if you really feel the need to use a delimiter
that you know that will be in the text that you are quoting, you should
have to go through the trouble of escaping it. Its only fair :)
'\qq[]' is the real source of evil here.
Actually the apocalypse says:
RFC 226: Selective Interpolation in Single Quotish Context.
This proposal has much going for it, but there are also difficulties,
and I've come close to rejecting it outright simply because the
single-quoting policy of Perl 5 has been successful.
Maybe if we pushed Larry a bit, he could reject it after all?
Why? I love \qq[] and \q[]. I'd much rather have embedded strings
than be able to balance used delimiters inside quotes. I don't like the
"balance delimeters" rule at all, and don't see it as anything more
than an ugly hack. I'd much rather have it go than embedded strings.
Personally I like 'not interpolated'_"interpolated"_'not interpolated'
much better than 'not interpolated\qq[interpolated]not interpolated'.
What about:
q[
not-interpolated not-interpolated not-interpolated
not-interpolated \qq[interpolated] not-interpolated
not-interpolated not-interpolated \qq[interpolated]
not-interpolated not-interpolated not-interpolated
not-interpolated not-interpolated not-interpolated
\qq[interpolated] not-interpolated \qq[interpolated]
not-interpolated \qq[interpolated interpolated]
];
compared to:
q[
not-interpolated not-interpolated not-interpolated
not-interpolated ] ~ qq[interpolated] ~ q[ not-interpolated]
not-interpolated not-interpolated ] ~ qq[interpolated] ~ q[
not-interpolated not-interpolated not-interpolated
not-interpolated not-interpolated not-interpolated
] ~ qq[interpolated] ~ q[ not-interpolated ] ~ qq[interpolated] ~ q[
not-interpolated ] ~ qq[interpolated interpolated
];
Re: String Literals, take 3
On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
> John Williams wrote:
> >On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
> >>With all of the new crazy quoting shenanagains, I'm not sure that the
> >>"balenced brackets are fine" rule will still be possible; and thus end
> >>delimeters will always need to be escaped. For instance, imagine
> >>what a nightmare this would be to parse:
> >>
> >>$var = qq[blah [\q[blah [\qq[%hash{qq[[hi]]} blah];
> >>
> >>Sure, anyone who writes something like this deserves to be shot;
> >>however, if the "balanced brackets are ok" rule still stands, the
> >>above code would be legal. (And I really, really, really don't
> >>want the above code to be legal ;)
> >
> >Well, just don't do it then. With or without balanced brackets, the
> >obfuscating programmer can do the above; he just needs more or less
> >backslashes.
>
> Saying "Just don't do it" doesn't stop someone from doing it. True,
> the example was an obfuscated one, but it was to prove a point. This is
> just as obfuscated in my opinion:
>
> $var = qq[[[%hash{qq[one]}{qq[next]}],[],[%hash{qq[hi]}{qq[there]}]]];
>
> Adding backslashes to the first example helps clear up some of the
> confusion:
>
> $var = qq[blah [\q[blah [\qq[%hash{qq[[hi\]]}]\]]\]blah];
> $var = qq[blah \[\q[blah \[\qq[%hash{qq[\[hi\]]}]\]]\]blah];
Maybe that's because you wrote it in the first place; as a reader I think
it looks just as bad, if not worse.
> Really, I think that if you really feel the need to use a delimiter
> that you know that will be in the text that you are quoting, you should
> have to go through the trouble of escaping it. Its only fair :)
No, it's not fair, because I ALWAYS have to worry about escaping
something. What I really want is a quote operator which really quotes
everything. I don't want to have to worry about what accidental "\q"
substrings are going to do in my strings. q{} was the best way to do that
in perl5, because even braces within the string were ok if they behaved
themselves.
> >'\qq[]' is the real source of evil here.
> >
> >Actually the apocalypse says:
> >
> >>RFC 226: Selective Interpolation in Single Quotish Context.
> >>
> >>This proposal has much going for it, but there are also difficulties,
> >>and I've come close to rejecting it outright simply because the
> >>single-quoting policy of Perl 5 has been successful.
> >
> >Maybe if we pushed Larry a bit, he could reject it after all?
>
> Why? I love \qq[] and \q[]. I'd much rather have embedded strings
> than be able to balance used delimiters inside quotes. I don't like the
> "balance delimeters" rule at all, and don't see it as anything more
> than an ugly hack. I'd much rather have it go than embedded strings.
I am diametrically opposed to your opinions here. I hate '\qq[]' as an
ugly hack, which ruins the non-embedding, non-quoting nature of
non-interpolated strings. If you want to embed, just use interpolated
strings.
What if \q[] was allowed in interpolated strings, but not in
non-interpolated strings. Then I'm happy with that non-interpolated
strings really don't interpolate, and you might be happy because it would
only make sense to do one level of nesting. ie, you cannot embed \qq[]
inside \q[]. Or you could do $(''), which is the same number of
characters as \qq[], and doesn't require introducing
yet-another-new-rule-to-an-already-too-complicated-escaping-system.
qq[q[
not-interpolated not-interpolated not-interpolated
not-interpolated ]interpolated\q[ not-interpolated
not-interpolated not-interpolated ]interpolated\q[
not-interpolated not-interpolated not-interpolated
not-interpolated not-interpolated not-interpolated
]interpolated\q[ not-interpolated ]interpolated\q[
not-interpolated ]interpolated interpolated
];
~ John Williams
RE: purge: opposite of grep
> FWIW, I came up with "purge" because my first inclination was to spell > "grep" backwards: "perg". :-) I like "purge", although "except", "exclude", and "omit" all have their charms. For partition function, I like "divvy", "carve", "segment" (in that order) and almost anything other than "separate", which IIRC is one of the most misspelled words in English. === Mark Leighton Fisher[EMAIL PROTECTED] Thomson multimedia, Inc.Indianapolis IN "we have tamed lightning and used it to teach sand to think"
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Dave Whipp wrote:
> Only if we apply a bit of magic (2 is a true value). The rule might be:
How about if we just have two different methods: one for boolean and one
for multiple divvies:
my(@true, @false) := @array.cull{/some test/};
my (@a, @b, @c) := @array.divvy{some code}
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Re: purge: opposite of grep
John Williams wrote in perl.perl6.language : > > While "purge" is cute, it certainly is not obvious what it does. Of > course neither is "grep" unless you are an aging unix guru... > > How about something which is at least obvious to someone who knows what > grep is, such as "vgrep" or "grep:v"? If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p What would be an idiomatic Perl 6 implementation of such a vrep function ?
How do you return arrays?; was: RE: seperate() and/or Array.cull
In thinking about how to write a "partition" function (or separate, or
whatever you want to call it) it occurs to me that you might want some
sort of reverse-varargs behavior, like
my (@a, @b, @c, @d) = @array.partiton { $_ % 4 };
So in this case, partition is supposed to determine, on the fly, how
many classes to return (or return all the classes it makes, and let an
exception take mismatches).
How do we do that?
And in general, without resorting to something hideous like scanf, is
there going to be some more-advanced want() variant that allows saying
@a, $i, $j, @b, %w, $k, @c = scramble(...);
??
=Austin
--- HellyerP <[EMAIL PROTECTED]> wrote:
> Angel Faus:
> > Maybe the solution is to make it hash-wise:
> >
> > %hash = @array.sep {
> > when /^[A-Z]*$/ {'uppercase'}
> > when /^[a-z]*$/ {'lowercase'}
> > default {'mixedcase'}
> > }
>
> I agree that general partitioning is 'better' than a fixed binary
> proposal,
> but what is gained over the full code except a tiny bit of sugar?
>
> for (@array)
> {
> when /^[A-Z]+$/ { push %hash{'uppercase'}, $_ }
> when /^[a-z]+$/ { push %hash{'lowercase'}, $_ }
> default { push %hash{'mixedcase'}, $_ }
> }
>
> On the other hand, perhaps binary-partitioning is sufficiently common
> to
> warrant Schwern's abbreviated syntax:
>
> (@switches, @args) = separate /^-/, @ARGV;
>
> Which in full would be something like:
>
> for (@ARGV)
> {
> when /^-/ { push @switches, $_ }
> default { push @args, $_ }
> }
>
> Philip
>
>
> Disclaimer
>
> This communication together with any attachments transmitted with it
> ('this E-mail') is intended only for the use of the addressee and may
> contain information which is privileged and confidential. If the
> reader of this E-mail is not the intended recipient or the employee
> or agent responsible for delivering it to the intended recipient you
> are notified that any use of this E-mail is prohibited. Addressees
> should ensure this E-mail is checked for viruses. The Carphone
> Warehouse Group PLC makes no representations as regards the absence
> of viruses in this E-mail. If you have received this E-mail in error
> please notify our ISe Response Team immediately by telephone on + 44
> (0)20 8896 5828 or via E-mail at [EMAIL PROTECTED] Please then
> immediately destroy this E-mail and any copies of it.
>
> Please feel free to visit our website:
>
> UK
> http://www.carphonewarehouse.com
>
> Group
> http://www.phonehouse.com
>
>
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On Thursday, December 5, 2002, at 02:11 AM, James Mastros wrote: On 12/04/2002 3:21 PM, Larry Wall wrote: \x and \o are then just shortcuts. Can we please also have \0 as a shortcut for \0x0? \0 in addition to \x, meaning the same thing? I think that would get us back to where we were with octal, wouldn't it? I'm not real keen on leading zero meaning anything, personally... :-P There ain't no such thing as a "wide" character. \xff is exactly the same character as \x[ff]. Which means that the only way to get a string with a literal 0xFF byte in it is with qq:u1[\xFF]? (Larry, I don't know that this has been mentioned before: is that right?) chr:u1(0xFF) might do it too, but we're getting ahead of ourselves. Hmm... does this matter? I'm a bit rusty on my Unicode these days, but I was assuming that \xFF and \x00FF always pointed to the same character, and that you in fact _don't_ have the ability to put individual bytes in a string, because Perl is deciding how to place the characters for you (how long they should be, etc.) So if you wanted more explicit control, you'd use C. Also, an annoying corner case: is "\0x1ff" eq "\0x[1f]f", or is it eq "\0x[1ff]"? What about other bases? Is "\0x1x" eq "\0x[1]", or is it eq "\0x[1x]" (IE illegal). (Now that I put those three questions together, the only reasonable answer seems to be that the number ends in the last place it's valid to end if you don't use explicit brackets.) Yeah, my guess is that it's as you say... it goes till it can't goes no more, but never gives an error (well, maybe for "\0xz", where there are zero valid digits?) But I would suspect that the bracketed form is *strongly* recommended. At least, that's what I plan on telling people. :-) Design team: If we're wrong on these, please correct. :-) MikeL
Re: Usage of \[oxdb]
On Wednesday, December 4, 2002, at 12:55 PM, David Whipp wrote: How far can we go with this \c thing? How about: print "\c[72, 101, 108, 108, 111]"; will that print "Hello"? Huh... having a comma-separated list to represent multiple characters. I can't think of any problems with that, and it would be marginally easier for some sequences... Unless someone on the design team objects, I'd say let's go for it. MikeL
Re: purge: opposite of grep
On Wednesday, December 4, 2002, at 09:11 PM, John Williams wrote:
On Wed, 4 Dec 2002, Miko O'Sullivan wrote:
FWIW, I came up with "purge" because my first inclination was to spell
"grep" backwards: "perg". :-)
While "purge" is cute, it certainly is not obvious what it does. Of
course neither is "grep" unless you are an aging unix guru...
The idea certainly has merit, though. It _is_ a quite common operation.
What about "divvy" (or are we already using that for something else?)
my(@a,@b) = divvy { ... } @c;
Other possibilities from the ol' thesaurus: C, C, C,
C.
Note that this does not generalize for cases > 2. If you want to split
things into, say, three different lists, or five, you have to use a
'given', and it gets less pleasant. Perhaps a C can be a
derivation of C or C by "dividing the streams", either like
this:
my(@a,@b,@c,@d) = divvy {
/foo/ ::
/bar/ ::
/zap/ ::
} @source;
or this (?):
divvy( @source; /foo/ :: /bar/ :: /zap/ ) -> @a, @b, @c, @d;
where C<::> is whatever delimiter we deem appropriate, and an empty
test is taken as the "otherwise" case.
Just pondering. Seems like a useful variation on the whole C
vs. C vs. C theme, though.
MikeL
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On Thu, Dec 05, 2002 at 09:18:21AM -0800, Michael Lazzaro wrote: : : On Thursday, December 5, 2002, at 02:11 AM, James Mastros wrote: : : >On 12/04/2002 3:21 PM, Larry Wall wrote: : >>\x and \o are then just shortcuts. : >Can we please also have \0 as a shortcut for \0x0? : : \0 in addition to \x, meaning the same thing? I think that would get : us back to where we were with octal, wouldn't it? I'm not real keen on : leading zero meaning anything, personally... :-P \0 still means chr(0). I don't think there's much conflict with the new \0x, \0o, \0b, and \0d, since \0 almost always occurs at the end of a string, if anywhere. : >>There ain't no such thing as a "wide" character. \xff is exactly : >>the same character as \x[ff]. : >Which means that the only way to get a string with a literal 0xFF byte : >in it is with qq:u1[\xFF]? (Larry, I don't know that this has been : >mentioned before: is that right?) chr:u1(0xFF) might do it too, but : >we're getting ahead of ourselves. : : Hmm... does this matter? I'm a bit rusty on my Unicode these days, but : I was assuming that \xFF and \x00FF always pointed to the same : character, and that you in fact _don't_ have the ability to put : individual bytes in a string, because Perl is deciding how to place the : characters for you (how long they should be, etc.) So if you wanted : more explicit control, you'd use C. A "byte" string is any string whose characters are all under 256. It's up to an interface to coerce this to actual bytes if it needs them. We'll presumably have something like "use bytes" that turns off all multi-byte processing, in which case you have to deal with any UTF that comes in by hand. But in general it'll be better if the interface coerces to types like "str8", which is presumably pronouced "straight". Don't ask me how str16 and str32 are pronounced. (But generally you should be using utf16 instead of str16 in any event, unless your interface truly doesn't know how to deal with surrogates.) In other words, str16 is the name of the obsolescent UCS-2, and str32 is the name for UCS-4, which is more or less the same as UTF-32, except that UTF-32 is not allowed to use the bits above 0x10. So anyway, we've got all these types: str8utf8 str16 utf16 str32 utf32 where the "str" version is essentially just a compact integer array. One could alias str8 to "latin1" since the default coercion from Unicode to str8 would have those semantics. It's not clear exactly what the bare "str" type is. "Str" is obviously the abstract string type, but "str" probably means the default C string type for the current architecture/OS/locale/whatever. In other words, it might be str8, or it might be utf8. Let's hope it's utf8, because that will work forever, give or take an eon. : >Also, an annoying corner case: is "\0x1ff" eq "\0x[1f]f", or is it eq : >"\0x[1ff]"? What about other bases? Is "\0x1x" eq "\0x[1]", or is it : >eq "\0x[1x]" (IE illegal). (Now that I put those three questions : >together, the only reasonable answer seems to be that the number ends : >in the last place it's valid to end if you don't use explicit : >brackets.) : : Yeah, my guess is that it's as you say... it goes till it can't goes no : more, but never gives an error (well, maybe for "\0xz", where there are : zero valid digits?) But I would suspect that the bracketed form is : *strongly* recommended. At least, that's what I plan on telling : people. :-) Sounds good to me. Dwimming is wonderful, but so is dwissing. Larry
Re: purge: opposite of grep
I like it except for the name, which feels too active to me (ie, if I were to
purge those elements from the array I'd expect the array to be altered, instead
of returning a new array with only those elements). But I do like the idea. I
think the name "except" would be pretty nice, though. Then again, I'm not too
terribly fond of "grep". If it were named "only", then things might be really
nice. (Or we could name them "accept" and "except" and be mean :))
> SUMMARY
>
> Proposal for the "purge" command as the opposite of "grep" in the same way
> that "unless" is the opposite of "if".
>
> DETAILS
>
> I've lately been going a lot of greps in which I want to keep all the
> elements in an array that do *not* match some rule. For example, suppose
> I have a list of members of a club, and I want to remove (i.e. "purge")
> from the list everybody for whom the "quit" property is true. With grep
> it's done like this:
>
>@members = grep {! $_->{'quit'}} @members;
>
> Obviously that works well enough, but just like "unless" somehow
> simplifies the logic by removing that leading !, "purge" can simplifiy the
> array filter:
>
>@members = purge {$_->{'quit'}} @members;
>
> FWIW, I came up with "purge" because my first inclination was to spell
> "grep" backwards: "perg". :-)
>
> -miko
>
>
> Miko O'Sullivan
> Programmer Analyst
> Rescue Mission of Roanoke
>
>
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
I love apathy with a passion.
--Jamin Gray
Re: purge: opposite of grep
On Wed, 4 Dec 2002, John Williams wrote: > While "purge" is cute, it certainly is not obvious what it does. Of > course neither is "grep" unless you are an aging unix guru... > > How about something which is at least obvious to someone who knows what > grep is, such as "vgrep" or "grep:v"? How about my original inclinaton: "perg"? It just screams out "the opposite of grep". -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: purge: opposite of grep
>How about my original inclinaton: "perg"? It just screams out "the
>opposite of grep".
So it greps a list in reverse order?
-R (who does not see any benefit of 'perg' over grep { ! code } )
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Robert Spier wrote:
> -R (who does not see any benefit of 'perg' over grep { ! code } )
My problem with grep { ! code } is the same problem I have with if (!
expression): I've never developed a real trust in operator precedence.
Even looking at your pseudocode example, I itched to "fix" it with grep {!
(code) }.
This may be a weakness on my part, but I like computers to address my
weaknesses: I certainly spend enough time addressing theirs.
-miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
RE: seperate() and/or Array.cull
On Thursday, December 5, 2002, at 10:09 AM, Michael Lazzaro wrote:
What about "divvy" (or are we already using that for something else?)
my(@a,@b) = divvy { ... } @c;
Other possibilities from the ol' thesaurus: C, C,
C, C.
@$#@%*. Trying to do too many %#@%@ things at once. I meant 'divvy'
instead of 'seperate', not 'purge', obviously (duh). I like Angel's
general theorizing, but maybe we base it on C instead of C?
Note that this does not generalize for cases > 2. If you want to
split things into, say, three different lists, or five, you have to
use a 'given', and it gets less pleasant. Perhaps a C can be a
derivation of C or C by "dividing the streams", either
like this:
my(@a,@b,@c,@d) = divvy {
/foo/ ::
/bar/ ::
/zap/ ::
} @source;
or this (?):
divvy( @source; /foo/ :: /bar/ :: /zap/ ) -> @a, @b, @c, @d;
where C<::> is whatever delimiter we deem appropriate, and an empty
test is taken as the "otherwise" case.
Just pondering. Seems like a useful variation on the whole C
vs. C vs. C theme, though.
MikeL
Re: purge: opposite of grep
On Thu, Dec 05, 2002 at 10:09:08AM -0800, Michael Lazzaro wrote:
: What about "divvy" (or are we already using that for something else?)
:
: my(@a,@b) = divvy { ... } @c;
Any such solution must use := rather than =. I'd go as far as to say
that divvy should be illegal in a list context.
Note that if the closure is expected to return a small integer saying
which array to divvy to, then boolean operators fall out naturally
because they produce 0 and 1.
Larry
Re: purge: opposite of grep
"Larry Wall" <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 05, 2002 at 10:09:08AM -0800, Michael Lazzaro wrote:
> : What about "divvy" (or are we already using that for something else?)
> :
> : my(@a,@b) = divvy { ... } @c;
>
> Any such solution must use := rather than =. I'd go as far as to say
> that divvy should be illegal in a list context.
I'm not sure I understand that: we're assigning here, not binding (aren't
we?).
> Note that if the closure is expected to return a small integer saying
> which array to divvy to, then boolean operators fall out naturally
> because they produce 0 and 1.
Only if we apply a bit of magic (2 is a true value). The rule might be:
If context is an list of arrays, then the coderef is evaluated in
integer context: to map each input value to an integer, which selects
which array to append the input-value onto.
If the size of the context is "list of 2 arrays", then the coderef is
evaluated in Boolean context, and the index determined as
c< $result ?? 1 :: 0 >.
If the context is a single array, then it is assumed to be an
array-of-arrays: and the coderef is evaluated in integer-context.
If the context is a hash, then the coderef is evaluated in scalar
context, and the result used as a hash key: the value is pushed
onto the array, in the hash, identified by the key.
One more thing: how to I tell the assignment not to clear to
LHS at the start of the operation. Can I say:
my (@a,@b) = divvy { ... } @a1;
(@a,@b) push= divvy { ... } @a2;
Dave.
Re: purge: opposite of grep
"Miko O'Sullivan" <[EMAIL PROTECTED]> wrote:
> On Thu, 5 Dec 2002, Dave Whipp wrote:
>
> > Only if we apply a bit of magic (2 is a true value). The rule might be:
>
> How about if we just have two different methods: one for boolean and one
> for multiple divvies:
>
> my(@true, @false) := @array.cull{/some test/};
>
> my (@a, @b, @c) := @array.divvy{some code}
I think you are correct, but only because of the psychology of
affordances: you wrote "@true, @false", not "@false, @true".
I use the same mental ordering, so I expect it would be a
common bug.
I think that c would be an abysmal name: that implies
"keep the false ones". I'm not sure that there is a synonym
for "boolean partition" though. Perhaps we need some help
from a linguist! ;)
Dave.
Advanced Contexts (was: RE: seperate() and/or Array.cull)
On Thursday, December 5, 2002, at 07:53 AM, Austin Hastings wrote: And in general, without resorting to something hideous like scanf, is there going to be some more-advanced want() variant that allows saying @a, $i, $j, @b, %w, $k, @c = scramble(...); This is a terribly important question, for divvy() and everything else. Whether or not the description of "context" of a sub/block has the same robustness as the "arguments" of that sub/block has big implications for multimethods, among other things. I would hope that, minimally, the return type is considered part of the (multimethod) signature, and that you can test for at least the scalar types: my int $i = bar(...);# so these are my str $s = bar(...);# the same sub, but my MyClass $o = bar(...);# different multimethod variants. In my fantasy world (which I visit quite often), P6 context has descriptive capabilities matching those that can be assigned to args. (@a,@b)= foo(...); # same sub, (@a,@b,@c) = foo(...); # different multimethod variants. my int @arr = zap(...); # ... you get the idea ... my num @arr = zap(...); my MyClass @arr = zap(...); my Array of Array of Hash of MyClass @arr = zap(...); That last one leads to the obvious question of what C returns in the case of compound types: my Array of Array of Hash of MyClass @arr = zap(...); ... then inside zap ... want scalar; # false; want list;# true (but what spelling?) want Array; # true (but what spelling?) want Array of Array; # true want Array of Array of Hash; # true want Array of Array of Hash of MyClass; # true want Hash; # false want MyClass;# false want Array of int; # false my $want = want; # 'Array of Array of Hash of MyClass'; (?) my @want = want; # qw(Array, Array, Hash, MyClass); (?) If we have such functionality, than divvy() and other multimethods can be tailored to DWYM even in quite specific contexts, and a lot of things become much easier. MikeL
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: > If you want good'ol Unix flavor, call it "vrep". Compare the ed(1) / > ex(1) / vi(1) commands (where 're' stands for regular expression, of > course) : > :g/re/p > :v/re/p I like it. Fits in with our Un*x heritage, and doesn't have any existing meaning that implies things it doesn't do. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: purge: opposite of grep
--- Dave Whipp <[EMAIL PROTECTED]> wrote:
>
> I think that c would be an abysmal name: that implies
> "keep the false ones". I'm not sure that there is a synonym
> for "boolean partition" though. Perhaps we need some help
> from a linguist! ;)
>
What's wrong with split()?
split { f($_) }, $iterator-or- @array.split { f($_) }
vs.
split /\Q$delim\E/, $string -or- $string.split( /\Q$delim\E/ )
BTW, since it's possible to say:
my (@even, @odd) = split { $_ % 2 }, 0 .. Inf;
I presume that split will be smart enough to be usefully lazy. So
laziness is probably a contagious property. (If the input is lazy, the
output probably will be, too.)
But what happens with side-effects, or with pathologically ordered
accesses?
That is, iterators tend to get wrapped with a lazy array, which caches
the accesses.
So if the discriminator function caches values of its own, what
happens?
E.g.,
# Side-effects
my (@even, @odd)
= split { is_prime($_) && $last_prime = $_; $_ % 2 }, 0..Inf;
The value of last_prime is .. ?
# Pathological access:
my (@even, @odd) = ... as above ...
print $#odd;
Does @even (which is going to be cached by the lazy array) just swamp
memory, or what?
=Austin
=Austin
Stringification of references and objects.
A big issue that still remains with literals is the stringification of
objects and references. In an effort to get the behaviors hammered
down, here are a few ideas:
First off, references:
By default, references should not stringify to anything "pretty", they
should stringifiy to something useful for debugging. Heck, even perl5
style should be fine. Not only is this handy, but also prevents
problems with circular referencing data structures, huge data
structures, etc. However, all built-in types should have a .repr()
method, which should provide primitive Data::Dumper-ish output
So:
$var = [1,2,3];
print "$var";
print "\n";
print "$($var.repr)";
Might print something like:
[REF_TO_ARRAY_AT: '0x1245AB']
[
'1',
'2',
'3'
]
Next, objects:
Objects should have an AS_STRING method inherited from UNIVERSAL
defined as follows:
method AS_STRING() {
return "[CLASS_INSTANCE_OF: '" ~ $self.CLASS() ~ "']";
}
The AS_STRING method is implicitly called when an object is
interpolated within a string. The AS_STRING method can be
overloaded within the class if the class's author wants nicer
(classier;) output.
so:
class Normal {}
class Special {
method AS_STRING() {
return qq['one','two',three']
}
}
my Normal $obj1;
my Special $obj2;
print $obj1;
print "\n";
print $obj2;
Should print:
[CLASS_INSTANCE_OF: 'Normal']
'one','two',three'
RE: Stringification of references and objects.
Joseph F. Ryan:
# By default, references should not stringify to anything
# "pretty", they should stringifiy to something useful for
# debugging. Heck, even perl5 style should be fine. Not only
Why? Isn't the pretty form more generally useful?
# is this handy, but also prevents problems with circular
# referencing data structures, huge data structures, etc.
# However, all built-in types should have a .repr() method,
# which should provide primitive Data::Dumper-ish output
#
# So:
#
#$var = [1,2,3];
# print "$var";
# print "\n";
# print "$($var.repr)";
#
# Might print something like:
#
# [REF_TO_ARRAY_AT: '0x1245AB']
What's wrong with a Perl 5-esque format for the debugging version?
Array(0x1245AB)
Personally, I like this format. It's succinct, informative, and tells
you enough to do identity testing.
# Next, objects:
#
# Objects should have an AS_STRING method inherited from
# UNIVERSAL defined as follows:
I'd prefer if we drop the capitals. str() ought to work fine, IMHO.
# method AS_STRING() {
# return "[CLASS_INSTANCE_OF: '" ~ $self.CLASS() ~ "']";
# }
Once again, what's wrong with:
method str() {
#Unnamed invocant means you need $_, right?
return $_.class() ~ "($_.id())";
}
(where id() returns a uniquely identifying integer, usually the
address).
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible."
--Ayn Rand, explaining how today's philosophies came to be
Re: Usage of \[oxdb]
Michael Lazzaro wrote: Huh... having a comma-separated list to represent multiple characters. I can't think of any problems with that, and it would be marginally easier for some sequences... Unless someone on the design team objects, I'd say let's go for it. Larry was certainly in favour of it when he wrote A5 (see under http://search.cpan.org/perl6/apo/A05.pod#Backslash_Reform). Except the separators he suggests are semicolons: Perl 5 Perl 6 \x0a\x0d\x[0a;0d] # CRLF \x0a\x0d\c[CR;LF] # CRLF (conjectural) Damian
Re: purge: opposite of grep
I would suggest that we could get away with a single n-ary built-in.
And I would strongly suggest that C isn't the right name for it,
since, apart from being a ugly, slang word, "divvy" implies dividing up
equally. The built-in would actually be doing classification of the
elements of the list, so it ought to be called C.
I would expect that C would return a list of array references.
So Larry is (of course! ;-) entirely correct in pointing out that it
would require the use of := (not =). As for an error when = is used,
perhaps that ought to be handled by a general "Second and subsequent
lvalue arrays will never be assigned to" error.
The selector block/closure would, naturally, be called in C
context each time, so (again, as Larry pointed out) a boolean
function would naturally classify into two arrays. Though it
might at first be a little counterintuitive to have to write:
(@false, @true) := classify { $^x > 10 } @nums;
I think it's a small price to pay to avoid tiresome special cases.
Especially since you then get your purge/vrep/antigrep for free:
(@members) := classify {$_->{'quit'}} @members;
;-)
Damian
Re: String Literals, take 3
John Williams wrote:
On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
John Williams wrote:
On Thu, 5 Dec 2002, Joseph F. Ryan wrote:
With all of the new crazy quoting shenanagains, I'm not sure that the
"balenced brackets are fine" rule will still be possible; and thus end
delimeters will always need to be escaped. For instance, imagine
what a nightmare this would be to parse:
$var = qq[blah [\q[blah [\qq[%hash{qq[[hi]]} blah];
Sure, anyone who writes something like this deserves to be shot;
however, if the "balanced brackets are ok" rule still stands, the
above code would be legal. (And I really, really, really don't
want the above code to be legal ;)
Well, just don't do it then. With or without balanced brackets, the
obfuscating programmer can do the above; he just needs more or less
backslashes.
Saying "Just don't do it" doesn't stop someone from doing it. True,
the example was an obfuscated one, but it was to prove a point. This is
just as obfuscated in my opinion:
$var = qq[[[%hash{qq[one]}{qq[next]}],[],[%hash{qq[hi]}{qq[there]}]]];
Adding backslashes to the first example helps clear up some of the
confusion:
$var = qq[blah [\q[blah [\qq[%hash{qq[[hi\]]}]\]]\]blah];
$var = qq[blah \[\q[blah \[\qq[%hash{qq[\[hi\]]}]\]]\]blah];
Maybe that's because you wrote it in the first place; as a reader I think
it looks just as bad, if not worse.
True, it looks *very* bad, but least its easier to tell what
quotes and what doesn't.
Really, I think that if you really feel the need to use a delimiter
that you know that will be in the text that you are quoting, you should
have to go through the trouble of escaping it. Its only fair :)
No, it's not fair, because I ALWAYS have to worry about escaping
something. What I really want is a quote operator which really quotes
everything. I don't want to have to worry about what accidental "\q"
substrings are going to do in my strings. q{} was the best way to do that
in perl5, because even braces within the string were ok if they behaved
themselves.
What's wrong with single quoted here-docs?
'\qq[]' is the real source of evil here.
Actually the apocalypse says:
RFC 226: Selective Interpolation in Single Quotish Context.
This proposal has much going for it, but there are also difficulties,
and I've come close to rejecting it outright simply because the
single-quoting policy of Perl 5 has been successful.
Maybe if we pushed Larry a bit, he could reject it after all?
Why? I love \qq[] and \q[]. I'd much rather have embedded strings
than be able to balance used delimiters inside quotes. I don't like the
"balance delimeters" rule at all, and don't see it as anything more
than an ugly hack. I'd much rather have it go than embedded strings.
I am diametrically opposed to your opinions here. I hate '\qq[]' as an
ugly hack, which ruins the non-embedding, non-quoting nature of
non-interpolated strings. If you want to embed, just use interpolated
strings.
Don't forget that the backslash is already special in
non-interpolating strings; I don't think that adding a single
special case will make things too confusing.
What if \q[] was allowed in interpolated strings, but not in
non-interpolated strings. Then I'm happy with that non-interpolated
strings really don't interpolate, and you might be happy because it would
only make sense to do one level of nesting. ie, you cannot embed \qq[]
inside \q[]. Or you could do $(''), which is the same number of
characters as \qq[], and doesn't require introducing
yet-another-new-rule-to-an-already-too-complicated-escaping-system.
I think \qq[] is the much more useful of the two, so
that really doesn't help much.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Subroutine IMC example with problem
[EMAIL PROTECTED] wrote: Leo -- * Bracket with one big .sub ... .end, and don't use .sub for my real subs (yuck -- I want to use .param, .arg, etc for subs and calls) You can use .param/.arg - again: "A .sub/.end delimits a unit of compilation". Look at imcc.y .param => restore, .arg => save that's it (modulo name mangling which you could handle with .namespace). * Use the anonymous blocks to bracket all non-sub linear code in the script as I have done (yuck -- results in the problems I've reported) And you cannot jump between them. * Change the Jako compiler to collect all linear code into a single segment and emit it at the end, Yep. I suggest that imcc should allow code outside .sub ... .end brackets, which should be good for Jako, Perl and other languages. Not needed IMHO. Regards, -- Gregor leo
Re: Stringification of references and objects.
Brent Dax wrote:
Joseph F. Ryan:
# By default, references should not stringify to anything
# "pretty", they should stringifiy to something useful for
# debugging. Heck, even perl5 style should be fine. Not only
Why? Isn't the pretty form more generally useful?
I don't think so; I'd think it to be annoying to have type more code
in order to specify a more cocise form; if I need to dump a structure,
I'd prefer to do it manually.
# is this handy, but also prevents problems with circular
# referencing data structures, huge data structures, etc.
# However, all built-in types should have a .repr() method,
# which should provide primitive Data::Dumper-ish output
#
# So:
#
#$var = [1,2,3];
# print "$var";
# print "\n";
# print "$($var.repr)";
#
# Might print something like:
#
# [REF_TO_ARRAY_AT: '0x1245AB']
What's wrong with a Perl 5-esque format for the debugging version?
Array(0x1245AB)
Personally, I like this format. It's succinct, informative, and tells
you enough to do identity testing.
I like it too, but I thought everyone else hated it :)
# Next, objects:
#
# Objects should have an AS_STRING method inherited from
# UNIVERSAL defined as follows:
I'd prefer if we drop the capitals. str() ought to work fine, IMHO.
# method AS_STRING() {
# return "[CLASS_INSTANCE_OF: '" ~ $self.CLASS() ~ "']";
# }
Once again, what's wrong with:
method str() {
#Unnamed invocant means you need $_, right?
return $_.class() ~ "($_.id())";
}
(where id() returns a uniquely identifying integer, usually the
address).
Objects aren't references anymore, are they? So I don't think it is
apporpriate for an object to stringify with its id.
Joseph F. Ryan
[EMAIL PROTECTED]
