On Sat, 26 Oct 2002, Leopold Toetsch wrote:
> I committed a new multiarray.pmc, now based on list.c. It's not totally
> finished yet (the clone codes needs some polishing to call the init_pmc
> method) and needs a lot more tests.
>
> But I hate failing tests ...
>
> leo
>
Well done Leo you
On 29 Oct 2002 at 5:45, Piers Cawley wrote:
> Whilst I don't wish to get Medieval on your collective donkey I must
> say that I'm really not sure of the utility of the proposed infix
> superposition ops. I'm a big fan of any/all/one/none, I just think
> that
>
> one(any($a, $b, $c), all($d, $
"Markus Laire" <[EMAIL PROTECTED]> writes:
> On 29 Oct 2002 at 5:45, Piers Cawley wrote:
>
>> Whilst I don't wish to get Medieval on your collective donkey I must
>> say that I'm really not sure of the utility of the proposed infix
>> superposition ops. I'm a big fan of any/all/one/none, I just thi
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Piers Cawley <[EMAIL PROTECTED]>
> Date: Tue, 29 Oct 2002 05:45:01 +
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Whilst I don't wish to get Medieval on your collective donkey I must
> say that I'm really not s
On Mon, 28 Oct 2002 13:09:37 -0800 (PST), Larry Wall <[EMAIL PROTECTED]> wrote:
> How do your read $a ! $b ! $c?
"Neither $a nor $b nor $c".
What? Aren't you able to see this invisible "neither" operator just at
the front? ;-)
/L/e/k/t
This is exactly what I wanted .= for.
@array .= splice(2,0,$element); # in-place, @array = @array.splice
@new = @array.splice(2,0,$element);
$sentence .= lcfirst;
The semantics are pretty clear, then it's just up to the compiler to optimize
it for in-place. Perhaps functions could ove
On Tue, 29 Oct 2002, Damian Conway wrote:
> Or one could define a copy-the-invoke method call operator (say, C<+.>):
As a rule I prefer to see "safe" operations have short names and
"dangergous" operations with longer ones. In this context that means "copy"
gets the short name and "in place" g
Luke Palmer <[EMAIL PROTECTED]> writes:
>> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>> From: Piers Cawley <[EMAIL PROTECTED]>
>> Date: Tue, 29 Oct 2002 05:45:01 +
>> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>>
>> Whilst I don't wish to get Medieval on your colle
> Cc: [EMAIL PROTECTED]
> From: Piers Cawley <[EMAIL PROTECTED]>
> Date: Tue, 29 Oct 2002 09:36:12 +
>
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> >> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> >> From: Piers Cawley <[EMAIL PROTECTED]>
> >> Date: Tue, 29 Oct 2002 05:45:01 +
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18139]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18139 >
Found yet another bug in sprintf: The code insists on prepending at
least one byte
"%
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote:
> Dan Sugalski wrote:
> > I'm currently leaning against it only because it doesn't ultimately help
> > the JIT. What we have now is wildly cool and damn useful (and has anyone
> > heard from Daniel lately, BTW?) but there's room fo
# New Ticket Created by "Aldo Calpini"
# Please include the string: [perl #18141]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18141 >
due to a bug in config/auto/stackdir.pl, Configure.pl
was unable to determine PARROT_
Josef Hook wrote:
Well done Leo you beat me to it, :-) i got finished last weekend with my
version of marray with underlying list.
If I had known, that i will rewrite it, I'd dropped a note - sorry for
work duplication. But it took an hour or so and I thought, just commit
early so that test
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #18142]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18142 >
Attached is a (big) patch that implements Parrot_destroy.
Test results with --gc-deb
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Well, on thinking a bit about this, there's no reason that we have to
> worry--it's perfectly OK for us to declare, unconditionally, that
> segment 0 is always bytecode, 1 line number info, and so on, with
> everything after position X (for some value of
Nicholas Clark wrote:
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote:
But then you end up with a messier two level register spillage problem at
compile time, don't you?
Yes.
...Which values to spill from fast to slow registers,
and which values to spill further from slow
[EMAIL PROTECTED] (Markus Laire) writes:
> In this case I find the latter to be easier to decode and more
> appealing. There are less chars and paretheses are seen much more
> easily.
Ack, I guess that means we need a one character DWIM operator.
Although "..." comes pretty close, I suppose.
>
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18144]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18144 >
In order to do some debugging with PackFiles I had resurrected
pdump. It now uses a va
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18139]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18139 >
Thanks, applied
leo
Dan Wrote,
>>This came up a while back in regards to GCC. Someone was working on a
>>front (or back, I don't recall) end to gcc to dump out the internal
>>representation of source as XML for some damn thing or other.
I am working on something like that, there are 2-3 other similar
projects. I
On Mon, 28 Oct 2002, Josh Wilmes wrote:
>
> If patch [perl #18127] goes in, we can dodge this bullet a while longer :)
Agreed. But since we can't dodge it forever, this seemed as good a place
to try it as any. (Particularly if your patch goes in, then I can't
possibly break anything :-).
--
Jason Gloudon (via RT) wrote:
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #18127]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18127 >
I have problems to understand the line below:
(not vot
Andy Dougherty wrote:
> but I'm unsure what to put for link_exe_out for each of the three
> compilers mentioned in config/init/hints/mswin32.pl, nor for the
> compilers used under OS/2 and VMS.
config/init/hints/mswin32.pl already defines what you need. is called
'ld_out' (also see my recent patch
On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote:
> >+cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr +
> >PARROT_PTR_ALIGNMENT)
>
> When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped
> during stack scanning by incrementing cur_var_ptr by sizeof(size_t) *
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18144]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18144 >
Thanks, applied - with little modifications.
leo
On Tue, 29 Oct 2002, Aldo Calpini wrote:
> Andy Dougherty wrote:
> > but I'm unsure what to put for link_exe_out for each of the three
> > compilers mentioned in config/init/hints/mswin32.pl, nor for the
> > compilers used under OS/2 and VMS.
>
> config/init/hints/mswin32.pl already defines what
--- Piers Cawley <[EMAIL PROTECTED]> wrote:
> >>
> >> one(any($a, $b, $c), all($d, $e, $f))
> >>
> >> Is a good deal more intention revealing than the superficially
> >> appealing than
> >>
> >> ($a & $b & $c) ^ ( $d | $e | $f )
Would it be practical/meaningful to say
$result = bitwis
On Tue, Oct 29, 2002 at 03:06:51AM -0700, Luke Palmer wrote:
> Superpositions will turn out to be unimaginably handy, possibly used
> in 10% or 15% of the code, so they get shorter names.
Statements like this bother me. Not because I don't think it might be
true, but because it's in future tense.
[EMAIL PROTECTED] (Jonathan Scott Duff) writes:
> Statements like this bother me. Not because I don't think it might be
> true, but because it's in future tense. If someone (named Damian :-)
> wrote a superposition synopsis that showed the many and varied uses of
> superpositions in contexts that
On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> Also the idea of allways using 'function' style for something so
> basic like superpositions doesn't appeal to me.
Superpositions are "basic" in a fabric-of-the-universe kind of way, but
they are hardly basic in the everyone-learns-
Simon Cozens <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Jonathan Scott Duff) writes:
>> Statements like this bother me. Not because I don't think it might be
>> true, but because it's in future tense. If someone (named Damian :-)
>> wrote a superposition synopsis that showed the many and va
At 11:22 AM -0600 10/29/02, Jonathan Scott Duff wrote:
On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
Also the idea of allways using 'function' style for something so
basic like superpositions doesn't appeal to me.
Superpositions are "basic" in a fabric-of-the-universe kind of
Dan Sugalski wrote:
> Leopold Toetsch wrote:
> >
> > Can we really have e.g. odd aligned PMCs on stack?
>
> the specs are available *somewhere*, and we should see
> about digging them up and getting a final answer one way
> or another.
A gold mine of cpu specs:
http://www.mit.edu/afs/sipb/contrib/
Matthew Zimmerman (via RT) wrote:
# New Ticket Created by Matthew Zimmerman
# Please include the string: [perl #18131]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18131 >
Thanks applied + printing of fingerprint.
leo
Jason Gloudon wrote:
On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote:
+cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr +
PARROT_PTR_ALIGNMENT)
When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are skipped
during stack scanning by incrementing cur_var_ptr by siz
At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote:
Jason Gloudon wrote:
On Tue, Oct 29, 2002 at 02:40:14PM +0100, Leopold Toetsch wrote:
+cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr +
PARROT_PTR_ALIGNMENT)
When PARROT_PTR_ALIGNMENT is not 1, that much pointers -1 are
skipped during
At 8:40 AM -0800 10/28/02, chromatic wrote:
On Sunday 27 October 2002 23:27, Brent Dax wrote:
Appearances are deceiving--the first adds some (unparsed?) source code,
the second adds information on file and line numbers, probably based on
offset into the bytecode.
Similar in terms of impleme
Jason Gloudon wrote:
ptrdiff_t is not a pointer type, so cur_var_ptr + PARROT_PTR_ALIGNMENT skips
exactly PARROT_PTR_ALIGNMENT bytes.
I did modify your patch slightly
- reversed directions (top->down is probably more common)
- increment by sizeof(void*)
This boost life.pasm gens from 270 ->
Dan Sugalski wrote:
At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote:
... Can we really
have e.g. odd aligned PMCs on stack? I don't think so. Or am I still
missing something?
There was some indication back when this was first implemented that the
i386, at least when running windows, could
At 4:57 PM +0100 10/29/02, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 3:27 PM +0100 10/29/02, Leopold Toetsch wrote:
... Can we really
have e.g. odd aligned PMCs on stack? I don't think so. Or am I
still missing something?
There was some indication back when this was first implemented th
[EMAIL PROTECTED]:
# > Well, on thinking a bit about this, there's no reason that
# we have to
# > worry--it's perfectly OK for us to declare, unconditionally, that
# > segment 0 is always bytecode, 1 line number info, and so on, with
# > everything after position X (for some value of X) left u
Here's my proposal for stage one: This patch is intended to define
explicitly what the different compiler and linker commands and flags
are, what they are supposed to mean, and how they are to be used.
Does this set of variables look sufficient for everyone, and are the
definitions clear? If so,
On Tue, 29 Oct 2002, Andy Dougherty wrote:
> Here's my proposal for stage one: This patch is intended to define
> explicitly what the different compiler and linker commands and flags
> are, what they are supposed to mean, and how they are to be used.
>
> Does this set of variables look sufficien
At 11:46 AM +0100 10/29/02, Juergen Boemmels wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
Well, on thinking a bit about this, there's no reason that we have to
worry--it's perfectly OK for us to declare, unconditionally, that
segment 0 is always bytecode, 1 line number info, and so on, wit
On Tue, 2002-10-29 at 11:48, Brent Dax wrote:
> [EMAIL PROTECTED]:
> # > Well, on thinking a bit about this, there's no reason that
> # we have to
> # > worry--it's perfectly OK for us to declare, unconditionally, that
> # > segment 0 is always bytecode, 1 line number info, and so on, with
> #
brian wheeler:
# Is this really necessary? Seems like a chicken-and-egg
# thing: to know which chuck the directory is in, you need to
# read the directory.
# However, since you've defined that the first chunk (0) is
# always the directory, there's really no need to have it in
# the directory
On Monday 28 October 2002 13:02, Dan Sugalski wrote:
> At 1:08 PM -0800 10/27/02, chromatic wrote:
> >Is there an underlying function used to add arbitrary (Unicode text)
> > metadata to the bytecode?
> Arbitrary metadata? Nope, no plans for that. While I can see it as a
> useful thing (though i
On Tue, Oct 29, 2002 at 05:18:53AM -0800, James Michael DuPont wrote:
>
> The gcc interface project has been offically restarted.
> http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html
Congratulations. I think it's an important project.
Tim.
On Tue, Oct 29, 2002 at 12:17:55PM -0600, Garrett Goebel wrote:
> Dan Sugalski wrote:
> > Leopold Toetsch wrote:
> > >
> > > Can we really have e.g. odd aligned PMCs on stack?
> >
> > the specs are available *somewhere*, and we should see
> > about digging them up and getting a final answer one way
Larry wrote:
All other things being equal, I think people will find modal operators
more confusing than if we just make separate operators.
Agreed.
That being said, I'm still wondering whether we can finesse it.
We can get close. But that might actually be counterproductive.
> Damian's d
On 29/10/02 16:05 -0500, Buddha Buck wrote:
> I was wondering...
>
> How persistant are superpositions? How pervasive are they?
Speaking of persistence, I just realized I'll need to start thinking about
YAML serializations of superpositions. My first cut at it would be:
---
letters: !su
Austin Hastings wrote:
I confess, I don't get it.
Yes, you did. :-)
To me, it appears to iterate over the input,
printing unique values except that two values ($start, $finish) are
considered to have already been encountered.
If that's all, then okay.
Okay then. That's all.
But does it
On 29/10/02 14:47 -0500, Dan Sugalski wrote:
> At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote:
> >This is why I am nervous about introducing terms like eigenbunny, etc.
>
> Oh, I dunno, I kind of like it. Of course, now my kids want
> eigenbunny slippers... (Though the trouble with those is th
Brian Ingerson wrote:
Speaking of persistence, I just realized I'll need to start thinking about
YAML serializations of superpositions. My first cut at it would be:
---
letters: !super [0, 1, 2]
digits: !super
- 0
- 1
- 2
...
Not quite. You also need to discri
On 29/10/02 13:26 -0800, Brian Ingerson wrote:
> On 29/10/02 16:05 -0500, Buddha Buck wrote:
> > I was wondering...
> >
> > How persistant are superpositions? How pervasive are they?
>
> Speaking of persistence, I just realized I'll need to start thinking about
> YAML serializations of superposi
Brian Ingerson wrote:
Oh! I just remembered the ultimate word for a container. It's "cozy", of
course!
Every eigenbunny needs a supercozy!
The plural of which is, presumable, "supercozens".
Now *I'm* really scared!
;-)
Damian
Damian Conway writes:
> My personal favorite solution is to use square brackets (for their dual
> array and indexing connotations, and because they highlight the operator
> so nicely):
>
> $count = @a + @b;
> @sums = @a [+] @b;
Mmm, yummy. I do have a question though (and apologies
On Tue, 29 Oct 2002, Austin Hastings wrote:
: --- Piers Cawley <[EMAIL PROTECTED]> wrote:
: > >>
: > >> one(any($a, $b, $c), all($d, $e, $f))
: > >>
: > >> Is a good deal more intention revealing than the superficially
: > >> appealing than
: > >>
: > >> ($a & $b & $c) ^ ( $d | $e | $f )
On Tue, 29 Oct 2002, Dan Sugalski wrote:
: Perhaps the best thing to do is to define a word operator for
: superpositions and, if they later become really popular, snag some
: generally-available* extended character to represent the operators.
Sorry, I believe in the transactional model of QM, a
On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
: On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
: > Also the idea of allways using 'function' style for something so
: > basic like superpositions doesn't appeal to me.
:
: Superpositions are "basic" in a fabric-of-the-universe kind
On Tuesday, October 29, 2002, at 09:08 AM, Jonathan Scott Duff wrote:
Statements like this bother me. Not because I don't think it might be
true, but because it's in future tense. If someone (named Damian :-)
wrote a superposition synopsis that showed the many and varied uses of
superpositions
[EMAIL PROTECTED] (Larry Wall) writes:
> So I would look favorably on finding a replacement for "superposition".
Predicate calculus? :) Seriously, I see no problem with calling them
"set operators".
--
For true believers, LORD would be K\textsc{nuth} in TeX, and
L\textsc{amport} in LaTeX. Athei
From: Simon Cozens [mailto:simon@;ermine.ox.ac.uk]
> [EMAIL PROTECTED] (Larry Wall) writes:
> > So I would look favorably on finding a replacement for
> > "superposition".
>
> Predicate calculus? :) Seriously, I see no problem with
> calling them "set operators".
Great minds think alike. Or in t
On Monday, October 28, 2002, at 01:25 PM, Michael Lazzaro wrote:
Again, I'm wondering if we're going about this wrong way -- perhaps we
need to go to more effort to save ^ as xor, and use something
different for hypers, like h<+> or h[+] or `+ or ~+ or ~~+, etc?
OK, I'm calling "Warnock's" on
At 10:02 AM -0800 10/29/02, Larry Wall wrote:
On Tue, 29 Oct 2002, Dan Sugalski wrote:
: Perhaps the best thing to do is to define a word operator for
: superpositions and, if they later become really popular, snag some
: generally-available* extended character to represent the operators.
Sorry,
On 29/10/02 09:58 -0800, Larry Wall wrote:
> On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
>
> So I would look favorably on finding a replacement for "superposition".
How about "christmasgift" or "gift"?
You don't know what it
On Tue, Oct 29, 2002 at 10:22:36AM -0800, Michael Lazzaro wrote:
> This is why I am nervous about introducing terms like eigenbunny, etc.,
> into the general vocabulary of the language. It attempts to make it
> sound harder than it is, I think -- there are plenty of uses for these
> operators o
On Tue, Oct 29, 2002 at 11:12:28AM -0800, Brian Ingerson wrote:
> On 29/10/02 09:58 -0800, Larry Wall wrote:
> > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> >
> > So I would look favorably on finding a replacement for "super
Oh boy, I just *hate* the idea of C for xor.
Hate it, hate it, hate it! Yuck, yuck, yuck!
But I do like Michael's idea of using C<@> as the hyperoperator marker
(the array connotation works well, I think). The only problem is that
we end up with too many C<@>'s in most expressions:
$count = @a +
On Tuesday, October 29, 2002, at 09:58 AM, Larry Wall wrote:
What kindergartener can't understand a
logically entangled list of nouns?
I want a tricycle or a video game or a teddy bear for Christmas.
I want a tricycle and a video game and a teddy bear for Christmas.
That's no differe
I think this may be in response to an earlier message of yours looking
for a replacement for "superposition." But I recall getting a Dilbert
calendar for Xmas some years back with a cover featuring the PHB saying
"I'm not indecisive - I'm flexible!"
Thus, flexops. And flexpressions (flexprs, for
On Tuesday, October 29, 2002, at 11:21 AM, Damian Conway wrote:
My personal favorite solution is to use square brackets (for their dual
array and indexing connotations, and because they highlight the
operator
so nicely):
$count = @a + @b;
@sums = @a [+] @b;
Any ideas on what
{ $^a op $^b
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Oh boy, I just *hate* the idea of C for xor.
DC> Hate it, hate it, hate it! Yuck, yuck, yuck!
tell us how you _really_ feel! :-)
DC> My personal favorite solution is to use square brackets (for their dual
DC> array and indexing
Can we have a secret handshake, too? Will we be blamed for the secret
features of the new US dollar bill?
"You know that eye-in-the-pyramid looking thingy? Well, notice what
character on the COMPUTER KEYBOARD that looks like? It's not by
coincidence that many of the programmers at the Treasury De
Michael Lazzaro wrote:
Any ideas on what
{ $^a op $^b }
would become?
It would be unchanged. Placeholders have nothing to do with hyperoperators.
And never have had.
Damian
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Tue, 29 Oct 2002 11:36:20 -0800
> Cc: [EMAIL PROTECTED]
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
>
> On Tuesday, October 29, 2002, at 11:21 AM, Damian Conway wrote:
>
At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote:
This is why I am nervous about introducing terms like eigenbunny, etc.
Oh, I dunno, I kind of like it. Of course, now my kids want
eigenbunny slippers... (Though the trouble with those is they may or
may not be keeping your feet warm--you can
Uri Guttman wrote:
what is a string complement? bitwise? i take it the numeric is one's
complement.
String complement treats the value as a string then bitwise complements every
bit of each character.
Integer complement treats the value as a int then bitwise complements every
bit.
DC>
At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote:
> This is why I am nervous about introducing terms like eigenbunny, etc.
Beats the heck out of "thingy". I had to read that chapter three times
before I realized that Randal hadn't just forgotten the real word.
I still feel uncomfortable saying
Simon Cozens wrote:
In this case I find the latter to be easier to decode and more
appealing. There are less chars and paretheses are seen much more
easily.
Ack, I guess that means we need a one character DWIM operator.
Although "..." comes pretty close, I suppose.
Great minds think alike.
On Tuesday, October 29, 2002, at 11:47 AM, Luke Palmer wrote:
[i.e. this change doesn't make any difference]
Doh! You're right, of course. For some reason I was thinking a long
while back that it would be confusing to have
{ $^a op $^b }
if ^ went back to meaning xor. But there's the s
damian's syntax table and his use of the term vectorizing made me wonder
why we call his [op] thing a hyperoperator? the word hyper i assume came
from hyperdimensional. but calling [] the vectorizing (or just vectored)
op variant makes much more sense.
@sum = @a [+] @b ;
that reads as ve
On Tue, Oct 29, 2002 at 11:26:56AM -0800, David Wheeler wrote:
> Well, I like "set operators," too, but what's the grammatical term for
> the above "logically entangled list of nouns"?
I'd call them "ents" if not for Austin Hastings' more sensible
"flexops" (unless someone wants to take a stab a
Scott Duff wrote:
Actually, I think we need a universal method on scalars that
gives the eigenstates of that value. It might be C<$val.eigenstates>
or maybe just C<$val.states>. The method would work on non-superimposed
values as well, in which cases it would just return a list containing
the val
Piers Cawley wrote:
Whilst I don't wish to get Medieval on your collective donkey I must
say that I'm really not sure of the utility of the proposed infix
superposition ops. I'm a big fan of any/all/one/none, I just think
that
one(any($a, $b, $c), all($d, $e, $f))
Is a good deal more intent
>>If someone (named Damian :-)
wrote a superposition synopsis that showed the many and varied uses of
superpositions in contexts that ordinary programmers can relate to, it
would bother me less when people make claims about the usefulness of
superpositions.
I'll take one of those for perl.com!
On Wed, Oct 30, 2002 at 06:51:14AM +1100, Damian Conway wrote:
> String complement treats the value as a string then bitwise complements every
> bit of each character.
Is that the complement of the codepoint or the individual bytes?
(I'm thinking utf8 here).
--
Nothing ventured, nothing lost.
On Tue, Oct 29, 2002 at 02:55:57PM -0500, Uri Guttman wrote:
>
> damian's syntax table and his use of the term vectorizing made me wonder
> why we call his [op] thing a hyperoperator? the word hyper i assume came
> from hyperdimensional. but calling [] the vectorizing (or just vectored)
> op varia
Brian Ingerson writes:
> On 29/10/02 09:58 -0800, Larry Wall wrote:
> > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> >
> > So I would look favorably on finding a replacement for "superposition".
>
> How about "christm
Larry...
> would look favorably on finding a replacement for "superposition".
any(
"multivalue",
"multival",
"opval"=> "andval"|"orval"|"xorval"|"nandval",
"opval"=> "andval"|"orval"|"exval"|"nonval",
"opval"=> "allval"|"anyval"|"oneval"|"noneval",
"set" => "andset"|"orset"
David Wheeler wrote:
Well, I like "set operators," too, but what's the grammatical term for
the above "logically entangled list of nouns"?
"Superposition".
Damian
On 10/29/02 3:13 PM, Damian Conway wrote:
> I suspect it will be quite unusual to see nested superpositions
> in code. Most folks are going to be using them for simple but
> very common checks like:
>
> [...]
>
> my $seen = $start | $finish;
> for <> -> $next {
> print $next unless $next == $seen;
Jonathan Scott Duff writes:
> On Tue, Oct 29, 2002 at 11:12:28AM -0800, Brian Ingerson wrote:
> > On 29/10/02 09:58 -0800, Larry Wall wrote:
> > > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> > > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> > >
> > > So I would look
I was wondering...
How persistant are superpositions? How pervasive are they?
I mean, will the following work?
$letters = any('a'..'z');
$digits = any('0'..'9');
$ndaTable = {
start => { $letters => 'OneLetter',
$digits => 'OneDigit' }
OneLetter => { $letters
I confess, I don't get it. To me, it appears to iterate over the input,
printing unique values except that two values ($start, $finish) are
considered to have already been encountered.
If that's all, then okay. But does it somehow skip all entries
before/after the delimiter?
Also, in a related ve
Michael Lazzaro writes:
>
> Any ideas on what
>
> { $^a op $^b }
>
> would become?
>
> MikeL
maybe
{ $_a op $_b }
{ _ op _ }
and we have simple ( ? ) rules to distinguish it from "space-eater" _
* _ surrounded by spaces is placeholder if term is ex
Buddha Buck wrote:
I was wondering...
How persistant are superpositions? How pervasive are they?
As I mentioned in a recent post, would expect them to be all-pervasive
and fully propagating.
I mean, will the following work?
I would certainly hope so! (modulo the syntax snafu)
In fact, i
Aaron Crane wrote:
Mmm, yummy. I do have a question though (and apologies if I've merely
missed the answer). We've got two productive operation-formation rules: one
saying "add a final = to operate-and-assign", and the other saying "wrap in
[] to vectorise". But no-one's said which order they
On Tuesday, October 29, 2002, at 01:50 PM, Damian Conway wrote:
PS: Is anyone collecting these examples. It would make writing that
perl.com
article much easier for me ;-)
But of course! Piers is summarizing this entire thread -- right,
Piers? :-)
Aaron Crane wrote:
@x [+]= @y;
I g
On 30/10/02 08:36 +1100, Damian Conway wrote:
> Brian Ingerson wrote:
>
> > Speaking of persistence, I just realized I'll need to start thinking about
> > YAML serializations of superpositions. My first cut at it would be:
> >
> > ---
> > letters: !super [0, 1, 2]
> > digits: !super
>
1 - 100 of 128 matches
Mail list logo
