Larry Wall wrote:
multi sub *scramble (String $s) returns String {...}
[...]
Or you can just call it directly as a function:
scramble(hello)
Can you also call scramble as a class method?
class String is extended {
method scramble { ..etc... }
}
String.scramble(hello)
A
Larry Wall wrote:
Yet another approach is to *replace* dot with something that mutates:
@array!sort
@array?sort
Either of those would work syntactically in that case, since neither !
nor ? is expected as a binary operator.
What about ? is as a ternary operator:
@foo?bar:baz;
AW == Andy Wardley [EMAIL PROTECTED] writes:
AW What about ? is as a ternary operator:
AW @foo?bar:baz;
IIRC, that was changed to ?? :: because larry wanted the single ? for
more important uses. also doubling the ? made it more like , || which
are related logical ops.
and ?? as the
Larry --
So, will mutatingness be a context we'll be able to inquire on
in the implementation of a called routine? Or, could we provide
a specialized distinct implementation for mutating that would get
called if .=X() is used? If we are performing some operation on
large data, and we know the end
On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
: Larry Wall wrote:
: multi sub *scramble (String $s) returns String {...}
: [...]
: Or you can just call it directly as a function:
: scramble(hello)
:
: Can you also call scramble as a class method?
:
: class String is
On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
: So, will mutatingness be a context we'll be able to inquire on
: in the implementation of a called routine?
Probably not, but it's vaguely possible you could somehow get a
reference to what is being assigned to, if available, and
On Thu, Mar 11, 2004 at 11:11:54AM -0800, Larry Wall wrote:
On the final hand, if people fall in love with both self:sort and =sort, we
could have =sort be a shorthand for self:sort where it's unambiguous.
Wouldn't =sort potentially muck with POD?
-Scott
--
Jonathan Scott Duff
[EMAIL
On Thu, Mar 11, 2004 at 02:05:55PM -0600, Jonathan Scott Duff wrote:
: On Thu, Mar 11, 2004 at 11:11:54AM -0800, Larry Wall wrote:
: On the final hand, if people fall in love with both self:sort and =sort, we
: could have =sort be a shorthand for self:sort where it's unambiguous.
:
: Wouldn't
On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote:
: Which is precisely the problem with something like
:
: $a cmp= $b
:
: insofar as $a is being treated as a string at one moment and as a boolean
: at the next.
Well, okay, not a boolean. More like a troolean.
Larry
On 3/11/04 4:04 PM, Larry Wall wrote:
On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote:
: Which is precisely the problem with something like
:
: $a cmp= $b
:
: insofar as $a is being treated as a string at one moment and as a boolean
: at the next.
Well, okay, not a
On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
Well, okay, not a boolean. More like a troolean.
Unless it's a falselean.
-- c
On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote:
: On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
:
: Well, okay, not a boolean. More like a troolean.
:
: Unless it's a falselean.
It's more truelean than falselean by a 2/3rds majority. And it's
much more if you include 2, -2, 3,
Dan Sugalski [EMAIL PROTECTED] wrote:
Right now, we can create new PMCs by calling the class init method.
It takes no parameters which somewhat limits the utility of the thing
as a true initializer.
Does it or not?
newclass P1, Foo
find_global P2, _init
store_global Foo, __init,
Jens Rieks [EMAIL PROTECTED] wrote:
Hi,
this time a funny bug :-)
2. create a file hello.imc with the following content:
.emit
.pcc_sub @LOAD _onload:
print foo\n
end
^^^
It's called as a PCC subroutine, so you have to return from it via
invoke P1. I wrote that end is
Dan Sugalski [EMAIL PROTECTED] wrote:
Calling a method:
object.variable(pararms)
object.literal name(params)
Done.
leo
Dan Sugalski [EMAIL PROTECTED] wrote:
While we still need to nail down the final bits of namespace stuff,
I'm running into the need for it in IMCC code, so its time to finally
deal with it.
I don't really care what the syntax looks like, so I'm proposing:
.namespace [foo; bar; baz]
At 2:15 PM +0100 3/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Calling a method:
object.variable(pararms)
object.literal name(params)
Done.
Woohoo!
--
Dan
--it's like
At 2:14 PM +0100 3/11/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
While we still need to nail down the final bits of namespace stuff,
I'm running into the need for it in IMCC code, so its time to finally
deal with it.
I don't really care what the syntax looks like, so I'm
Dan Sugalski [EMAIL PROTECTED] wrote:
Method declarations:
.pcc_sub foo prototyped, method
.param pmc foo
.param pmc bar
.end
That is, you add a method on the end of the sub declaration line. If
you do so, the local self refers to the object pmc register.
Done.
Okay, unless there are objections I'm going to rejig the date
decoding logic to return months from 1-12, rather than 0-11. We
already fix years, so it seems to make sense.
--
Dan
--it's like this---
Dan
Hi,
attached is a patch to t/pmc/object-meths.t that adds a test that is currently
failing because IMCC rejects code like self.blah()
jens
Index: t/pmc/object-meths.t
===
RCS file: /cvs/public/parrot/t/pmc/object-meths.t,v
At 4:34 PM +0100 3/11/04, Jens Rieks wrote:
Hi,
attached is a patch to t/pmc/object-meths.t that adds a test that is currently
failing because IMCC rejects code like self.blah()
Before I go and apply this, could you sync and retry? I'm not seeing
any test failures here, so there might be a
Jens Rieks [EMAIL PROTECTED] wrote:
Hi all,
attached is an object orientated version of library/dumper.imc.
(it needs libraray/objecthacks.imc from yesterday)
Should that still get applied? Major object syntax improvements are now
in. It should get much cleaner and simpler now.
leo
Dan Sugalski [EMAIL PROTECTED] wrote:
While we still need to nail down the final bits of namespace stuff,
I'm running into the need for it in IMCC code, so its time to finally
deal with it.
I don't really care what the syntax looks like, so I'm proposing:
.namespace [foo; bar; baz]
as
Hi,
On Thursday 11 March 2004 16:31, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
Hi all,
attached is an object orientated version of library/dumper.imc.
(it needs libraray/objecthacks.imc from yesterday)
Should that still get applied? Major object syntax improvements are
(YAY!)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Thursday March 11, 2004 10:34
To: [EMAIL PROTECTED]
Subject: Dates. Or, rather, months
Okay, unless there are objections I'm going
Hi,
On Thursday 11 March 2004 16:41, Dan Sugalski wrote:
At 4:34 PM +0100 3/11/04, Jens Rieks wrote:
Hi,
attached is a patch to t/pmc/object-meths.t that adds a test that is
currently failing because IMCC rejects code like self.blah()
Before I go and apply this, could you sync and retry?
At 10:50 AM -0500 3/11/04, Gordon Henriksen wrote:
(YAY!)
Heh. And done, too. May cause issue with legacy code, but the
libraries for the various languages can hide the correct behaviour
with historically accurate incorrect behaviour. :)
-Original Message-
From: Dan Sugalski
At 5:07 PM +0100 3/11/04, Jens Rieks wrote:
Hi,
On Thursday 11 March 2004 16:41, Dan Sugalski wrote:
At 4:34 PM +0100 3/11/04, Jens Rieks wrote:
Hi,
attached is a patch to t/pmc/object-meths.t that adds a test that is
currently failing because IMCC rejects code like self.blah()
Before I
Jens Rieks [EMAIL PROTECTED] wrote:
attached is a patch to t/pmc/object-meths.t that adds a test that is
currently failing because IMCC rejects code like self.blah()
Yep. It produces reduce/reduce conflicts. Something's wrong with
precedence. I'd be glad if someone can fix it.
One more bug
Hi,
$ tar xzf err.tgz
$ cd err
$ ../parrot dumper_1.imc
parrot: src/packfile.c:2783: store_sub_in_namespace: Assertion `ns
pf-const_table-const_count' failed.
aborted.
It seems to be trigger by the empty __register sub in
err/library/Data/Dumper/Default.imc
The bug vanishes if one line of the
Hi,
Am I the only one who receives this annoying message each time I send an .tgz
attachment to the list?
jens
---BeginMessage---
ScanMail for Microsoft Exchange has taken action on the message, please
refer to the contents of this message for further details.
Sender = [EMAIL PROTECTED]
At Thu, 11 Mar 2004 19:00:18 +0100,
Jens Rieks wrote:
[1 text/plain; us-ascii (7bit)]
Hi,
Am I the only one who receives this annoying message each time I send an .tgz
attachment to the list?
You're the only one who has complained.
I'll unsubscribe the offender.
-R
# New Ticket Created by Jens Rieks
# Please include the string: [perl #27590]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27590
Hi,
the following patch adds 4 more tests to t/pmc/sub.t
One of the new tests
Hi,
the following patch adds 4 more tests to t/pmc/sub.t
One of the new tests ('load_bytecode @LOAD second sub - imc') is currently
failing.
(The patch also removes a redundant assignment of $temp)
jens
Index: t/pmc/sub.t
===
RCS
Hi,
$ tar xzf err2.tgz
$ cd err2
$ ../parrot t/pmc/dumper_1.imc
parrot: src/hash.c:256: promote_hash_key: Assertion `key' failed.
aborted
It is caused by 'callmethod dumper' (err2/library/dumper.imc:82)
jens
err2.tgz
Description: application/tgz
If the current ponie in CVS is built with full defaults for parrot, then
it fails to build Unicode::Normalize, and fails about 40 regression tests.
If parrot's garbage collector is changed from the default (compacting, IIRC)
to the either libc or malloc, then ponie only fails 6 tests. ie make this
On Thu, 11 Mar 2004, Jens Rieks wrote:
$ tar xzf err2.tgz
$ cd err2
$ ../parrot t/pmc/dumper_1.imc
parrot: src/hash.c:256: promote_hash_key: Assertion `key' failed.
aborted
It is caused by 'callmethod dumper' (err2/library/dumper.imc:82)
Ah, I stumbled over this yesterday. The problem
Nicholas Clark [EMAIL PROTECTED] wrote:
If parrot's garbage collector is changed from the default (compacting, IIRC)
to the either libc or malloc, then ponie only fails 6 tests.
As I understand it parrot's default garbage collector will move data blocks
owned by PMCs. However, all of the
Hi all,
I have a newbie question. If the answer exists in a doc, just
point the way (I browsed the docs directory). What is the design
rationale for so many opcodes in parrot? What are the criteria for
adding/deleting them?
Thanks,
But what should those addresses do when receiving a message?
- parrotbug: should open a RT ticket?
Yes. This is the new equivalent of bugs-parrot at rt.perl.org.
Use of that address should be phased out in favor of the new one.
- status-ok: ?
- status-nok: should open a RT ticket?
Matt Greenwood wrote:
I have a newbie question. If the answer exists in a doc, just
point the way (I browsed the docs directory). What is the design
rationale for so many opcodes in parrot?
Let me try as another newbie... ;-)
Since the opcodes of parrot are not directly supported by any
Larry Wall wrote:
On Thu, Mar 11, 2004 at 01:18:52PM -0800, chromatic wrote:
: On Thu, 2004-03-11 at 13:04, Larry Wall wrote:
:
: Well, okay, not a boolean. More like a troolean.
:
: Unless it's a falselean.
It's more truelean than falselean by a 2/3rds majority. And it's
much more if you
Larry wrote:
On the other hand, I suspect most people will end up declaring it
int method
self:rotate (int $a is rw) {...}
in any event, and reserve the =rotate for .=rotate, which can never put
the = on the left margin, even if we let ourselves have whitespace
before POD directives.
44 matches
Mail list logo
