PARROT requests!
Hi! Some simple (some other not so simple) suggestions to do on current parrot source: - make 'genclass.pl' put on the first line of the pmc file something like '-*- c -*-' in a comment, to tell emacs we are editing c code. - make 'genclass.pl' put a sample line of Parrot in comment before each class method. Best regards, Alberto Simões -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
RE: Perl6 grammar (take V)
Ashley Winters:
# > You've got a point. There's an easy way to say "I want a sub":
# >
# > my $sub = -> { ... }
# >
# > But I can't think of a similarly punctuation-intensive way
# to say "I
# > want a hash." (someone please step in and correct me).
#
# I nominate:
#
# $() == scalar()
# %() == hash()
# @() == array()
#
# For the above function:
#
# $hashref = %(function_returning_list_which_needs_to_be_hashified());
#
# That would make %() a hash constructor, just like {}.
IIRC, $() and @() are already being used to denote scalar and array
context. Of course, an array or hash in scalar context would probably
referencify.
I'd suggest that $(), @(), and %() all be syntactic sugar for a
context() keyword:
$(foo) = context SCALAR : foo();
@(foo) = context ARRAY : foo();
%(foo) = context HASH: foo();
foo(); = context VOID: foo();
\foo() = context REF : foo();
foo()[0..5] = context ARRAY, 6: foo();
my MyClass $x=foo() = my MyClass $x=context MyClass : foo();
This context() keyword would be like the opposite of want(). Of course,
something like:
context $x: foo();
Might not work.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: Streams vs. Descriptors
--- Josh Wilmes <[EMAIL PROTECTED]> wrote: > IMHO, all IO in parrot should go through PIO, so > file descriptors should > not be used at all. >From io.ops: "This will go away when print ops are all migrated to use ParrotIO instead of STDIO. Right now ParrotIO is not stable enough to replace STDIO." Maybe someone with more knowledge than me can explain what is unstable? Thanks, Stephen Rawls __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Perl6 grammar (take V)
On Monday 15 July 2002 07:52 am, Brent Dax wrote:
> Ashley Winters:
> # > You've got a point. There's an easy way to say "I want a sub":
> # >
> # > my $sub = -> { ... }
> # >
> # > But I can't think of a similarly punctuation-intensive way
> # to say "I
> # > want a hash." (someone please step in and correct me).
> #
> # I nominate:
> #
> # $() == scalar()
> # %() == hash()
> # @() == array()
> #
> # For the above function:
> #
> # $hashref = %(function_returning_list_which_needs_to_be_hashified());
> #
> # That would make %() a hash constructor, just like {}.
>
> IIRC, $() and @() are already being used to denote scalar and array
> context. Of course, an array or hash in scalar context would probably
> referencify.
But we don't need @() for array context, we have @{} for that.
@{foo()} would pass foo() a 'want' value of 'ARRAY', would it not? In fact,
the block in @{} as a whole has a 'want' value of 'ARRAY', and that
wantedness propagates to whatever statements return a value from the block.
So, I still want to use @() as a smart array constructor. If you pass an array
reference to @(), it would dereference. If you passed a list, it would
construct a reference. Perhaps it could even copy an array if it's passed one
directly...
my @copy = [ *@orig ]; # before
my @copy = @( @orig ); # after
Or not. That's weird.
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Initial Matrix class
I have successfully written and read an 8x8 matrix.
I will start writing some documentation.
Current code lacks a proper representation of a matrix ( it doesnt have a
matrix structure ) , it works directly in a Buffer structure. I really
need some people to discuss ideas with before deciding the Matrix
structure. This code also lacks a dynamic allocation. I think i will
implement a similar pool as perlhash bucket->pool.
I also have the code in a "old key styled parrot" version so i would
apreciate if someone told me how the new vtable structure will look like.
I also added a init_keyed function in my version of vtable something that
cvs of parrot lacks. Is this something that we may add later i do need it.
The implementation represent a point or a CELL with a pointer to data and
a virtual_addr.
Y
|
|
| [ 7 ][ 8 ][ 9 ]
| [ 4 ][ 5 ][ 6 ]
| [ 1 ][ 2 ][ 3 ] < a CELL
|-- X
|---|
X0
CELL:
struct _cell {
INTVAL *data;
INTVAL *virtual_addr; // this one is used to handle offsets
INTVAL submatrix; // Answers the question are we a submatrix
};
The virtual_addr is the answer from a calculation of a CELL's position:
the equation looks like this (y-1)X0+x
lets say we want a number representation on cell
[2,2] accordingly to our equation it would be 5
[2,2] = 5.
The return (5) value is then used as an offset value from Buffer
base address. The offset value (5) is stored in virtual_addr.
and is later on read when reading a CELL in a certain location.
Current code hase complexity:
O(1) writing.
O(1) reading and in worst case O(N).
This kind of implementation has a major drawback and thatis when doing
dynamic growth of the matrix the offset value would then be corrupted.
But i have a couple of ideas on howto solve this. One way could be glueing
several submatrices toghether or another way would be a polymorphic
equation.
The good thing is that it would be possible to represent a
multidimensional array fairly the same way, though the equation would grow
linearly as dimensions grow.
/Josef
Re: [PATCH] usleep, sleep(num)
On Sun, 14 Jul 2002, Dan Sugalski wrote: > At 9:36 PM -0500 7/13/02, Steve Purkis wrote: > >Hi, > > > >I was inspired by Time::HiRes to create 2 new simple ops for parrot: > >usleep(int), and sleep(num), to behave a bit more like the float version > >of the time op. > > > >I've attached a patch made off of the 0.0.6 source tree that works *for > >Linux* as a proof of concept to try and spark some discussion. > > I like this, and want it to go in--I think it's a capability we > should provide. However... Until it works on Win32 we need to wait. > Can someone running a Win box grab this and get a win version going? > When we have that, this can get committed. Fair enough - I have no access to a C compiler on Win32 ATM, so I'm afraid I won't be much use there. I will have a look at getting it working with Darwin when I have the chance. Cheers, -Steve
Re: Perl 6 Summary for week ending 20020714
> ..., and someone pointed out that it had a problem
> with code like "{ some_function_returning_a_hash() }". Should it give a
> closure? Or a hash ref? ...
Oh, well now that it's stated this way... (something went wrong in my
brain when I read the actual message) It returns a closure :(. A4 says
that as a term, { } define a closure, unless it contains a pair
constructor at the top level. But, thanks to Perl 6's smartness, that would
be excessive syntax anyway:
$hashref = some_function_returning_a_hash()
would do what you wanted.
Luke
Re: Initial Matrix class
I forgot to ask, should i make a patch in this stage early stage or should i wait until i got the memory stuff added? /Josef
Re: PARROT QUESTIONS: Use the source, Luke
On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote: > On Monday 15 July 2002 02:25 am, Brent Dax wrote: > > -C library wrappers: This is Parrot's version of the function, so it > > makes sense to prefix it with Parrot_. > > > > The third category I can see having a prefix of plat_ (for platform) or > > some such, and perhaps the second could have misc_, but I foresee that > > becoming annoying. (Which seems better to you, Parrot_sprintf or > > misc_sprintf?) > > c. parrot_sprintf Why does Parrot need C library wrappers? For portability? If so, then for portability external applications should also use the wrapped functions, which means they are part of the Parrot API and so they should be prefixed with Parrot_. Paul Kienzle
hyper operators - appalling proposal
In Apocalypse 2 Larry Wall wrote: > RFC 082: Arrays: Apply operators element-wise in a list context > > APL, here we come... :-) > > This is by far the most difficult of these RFCs to decide, so I'm going > to be doing a lot of thinking out loud here. This is research--or at > least, a search. Please bear with me. > So the resolution of this is that the unmarked forms of operators will > force scalar context as they do in Perl 5, and we'll need a special > marker that says an operator is to be auto-iterated. That special > marker turns out to be an uparrow, with a tip o' the hat to > higher-order functions. That is, the hyper-operator: > > > @a ^* @b Excuse me, but *bletch*, - this is as ugly as sin. Especially when we get into complex formulae. Imagine: @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a); (or would it be ^sqrt() ?) - This looks like sendmail :-) What is wrong with using @a * @b - the only reason I can think is to preserve a backward compatibility which is not needed? perl6 is supposed to prefer improvement over backward compatibility. The last thing we need is yet more line noise in perl6. This is a pity because in many ways perl6 changes all look rather attractive to me (e.g. consistent sigils, use of . vs ->, no need to make PDL arrays any different from perl arrays). Why do we need to preserve @x as array length when you are proposing @x.length ? As instigator of PDL, I am very concerned. Clearly inbuilt vectorization and compact arrays in perl6 will make PDL obsolete. I have no problem with that. A sign of success to get in the core. :-) What I do have a problem with is replacing it with a construct this ugly. If I was forced to write vector code like this I *WILL* give up on perl, and resort to Numerical Python or IDL instead. appalled, Karl Glazebrook
Re: [PATCH] usleep, sleep(num)
At 5:24 AM -0500 7/15/02, Steve Purkis wrote: >On Sun, 14 Jul 2002, Dan Sugalski wrote: > >> At 9:36 PM -0500 7/13/02, Steve Purkis wrote: >> >Hi, >> > >> >I was inspired by Time::HiRes to create 2 new simple ops for parrot: >> >usleep(int), and sleep(num), to behave a bit more like the float version >> >of the time op. >> > >> >I've attached a patch made off of the 0.0.6 source tree that works *for >> >Linux* as a proof of concept to try and spark some discussion. >> >> I like this, and want it to go in--I think it's a capability we >> should provide. However... Until it works on Win32 we need to wait. >> Can someone running a Win box grab this and get a win version going? >> When we have that, this can get committed. > >Fair enough - I have no access to a C compiler on Win32 ATM, so I'm afraid >I won't be much use there. I will have a look at getting it working with >Darwin when I have the chance. Don't sweat Darwin--it's got usleep as part of the core stuff, so it's fine. I think anything even remotely resembling a modern Unix is fine (which, oddly enough these days, includes VMS. Don't ask). Win9X and its descendants are what I'm worried about. I think we're likely OK on the NT side of the family. Beats me on the handhelds, though I'd be shocked if they didn't have short sleep capabilities. OTOH, we don't build there. Yet... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[SMALLEST PATCH ON EARTH]: for emacs users
Well... emacs does not recognize .pmc files as any kind of known type. I suggest to add a -*- c -*- comment on the generated files. For that, a simple line can be added on genclass.pl: Index: genclass.pl === RCS file: /cvs/public/parrot/classes/genclass.pl,v retrieving revision 1.11 diff -r1.11 genclass.pl 16a17,18 > /* Emacs flags: -*- c -*- */ > Hugs, Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: hyper operators - appalling proposal
On Mon, 15 Jul 2002, Karl Glazebrook wrote:
> In Apocalypse 2 Larry Wall wrote:
>
> > RFC 082: Arrays: Apply operators element-wise in a list context
> >
> > APL, here we come... :-)
> >
> > This is by far the most difficult of these RFCs to decide, so I'm going
> > to be doing a lot of thinking out loud here. This is research--or at
> > least, a search. Please bear with me.
>
> > So the resolution of this is that the unmarked forms of operators will
> > force scalar context as they do in Perl 5, and we'll need a special
> > marker that says an operator is to be auto-iterated. That special
> > marker turns out to be an uparrow, with a tip o' the hat to
> > higher-order functions. That is, the hyper-operator:
> >
> >
> > @a ^* @b
>
> Excuse me, but *bletch*, - this is as ugly as sin. Especially when we
> get into
> complex formulae. Imagine:
>
> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
That would not be very pretty, indeed. It would also not be very
efficient. (BTW, its b**2 - 4ac, not + :)A more efficient, pretty,
and clear way would be like this:
for @a; @b; @c; @s is rw ->
$a; $b; $c; $s {
$s = (-$b + sqrt($b**2 - 4*$a*$c)) / (2*$a)
}
> What is wrong with using @a * @b - the only reason I can think is to
> preserve
> a backward compatibility which is not needed?
> ...
> Why do we need to preserve @x as array length when you are proposing
> @x.length ?
I see your point. I went through a couple of my larger perl programs, and
the only time I used arrays in numeric context was in the C-style for
loop.
I think the idea is the red flag. If you have a 1-element array, you
wouldn't think a line like:
$end = @array - 1
is going to take a long time and stick a big reference into $end. And a
lot of Perl 5 programmers would do that. I guess this is back on
backwards-compatibility. But do you see my point?
I wouldn't mind if this proposal was accepted, but I also think the hyper
operator syntax is nice. At least for what I'm doing, in which it's
usually Yet Another shorthand for a C (or now just C) loop.
> If I was forced to write vector code like this I *WILL* give up on perl,
> and resort to Numerical
> Python or IDL instead.
Well, I guess that will be your loss... especially when Python is
assimilated by Perl. You will have nowhere to go :)
> appalled,
>
> Karl Glazebrook
attempting unappalment,
Luke
Re: hyper operators - appalling proposal
>Karl Glazebrook <[EMAIL PROTECTED]> disgusted: > > @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a); >[Stuff] >If I was forced to write vector code like this I *WILL* give up on perl, >and resort to Numerical >Python or IDL instead. > You can always use the map and foreach like we've done all along. And, frankly, I find this (surprisingly) legible. It's no great shakes, but there are regexen which are signifigantly worse. Remember, your never forced to do much of anything in Perl. Where I see a big win for hyper operators is in places where the scafolding code ordinarly clutters the actual work. I like being able to write @defaults ^//= 1; don't you? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Perl6 grammar (take V)
On Fri, 2002-07-12 at 13:22, Thomas A. Boyer wrote:
> Aaron Sherman wrote:
> > An example:
> >
> > $pid = fork() // -1;
> > if $pid < 0 {
> > # error ...
> > } else unless $pid {
> > # Parent
> > } else if $pid > 0 {
> > # Child
> > } else {
> > # Huh? Can't happen
> > }
>
> Of course, your indentation implies a different syntax than the parser actually sees.
I don't think so. What do you see when you look at that? Is there more
than one order? "if ... else unless ... else ..." is different from "if
elsif (!...) ... else ..." in what way?
I think you're confusing nested if statements (which is all you can do
in C, you don't have any other option) with this syntax for chaining
conditionals (which is more like a C switch). Granted you can do the
same thing in C in terms of effect, the language just doesn't give you a
handy syntax for it.
This syntax is actually much less ambiguous than "1 + 2 * 3 + 4", for
which you have to know precedence to resolve the ambiguity.
But, realistically I'm still doing it the Perl5 way. The "else if" vs
"elsif" distinction is only important to the "lexer" (not that there
will be a clear distinction in Perl6).
I'm still not 100% happy with dropping the ()s around the expr, but I
can see why it's appealing.
Re: hyper operators - appalling proposal
On Mon, 15 Jul 2002, Luke Palmer wrote: > On Mon, 15 Jul 2002, Karl Glazebrook wrote: > > > @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a); > > That would not be very pretty, indeed. It would also not be very > efficient. (BTW, its b**2 - 4ac, not + :)A more efficient, pretty, > and clear way would be like this: Not necessarily true! The compiler can figure out that a sequence of operators is hyped and avoid the temporary arrays (like your for-loop). It takes a little more work, but it's really not all that hairy when the necessary information is right in the syntax. Furthermore, the beauty of the hyper-operators (or the implicitly-vector normal operators below) is they don't give the programmer a loop body in which to do wierd things to the arrays. Since @y = $a ^* @x ^+ @b is all a single operation from the user's perspective, the compiler can make it faster than a loop written in pure Perl. > > What is wrong with using @a * @b - the only reason I can think is to > > preserve > > a backward compatibility which is not needed? > > ... > > Why do we need to preserve @x as array length when you are proposing > > @x.length ? > > I see your point. I went through a couple of my larger perl programs, and > the only time I used arrays in numeric context was in the C-style for > loop. I actually find myself using @a in numeric context quite a bit, but would have no objections to changing it to @a.length, since the former is completely bizarre to someone not familiar with Perl. > I wouldn't mind if this proposal was accepted, but I also think the hyper > operator syntax is nice. At least for what I'm doing, in which it's > usually Yet Another shorthand for a C (or now just C) loop. Maybe we could add a hyper-context to cut down on the line-noise without startling Perl 5 programmers: @solution = ^( -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a) ); Or (this might break something): @solution ^= -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a); (then watch as people have all their inplace-array-bitwise-xors change meaning;) I agree that the ^op syntax is painful if you have to type it a lot, but for the majority of people not using Perl for numerical code, hyper-operation is something out of the ordinary, and seems to deserve syntactic markers. For example: my @things = @args || @defaults; # @args if it is true, else @defaults # vs my @things = @args ^|| @defaults; # $args[$_] || $defaults[$_] for 0..X If infix operators are implicitly vector, the first's becoming the second could be a bit surprising. Even more so since, if we're handling infinite lists, hyper-operators should iterate over the number of items in their shorter argument. /s
Re: hyper operators - appalling proposal
On Mon, 2002-07-15 at 11:29, Karl Glazebrook wrote:
> complex formulae. Imagine:
>
> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>
> (or would it be ^sqrt() ?) - This looks like sendmail :-)
I would imagine that non-binary operators would simply have a hyper-form
(which could be provided as a module) such as:
hypersqrt(@x)
or perhaps
@x.^{sqrt()}
or something like that.
> What is wrong with using @a * @b - the only reason I can think is to
There's nothing really *wrong* with it. In fact, I see no reason that
they can't co-exist:
@a = @b * @c if @d == 2;
since making hyper-operation context sensitive seems a reasonable thing
to me.
> Why do we need to preserve @x as array length when you are proposing
> @x.length ?
This is one of the most common operations performed on arrays. It seems
like Perl6 should be hospitable in that respect.
> As instigator of PDL, I am very concerned. Clearly inbuilt vectorization
> and compact
> arrays in perl6 will make PDL obsolete. I have no problem with that. A
PDL does much more than that, but of course you know that :) I think a
Perl6 re-design of PDL will be much more streamlined, but still
essential.
> If I was forced to write vector code like this I *WILL* give up on perl,
> and resort to Numerical
> Python or IDL instead.
Sure, that's always an option. I think Perl has a lot going for it other
than the way vectorization happens, and with the ability to define your
own array behavior, you can pretty much do this however you want anyway.
Re: hyper operators - appalling proposal
[several replies flattened into one] On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote: > On Mon, 15 Jul 2002, Luke Palmer wrote: > >> On Mon, 15 Jul 2002, Karl Glazebrook wrote: >> >>> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a); >> >> That would not be very pretty, indeed. It would also not be very >> efficient. (BTW, its b**2 - 4ac, not + :)A more efficient, pretty, yeah the minus sign got lost in all the clutter. My point I think :) >> and clear way would be like this: > > Not necessarily true! The compiler can figure out that a sequence of > operators is hyped and avoid the temporary arrays (like your for-loop). > It takes a little more work, but it's really not all that hairy when the > necessary information is right in the syntax. > > Furthermore, the beauty of the hyper-operators (or the implicitly-vector > normal operators below) is they don't give the programmer a loop body in > which to do wierd things to the arrays. Since > > @y = $a ^* @x ^+ @b > > is all a single operation from the user's perspective, the compiler can > make it faster than a loop written in pure Perl. This is exactly what happens in PDL currently, but instead you say $y = $a * $x + $b where everything is an object > I actually find myself using @a in numeric context quite a bit, but > would > have no objections to changing it to @a.length, since the former is > completely bizarre to someone not familiar with Perl. glad you agree. I want to hear what Larry says. > >> I wouldn't mind if this proposal was accepted, but I also think the >> hyper >> operator syntax is nice. At least for what I'm doing, in which it's >> usually Yet Another shorthand for a C (or now just C) >> loop. > > Maybe we could add a hyper-context to cut down on the line-noise without > startling Perl 5 programmers: > > @solution = ^( -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a) ) Still looking ugly! > Or (this might break something): > > @solution ^= -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a); > But would not work if there was no = sign - e.g. foo(@x * @b +1) > (then watch as people have all their inplace-array-bitwise-xors change > meaning;) > > I agree that the ^op syntax is painful if you have to type it a lot, but > for the majority of people not using Perl for numerical code, > hyper-operation is something out of the ordinary, and seems to deserve > syntactic markers. For example: > > my @things = @args || @defaults; # @args if it is true, else @defaults > # vs > my @things = @args ^|| @defaults; # $args[$_] || $defaults[$_] for 0..X > > If infix operators are implicitly vector, the first's becoming the > second > could be a bit surprising. Even more so since, if we're handling > infinite > lists, hyper-operators should iterate over the number of items in their > shorter argument. I say the latter is more useful and it is time to break with the past > > On Monday, July 15, 2002, at 01:03 PM, Erik Steven Harrison wrote: > > > Where I see a big win for hyper operators is in places where the > scafolding code ordinarly clutters the actual work. I like being able > to write > > @defaults ^//= 1; > > don't you? > > -Erik @defaults = 1 > On Monday, July 15, 2002, at 01:52 PM, Aaron Sherman wrote: > Sure, that's always an option. I think Perl has a lot going for it other > than the way vectorization happens, and with the ability to define your > own array behavior, you can pretty much do this however you want anyway. Yes but it would be nuts to have PDL arrays do things one way and inbuilt compact arrays do things another way. Karl
RE: PARROT QUESTIONS: Use the source, Luke
Paul Kienzle:
# On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote:
# > On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > > -C library wrappers: This is Parrot's version of the
# function, so
# > > it makes sense to prefix it with Parrot_.
# > >
# > > The third category I can see having a prefix of plat_
# (for platform)
# > > or some such, and perhaps the second could have misc_,
# but I foresee
# > > that becoming annoying. (Which seems better to you,
# Parrot_sprintf
# > > or
# > > misc_sprintf?)
# >
# > c. parrot_sprintf
#
# Why does Parrot need C library wrappers? For portability?
# If so, then for portability external applications should also
# use the wrapped functions, which
# means they are part of the Parrot API and so they should be
# prefixed with Parrot_.
If at some point in the future, we no longer need Parrot_time, I don't
think we should have to leave it in for backwards compatibility with
embedders. Perhaps we should export it *if they ask for it somehow*,
but not by default, and not in a way that implies that it'll always be
there till the end of time.
BTW, Parrot_sprintf is a reimplementation with extra features, not a
compatibility wrapper.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: hyper operators - appalling proposal
At 2:09 PM -0400 7/15/02, Karl Glazebrook wrote: > >>On Monday, July 15, 2002, at 01:52 PM, Aaron Sherman wrote: >>Sure, that's always an option. I think Perl has a lot going for it other >>than the way vectorization happens, and with the ability to define your >>own array behavior, you can pretty much do this however you want anyway. > >Yes but it would be nuts to have PDL arrays do things one way and inbuilt >compact arrays do things another way. Oh, I dunno. I don't think it's all that bizarre to have Arrays operate one way and Matrices operate another way. But, then, that's just me. If you don't want to, you won't have to hyperoperate on matrices, or any other user-defined class, if you don't want to, as you're going to have to be able to override * for both the single element and aggregate case. The only real issue then is the behaviour of core arrays and hashes when dealt with in aggregate. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: hyper operators - appalling proposal
Karl Glazebrook: # On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote: # # > On Mon, 15 Jul 2002, Luke Palmer wrote: # > # >> On Mon, 15 Jul 2002, Karl Glazebrook wrote: # >> # >>> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a); # >> # >> That would not be very pretty, indeed. It would also not be very # >> efficient. (BTW, its b**2 - 4ac, not + :)A more # efficient, pretty, # # yeah the minus sign got lost in all the clutter. My point I think :) # # >> and clear way would be like this: # > # > Not necessarily true! The compiler can figure out that a # sequence of # > operators is hyped and avoid the temporary arrays (like your # > for-loop). It takes a little more work, but it's really not # all that # > hairy when the necessary information is right in the syntax. # > # > Furthermore, the beauty of the hyper-operators (or the # > implicitly-vector normal operators below) is they don't give the # > programmer a loop body in which to do wierd things to the arrays. # > Since # > # > @y = $a ^* @x ^+ @b # > # > is all a single operation from the user's perspective, the compiler # > can make it faster than a loop written in pure Perl. # # This is exactly what happens in PDL currently, but instead you say # # $y = $a * $x + $b # # where everything is an object # # > I actually find myself using @a in numeric context quite a bit, but # > would # > have no objections to changing it to @a.length, since the former is # > completely bizarre to someone not familiar with Perl. # # glad you agree. I want to hear what Larry says. # # > # >> I wouldn't mind if this proposal was accepted, but I also think the # >> hyper # >> operator syntax is nice. At least for what I'm doing, in # which it's # >> usually Yet Another shorthand for a C (or now # just C) # >> loop. # > # > Maybe we could add a hyper-context to cut down on the line-noise # > without startling Perl 5 programmers: # > # > @solution = ^( -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a) ) # # Still looking ugly! That statement looks ugly anyways. $solution = -$b + sqrt($b**2 + 4*$a*$c) / (2*$a); Ugly, ugly, ugly. It needs more spacing to make it pretty, not fewer carrots. Besides, mistakes like this are the alternative: #This should be $baz, not $foo... $foo=something_that_returns_an_infinite_array_ref(); ... #1654 lines later... $bar=$foo ** 2; #Anyone have a date for the heat death of the Universe? If the hyperoperization was implicit, the guy who wrote this would be sitting there twiddling his thumbs till he died. Now imagine that that error was in a CGI script running on Apache/NT. He *can't* kill the Perl process and make life better--he doesn't have the access. (I've learned this point the hard way. :^) ) With explicit, you just get the result of Inf ** 2 (which presumably is still Inf) in $bar. Perhaps neither is what you want, but at least it doesn't take forever to run. # > Or (this might break something): # > # > @solution ^= -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a); # > # # But would not work if there was no = sign - e.g. foo(@x * @b +1) # # > (then watch as people have all their # inplace-array-bitwise-xors change # > meaning;) # # # > # > I agree that the ^op syntax is painful if you have to type # it a lot, # > but for the majority of people not using Perl for numerical code, # > hyper-operation is something out of the ordinary, and seems # to deserve # > syntactic markers. For example: # > # > my @things = @args || @defaults; # @args if it is true, # else @defaults # > # vs my @things = @args ^|| @defaults; # $args[$_] || $defaults[$_] # > for 0..X # > # > If infix operators are implicitly vector, the first's becoming the # > second # > could be a bit surprising. Even more so since, if we're handling # > infinite # > lists, hyper-operators should iterate over the number of # items in their # > shorter argument. # # I say the latter is more useful and it is time to break with the past I say we shouldn't decide for the user what's more useful. Personally, I think the first is more useful, but that's irrelevant. With implicit vectorization, they have to jump through hoops to get the first one. So many hoops, in fact, that I can't even think of a decent way to do it. (@args.length ?? @args :: @defaults would work, but that's horrible.) With explicit, one of the ways of doing it is one character longer, but at least the other one is *possible to do*. # > On Monday, July 15, 2002, at 01:03 PM, Erik Steven Harrison wrote: # > # > # > Where I see a big win for hyper operators is in places where the # > scafolding code ordinarly clutters the actual work. I like # being able # > to write # > # > @defaults ^//= 1; # > # > don't you? # > # > -Erik # # @defaults = 1 Somehow, that seems wrong to me... # > On Monday, July 15, 2002, at 01:52 PM, Aaron Sherman wrote: # > Sure, that's always an option. I think Perl has a lot going #
RE: hyper operators - appalling proposal
In a message dated Mon, 15 Jul 2002, Brent Dax writes: > With explicit, you just get the result of Inf ** 2 (which presumably is > still Inf) in $bar. Perhaps neither is what you want, but at least it > doesn't take forever to run. Yes. This is my fear of hyperoperation being the default for normal aggregates. Loops--and large, multiply-nested, potentially-infinite ones--can spring out of code that doesn't look loopy at all. Erm... you know what I mean. :-) Karl, do you have any objection to marking aggregates for which hyperoperation is to be the default? Then you could say: my @foo, @bar; # Are the parens required in p6? # or my (@foo, @bar) is ; # Can you distribute properties? <...> @foo += @bar; where is matrix, hyper, or something along those lines (choosing great names is Larry, Damian and Allison's jobs, not mine :-) If we simply made such hyperoperated aggregates builtins rather than requiring user-defined classes, this would offer a compromise, would it not? Trey
[perl #819] [PATCH] imcc: bugfixes and life analysis
# New Ticket Created by Angel Faus
# Please include the string: [perl #819]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=819 >
Hi Melvin,
This patch does the following things:
- It includes patch #813 from Sean O'Rourke
- It fixes another bug in spill(), who was generating bad code
- It adds a bunch of work using the control-flow graph, analyzing the
exact places of the code where a variable is alive, and using this in
order to improve the interference analysis.
Incidentally, while tracking a memory bug, I added code to check the
results of all malloc calls. I've left it there, since it shouldn't
hurt.
I am sending you this through bugs-parrot, as people on the IRC
channel suggested.
Best,
-àngel
[EMAIL PROTECTED]
-- attachment 1 --
url: http://bugs6.perl.org/rt2/attach/3858/3565/a26fc6/patch_cfg.diff
-- attachment 2 --
url: http://bugs6.perl.org/rt2/attach/3858/3566/337423/test_cfg.imc
RCS file: /cvs/public/parrot/languages/imcc/cfg.c,v
retrieving revision 1.1
diff -r1.1 cfg.c
28c28
<
---
>
30a31
> ins = NULL;
41,42c42,45
< bb->end = ins;
< bb = make_basic_block(next);
---
> if (ins != NULL) {
> bb->end = ins;
> bb = make_basic_block(next);
> }
121a125,128
> if (e==NULL) {
> fprintf(stderr, "Memory error at bb_add_edge\n");
> abort();
> }
131a139,310
>
> void life_analysis() {
> int i;
>
> for(i = 0; i < HASH_SIZE; i++) {
> SymReg * r = hash[i];
> for(; r; r = r->next) {
> if (r->type == VTIDENTIFIER)
> analyse_life_symbol(r);
> }
> }
> }
>
> void analyse_life_symbol(SymReg* r) {
> int i;
>
> r->life_info = calloc(n_basic_blocks, sizeof(Life_range*));
> if (r->life_info == NULL) {
> fprintf(stderr, "Memory error at analyse_life_symbol");
> abort();
> }
>
> /* First we make a pass to each block to gather the information
> * that can be obtained locally */
>
> for (i=0; i < n_basic_blocks; i++) {
> analyse_life_block(bb_list[i], r);
> }
>
> /* Now we need to consider the relations between blocks */
>
> for (i=0; i < n_basic_blocks; i++) {
> if (r->life_info[i]->flags & LF_use) {
>
> /* This block uses r, so it must be live at
> the beggining */
> r->life_info[i]->flags |= LF_lv_in;
>
> /* propagate this info to every predecessor */
> propagate_need (bb_list[i], r);
> }
> }
> }
>
> /* analyse_life_block studies the state of the var r
> * in the block bb.
> *
> * Its job is to set the flags LF_use, or LF_read,
> * and record the intervals inside the block where
> * the var is alive.
> */
>
> void analyse_life_block(Basic_block* bb, SymReg* r) {
> int i, write_pos, read_pos;
> Instruction* ins;
> Life_range* l;
>
> l = make_life_range(r, bb->index);
> write_pos = -1;
> read_pos = -1;
>
> for (i=bb->start->index; i < bb->end->index; i++) {
> ins = instructions[i];
> if (ins==NULL) {
> fprintf(stderr, "Index %i of %i has NULL instruction\n",
> i, bb->end->index);
> fprintf(stderr, "Total numb. of instructions = %li\n",
> n_instructions);
> abort();
> }
> if (instruction_reads(ins, r)) {
> if (l->flags != LF_def) {
>
> /* we read before having written before, so the var was
> * live at the beggining of the block */
> write_pos = bb->start->index;
> l->flags = LF_use;
> }
> read_pos = i;
> }
>
> if (instruction_writes(ins, r)) {
> if (write_pos < 0) {
> l->flags = LF_def;
> write_pos = i;
> }
> else if (read_pos < 0) {
> /* there has not been any read until here, so the previous write
> * is irrelevant */
> write_pos = i;
> }
> else {
> /* this is new writing, after some reading */
> add_life_interval(l, write_pos, read_pos);
> read_pos = -1;
> write_pos = i;
> }
> }
> }
>
> /* At the end, we need to add the last range */
> if (read_pos < 0) read_pos = write_pos;
>
> if (write_pos >= 0)
> add_life_interval(l, write_pos, read_pos);
>
>
> /* The read_pos can latter be extended if it turns out
> * that another block needs the value resulting of this
> * computation */
> }
>
> /* add_life_interval records a new range of use of the var
> * and set the LF_lv_inside flag
> */
>
> void add_life_interval(Life_range *l, int from, int to) {
> int length = l->n_intervals;
>
> l->intervals = realloc(l->intervals, (length + 2) * sizeof(int) + 1);
> if (l->intervals == NULL) {
> fprintf(stderr, "Memory error at add_life_interval\n");
> abort();
> }
>
> l->intervals[length*2] = from;
> l->intervals[length*2 + 1] = to;
>
> l->n_interval
Tracking Patches (was RE: PARROT QUESTIONS: Use the source, Luke)
Brent Dax writes: >[EMAIL PROTECTED]: ># Good stuff. Didn't you also send out a draft PDD about how ># types should ># be named and managed in parrot at one point? I, for one, > >At one point I sent out a patch to PDD7 that handled type naming. (I don't know what happened to this specific patch... but) If you send your patches through the bugtracker to bugs-parrot bugs6.perl.org, then metadata can be attached to a specific patch. Also, by including [PATCH] in the subject, the tracker learns that it's a patch, useful for reports, such as http://www.parrotcode.org/openpatches. -R
[perl #820] [PATCH] byteorder.c
# New Ticket Created by "Tanton Gibbs" # Please include the string: [perl #820] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=820 > Adds some additional comments to byteorder.c and adds a byteorder.dev file. Tanton Gibbs -- attachment 1 -- url: http://bugs6.perl.org/rt2/attach/3860/3569/87ed3a/byteorder.diff -- attachment 2 -- url: http://bugs6.perl.org/rt2/attach/3860/3570/4f1c74/byteorder.dev byteorder.diff Description: byteorder.diff byteorder.dev Description: byteorder.dev
Re: Parrot contribution
On Fri, 12 Jul 2002, John Porter wrote: > > > >Which IRC network, which channel? > > > > I use irc.pobox.com, you can also try irc.rhizomatic.net > > Channel is #parrot > > Problem I have with irc (besides the fact that I don't, can't and won't > use it) is that all the good stuff that flows by isn't getting captured > and archived anywhere. Whadda mean? It's all in my scrollback. :-) - D <[EMAIL PROTECTED]>
Re: PARROT QUESTIONS: The PDDs
On Mon, 15 Jul 2002, Ashley Winters wrote: > PDD02: Common vtable format for all variables > Nice. I should be able to answer some of these. > Question: Why is the key param for keyed_int vtable functions a pointer? > Considering I have to implement all those functions to add a PMC... > seems odd to be passed a pointer to a value which is guaranteed to be > non-NULL. In some cases they are not guaranteed, but you are right, this is a valid point for a few cases. A little history: they were all originally not pointers. When I realized that you didn't *have* to specify a key for all args of certain ops (namely, those that take multiple PMCs), I made them all pointers (not following the logic through in my head like you did). I suppose they are all pointers now just for consistancy. If that's not a good enough reason (speak now people) then I'll change it for those cases where they will not be NULL. The real kicker is that I'll bet this is going to change in view of the multimethod vtable method non-method methodology that has been discussed recently. > Is every parameter for every vtable function IN? Err, I just found the > add_* functions. Answer: no. For a specification like this, perhaps > in/out could be added to parameters or something? It's loathesome non-C > clutter, I know. You don't have to put it in, I can live without it. :) If there's an output parameter, it's named "dest". That rule holds throughout the vtable spec. > Question: set_string_(native|unicode|other) specifies source or dest > format? I'd assume the string type is the destination's type. It does > coercion from the source STRING*'s format to the $1 format, right? Um, that one I'm not sure about, not being up to speed on strings. I'll get back to you in a few months (years??) :-) If the convention for integers/numbers is followed it would refer to the source, but that really doesn't make sense since the source string's encoding should be able to be determined without help. I would say it is the destination format. > I don't see any mention of thunking /(.*)(_keyed.*)/ functions to > $1(get_pmc$2()). > > Question: Are thunked _keyed methods provided by default for PMC implementors? > vtables.pod says there are 'sensible' defaults, but it seems to have been > written pre-keyed-PMCs. There are defaults for the _keyed(_int)? methods that will throw exceptions if you try to do an aggregate operation on a PMC that "inherits" those defaults. But like I said, expect everything to change with the multimethod stuff coming in. - D <[EMAIL PROTECTED]>
Re: PARROT QUESTIONS: Use the source, Luke
On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote: > >The last four are reserved by various C and C++ standards. > > I always hear this, but in real life it is never much of a problem. > Especially > with a namespace like [Parrot] It is a good idea to avoid using the reserved identifier space, not only because it avoids conflicts with vendor libraries, but for documentation purposes. The leading underscore means "system internal, do not touch"; blurring this meaning doesn't help. It's also unnecessary. It isn't like there aren't perfectly good alternatives--what's wrong with "Parrot__"? - Damien
Re: Streams vs. Descriptors
On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote: > 1) Async support. The IO system needs to be asynchronous and re-entrant > at the core, whether by threads or by use of the platform's async support. > Other things like callbacks assume other features of Parrot to be finished, > like subs/methods. Out of curiosity, what's the motivation for supporting true signal-driven async IO (which is what you seem to be referring to)? In my experience, nonblocking IO and a standard event loop is more than sufficient, and far easier to implement--especially portably. - Damien
Re: [PATCH] imcc: bugfixes and life analysis
At 05:25 AM 7/16/2002 +0200, Angel Faus wrote: >Hi Melvin, > >This patch does the following things: > > - It includes patch #813 from Sean O'Rourke > > - It fixes another bug in spill(), who was generating bad code > > - It adds a bunch of work using the control-flow graph, analyzing the >exact places of the code where a variable is alive, and using this in >order to improve the interference analysis. Thanks, applied. It is probably time for me to make a documentation pass. :) -Melvin
Re: vtables and multimethod dispatch
On Wed, 10 Jul 2002, Dan Sugalski wrote: > >What bothers me is this: the programmer needs to be able to predict > >what the machine is going to do with the code she gives it. > >And predicting how the machine is going to resolve the multimethod > >call could be, in any but trivial cases, far too difficult. > >Programmers will end up guessing -- or, even worse, not giving it > >a single thought -- and then we may as well be programming in PL/1. > >:-) > > Yeah, this definitely true, and I've been told it's an issue when there > are multiple routines that are almost, but not quite, correct. > > One place where we make it easier on ourselves at this level is > restricting the inheritance hierarchy. Since pretty much everything > inherits directly from default it's pretty simple to predict. I think that this inheritance stuff should be talked about before we run too far with this. Do we really want *two* inheritance trees per object in Perl 6? One language-level and one PMC-level? How would that even work? Right now the whole concept of "PMC Inheritance" is purely just a way to save implementors some typing. There is really no inheritance of any kind going on, it just sticks pointers to the default functions into the vtable structure method entries for undefined methods. I'm inclined to say that vtables shouldn't inherit at all, but I may be missing something important. I usually am. - D <[EMAIL PROTECTED]>
Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
Back to this again . .
> > ..., and someone pointed out that it had a problem
> > with code like "{ some_function_returning_a_hash() }". Should it give a
> > closure? Or a hash ref? ...
> Oh, well now that it's stated this way... (something went wrong in my
> brain when I read the actual message) It returns a closure :(. A4 says
> that as a term, { } define a closure, unless it contains a pair
> constructor at the top level. But, thanks to Perl 6's smartness, that would
> be excessive syntax anyway:
> $hashref = some_function_returning_a_hash()
> would do what you wanted.
Would it always? What if I had two functions (or more), all returning
part of the hash I want to package up? Can I do:
$hashref = some_function_returning_a_hash(),
some_other_function_returning_more_of_the_hash();
and get the result of both functions into the anonymous hash?
Besides, does
$hashref = some_function_returning_a_hash()
make $hashref simply refer to the result of the function, or does it
make $hashref refer to a hash containing a *copy* of the result of the
function? If Perl6 is going to do fancy things with functions returning
lvalues, which looks like the case, those two things aren't necessarily
the same thing.
Or, saying the same thing another way, does this:
$href = %hash;
which I presume will be legal Perl6, mean the same as this Perl5:
$href = \%hash;#A
or this Perl5:
$href = { %hash }; #B
and how would I say each of A and B in Perl6 unambiguously?
Automatic referencing and dereferencing is all well and good, and it
appears that it's here to stay in Perl6 (it's been in most Apocalypses),
but I don't think anyone's actually sat down yet to thrash out exactly
under what circumstances it happens.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"It's no good believing in somebody else if you can't believe in yourself. You
give them the reason to take all the power and wealth." - _Turn it Up_, Alan
Parsons
[perl #821] [PATCH] Update hanoi.pasm to use new keyed ops
# New Ticket Created by Tony Payne # Please include the string: [perl #821] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=821 > Updated hanoi.pasm to use the new (correct?) keyed ops. Basically used trial and error :-) to find the correct format. Would be good for someone to update parrot_assembly.pod to explain the current (or planned final) forms of these ops. If someone wants to key me in (pun intended), I'd be happy to update the docs accordingly. ++t -- attachment 1 -- url: http://bugs6.perl.org/rt2/attach/3864/3574/880aac/hanoi.diff Index: hanoi.pasm === RCS file: /cvs/public/parrot/examples/assembly/hanoi.pasm,v retrieving revision 1.4 diff -u -u -r1.4 hanoi.pasm --- hanoi.pasm 13 Jul 2002 17:38:43 - 1.4 +++ hanoi.pasm 15 Jul 2002 23:45:18 - @@ -64,21 +64,21 @@ # } MAIN: - set I5, P0, 1 #I5 = argv[0] + set I5, P0[1] #I5 = argv[0] new P0, .PerlArray new P1, .PerlArray new P2, .PerlArray new P3, .PerlArray - set P0, 0, P1 #P0 = [[],[],[]] - set P0, 1, P2 - set P0, 2, P3 + set P0[0], P1 #P0 = [[],[],[]] + set P0[1], P2 + set P0[2], P3 set I0, 0 loop_populate: add I1, I0, 1 - set P1, I0, I1 #P0=[[1,2,3,...],[0,0,0...],[0,0,0...]] - set P2, I0, 0 - set P3, I0, 0 + set P1[I0] I1 #P0=[[1,2,3,...],[0,0,0...],[0,0,0...]] + set P2[I0], 0 + set P3[I0], 0 inc I0 lt I0, I5, loop_populate set I1, I5 # size @@ -98,8 +98,8 @@ loop_rows: set I2, 0 loop_cols: - set P1,P0,I2 #P1 = P0[j] - set I4,P1,I1 #I4 = cursize; cursize=array[j][i] + set P1,P0[I2] #P1 = P0[j] + set I4,P1[I1] #I4 = cursize; cursize=array[j][i] sub I5, I0, I4 #I5 = size-cursize repeat S0, " ", I5 @@ -128,25 +128,25 @@ # I3 = dest_col MOVE: #vars used: I4, I5, I6, I7, I8, P1, P2 set I4, 0 #I4 = i - set P1, P0, I2 #P1 = array[start_col] + set P1, P0[I2] #P1 = array[start_col] loop_find_start_row: - set I7, P1, I4 #I7 = array[start_col][i] + set I7, P1[I4] #I7 = array[start_col][i] ne I7, 0, found_start_row inc I4# i++ lt I4, I0, loop_find_start_row# i < size found_start_row: set I5, I4 #I5 = start_row = i - set P2, P0, I3 #P2 = array[dest_col] + set P2, P0[I3] #P2 = array[dest_col] set I4, 0 # for( i = 0 loop_find_dest_row: - set I8, P2, I4 #I8 = array[dest_col][i] + set I8, P2[I4] #I8 = array[dest_col][i] ne I8, 0, found_dest_row # if(array[dest_col][i]) inc I4 # i++ lt I4, I0, loop_find_dest_row # i < size found_dest_row: sub I6, I4, 1 #I6 = dest_row = i - 1 - set P2, I6, I7 # array[dc][dr]=array[sc][sr] - set P1, I5, 0 # array[sc][sr]=0 + set P2[I6], I7 # array[dc][dr]=array[sc][sr] + set P1[I5], 0 # array[sc][sr]=0 bsr PRINT ret
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
Deborah Ariel Pickett:
# > > ..., and someone pointed out that it had a problem
# > > with code like "{ some_function_returning_a_hash()
# }". Should it give a
# > > closure? Or a hash ref? ...
# > Oh, well now that it's stated this way... (something went
# wrong in my
# > brain when I read the actual message) It returns a closure
# :(. A4 says
# > that as a term, { } define a closure, unless it contains a pair
# > constructor at the top level. But, thanks to Perl 6's
# smartness, that would
# > be excessive syntax anyway:
# > $hashref = some_function_returning_a_hash()
# > would do what you wanted.
#
# Would it always? What if I had two functions (or more), all returning
# part of the hash I want to package up? Can I do:
# $hashref = some_function_returning_a_hash(),
# some_other_function_returning_more_of_the_hash();
# and get the result of both functions into the anonymous hash?
Not directly--just use the hash {} constructor.
# Besides, does
# $hashref = some_function_returning_a_hash()
# make $hashref simply refer to the result of the function, or does it
# make $hashref refer to a hash containing a *copy* of the result of the
# function? If Perl6 is going to do fancy things with
# functions returning
# lvalues, which looks like the case, those two things aren't
# necessarily
# the same thing.
#
# Or, saying the same thing another way, does this:
# $href = %hash;
# which I presume will be legal Perl6, mean the same as this Perl5:
# $href = \%hash;#A
# or this Perl5:
# $href = { %hash }; #B
# and how would I say each of A and B in Perl6 unambiguously?
A. And unambiguously:
$href = \%hash; #A
$href = hash { %hash }; #B
# Automatic referencing and dereferencing is all well and good, and it
# appears that it's here to stay in Perl6 (it's been in most
# Apocalypses),
# but I don't think anyone's actually sat down yet to thrash out exactly
# under what circumstances it happens.
Autodereferencing happens whenever we have a scalar but we need an array
or hash; autoreferencing happens whenever we have an array or hash but
need a scalar (usually because of scalar assignment, but not
necessarily).
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
On Monday 15 July 2002 11:22 pm, Deborah Ariel Pickett wrote:
> Besides, does
> $hashref = some_function_returning_a_hash()
> make $hashref simply refer to the result of the function, or does it
> make $hashref refer to a hash containing a *copy* of the result of the
> function? If Perl6 is going to do fancy things with functions returning
> lvalues, which looks like the case, those two things aren't necessarily
> the same thing.
I don't think scalar context can ever make copies of aggregate data. Here's a
little experiment.
sub func {
return a => 10; # returns a single pair; not a list or a hash
}
$foo = func(); # $foo is a PAIR ref, not a hash ref
$foo = { func() } # $foo is a CODE ref
$foo = { *func() } # $foo is still a CODE ref, I assume?
$foo = %{ func() } # die "Not a HASH reference"
$foo = hash func(); # This should work
> Or, saying the same thing another way, does this:
> $href = %hash;
> which I presume will be legal Perl6, mean the same as this Perl5:
> $href = \%hash;#A
It always means A according to some apocalypse.
my %hash = (key => "bar");
sub foo {
return %hash;
}
$ref = foo();# $ref = \%hash
%copy = foo(); # %copy = { %hash }
%alias := foo(); # \%alias == \%hash
%$ref = foo(); # ($ref = {}) = %hash
> or this Perl5:
> $href = { %hash }; #B
The ways I can think to do that are:
%$href = %hash; # autovivify $href = {}, then copy
$href = hash %hash; # Perhaps * flattening is required?
> and how would I say each of A and B in Perl6 unambiguously?
I don't much like the effects of using %$foo as an lvalue. Having a context
sigil clobber the value doesn't seem very perl5ish. Perhaps I have my
blinders on and don't see where Perl5 does that.
> Automatic referencing and dereferencing is all well and good, and it
> appears that it's here to stay in Perl6 (it's been in most Apocalypses),
> but I don't think anyone's actually sat down yet to thrash out exactly
> under what circumstances it happens.
I think the rule of auto-hashifying only when an explicit pair is found is
gonna be hard to swallow.
I still have my vote on %() as a hash constructor in addition to {}. :)
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
Brent Dax wrote:
> $href = hash { %hash }; #B
Why the curlies? if C is a function (ctor), then surely these should
be parentheses. In this context, parentheses are optional, so this could be
written
$href = hash %hash;
Dave.
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
David Whipp:
# Brent Dax wrote:
# > $href = hash { %hash }; #B
#
# Why the curlies? if C is a function (ctor), then surely
# these should be parentheses. In this context, parentheses are
# optional, so this could be written
#
#$href = hash %hash;
C is not a function. It's a keyword, analogous to C.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
> I still have my vote on %() as a hash constructor in addition to {}. :)
The problem I see with that is that % as a prefix implies a
*dereferencing*, though years of Perl5 conditioning like this:
%{ $mumble } = return_a_hash();
print_hash( %{ $mumble } );
(Yes, the braces are optional; I'm assuming that they'll still be needed
in Perl6, when $mumble is something complex.)
Using %(...) to create a hashref, as { ... } does in Perl5, would go
against all that, because the purpose of making a hashref is to
*reference* something. Now a unary % operator/sigil/prefix might mean
referencing, or it might mean dereferencing, depending on whether the
symbols following are (...) or {...}. Ouch.
I suppose we're going to have that kind of thing already in Perl6,
though, with {...} meaning both ref and deref, just as it has in Perl5:
%foo{"abc"} # dereference-type op, extract member "abc".
hash { "abc" => 1 } # reference-type op, construct member "abc".
That's kind of ouchy too, come to think of it.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"You can't take me up, you can't wind me down, There's no escape but I'll never
drown, no wires or strings, no rough and smooth, just like fire and stings,
watch me closely, watch my every move." - _Wine from the Water_, Alan Parsons
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
On Tue, 16 Jul 2002, Deborah Ariel Pickett wrote:
> > I still have my vote on %() as a hash constructor in addition to {}. :)
>
> The problem I see with that is that % as a prefix implies a
> *dereferencing*, though years of Perl5 conditioning like this:
> %{ $mumble } = return_a_hash();
> print_hash( %{ $mumble } );
>
> (Yes, the braces are optional; I'm assuming that they'll still be needed
> in Perl6, when $mumble is something complex.)
>
> Using %(...) to create a hashref, as { ... } does in Perl5, would go
> against all that, because the purpose of making a hashref is to
> *reference* something. Now a unary % operator/sigil/prefix might mean
> referencing, or it might mean dereferencing, depending on whether the
> symbols following are (...) or {...}. Ouch.
As with $(), I assume %() would force hash context. Nothing more. You'd
just probably never need to force hash context, so we won't see it often.
Luke
Re: hyper operators - appalling proposal
Trey Harris wrote: > Yes. This is my fear of hyperoperation being the default for normal > aggregates. Loops--and large, multiply-nested, potentially-infinite > ones--can spring out of code that doesn't look loopy at all. Erm... you > know what I mean. :-) > > Karl, do you have any objection to marking aggregates for which > hyperoperation is to be the default? Then you could say: > > my @foo, @bar; # Are the parens required in p6? > # or > my (@foo, @bar) is ; # Can you distribute properties? > <...> > @foo += @bar; > > where is matrix, hyper, or something along those lines (choosing > great names is Larry, Damian and Allison's jobs, not mine :-) > > If we simply made such hyperoperated aggregates builtins rather than > requiring user-defined classes, this would offer a compromise, would it > not? This is a good compromise. The numerics person might even be able to say: use default => hyperops; # somewhere at the top of your script @res = @foo * sqrt(@bar); while brent and others can do their CGI scripts without having to wait for the end of the known Perl universe.
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
> > Using %(...) to create a hashref, as { ... } does in Perl5, would go
> > against all that, because the purpose of making a hashref is to
> > *reference* something. Now a unary % operator/sigil/prefix might mean
> > referencing, or it might mean dereferencing, depending on whether the
> > symbols following are (...) or {...}. Ouch.
> As with $(), I assume %() would force hash context. Nothing more. You'd
> just probably never need to force hash context, so we won't see it often.
If all it does is force hash context, then this:
$href = %( %somehash );
would simply mean the same as this:
$href = \%somehash; # reference existing hash.
and not this, which may have been what I wanted:
$href = hash { %somehash }; # reference clone of hash.
Or, in other words, context alone can't turn a simple reference into a
constructor. Something, somewhere, has to clone %somehash's contents.
If %(...) makes a shallow copy of its innards, as Perl5's { ... } does,
then how do you impose hash context onto something without doing the
copy? There'd need to be a different syntax to do that, since Perl
can't possibly always DWIM in this case. %(...), assuming it's valid
Perl6 (I don't remember seeing it or $(...) in any Apocalypse[1]),
means one or the other; it can't mean both.
[1] $(...) has been seen inside double-quoted strings to interpolate
expressions, but that's not the same thing.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"You can't take me up, you can't wind me down, There's no escape but I'll never
drown, no wires or strings, no rough and smooth, just like fire and stings,
watch me closely, watch my every move." - _Wine from the Water_, Alan Parsons
Re: Streams vs. Descriptors
At 11:18 AM 7/15/2002 -0700, Damien Neil wrote: >On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote: > > 1) Async support. The IO system needs to be asynchronous and re-entrant > > at the core, whether by threads or by use of the platform's async support. > > Other things like callbacks assume other features of Parrot to be finished, > > like subs/methods. > >Out of curiosity, what's the motivation for supporting true signal-driven >async IO (which is what you seem to be referring to)? In my experience, >nonblocking IO and a standard event loop is more than sufficient, and >far easier to implement--especially portably. Hi Damien, True async IO implementations allow other things besides just notifying the process when data is available. Things like predictive seeks, or bundling up multiple read/writes, etc. aren't doable with select/poll loops. And the aioread/aiowrite/listio, etc. are a POSIX standard now, so they should be reasonably available on most UNIXen. You are right, though, I blurred the concepts. Callbacks are good to have as well, for calling code blocks when data is available, and this might be done as an event loop, or a thread. However, the talks I've had with Dan always ended up in us deciding that calling an event loop between every op, or even every N ops wasn't what we wanted to do. Finally, I'm not an async IO expert, so don't take anything I say too seriously. :) I'm just a product of all the hoopla that I read. I do know that each OS implements it differently, for example last time I checked Solaris did it with light-weight threads, whereas Digital UNIX/Tru64 (and maybe AIX??) did it with true kernel threads. For many things, synchronous IO is adequate, and faster, but for people that really want the aio interface, I'm not sure it is worth trying to fake it. I'll try doing some research for some performance cases so maybe I can add to this discussion. -Melvin
Re: PARROT QUESTIONS: Use the source, Luke
At 11:08 AM 7/15/2002 -0700, Damien Neil wrote: >On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote: > > >The last four are reserved by various C and C++ standards. > > > > I always hear this, but in real life it is never much of a problem. > > Especially > > with a namespace like [Parrot] > >It is a good idea to avoid using the reserved identifier space, not >only because it avoids conflicts with vendor libraries, but for >documentation purposes. The leading underscore means "system internal, >do not touch"; blurring this meaning doesn't help. > >It's also unnecessary. It isn't like there aren't perfectly good >alternatives--what's wrong with "Parrot__"? Well, what's wrong with Parrot_ ? -Melvin
[perl #822] [PATCH] Fix segfault in intqueu
# New Ticket Created by Tony Payne # Please include the string: [perl #822] # in the subject line of all future correspondence about this issue. # http://bugs6.perl.org/rt2/Ticket/Display.html?id=822 > I set off to try to increase the coverage of parrot_coverage and right away tripped into a segfault in intqueue if you try to dequeue an empty queue. This patch fixes the segfault and adds a test for it. ++t -- attachment 1 -- url: http://bugs6.perl.org/rt2/attach/3866/3577/55bba3/intq.diff Index: t/pmc/pmc.t === RCS file: /cvs/public/parrot/t/pmc/pmc.t,v retrieving revision 1.32 diff -u -u -r1.32 pmc.t --- t/pmc/pmc.t 4 Jul 2002 00:49:04 - 1.32 +++ t/pmc/pmc.t 16 Jul 2002 01:42:42 - @@ -1,6 +1,6 @@ #! perl -w -use Parrot::Test tests => 59; +use Parrot::Test tests => 60; use Test::More; my $fp_equality_macro = <<'ENDOFMACRO'; @@ -1258,6 +1258,15 @@ ok 3 ok 4 OUTPUT + +output_is(value; + INTVAL value; if(container->head != container->tail) { BUCKET* cur = container->tail; +value = container->tail->value; container->tail = container->tail->prev; container->tail->next = NULL; free(cur); } else if(container->head != NULL) { +value = container->tail->value; free(container->head); container->head = NULL; container->tail = NULL; } else { fprintf(stderr,"*** dequeue tried to dequeue empty bucket\n"); +/* XXX: Should raise an exception */ +return 0; } return value; }
Re: PARROT QUESTIONS: Use the source, Luke
On Tuesday 16 July 2002 01:02 am, Melvin Smith wrote: > >It's also unnecessary. It isn't like there aren't perfectly good > >alternatives--what's wrong with "Parrot__"? > > Well, what's wrong with Parrot_ ? There's nothing wrong with Parrot_ -- as long as it isn't used *everywhere*. A good thing used in excess is bad, and all that mumbo jumbo. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
On Tuesday 16 July 2002 01:01 am, Deborah Ariel Pickett wrote:
> If %(...) makes a shallow copy of its innards, as Perl5's { ... } does,
> then how do you impose hash context onto something without doing the
> copy?
%{} forces hash context. What else could it do?
%{ foo() } calls foo() in hash context, asking it to return a HASH ref, does
it not?
%( foo() ) would call foo() in list context asking for a list of PAIRs. If
foo() returns a hash ref which you want a copy of, you would use %( *foo() )
which would flatten the returning hash ref into a PAIR list, then construct a
hash ref from those pairs.
My argument is that %{} already represents 'HASH' context, and we don't need
%() for that as well. Instead, we need a punctuation-happy hash constructor.
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
Sorry, I was being too terse in my original message, I guess some of the
meaning got lost.
When I said:
> > If %(...) makes a shallow copy of its innards, as Perl5's { ... } does,
> > then how do you impose hash context onto something without doing the
> > copy?
What I meant to say was:
> > Speaking hypothetically, for a moment, let's assume that what %(...)
> > does is it makes a shallow copy of its innards, as Perl5's { ... } does.
> > Then what syntax do you use to impose hash context onto something
> > without doing the copy?.
In other words, I was attempting a proof-by-contradiction. It didn't
come out too well, I gotta say.
I'm pretty sure that none of us is quite on the same wavelength here.
But since it's all speaking hypothetically, who cares?
Anyway, after all this, I went back to see Apocalypse 2, and this bit
stood out:
And the { foo => $bar } list composer will be required to use => (or be
in a hashlist context), or it will instead be interpreted as a closure
without a sub. (You can always use an explicit sub or hash to cast the
brackets to the proper interpretation.)
which I guess answered my original question.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"You can't take me up, you can't wind me down, There's no escape but I'll never
drown, no wires or strings, no rough and smooth, just like fire and stings,
watch me closely, watch my every move." - _Wine from the Water_, Alan Parsons
Re: vtables and multimethod dispatch
"David M. Lloyd" wrote: > Do we really want *two* inheritance trees per object > in Perl 6? One language-level and one PMC-level? Well, parrot != perl6, so I don't see a problem. The MM dispatch problem is pretty much solidly in the realm of pmc inheritance, and that's something we have control over the complexity of. And Dan assures us that the complexity will be quite low. :-) > ...to save implementors some typing. I'm guessing you didn't intend irony there? :-) > There is really no inheritance of any kind going on, > it just sticks pointers to the default functions into the vtable > structure method entries for undefined methods. But that's what type inheritance is! -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Grammar (take V.00I_0I)
The short version: This is intended to be the "cleaned up to check into
the Parrot tree" version Dan mentioned, so now would be a good time to
yell if you have problems with it. The documentation is much better (or
at least larger) than that in the previous version. You _will_ run into
bugs, but there's enough that works for it to be fun to play with.
The longer version:
Additions:
- statement guards: if, unless, while, until
- loops: while, until
- subs without explicit parameter lists get @_ (and do strange things
with it, since flattening doesn't work yet).
- hyped logical operators
- more compiler tests.
- more parser tests (John Kingsley).
- more docs.
- a bit more speed in the grammar by using regexes rather than a rule
to hype operators
- sub parameter lists will affect parsing (e.g. "sub foo($x)" will be
a unary operator).
Fixes:
- || and && on lists return lists instead of scalars.
- a few more misc. things
- and a whole batch of fixes from Kingsley:
- foreach $f (@a) {}"
- "f() if (1)"
- "next if $a < $b"
- comment between end of block and next statement.
/s
grammar.tgz
Description: Binary data
[perl #823] [PATCH] put numeric comparisons in the right order
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #823]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=823 >
NOTE: this may be part of the monster-patch to fix the over-agressive
string GC (814), but it's much more palatable in this form. PerlInt's
cmp() method was backwards, and would truncate floats on the other side of
the comparison. This patch always uses floating-point, and makes the
direction consistent with the PDD 2.
/s
Index: perlint.pmc
===
RCS file: /cvs/public/parrot/classes/perlint.pmc,v
retrieving revision 1.24
diff -u -r1.24 perlint.pmc
--- perlint.pmc 12 Jun 2002 22:12:18 - 1.24
+++ perlint.pmc 16 Jul 2002 04:14:09 -
@@ -557,14 +558,14 @@
}
INTVAL cmp(PMC* value) {
-INTVAL diff;
-diff = value->vtable->get_integer(INTERP, value) - SELF->cache.int_val;
+FLOATVAL diff;
+diff = SELF->cache.int_val - value->vtable->get_number(INTERP, value);
return diff > 0 ? 1 : diff < 0 ? -1 : 0;
}
INTVAL cmp_num(PMC* value) {
-INTVAL diff;
-diff = value->vtable->get_integer(INTERP, value) - SELF->cache.int_val;
+FLOATVAL diff;
+diff = SELF->cache.int_val - value->vtable->get_number(INTERP, value);
return diff > 0 ? 1 : diff < 0 ? -1 : 0;
}
Re: [perl #823] [PATCH] put numeric comparisons in the right order
Sean O'Rourke wrote: > NOTE: this may be part of the monster-patch to fix the over-agressive > string GC (814), but it's much more palatable in this form. > PerlInt's > cmp() method was backwards, and would truncate floats on the other > side of the comparison. > This patch always uses floating-point, and makes the > direction consistent with the PDD 2. Um, I don't think it's right to *always* do the comparison floating point. Specifically, if both operands are ints, the comparison should be int. -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: [perl #823] [PATCH] put numeric comparisons in the right order
In-Reply-To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 15 Jul 2002, John Porter wrote: > Sean O'Rourke wrote: > > NOTE: this may be part of the monster-patch to fix the over-agressive > > string GC (814), but it's much more palatable in this form. > > PerlInt's > > cmp() method was backwards, and would truncate floats on the other > > side of the comparison. > > This patch always uses floating-point, and makes the > > direction consistent with the PDD 2. > > Um, I don't think it's right to *always* do the comparison > floating point. Specifically, if both operands are ints, > the comparison should be int. I thought about this, but all it buys you is a few bits of precision when your ints and floats are both 64-bit, and slower comparisons all the time. IMHO it's a wash, so I did it this way. /s
Re: [perl #823] [PATCH] put numeric comparisons in the right order
Sean O'Rourke wrote: > ... all it buys you is a few bits of precision when your ints > and floats are both 64-bit, and slower comparisons all the time. > IMHO it's a wash, so I did it this way. I would point out that integers have infinite precision. More than a few bits' difference, I'd say. But you're right. As long as the conversion from int to float is done just before the comparison -- i.e. no intervening floating-point ops on the numbers -- then the result of comparison should always be right, no precision issue. (I'm just talking about in the int-vs-int case.) So, never mind. :-) -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: [perl #823] [PATCH] put numeric comparisons in the right order
> > Um, I don't think it's right to *always* do the comparison > > floating point. Specifically, if both operands are ints, > > the comparison should be int. > > I thought about this, but all it buys you is a few bits of precision when > your ints and floats are both 64-bit, and slower comparisons all the time. > IMHO it's a wash, so I did it this way. If A = 2^30 and B = 2^30+1, won't they be the identical value when converted to IEEE floats on a 32-bit platform? IEEE floats have a 23 bit mantissa, which isn't enough to differentiate between 1^30 and 1^30+1^0, since 30 - 0 > 23. Am I missing something here? Thanks, Mike Lambert
[PATCH] auto-document pmc files
My suggestion is to add on vtable.tbl comment like
void set_integer_native(INTVAL value) # example: set P0, I0
void set_number_native(FLOATVAL value) # example: set P0, N0
and so on. Of course the content of the comment can be more descritive.
Then, I changed parse_vtable and genclass.pl to create comments with this
just before each pmclass method.
I send the patch in attatchment.
Alberto
--
Alberto Manuel B. Simoes
Departamento de Informática - Universidade do Minho
http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Index: vtable.tbl
===
RCS file: /cvs/public/parrot/vtable.tbl,v
retrieving revision 1.25
diff -r1.25 vtable.tbl
62c62
< void set_integer_native(INTVAL value)
---
> void set_integer_native(INTVAL value) # example: set P0, I0
68c68
< void set_number_native(FLOATVAL value)
---
> void set_number_native(FLOATVAL value) # example: set P0, N0
80c80
< void set_string_native(STRING* value)
---
> void set_string_native(STRING* value) # example: set P0, S0
87c87
< void set_pmc(PMC* value)
---
> void set_pmc(PMC* value) # example: set P0, P1
Index: classes/genclass.pl
===
RCS file: /cvs/public/parrot/classes/genclass.pl,v
retrieving revision 1.11
diff -r1.11 genclass.pl
38,39c38,40
< my ($retval, $methname, $args) = @{$_};
<
---
> my ($retval, $methname, $args, $comment) = @{$_};
>
> print "/* $comment */\n" if $comment;
Index: lib/Parrot/Vtable.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Vtable.pm,v
retrieving revision 1.16
diff -r1.16 Vtable.pm
31c31
<
---
>
37,39c37,39
<
< if (/^\s*($type_re)\s+($ident_re)\s*\(($arglist_re)\)\s*$/) {
< push @{$vtable}, [ $1, $2, $3 ];
---
>
> if (/^\s*($type_re)\s+($ident_re)\s*\(($arglist_re)\)\s*(?:#(.*))?$/) {
> push @{$vtable}, [ $1, $2, $3, $4 || "" ];
