Re: In defense of zero-indexed arrays.
On 05/12/02 02:45 -0800, Michael G Schwern 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] With languages like Perl that have negative subscripts, using a zero base gives continuity. @INC[-2..2] should continue to DWIM. Cheers, Brian
RE: Stringification of references and objects.
Joseph F. Ryan:
# >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.
I think it's useful to be able to say @array.str() and $arrayref.str()
and get the same result. And since we already know what @array.str will
do (essentially what "@array" does in Perl 5), that suggests that
$arrayref.str() will do the same.
# > 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.
To tell you the truth, I don't consider arrayrefs references anymore.
They're just Array objects that don't happen to be in @whatever symbols.
I don't know if this is the official view, but that fits my brain
better.
--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: Stringification of references and objects.
Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members?
Re: Subroutine IMC example with problem
Leo -- OK. I'll have a look at a single outer .sub ... .end, and implementing subs with regular labels along with the .param stuff. If .sub ... .end bracket not a subroutine, but a unit of compilation (module?), then shouldn't we make the name reflect the purpose? BTW, what is the difference between .sym and .local? And, .endclass and .endnamespace are not mentioned in imcc/README. Regards, -- Gregor Leopold Toetsch <[EMAIL PROTECTED]> 12/05/2002 12:43 PM To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: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: Usage of \[oxdb] (was Re: String Literals, take 2)
On 12/05/2002 12:18 PM, 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 You misinterpret. I meant \0 meaning the same as \c[NUL], IE the same as chr(0), a null character. (I suppse I should have said \0x[0].) 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? Sorry. It does, in fact, not matter... momentarly stopped thinking in terms of utf8 encoding being a completly transparent process.
Re: purge: opposite of grep
On Fri, 6 Dec 2002, Damian Conway wrote: > 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: OK, but I would assert that the false/true classification is going to be the more common case, not "classify by index position", and that furthermore there will be a lot of situations where the false/true value may be any number, not just 1 or 0. For example, suppose I want to separate a list of people into people who have never donated money and those who have. Assuming that each person object has a donations property which is an array reference, I would want to classify them in this manner: (@nevers, @donors) := classify($_->[donations]) @people; According to the C model, that would give me people who have donated zero times, and people who have donated once, and the people who have donated more than once would be lost. Now, of course you can force the dontations into a boolean context, but, frankly, I think If we force people to always remember to force boolean context, just to preserve the (IMHO) unusual case of classifying by integer, we're, on balance, making more work for the world. Ergo, I suggest we simply have a separate command for the false/true situation: (@nevers, @donors) := falsetrue($_->[donations]) @people; (Yes, "falsetrue" is a stupid name, please replace with something better.) -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Quick translation wanted
Is it clear how attributes accessors on objects are going to work yet?
I need to say something along the lines of:
sub new {
my $class = shift;
my ($name, $age) = @_;
bless {
name => $name,
age => $age
}, $class;
}
sub age { my $self=shift; $self->{age} }
--
"They laughed at Columbus, they laughed at Fulton, they laughed at the
Wright brothers. But they also laughed at Bozo the Clown."
-- Carl Sagan
Re: Quick translation wanted
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Sender: [EMAIL PROTECTED]
> From: Simon Cozens <[EMAIL PROTECTED]>
> Date: 06 Dec 2002 14:54:43 +
> Organization: Bethnal Green is PEOPLE!
> X-Posted-By: 217.204.174.162
>
>
> Is it clear how attributes accessors on objects are going to work yet?
> I need to say something along the lines of:
>
>sub new {
>my $class = shift;
>my ($name, $age) = @_;
> bless {
> name => $name,
> age => $age
> }, $class;
>}
>
>sub age { my $self=shift; $self->{age} }
>
There's nothing decided on how constructors work yet, so I'll use a
fill-in syntax.
class Person {
has $.name is private;# No accessor generated
has $.age;
method new($n, $a) {
($.name, $.age) = ($n, $a);
return bless; # bless me => myself
}
}
Re: purge: opposite of grep
On Fri, Dec 06, 2002 at 09:33:14AM -0500, Miko O'Sullivan wrote: > For example, suppose I want to separate a list of people into people who > have never donated money and those who have. Assuming that each person > object has a donations property which is an array reference, I would want > to classify them in this manner: > > (@nevers, @donors) := classify($_->[donations]) @people; > > According to the C model, that would give me people who have donated > zero times, and people who have donated once, and the people who have > donated more than once would be lost. Then turn donations into a boolean. (@donors, @nevers) := classify(!$_->[donations]) @people; I don't think there is the need to bloat the langauge with every special case we can think of. Graham.
Re: [CVS ci] imcc syntax change
Gopal V wrote:
iANY("add", R3(r0,r1,r2))
Better use INS (the public interface of above functions)
Thanks, a shared library implementation of such a thing is what I'm
looking for ... I'll take a look at doing that ...
WOuld it help to split imcc.y into main/parser/parser_utils or are you
doing this anyway?
Gopal
leo
Re: Subroutine IMC example with problem
[EMAIL PROTECTED] wrote: Leo -- If .sub ... .end bracket not a subroutine, but a unit of compilation (module?), then shouldn't we make the name reflect the purpose? A thing compiled in one piece ist mostly a subroutine. BTW, what is the difference between .sym and .local? UTSL ;-) none. (Most documentation files end in .c (or .y)) And, .endclass and .endnamespace are not mentioned in imcc/README. Thanks - done. Regards, -- Gregor leo
IMCC puzzle
Leo -- Here is a simple Jako test program, which exercises the assignment syntax: var int a, b, c; var num d, e; var str f, g; a = 5; a = b = c = 5; d = 3.14; d = e = 3.14; f = "Howdy"; f = g = "Howdy"; a = b; a = b = c; Here it is compiled to IMC: .sub __MODULE__ .local int a # var int a; .local int b # var int b; .local int c # var int c; .local float d # var num d; .local float e # var num e; .local string f # var str f; .local string g # var str g; a = 5 # a = 5; a = 5 # a = 5; b = 5 # b = 5; c = 5 # c = 5; d = 3.14 # d = 3.14; d = 3.14 # d = 3.14; e = 3.14 # e = 3.14; f = "Howdy" # f = "Howdy"; f = "Howdy" # f = "Howdy"; g = "Howdy" # g = "Howdy"; a = b # a = b; a = c # a = c; b = c # b = c; end .end And, here is the PASM imcc turns it into: __MODULE__: set I2, 5 set I2, 5 set I0, 5 set I1, 5 set N0, 3.14 set N0, 3.14 set N0, 3.14 set S0, "Howdy" set S0, "Howdy" set S0, "Howdy" set I2, I0 set I2, I1 set I0, I1 end I don't understand how d and e both become N0, nor how both f and g become S0. a, b, and c all seem to get their own registers. Is there some optimization going on here since in both cases (num and str), the assigns are from the same constant table location? Is imcc smart enough to realize that the above transformation doesn't change the semantics of my program, or is it perhaps a bug? Regards, -- Gregor
Re: IMCC puzzle
On Fri, 2002-12-06 at 10:40, [EMAIL PROTECTED] wrote: > set N0, 3.14 > set N0, 3.14 > set N0, 3.14 > I don't understand how d and e both become N0, nor how both f and g become > S0. a, b, and c all seem to get their own registers. Is there some > optimization going on here since in both cases (num and str), the assigns > are from the same constant table location? Is imcc smart enough to realize > that the above transformation doesn't change the semantics of my program, > or is it perhaps a bug? Looks like the first stages of constant-folding to me, no? Presumably if d and e were set to different values or had unpredictable side effects acting on them, this would not happen. The constant folding may simply not deal with integers yet -- Aaron Sherman <[EMAIL PROTECTED]>
Re: Subroutine IMC example with problem
Leo -- > > If .sub ... .end bracket not a subroutine, but a unit of compilation > > (module?), then > > shouldn't we make the name reflect the purpose? > A thing compiled in one piece ist mostly a subroutine. I disagree. A think what is most often compiled in one piece is a file, with a combination of sub and not-sub stuff in it, possibly a whole class, or possibly just chunks of code (as with Jako and Perl). Certainly while imcc operates on files, I would imagine it to be common that a single source language file gets turned into a single .imc file, which imcc turns into a single .pasm file, which assemble.pl turns into a single .pbc file (its files all the way down :). Regards, -- Gregor
Re: Subroutine IMC example with problem
[EMAIL PROTECTED] wrote: Leo -- If .sub ... .end bracket not a subroutine, but a unit of compilation (module?), then shouldn't we make the name reflect the purpose? A thing compiled in one piece ist mostly a subroutine. I disagree. A think what is most often compiled in one piece is a file, with a combination of sub and not-sub stuff in it, possibly a whole class, or possibly just chunks of code (as with Jako and Perl). I wanted to say: you can compile one sub in one piece, while you can't compile smaller pieces. So a sub is the smallest compilation unit. Of course you can compile one file containing many subs as one piece of code. WRT you jako code - I thought about it a little longer: It wouldn't be a big problem to gather code outside subs and compile it at the end, after interpsarsed subs. It would only need one additional instruction** pointer to collect all ins there. Likewise nested subs. Though the HL still has to generate appropriate "bsr" to call the main routine. Your example code would be spit out aus: callmainsub sub1 sub2 main (code goes here (containing everything outside subs)) Regards, -- Gregor leo
Re: IMCC puzzle
Aaron Sherman wrote: On Fri, 2002-12-06 at 10:40, [EMAIL PROTECTED] wrote: Looks like the first stages of constant-folding to me, no? No, but constant folding is done anyway. Both "3.14" are one constant loation. The constant folding may simply not deal with integers yet No, integer constants are intersparsed in the pbc and can't be folded. leo
Re: IMCC puzzle
[EMAIL PROTECTED] wrote: Leo -- Here is a simple Jako test program, which exercises the assignment syntax: Here it is compiled to IMC: [ Q/A intersparsed in imcc code for clearness ] .sub __MODULE__ .local int a # var int a; .local int b # var int b; .local int c # var int c; .local float d # var num d; .local float e # var num e; .local string f # var str f; .local string g # var str g; a = 5 # a = 5; a = 5 # a = 5; b = 5 # b = 5; c = 5 # c = 5; d = 3.14 # d = 3.14; d = 3.14 # d = 3.14; > I don't understand how d and e both become N0, d is not read beyond this point, so the register N0 gets reused. e = 3.14 # e = 3.14; f = "Howdy" # f = "Howdy"; f = "Howdy" # f = "Howdy"; g = "Howdy" # g = "Howdy"; > nor how both f and g become > S0. Same her, f ist not used RHS so, S0 gets reused. a = b # a = b; a = c # a = c; b = c # b = c; > a, b, and c all seem to get their own registers. Yes, these are used so need there own register. ... Is there some optimization going on here since in both cases (num and str), the assigns are from the same constant table location? No, constant table location doesn't matter. Is imcc smart enough to realize that the above transformation doesn't change the semantics of my program, or is it perhaps a bug? It's a result of variable lifeness analyses, which is the base for register allocation and definitely no bug ;-) Regards, -- Gregor leo
Re: String Literals, take 3
On Fri, 6 Dec 2002, Joseph F. Ryan wrote:
>
> What's wrong with single quoted here-docs?
What's wrong is that the documentation team is trying to allow \qq[]
there too, contradicting their own assertion that backslashes are not
special in that context.
> 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.
Oh well, I'm being overly-speculative above, which I shouldn't do on this
list, but I was wondering if compromise was possible. Changing the
behavior of backslashes and balanced delimiters is also speculative.
The current behavior in perl5 is that only two sequences are special in
non-interpolated strings
\\ --> \
\ -->
can be either the opening or closing delimiter when they are
balanced. So you CAN backslash them, but I don't HAVE to.
Larry has added \qq[] and \q[], so "\q" is now special. (Are \qw[] and
\qx[] in? qw doesn't make sense, and qx might be insecure.)
I would really appreciate a ruling from the design team before we change
non-interpolative semantics regarding:
1) the interpretation of \,
PRO: it makes backslash behavior consistent
CON: the perl5 behavior is as unobtrusive as possible
2) requiring balanced delimiters to be escaped,
PRO: it's consistent with non-balanced delimiter requirements
CON: you already can; don't force it those who don't want it
3) allowing \qq[] in single-quoted here-docs.
PRO: it's consistent with single-quotes
CON: it contradicts the assertion that backslashes are not special in
single quoted here-docs
we need a quoting mechanism where NOTHING is special
(Those are ordered from least to most offensive, BTW.)
~ John Williams
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 04:28 AM, Joseph F. Ryan wrote: Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members? How about something like what Ruby's irb does? % irb irb(main):001:0> class Foo irb(main):002:1>def initialize irb(main):003:2> @a, @b, @c = 1, 2, 3 irb(main):004:2>end irb(main):005:1> end nil irb(main):006:0> Foo.new # irb(main):007:0>
RE: Stringification of references and objects.
Joseph F. Ryan:
# Brent Dax wrote
#
# >To tell you the truth, I don't consider arrayrefs references
# anymore.
# >They're just Array objects that don't happen to be in @whatever
# >symbols. I don't know if this is the official view, but that fits my
# >brain better.
# >
#
# So you're saying that classes should stringify to a
# pretty-print of their public members?
No, because that wouldn't reveal enough for an equality check. At the
same time, however, exposing private members would be wrong, especially
since editing the string and creating a new instance from it would allow
the user to manipulate private members.
What I'm saying is that .str and .identity (for lack of a better name)
are identical in Object, but classes should feel free to override .str
if they have a better WTDI. The built-in classes (Array, Hash, etc.)
should override .str to yield their members in some format (probably
influenced by properties).
--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: [CVS ci] imcc syntax change
If memory serves me right, Leopold Toetsch wrote: > WOuld it help to split imcc.y into main/parser/parser_utils or are you > doing this anyway? yes pushing some code from imcc.y into a seperate file is what I had in mind ... But have not got to that yet ... Was curious about the following lines and sort of wasted that whole evening ... || return iANY(name, fmt, regs, 0); if emit (last param) is zero when called from INS ... when does the code actually get emitted ? So can I just do this to emit *.pbc ? emit_open(...) .. emit_close() to do my stuff ? (and how to do that without the interpreter interfering) So I sort of concluded to leave the output to direct fprintf's . Roughing it out with the changes in imcc seem easier than programming for this interface :-) Gopal -- The difference between insanity and genius is measured by success
Re: [CVS ci] imcc syntax change
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
WOuld it help to split imcc.y into main/parser/parser_utils or are you
doing this anyway?
yes pushing some code from imcc.y into a seperate file is what I had in
mind ... But have not got to that yet ...
Ok, than I'll separate it.
Was curious about the following lines and sort of wasted that whole
evening ...
|| return iANY(name, fmt, regs, 0);
if emit (last param) is zero when called from INS ... when does the code
actually get emitted ?
Yuu have to insert it somewhere into the instruction stream by either
emitb() or insert_ins() or so. I could make a shortcut for emitb(INS()).
So can I just do this to emit *.pbc ?
emit_open(...)
..
emit_close()
to do my stuff ? (and how to do that without the interpreter interfering)
Yes, emit_open just defines the emitter type (pasm file or pbc stuff).
The emit_pbc (e_pbc_emit) stuff generates a unpacked packfile for the
global interpreter ready for running or spitting out a PBC file to disc.
When you want to use this, have a look at imcc.y:
sub: sub_start statements ESUB {
allocate();
emit_flush();
clear_tables();
The instructions come from iANY or better from emitb(INS(...)). You
would need only to fill the SymRegs with the param information a la
mk_ident or mk_symreg ...
So I sort of concluded to leave the output to direct fprintf's . Roughing
it out with the changes in imcc seem easier than programming for this
interface :-)
For a first try going via file is of course simpler and easier to debug
too. You can always change this later, given some modularity is in place.
Gopal
leo
Re: purge: opposite of grep
On Thursday, December 5, 2002, at 07:55 PM, Damian Conway wrote:
equally. The built-in would actually be doing classification of the
elements of the list, so it ought to be called C.
I worry that C sounds too much like something class-related,
and would confuse people. What about C or something? Decent
thesaurus entries for include:
assign, classify, comb, compartmentalize, discriminate, distribute,
group, order, segregate, sift, winnow, amputate, cut, dismember,
excise, lop, disunite, divorce, estrange, part, wean, detach,
disconnect, disengage, dissociate, extract, isolate, part, steal, take,
uncouple, withdraw
Some of those might be appropriate (or just amusing). :-)
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
How would you do something like:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
I was more hoping for a C or C derivative that would
provide a series of 'stream'-like tests, not just one test with N
answers. Something that was a shorthand for the obvious but somewhat
tedious C counterpart. (If @source had an entry 'foobar', we
could debate whether that should go in one destination stream or two.)
Especially since you then get your purge/vrep/antigrep for free:
I don't think we need a separate func either, but if we're gonna have a
purge/vrep/antigrep, can someone _please_ think of a better name for
it? "purge" clearly needs an inverse called "binge", "vrep" sounds
like, well, UNIX, and "antigrep" sounds like something I put in my car
to avoid it grepping when I start it on cold mornings.
Even just "ngrep" sounds better to me. :-|
MikeL
Re: String Literals, take 3
> Date: Fri, 6 Dec 2002 10:16:20 -0700 (MST) > From: John Williams <[EMAIL PROTECTED]> > > 2) requiring balanced delimiters to be escaped, >PRO: it's consistent with non-balanced delimiter requirements >CON: you already can; don't force it those who don't want it I'll say no, agreeing with the CON. > 3) allowing \qq[] in single-quoted here-docs. >PRO: it's consistent with single-quotes >CON: it contradicts the assertion that backslashes are not special in > single quoted here-docs I'd say no here, which is consistent with Perl 5. My opinion basically agrees with Perl 5: I've never had a problem with those quoting rules. OTOH, I've never had to deal with localization. In single-quoted heredocs, _nothing_ should be special. When I'm writing a P::RD grammar, I don't want to worry about doubling my backslashes, which might already be doubled. is never pretty. If there is a single backslashed construct, then backslashes must be doubled, which stinks. > we need a quoting mechanism where NOTHING is special I agree one-hundapacent! Luke
Re: Stringification of references and objects.
At 6:36 PM -0500 12/5/02, Joseph F. Ryan wrote: 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 If an aggregate and a reference to an aggregate are going to behave the same, which is what Larry's indicated in the past, then stringifying a reference should be the same as stringifying its referent. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: 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 :) I think people like it fine, but many people don't want it to be the default stringification. Like I said in an earlier thread, the problem is that there's "stringification for output purposes" and "stringification for debugging purposes", but we have to chose one or the other to be the default. I'd rather the debugging one _not_ be the default, personally, because I imagine the other usage is more common. An obvious counterproposal would be to say that references are invisible to stringification (e.g. it stringifies to whatever its contents stringify to). This would seem to be in keeping with the the spirit of arrayref/array transparentness, etc. So you're saying that classes should stringify to a pretty-print of their public members? No, the AS_STRING (or str(), or whatever) is definitely the way to go. We pretty much _have_ to do it via a method. Brent Dax wrote: What I'm saying is that .str and .identity (for lack of a better name) are identical in Object, but classes should feel free to override .str if they have a better WTDI. The built-in classes (Array, Hash, etc.) should override .str to yield their members in some format (probably influenced by properties). I like this a lot, personally. MikeL
Re: String Literals, take 3
On Friday, December 6, 2002, at 09:46 AM, Luke Palmer wrote: 3) allowing \qq[] in single-quoted here-docs. PRO: it's consistent with single-quotes CON: it contradicts the assertion that backslashes are not special in single quoted here-docs The problem is, as Larry said, that heredocs are *exactly* where you most want to use \q and \qq. You have a big long hairy thing, and you want to treat only one-little-part of it differently, without escaping all the special characters throughout every other part of the doc. By allowing \qq in single-quoted heredocs, we allow things like: < ...big long text with $ chars $all$ $over$ $it$... The value of $v is \qq[$v] ...$more$ $icky$ $text$... END we need a quoting mechanism where NOTHING is special Well, I suppose you could default something to a qq heredoc, and q all the non-qq parts. But that's significantly more awkward-looking, IMO. Does \qq really come up in heredocs unless you explicitly mean it? MikeL
Re: Stringification of references and objects.
On Fri, Dec 06, 2002 at 10:40:18AM -0500, Dan Sugalski wrote:
: If an aggregate and a reference to an aggregate are going to behave
: the same, which is what Larry's indicated in the past, then
: stringifying a reference should be the same as stringifying its
: referent.
This is a bit of an oversimplification. $foo and @foo do not always
behave the same, even if $foo and @foo refer to the same array object.
In particular, $foo doesn't behave like @foo in a list context.
Scalars must continue to behave like scalars in list context, even
if they're internally composite. As in Perl 5, if you say
for $foo {...}
the sub only gets one argument, the array ref, but if you say
for @foo {...}
or
for @$foo {...}
you get all of the elements.
But it's probably fair to say that $foo and @foo always behave
identically in a scalar context.
We may, in fact, have to deprecate the term "list context" and replace
it with something like "flattening context", since we can have lists
of scalars that are in some sense in a "list context" but that aren't
in a flattening context:
my ($a,@b,%c) := (@a,$b,%c);
But "flattening" is a lousy word. It's really more of a "variadic"
context, but that's no improvement.
At the moment I can't think of anything better than "splat" context...
Larry
Re: purge: opposite of grep
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
>
> Some of those might be appropriate (or just amusing). :-)
I still like partition (or simply C). Segregate (c)
might also work
I notice everyone still want Int context for eval of the block:
Pease don't forget about hashes. Is there such a thing as
'hashkey context'?
Perl6 is much better than Perl5 for naming parameters. Could
we make the following work?
( low=>@under,
mid=>@in_range,
high=>@over )
= partition @input -> $v {
$v < 10 ?? "low" :: $v > 20 ?? "high" :: "mid";
};
Also, can I return superpositions (sorry, junctions), to provide
multiple classifications? Or would I return an array for that?
Dave.
Re: String Literals, take 3
On Fri, Dec 06, 2002 at 10:16:20AM -0700, John Williams wrote:
: On Fri, 6 Dec 2002, Joseph F. Ryan wrote:
: >
: > What's wrong with single quoted here-docs?
:
: What's wrong is that the documentation team is trying to allow \qq[]
: there too, contradicting their own assertion that backslashes are not
: special in that context.
Ahem. If you go back and look again, you'll see that I'm the one
who contradicted the assertion...
: > 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.
:
: Oh well, I'm being overly-speculative above, which I shouldn't do on this
: list, but I was wondering if compromise was possible. Changing the
: behavior of backslashes and balanced delimiters is also speculative.
:
: The current behavior in perl5 is that only two sequences are special in
: non-interpolated strings
:
:\\ --> \
:\ -->
:
: can be either the opening or closing delimiter when they are
: balanced. So you CAN backslash them, but I don't HAVE to.
:
: Larry has added \qq[] and \q[], so "\q" is now special. (Are \qw[] and
: \qx[] in? qw doesn't make sense, and qx might be insecure.)
That's not what I said. I said that \qq[ is special. Don't go
chopping my bracket off--I intend it to be required. Also, there's
no reason to allow \q[] inside single quotes. The others are rare
enough that they could be put inside \qq[].
In fact, if you want it all consistent, we could say that the *only*
way to put anything non-verbatim into any single-quoted string is
with \qq[]. So instead of '\\' you'd say '\qq[\\]' and instead of '\''
you'd say '\qq[']'. (And no, the latter doesn't actually require a
backslash before the '. If you think it does, you're still thinking
of a two-pass lexer like Perl 5. Perl 6 will have a one-pass lexer,
and the only delimiter it's looking for at the time it sees the quote
is actually a right bracket.)
On the other hand, people are likely to expect \\ and \' to continue working
as they currently do in ordinary single quoted strings. We could go with
the stricter rule for just single-quoted here docs, I suppose.
: I would really appreciate a ruling from the design team before we change
: non-interpolative semantics regarding:
:
: 1) the interpretation of \,
:PRO: it makes backslash behavior consistent
:CON: the perl5 behavior is as unobtrusive as possible
Well, no, I don't think \\ and \' are really "as unobtrusive as possible"...
: 2) requiring balanced delimiters to be escaped,
:PRO: it's consistent with non-balanced delimiter requirements
:CON: you already can; don't force it those who don't want it
See above about one-pass lexer. Balanced delimiters generally need no
backslashing unless they're a literal outside of any other bracketing
construct.
: 3) allowing \qq[] in single-quoted here-docs.
:PRO: it's consistent with single-quotes
:CON: it contradicts the assertion that backslashes are not special in
: single quoted here-docs
: we need a quoting mechanism where NOTHING is special
:
: (Those are ordered from least to most offensive, BTW.)
Then paint me most offensive, by all means. :-)
Larry
Re: purge: opposite of grep
Michael Lazzaro wrote: I worry that C sounds too much like something class-related, and would confuse people. What about C or something? Decent thesaurus entries for include: assign, classify, comb, compartmentalize, discriminate, distribute, group, order, segregate, sift, winnow, amputate, cut, dismember, excise, lop, disunite, divorce, estrange, part, wean, detach, disconnect, disengage, dissociate, extract, isolate, part, steal, take, uncouple, withdraw designate? -- Tim
Re: Quick translation wanted
On Fri, Dec 06, 2002 at 08:44:23AM -0700, Luke Palmer wrote:
: > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
: > Sender: [EMAIL PROTECTED]
: > From: Simon Cozens <[EMAIL PROTECTED]>
: > Date: 06 Dec 2002 14:54:43 +
: > Organization: Bethnal Green is PEOPLE!
: > X-Posted-By: 217.204.174.162
: >
: >
: > Is it clear how attributes accessors on objects are going to work yet?
: > I need to say something along the lines of:
: >
: >sub new {
: >my $class = shift;
: >my ($name, $age) = @_;
: > bless {
: > name => $name,
: > age => $age
: > }, $class;
: >}
: >
: >sub age { my $self=shift; $self->{age} }
: >
:
: There's nothing decided on how constructors work yet, so I'll use a
: fill-in syntax.
:
: class Person {
: has $.name is private;# No accessor generated
: has $.age;
Attributes are probably private by default. Methods are public
by default.
: method new($n, $a) {
: ($.name, $.age) = ($n, $a);
: return bless; # bless me => myself
: }
: }
That would need to be a .bless, since bless is not longer a
builtin, but a class method. So I'd make it:
class Person {
has $.name;
has $.age is public;
method new($n, $a) {
($.name, $.age) = ($n, $a);
return .bless;
}
}
which is short for something like:
class Person {
has $.name;
has $.age;
method new($class: $n, $a) {
($.name, $.age) = ($n, $a);
return $class.bless;
}
method age () is rw {
return $.age;
}
}
There may well be a property on a class that makes all its attributes
public by default, so it acts more like a struct in C++.
As for constructor syntax, I suppose we might make use of the $. notation
like this:
method new($.name, $.age) {
return $class.bless;
}
and it would be assumed that those args go straight into the object. We
also have to thrash out the difference between "new" and "init". An
init() call might occur within a bless, in which case you might just
write
method init($.name, $.age) {...}
Maybe the default initializer is
method init($.name = undef, $.age = undef, *@extras) {...}
So we might actually end up with a constructor calls looking like
$class.bless(name => $me, rank => "low", serial => 12345);
Named parameters tend to work a lot better than positional for constructors,
especially if the parameters intended for a different initializer can be
ignored.
But this is all Apo 12, so still highly speculative...
Larry
Re: purge: opposite of grep
Michael said:
> I worry that C sounds too much like
> something class-related
'Classify' also seems wrong if some items are
thrown away. I like 'part':
(@foo,@bar) := part { ... } @source;
Headed off in another direction, having a sub
distribute its results like this reminds me of:
... -> ...
Can arrays on the rhs of a -> ever mean
something useful?
--
ralph
Re: Quick translation wanted
> Date: Fri, 06 Dec 2002 11:15:20 -0800
> From: Larry Wall <[EMAIL PROTECTED]>
>
> As for constructor syntax, I suppose we might make use of the $. notation
> like this:
>
> method new($.name, $.age) {
> return $class.bless;
> }
Come to think of it, new is a class method, not an object method. How
is that specified again? Is there going to be sugar to blur that
distinction for constructors?
Luke
Re: Quick translation wanted
On Fri, Dec 06, 2002 at 12:27:31PM -0700, Luke Palmer wrote:
: > Date: Fri, 06 Dec 2002 11:15:20 -0800
: > From: Larry Wall <[EMAIL PROTECTED]>
: >
: > As for constructor syntax, I suppose we might make use of the $. notation
: > like this:
: >
: > method new($.name, $.age) {
: > return $class.bless;
: > }
:
: Come to think of it, new is a class method, not an object method. How
: is that specified again? Is there going to be sugar to blur that
: distinction for constructors?
You'll not that $class was declared typeless, so it doesn't matter if it was
actually a class or an object of that class.
Actually, that last example was wrong--it should have been
method new($.name, $.age) {
return .bless;
}
or
method new($class: $.name, $.age) {
return $class.bless;
}
But in either case, if $class is untyped, it can work with either cloning
or class-based constructors.
Larry
Re: In defense of zero-indexed arrays.
On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote: > Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 > will benefit most users. Do not invoke legacy. [1] Answer 1: Ignoring legacy, it won't. Answer 2: Because C uses 0-based indexes, Parrot is written in C, and it would be just painful to switch back and forth when working on different layers of the system. (Not a legacy argument, unless you want to argue that Parrot is a legacy system.) Answer 3: In a lower-level language than Perl, an array is usually a block of memory divided into array elements. The index is the offset from the start of the array. In languages like C which allow pointer arithmetic, it makes sense for the array index to be the element offset, to allow a[i] to be equal to *(a + i). Higher level languages should follow this convention, for consistency. (Again, not a legacy argument, since it offers a first-principles rationale for 0-based arrays in certain contexts.) - Damien
Re: In defense of zero-indexed arrays.
> 2002-12-05 10:45:39, 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. > :) The other (reverse) way out, i'm not trying to make an essay, just think out loud but if you have $string = "Hello World", and you want the last three chars, you do: $wanted = substr $string, -3; If the first index was 1, it could be ok too, but what would be offset 0? What if someone was looking at his string backwards? $pos = 1; # 0 | 1 # - substr $string, $pos--, 1; # 'H' | 'e' substr $string, $pos--, 1; # 'd' | 'H' substr $string, $pos--, 1; # 'l' | '' ? substr $string, $pos--, 1; # 'r' | 'd' ? Dont ask me why someone would do that... But i expect to get the last $string's char with $pos == -1, not 0. I also find the 'offset' idea to be consistent with binary math. After all, with bytes, 0x7F + 1 == +0d127 but also -0d128... and i found it sometimes useful to be able to mix signed and unsigned values. One could argue it's not the way to go, it's tricky, you dont mix signed/unsigned... blah. Walking is tricky, bicycling is tricky, remember the first time you tried and you fell? blah. no more args :-) (yet another lurker)
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: > John Williams wrote in perl.perl6.language : > 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 Or, to follow the spirit rather than the letter of Unix, how 'bout "ere" for "Elide REgex" or "tang" for "Tog's A Negated Grep"? /s
Perl 6 and Set Theory
=head1 Perl 6 and Set Theory
This document will introduce a new way of thinking about some Perl 6
constructs. In addition, it proposes some minor changes that would
help this way of thinking be more consistent. These changes may make
Perl 6 a better language in general, as a side effect.
Even in absence of an explicit "set" type, Perl 6 is quite proficient
in set theory. There are two types of sets it knows about: finite and
infinite. The former we call "junctions," while "classes" make up
infinite sets.
=head2 Junctions
Junctions are a transparent mechanism for dealing with finite sets.
They indeed hold a discrete set of objects, but operations on the
junction are automatically delegated to operations on its members.
The two types of junctions, disjunctive (C) and conjunctive
(C) just determine how the junction is evaluated in boolean
context.
The expressions:
1 | 2 | 3
any(1, 2, 3)
1 & 2 & 3
all(1, 2, 3)
represent the set:
{ 1, 2, 3 }
Which we will call N. Performing some operation I on them
constructs and returns the set:
{ z(x): x ∈ N }
If, for example, this operation is C<{ $^x + 2 }>, we have:
{ x + 2: x ∈ N }
or
{ 3, 4, 5 }
If that was a comparison operation, say C<{ $^x > 2 }>, the resultant
set would be:
{ undef, undef, 1 }
Evaluating this in boolean context should be true if the junction was
conjunctive, and false if it was disjunctive. So, for a junction J,
boolean context evaluation is defined as follows:
{ ∃x: x ∈ J ∧ ?x, disjunctive
?J ≡ {
{ ∀x: x ∈ J ⇒ ?x, conjunctive
That is, the "type" of junction just determines whether the quantifier
is existential or universal.
There is one behavior of junctions, however, that doesn't work with
this definition: If a boolean operation is applied in non-boolean
context to a junction, it will return a junction of only the values
for which the condition evaluated true. But with a few minor changes,
this can be achieved:
• Junctions discard Cs on-sight (i.e. C can never be
a member of a junction).
• Comparison operators return C if they fail, and their
left-hand side "C" if they succeed.
• Comparison operators are right-associative.
Unfortunately, the last change clobbers the left-short-circuiting
behavior of comparison operators. A way to fix this would be to treat
a chain of comparison operators as a single n-ary operator. Other
methods for fixing this are welcome (and encouraged).
Note that the definition of how junctions behave in itself allows
operators involving more than one junction to represent the outer
product of those junctions with respect to an operator. Consider two
sets, A = any(1,2,3), and B = all(4,5,6).
A + B = { x + B: x ∈ A }
= { { x + y: y ∈ B }: x ∈ A }
= { { 5, 6, 7 }, { 6, 7, 8 }, { 7, 8, 9 } }
Where each inner set is a conjunctive set, and the outer is a
disjunctive set. If you call this resultant set C, and ask:
5 < C < 9
It would be true (in fact, "C<5 but true>"), as all(6, 7, 8) would
match.
=head2 Classes
In Perl 6, classes represent infinite sets of objects. The class
C represents the set of integers, C the set of all numbers,
including the integers. Inheritance represents supersets. Finite
sets, or junctions, can be used for union and intersection of these
infinite sets.
Unlike junctions, classes are not transparent interfaces to their
members. You can't say C<< Int > 10 >> to find out whether all
integers are greater than 10. There is, in fact, no way to assert
this in Perl, as Perl would have to instantiate ℵ₀ objects, which
would take ℵ₀ seconds (forever). Similarly with Num, except now
there's ℵ₁ objects and seconds (foreverer).
For instance, to declare a variable that can represent either an
integer or a string:
my (Int | Str) $var;
The type of that variable is the union of the sets of integers and
strings. The value of $var must be a member of at least one of those
sets.
Since a derived object can be used in place of its parent anywhere, it
must represent an improper superset of its parent. This seems
backwards, but if you think about it logically: Every member of the
parent set needs to be a member of the child set; every member of the
child set need not be a member of the parent set. Q.E.D.
Multiple inheritance represents a superset of multiple sets.
C or C represents the "universe"; i.e. the set of
all objects. The null junction C represents the empty set
(which is different from C, as proposed above).
It is an interesting issue whether any junction can be used as a
class. That is:
my (1 | 2 | 4) $var;
would declare $var to only accept values 1, 2, and 4. This probably
introduces too much complexity for what it's worth.
=head2 Summary
The rules for a junction J, again, are:
z(J) ≡ { z(x): x ∈ J }
{ ∃x: x ∈ J ∧ ?x, disjunctive
?J ≡ {
{ ∀x: x ∈ J ⇒ ?x, conjunctive
Classes have no such rules, as t
Re: Stringification of references and objects.
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: >>> 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 :) > > I think people like it fine, but many people don't want it to be the > default stringification. Like I said in an earlier thread, the > problem is that there's "stringification for output purposes" and > "stringification for debugging purposes", but we have to chose one or > the other to be the default. I'd rather the debugging one _not_ be > the default, personally, because I imagine the other usage is more > common. Well, personally I think you're very wrong. Kent Beck is good on this in 'Smalltalk Best Practice Patterns': The two audiences for strings generated by objects, you and your client are often in conflict. You want all the internal, structural details of your object laid out in one place so you don't have to go searching layers and layers of objects to find what you want. Your client assumes the object is working correctly and just wants to see externally relevant aspects of the object in the string. He notes that VisualWorks Smalltalk makes the distinction between 'displayString', for the user oriented stringification and 'printString', for the programmer oriented. Personally I reckon that having the the default behaviour be the 'debugging' string makes too from the point of view of separation of concerns; generally you want to separate formatting from the objects themselves. Also, the debugging approach makes sense from the point of view of a 'composite' object. One can imagine cases where a contained object makes incorrect assumptions about how it is being displayed, which could cause problems for the implementation of the container's as_string method; instead of simply doing: join "\n\t" .members (say), you could find yourself adding class based overrides for different sorts of member objects and it could all get ugly quickly. > An obvious counterproposal would be to say that references are > invisible to stringification (e.g. it stringifies to whatever its > contents stringify to). This would seem to be in keeping with the the > spirit of arrayref/array transparentness, etc. Personally I'm not keen on this idea. The distinction between the thing itself and a pointer to the thing is an important distinction for the programmer to be aware of. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Stringification of references and objects.
> This is a bit of an oversimplification. $foo and @foo do not always > behave the same, even if $foo and @foo refer to the same array object. > In particular, $foo doesn't behave like @foo in a list context. > Scalars must continue to behave like scalars in list context, even > if they're internally composite. Am I the only one here who thinks Perl 6's rules for arrays/lists/refs are getting way too complicated? This is getting even worse than C's confusion of them. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 01:08 PM, Piers Cawley wrote:
He notes that VisualWorks Smalltalk makes the distinction between
'displayString', for the user oriented stringification and
'printString', for the programmer oriented.
One could imagine a scenario in which a user could accomplish an
unlimited number of "styles" of stringification by creating multiple
subclasses of C, one per desired style:
class FormalStr is Str;
class InformalStr is Str;
class PersonName {
...
method FormalStr { "$.hon $.first $.middleInitial\. $.last" }
method InformalStr { $.nick || $.first }
}
my PersonName $name = .new(...);
my FormalStr $s = $name;# "Dr. William P. Smith"
my InformalStr $s = $name;# "Bill"
Whether that is good, bad, or indifferent I leave to the OO Police.
But the same approach could be used for Str and DebugStr, etc. It just
depends on what audience we want Perl6 str's to be geared for.
(Ignoring the various context/coercion issues raised by the above.)
MikeL
Re: Usage of \[oxdb]
On Fri, Dec 06, 2002 at 03:24:44PM +1100, Damian Conway wrote:
> 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)
I just had this thought - can I interpolate in there?
Something like
"\c[$(call_a_func())]"
and I interpolate the string returned by call_a_func() using whatever
interpolation system it finds itself in. (so the same function could
create the literal control characters if it finds itself in "\c[...]", or
the pretty-printed version if it finds itself within "\\c[...]"
I'm not sure if this is useful - I think its only benefit is to save a
string eval occasionally, with the downside of being obscure, complicating
understanding (interpolation becomes run time rather than compile time if
it's non-constant), and possibly the implementation.
[No I'm not smoking anything. I'm drinking tea today. Maybe it's just side
effects of over-exposure to london.pm yesterday, or reading Damian's book
(If it moves^Wis a reference - bless it! :-))]
Nicholas Clark
PS Time for a second edition:
perl5.8.0 -lwe 'format FOO = ' -e '.' -e '$a = *FOO{FORMAT}; print ref $a'
FORMAT
Re: Stringification of references and objects.
On 12/6/02 4:41 PM, Michael Lazzaro wrote:
> my PersonName $name = .new(...);
> my FormalStr $s = $name;# "Dr. William P. Smith"
> my InformalStr $s = $name;# "Bill"
>
> Whether that is good, bad, or indifferent I leave to the OO Police.
I'm not even deputized, but I call foul: excessive use of subclassing ;)
Even in Perl 5 code, I end up having multiple stringification methods for
things like error messages. But I simply use different method names for
each (e.g. error() and public_error()), and don't bother with overloading ""
at all.
I think the desire to have stringification DWIM is now bordering on RMMP
("read my mind, please" :) Yes, there will probably be many WTDI in Perl 6,
but I doubt any will end up beating the simplicity and clarity of named
methods.
Standardizing these methods names in an effort to help out debuggers seems
reasonable, but I wouldn't go much further than that. In fact, I'd go so
far as to say that the default stringification of most objects should
probably still be something like FOO(0x1234), since I frequently use those
strings to find out if two things are pointing to the same object. At the
very least, some sort of similar "unique identifier" should be accessible to
any stringification method writer...
-John
Re: Stringification of references and objects.
> This is a bit of an oversimplification. $foo and @foo do not always > behave the same, even if $foo and @foo refer to the same array object. > In particular, $foo doesn't behave like @foo in a list context. > Scalars must continue to behave like scalars in list context, even > if they're internally composite. Am I the only one here who thinks Perl 6's rules for arrays/lists/refs are getting way too complicated? This is getting even worse than C's confusion of them. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Stringification of references and objects.
> This is a bit of an oversimplification. $foo and @foo do not always > behave the same, even if $foo and @foo refer to the same array object. > In particular, $foo doesn't behave like @foo in a list context. > Scalars must continue to behave like scalars in list context, even > if they're internally composite. Am I the only one here who thinks Perl 6's rules for arrays/lists/refs are getting way too complicated? This is getting even worse than C's confusion of them. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Stringification of references and objects.
Sent to the wrong list. Ignore, please. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: logical_not issue
At 5:47 PM -0500 12/3/02, David Robins wrote: On Tue, 3 Dec 2002, Dan Sugalski wrote: At 4:29 PM -0500 12/3/02, David Robins wrote: >Enlightenment appreciated as always. This is something that'll come up with perl 6 reasonably soon as well. The solution for us is to have truth and falsehood be an optional property on the variable, potentially separate from the variable's value. The mechanism for that's not in yet. (I'd forgotten. It's on the todo list now) Was this discussed earlier (and if so, got a link?) or just sketched out and /* TODO */'d? Just sketched out and TODO'd. Adding an extra knob doesn't seem like all that good a solution (seems you'd run into weird issues, like a boolean PMC that was both true and false at the same time, or an undef value that was true); why not - True, but I'm looking at the boolean state of a variable as potentially part of a larger set of things. I freely admit a boolean PMC with a true value and a false property would be really bizarre. (So I'd suggest that you make it so that can't happen... :) It is OK for an undef value to be true, though. That's not only allowable, it has to be allowed. For perl, at least, it's how Larry plans on getting around the "function returns undef, but it's a real undef value, not a false 'I didn't work' value" issues we have in perl 5 now. - create immutable "true" and "false" PMCs That's fine. - have not P0, P1 set P0 to $1->get_bool ? true : false Sure, that works. I can't think of a good reason to have PMCs be able to return something fancier than true or false when we ask them for their logical negation. (Can any language override logical negation to return something besides true/false?) - and P0, P1, P2 set P0 to $1->get_bool ? $2->get_bool ? $2 : $1 : false - or P0, P1, P2 set P0 to $1->get_bool ? $1 : $2->get_bool ? $2 : false - xor P0, P1, P2 set P0 to whichever is set, false if both/neither Not for these, though. Logical and, or, and xor need to be delegated to the PMCs as they may be overridden, and binary logical operations may return something other than a plain true or false value. Otherwise perl's short-circuiting logical stuff behaves... oddly. And I know that can be overridden. - plus optionally allow a not Ix, Px op which sets Ix to 1 or 0, etc. Maybe. Would any compiler actually use this, though? I don't often care about what opcodes we put in, but apparently today I do. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Sean O'Rourke wrote: > On 5 Dec 2002, Rafael Garcia-Suarez wrote: > > John Williams wrote in perl.perl6.language : > > 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 > > Or, to follow the spirit rather than the letter of Unix, how 'bout "ere" > for "Elide REgex" or "tang" for "Tog's A Negated Grep"? Gah. s/Tog/Tang/. /s
Re: In defense of zero-indexed arrays.
Damien Neil wrote: On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote: Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 will benefit most users. Do not invoke legacy. [1] Answer 1: Ignoring legacy, it won't. Bingo. Answer 2: Because C uses 0-based indexes, Parrot is written in C, and it would be just painful to switch back and forth when working on different layers of the system. (Not a legacy argument, unless you want to argue that Parrot is a legacy system.) I doubt "most users" will be writing Parrot. Answer 3: In a lower-level language than Perl, an array is usually a block of memory divided into array elements. The index is the offset from the start of the array. Assuming the base index of the array is 0. More generally, the index of an array element is that element's offset from the base index of the array. Your argument is somewhat circular. I have oodles of arrays declared to start at 1980. Most of my arrays start at index 1. But then I'm a Fortran programmer. (And I hope that's not an opening for a language war thread.) Choice of language aside, having max_index == num_elements appeals to me. YMMV. In any case, the choice of default base index is less important for Perl than for other languages given how seldom arrays in Perl are accessed by index as opposed to manipulated by push, pop, for $x (@array) loops and such. brad
Re: purge: opposite of grep
Sean O'Rourke writes:
> On Thu, 5 Dec 2002, Sean O'Rourke wrote:
> > how 'bout "tang" for "Tog's A Negated Grep"?
>
> Gah. s/Tog/Tang/.
Wouldn't that mean we had to rename grep to 'gnat'? ("Gnat's Not A Tang",
presumably, never mind rot13 and reversal...)
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: In defense of zero-indexed arrays.
On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern 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] How about, because I like it? You may, of course, see that as a legacy argument, depending on our relative ages... :-) Anyway, that aside, I see no reason why we couldn't have array types that are explicitly declared with array bases other than 0. Perhaps even the built-in types can just take a range property: my @array is range(1...); One could even go so far as to have a pragma that causes all arrays declared in the current *lexical* scope to be based at 1. Call it use fortran; or some such... This is not problematical in the same way that $[ was, since we're limiting the effect to the current lexical scope. In fact, speaking of legacy, you'll recall that the "fix" for Perl 5 was to make $[ = 1; really do a lexically scoped declaration despite having the appearance of a global assignment. By the way, I noticed when visiting Uruguay that the elevators number the floors ...-2, -1, 0, 1, 2..., where 0 is the ground floor, and basement floors are negative. Way cool. Now all we have to do is convince everyone that the year 1 B.C. is the same as year 0 A.D., and 2 B.C. is the same as -1 A.D., and so on. Larry
Re: logical_not issue
[Fri, Dec 06, 2002 at 05:01:21PM -0500: Dan Sugalski]
> At 5:47 PM -0500 12/3/02, David Robins wrote:
> >On Tue, 3 Dec 2002, Dan Sugalski wrote:
> >- create immutable "true" and "false" PMCs
>
> That's fine.
>
> >- have not P0, P1 set P0 to $1->get_bool ? true : false
>
> Sure, that works. I can't think of a good reason to have PMCs be able
> to return something fancier than true or false when we ask them for
> their logical negation. (Can any language override logical negation
> to return something besides true/false?)
Be careful not to stop people doing interesting, useful but entirely
sick things. Current perl has problems rooted in the way it deals
with overloading and tieing that mean some things can't be done
without lots of rewriting.
I'd say that any operation who's result could be stored somewhere
should (nay, must) be able to return a fully fledged PMC.
That is to say, in "if ( !exp1 ) { ... }", !exp1 merely has to be true
or false, while $foo = !exp1 leaves !exp1 needing to be all manner of
things.
Alex Gough
--
It was at this time that some very pious Englishmen, known as the Early
Fathers, sailed away to America in a ship called the Mayfly; this is
generally referred to as the Pilgrims' Progress and was one of the
chief causes of America.
Re: In defense of zero-indexed arrays.
Larry wrote: : Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 : will benefit most users. Do not invoke legacy. [1] How about, because I like it? You may, of course, see that as a legacy argument, depending on our relative ages... :-) A practical argument in its favour is that it makes circular-lists-via-modulo: @list[++nextidx%7] = $nextval; and cyclic-value-mapping-via-modulo: $day_name = <>[$day%7]; both work correctly. Anyway, that aside, I see no reason why we couldn't have array types that are explicitly declared with array bases other than 0. Perhaps even the built-in types can just take a range property: my @array is range(1...); Surely, that would be: my @array is domain(1...); ??? Damian
Re: purge: opposite of grep
ralph wrote:
I worry that C sounds too much like
something class-related
'Classify' also seems wrong if some items are
thrown away. I like 'part':
(@foo,@bar) := part { ... } @source;
ralph and I don't often agree, but I certainly do in this case.
I like C very much as a name for this built-in. Must be
the vaguely biblical association ;-)
Headed off in another direction, having a sub
distribute its results like this reminds me of:
... -> ...
Can arrays on the rhs of a -> ever mean
something useful?
Sure. It means that the key of the pair is an array reference.
Damian
Re: Usage of \[oxdb]
Nicholas Clark mused: I just had this thought - can I interpolate in there? Something like "\c[$(call_a_func())]" Why not just: "$(chr call_a_func()]" ??? Damian
Re: purge: opposite of grep
Dave Whipp wrote:
I notice everyone still want Int context for eval of the block:
Pease don't forget about hashes. Is there such a thing as
'hashkey context'?
I doubt it. Unless you count Str context.
Perl6 is much better than Perl5 for naming parameters. Could
we make the following work?
( low=>@under,
mid=>@in_range,
high=>@over )
= partition @input -> $v {
$v < 10 ?? "low" :: $v > 20 ?? "high" :: "mid";
};
I very much doubt it. I think at that point you really want:
for @input -> $v {
push ($v < 10 ?? @under :: $v > 20 ?? @over :: @in_range), $v;
}
Also, can I return superpositions (sorry, junctions), to provide
multiple classifications? Or would I return an array for that?
A (dis)junction ought to work there.
Damian
Re: purge: opposite of grep
Michael Lazzaro wrote:
How would you do something like:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
Since I don't understand what that's supposed to do, I probably *wouldn't*
do something like it. What effect are you trying to achieve?
Damian
RE: purge: opposite of grep
Damian Conway:
# > Also, can I return superpositions (sorry, junctions), to provide
# > multiple classifications? Or would I return an array for that?
#
# A (dis)junction ought to work there.
That sounds horribly scary...
--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
IMCC and locals/lexicals
Leo --
Here's a Jako snippet:
var int x = 5;
{
var int x = 3;
print x;
}
print x
A naiive translation to imcc might be:
.sub _foo
.local int x
x = 5
.local int x
x = 3
print x
print x
.end
but (of course) that leads to an "x already defined" error.
I was hoping to use .local for all my variables, but I don't see a way to
handle
scopes with the IMCC machinery. It looks like the perl6 compiler uses
virtual
registers so it can do its own scoping stuff.
Is IMCC intended to (eventually) have scoping support for .local? Wouldn't
that require .scope ... .endscope directives, which would correspond to
the
open and close braces above? The .namespace ... .endnamespace directives
look suspiciously like they might be the ones I need. Based on a quick
look
at the source (didn't see any examples), this seemed reasonable, but it
doesn't help:
.sub _foo
.local int x
x = 5
.namespace ANON
.local int x
x = 3
print x
.endnamespace ANON
print x
.end
Is this supposed to be working in IMCC? Could you give me some pointers?
I'll need to bracket my subs and inner blocks with whatever scoping
mechanism
is appropriate.
I'd like to preserve my use of named .locals rather than move entirely to
temporaries,
since having the names around makes the .imc file easier to follow.
Regards,
-- Gregor
Re: In defense of zero-indexed arrays.
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> A practical argument in its favour is that it makes DC> circular-lists-via-modulo: DC> @list[++nextidx%7] = $nextval; DC> $day_name = <>[$day%7]; DC> both work correctly. not to defend 1 based arrays but all you have to do with the above is add the base offset to them: DC> @list[++nextidx%7 + 1] = $nextval; DC> $day_name = <>[$day%7 + 1]; in any case i like 0 based. the best argument i have seen so far is that is makes -1 a meaningful index. that is something pl1 and fortran could never do without a range declaration. and larry's property and pragma ideas are fine solutions for those who want impaired indexing. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
