Re: Properties
Simon Glover wrote: On Wed, 11 Dec 2002, Simon Glover wrote: Is this a bug, or am I misunderstanding how properties are supposed to work? I did check in (a totally untested) fix. leo
Re: Parrot v0.0.9 code freeze
Are the Tru64 registers scanned for live PMCs/Buffers? I don't know what things would typically get missed that way, but it's a known problem for most architectures (or was until recently? What's the status on this?) I don't know if they are or not. How could you tell? Does Tru64 have hardware breakpoints? They're nice for this sort of thing -- find a value that eventually becomes incorrect, take the address of it at a point when it is still correct, then watch what it points to: (gdb) p interpreter-ctx.pmc_reg.registers[0]-cache.int_val $6 = 1 (gdb) p interpreter-ctx.pmc_reg.registers[0]-cache.int_val $7 = (INTVAL *) 0x810c904 (gdb) watch *$7 Hardware watchpoint 2: *$7 (gdb) continue . I'll try this on the weekend...I'm moving today and won't have internet until tomorrow. But I'll give it a shot and see. Tanton
RE: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Luke Palmer:
# There's no need for special methods or (gods forbid) more operators.
# Just:
#
# $obj1.id == $obj2.id
#
# That's what the universal Cid method is *for*.
#
# I rather like that. It's used for hashing by default (in
# absence of a stringification or .hash (?) method), yes?
I'd assume so, but more by default rather than by design:
class Object {
method hash() {
return .str();
}
method str() {
return .id();
}
method id() {
return sprintf(%s(%#x), .class,
Perl6::addressof($_));
#Or some such nonsense
}
}
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: [perl #18782] [PTACH] long double support i386/linux
Leopold Toetsch (via RT) wrote: # New Ticket Created by Leopold Toetsch # Please include the string: [perl #18782] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18782 As no one complained (or answered) I have checked in long double support for i386. To test this, compile a perl 5.8.0 with long double support: rm -f config.sh Policy.sh sh Configure -Dprefix=/opt/perl-ld -Duselongdouble make make test make install After this, parrots perl Configure.pl defaults to long double. To use 8 byte doubles again you can run perl Configure.pl --floatval=double. Test results (also with JIT) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/src/sprintf.t1 256 21 50.00% 1 Here is myconfig: Summary of my parrot 0.0.8 configuration: configdate='Thu Dec 12 10:09:52 2002' Platform: osname=linux, archname=i686-linux-ld jitcapable=1, jitarchname=i386-linux, jitosname=linux, jitcpuarch=i386 perl=/opt/perl-ld/bin/perl Compiler: cc='cc', ccflags='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib ', cc_ldflags='', libs='-lnsl -ldl -lm -lposix -lcrypt -lutil' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=long double, numvalsize=12, doublesize=8 Success (only ;-) messages for other i386 system welcome. (The format char %Lf in format.pl might need adjustment for different compilers) leo
Re: right-to-left pipelines
Date: Thu, 12 Dec 2002 02:19:18 -0500
From: Dan Sugalski [EMAIL PROTECTED]
Since that may be either:
$foo = bar($x, $y), foo()
in which case it's in scalar context, or
$foo = bar($x, $y, foo())
in which case it's in list context (sort of)
The fun thing is that, potentially, you need to actually *call* foo()
to figure out what context to call foo in. (Since, depending on what
it returns, you may dispatch to different bar subs, which may or may
not actually need what foo returns, thus changing its context)
A similar thing arises with multimethods:
class Foo; class Bar;
sub baz(*@args);
sub foo(Foo $thing) { ... }
sub foo(Bar $thing, $arg) { ... }
sub bar($blah) {
if $blah {
return new Foo:;# is that : required?
}
else {
return new Bar:;
}
}
baz foo bar $x, $y;
If $x is true, that's:
baz(foo(bar($x)), $y)
Otherwise, it's:
baz(foo(bar($x), $y));
It's not as paradoxical as Dan's example, but it's also not fixable
with an actually, context ... argument.
As a solution (not just to this, just as a general sanity mechanism),
I propose that we
a) Only differentiate between unary and list ops, as in Perl 5.
b) Consider a sub unary only if _all_ of it's versions are unary.
Thus, in this case, it would parse as:
baz(foo(bar($x), $y));
And if $x happened to be true, a run-time error would occur.
This way, people would not have to remember how many arguments things
take, just whether they're unary or not. This allows for easier
parsing on the human side, and encourages parentheses when they would
be beneficial to readers.
Luke
Re: is it required to use type declarations? (was Re: 'hashkey context/Str context')
On Wed, Dec 11, 2002 at 12:13:49PM -0700, Luke Palmer wrote: [Dks wrote:] So...are we intending that types and type safety will be like 'use strict' (optional and only on request), or will they be like sigils (mandatory, can't be turned off)? Or, perhaps, on by default but able to be turned off? Optional by request, but not explicit request. If you type a variable, you're asking for type checking on that variable. Excellent. That's the best of all worlds. Thanks; I am much relieved. --Dks
Re: REs as generators
On Thu, Dec 12, 2002 at 10:35:47AM +1100, Damian Conway wrote: Dave Storrs wrote: - the ability for the programmer to set limiters (??better name??) on the junction, which will specify how the junction should collapse--e.g. always collapse to the lowest/highest value that hasn't been supplied yet, or to the lowest/highest unsupplied value that causes a particular code block to return true, or whatever. Junctions don't collapse. They distribute. Remember: Junctions Aren't Quantum. Ah. Obviously, I don't know JAQ. (sorry) However, I don't believe this answers my question...or, more likely, I am just misunderstanding junctions. I believe that this code: my $i = one(7...); print $i; Is roughly equivalent to this English: - declare a lexical variable $i - create a junction. The states of the junction are (7..Inf). The type of the junction is one - assign the junction to $i - distribute the junction [that still doesn't sound right, but ok] by choosing one of the states (at random??) - print the number chosen in the previous step. First of all, am I correct about this? Second, what I was originally asking is this: could there be some way for the programmer to attach a (method/code block/sub/whatever) to the junction, such that when the state is chosen, the default method of choosing a state is overriden by the code supplied by the programmer. --Dks
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On Wed, Dec 11, 2002 at 02:54:18PM -0800, Dave Whipp wrote: Michael Lazzaro [EMAIL PROTECTED] wrote: After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Definitely '==='. Hopefully, this thread has been settled by Damian's pointing out the existence of id(), but could I put in a strong vote against the use of '===' for anything? It is far too easy to misread as ==, IMHO. --Dks
Re: right-to-left pipelines
Simon Cozens [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Deborah Ariel Pickett) writes:
About this point was when my brain when a ha!. But I'm not yet
convinced that generating all possible parses is (a) of sane time
complexity, and (b) a little *too* DWIM for its own good.
As I said, I wasn't sure whether or not I was being serious at this point.
method bar($x, $y) {
method bar($z) { # note 1
Oh, bringing in multimethods Just Isn't Fair.
Those are multimethods? Migod, I feel like a person who's just
discovered for the first time in their life that the plate that gets
passed around in church is for putting money *onto*.
Oh, if you have a method which does X when it gets one argument and does
Y when it gets another, I'd call that a multimethod. But then, I am no
OO wizard.
I believe what Deborah is talking about is a special case of a
multimethod. Real multimethods get to dispatch on more than just the
first argument, but if you have real multimethods then function
overloading just falls out.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Stringification of references (Decision, Please?)
Michael Lazzaro [EMAIL PROTECTED] writes: On Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote: Maybe AS_STRING and AS_STRING_DEBUG? Too long? DEBUG_STRING? Are we married to the AS_* thing? Not really -- whatever works. We also had .debug, .identity, and .id proposed, for example. You shouldn't be stringifying objects merely to test if they're the same object -- yuck. It was an artifact of Perl5 that we should be replacing.) So, what is the Perl 6 way to test this? I was hoping someone would ask that. :-) We don't _have_ a way, AFAIK. It was discussed briefly during the operator thread, but without decision. We know: $obj1 == $obj2; # compares them numerically $obj1 eq $obj2; # compares them stringically We could override either C== or Ceq of CObject to do it. Then we have to ask what happens if you say: $obj == 5; $obj eq 'foo'; That would hopefully *not* compare the identity of $obj to either 5 or 'foo', but instead Do The Right Thing (numerify or stringify $obj). So presumably, this is a job for multimethod variants of class-specific C== or Ceq operators. Well, sortof. OR, you just explicitly compare the identities, e.g. $obj1.identify == $obj2.identity; # yuck I like this. Gets 'round needing a million and one different equality operators. If you find yourself using a particular form more often than others then just write yourself an operator. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Damian Conway writes: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. How universal are universal methods? That is, can a programmer override .id() in a user-defined class? If so, simply comparing .id for numeric equality isn't a good enough way of comparing object identity. I think you'd have to do something like $obj1.UNIVERSAL::id == $obj2.UNIVERSAL::id which is getting fairly verbose. But I also have a feeling of non-specific unease at the idea that I might _not_ be able to override a universal method. Another question. Consider the integer 17. There are two plausible representations for it -- one boxed, and one unboxed. There might also be several distinct boxed 17s that aren't object-identical. My question is whether all of those should have the same .id(). That is, should the programmer be allowed to determine whether two apparently-identical numbers have the same representation, or should .id() fudge the issue by pretending that all representations of a number of a given type are identical. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: Everything is an object.
Simon Cozens [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Dave Whipp) writes: There is a difference between verbs and noun. Sometimes you don't want to associate a verb with an object: you want to associate it with the subject: Verbs are almost always associated with their subject in OO languages, so I don't see where you're coming from. the cat sat on the mat is that the_mat.sat_on(the_cat) Nope. or the_cat.sat_on(the_mat) This one. If you called $cat-sit_on($mat); in Perl 5, who would you expect to be sitting on what? C $cat.sat_on($the_mat) is surely a predicate, returning true or false depending on whether the cat is on the mat or not. But unless I can write it as C $cat.sat_on?($the_mat) then I'd be very cross with anyone who didn't call the method C is_sat_on . -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Comparing Object Identity
Luke Palmer [EMAIL PROTECTED] writes: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Wed, 11 Dec 2002 19:21:35 -0500 From: John Siracusa [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ On 12/11/02 6:16 PM, Damian Conway wrote: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. I must have missed this (or forgotten it?) Any chance of it becoming .ID or .oid or even ._id? I'm kind of attached to using an id method on objects that represent things in a database... :-/ Well I use .str all the time, an .eq is one of my favorites! Don't take those, put a prefix on them! Theoretically, there are sufficiently few Object methods to warrant normal names. Right now there are 'sufficiently few' Object methods, but I'm betting that before the game is over there's going to a be a whole pile more, just take a look at any Smalltalk image if you don't believe me. But that's no reason for upcasing said methodnames. Anyway, you haven't lived 'til you've added a suite of methods to UNIVERSAL/Object; it's how we make Pixie work for instance. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Help with setting up Perl6
I'd like to help write some test cases for Perl6 to deliver on that part of this group's charter. I'm having problems getting Perl 6 working, and I'd like help. This may be off-charter for this group, but there's hardly a better place, and the info is probably generally useful to others also seeking to create tests (nudge nudge). The head of the tree won't compile for me (dod.c:508: undefined reference to `flush_register_windows'), but RELEASE_0_0_8 will (as described below). The perl6 test harness is failing for me though. So, starting with a blank directory, I: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/public login [return for blank password] cvs -d :pserver:[EMAIL PROTECTED]:/cvs/public checkout -r RELEASE_0_0_8 parrot cd parrot perl Configure.PL make Everything through this point works ok, as far as I can tell. I get a functional parrot binary in the top directory and a make test goes off its merry way passing all the basic and jako tests. Harness output: All tests successful, 5 subtests skipped. Files=26, Tests=433, 579 wallclock secs (440.29 cusr + 34.98 csys = 475.27 CPU) So I proceed to try to play with perl6: cd languages/perl6 make and it proceeds to go into the imcc, classes, and doc directories to make and I end up with a blib/lib/libparrot.a. Still no errors. So I try a 'make test', and I get: -- begin -- - make test /usr/bin/perl t/harness t/compiler/1...Can't bless non-reference value at ../../assemble.pl line 163. # Failed test (t/compiler/1.t at line 7) # got: 'Parrot VM: Can't stat t/compiler/1_1.pbc, code 2. # ' # expected: 'Hello, world # ' t/compiler/1...NOK 1Can't bless non-reference value at ../../assemble.pl line 163. # Failed test (t/compiler/1.t at line 16) # got: 'Parrot VM: Can't stat t/compiler/1_2.pbc, code 2. # ' # expected: '5 # -1 # 6 # 3.00 # 2 # 23 # 8.00 # 8.00 # 2.00 # 0.50 # ' t/compiler/1...NOK 2 -- end -- In languages/perl6/t/compiler/1_1.err, I get: Can't find loader Parrot_DynOp_core_0_0_7: ../imcc/imcc: undefined symbol: Parrot_DynOp_core_0_0_7 which is suspicious for the 0_0_7 when I actually checked out 0_0_8. For kicks, I rebuilt the Perl6 grammer via './perl6 --force-grammar', and that works. If I manually feed some code to perl6 (cat examples/life-ar.p6 | ./perl6), it produces a reasonable 'a.imc' file . I've tried deconstructing the perl6 Makefile and run the steps individually but everything has broken in ways that make me think I'm missing something more fundamental. I'll try this procedure again when 0.0.9 comes out soon, but this is more likely my problem. Suggestions? -- [EMAIL PROTECTED] http://www.geekcode.com/geek.html -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/B d s:+++ a- C++()$ USL P+++ L+++ E++(+++) W N- !o !K w !O M V PS+++(-) PE++(--) Y+ PGP++ t@ 5 X+ R+ tv++-- b++ DI+ D- G e++ h- r+ y+++ --END GEEK CODE BLOCK--
Re: [perl #18745] [PATCH] config test for i386 fcomip
Leopold Toetsch (via RT) wrote: # New Ticket Created by Leopold Toetsch # Please include the string: [perl #18745] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18745 I did put in a patch based on #18745 - jit/i386 test for fcomip (old pentiums don't have it) - NEW feature.pl/feature_h.in to actually use the test result - extended genfile() to eval the feature_h.in file - this is the most flexible way to generate some config defines - if it's too dangerous feel free to make it more safe. Have fun, leo
Re: Jako and Native Calls
[EMAIL PROTECTED] wrote: Dan -- We were talking earlier about Jako supporting native calls. I have looked at PDD 6 and PDD 3, and here's what I think so far... I don't think I can get the native call stuff working until I have IMCC support for PDD 3. IMCC is totally in charge of what goes into each register, You can always define an explicit register: I5 = your_var I6 = another I7 = $I199 call _the_sub # or invoke result_var = I5 Above snipped should be probably wrapped into its own sub, where you can saveall your registers. Regards, -- Gregor HTH leo
Re: Partially Memoized Functions
On 12/10/2002 5:46 PM, Smylers wrote: OK. There was something on MJD's QOTW recently where using the current Perl 5 Memoize module slowed code down -- that gave me the impression that caching had the potential. It does. In fact, all caching has that potential. Specificly, if the time to look up somthing in the cache is greater then the time to recompute it, caching is a loose. Additionaly, if the hit rate (probablity; 0..1) times the time to recompute the datum is less then the time to look up the result in the cache, it's a loss for that datum. MJD has a set of presentation slides on this at http://perl.plover.com/yak/memoize-quant/ -- Quantitative Analysis of Memoization. -=- James Mastros PS -- This is getting offtopic, even for p6l.
Re: superposed parsers (was: right-to-left pipelines)
[EMAIL PROTECTED] (Stephen McCamant) writes: Simon I'm afraid I can't tell whether or not I'm being serious any Simon more. I don't know if this has been discussed before, but there are completely serious parsing algorithms that work this way Morale: If you can come up with a crazy enough idea on perl6-language, someone else will show how it can be seriously implemented. -- ... though the Japanese must be the most stupid people... I'm sure I read somewhere that Tokyo has the densest population in the world... - Gid Holyoake, sdm.
Re: right-to-left pipelines
Michael Lazzaro asked: foo $a, $b, $c, $d; # how many args? Damian Conway wrote: Yep. Can't be known unless predeclared and hence compile-time discernible. And methods can't be discerned in the presence of run-time dispatch. Is that not the purpose of an interface? That is, to specify at compile time that a given object conforms to a particular set of method signatures? The method is still resolved for dispatch at runtime, depending on the object type, multimethod arguments, etc. At compile time we don't know which method will be called, but, thanks to the interface, we do know what argument(s) it will be expecting. A
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/12/2002 5:50 AM, Aaron Crane wrote: Damian Conway writes: There's no need for special methods or (gods forbid) more operators. Just: $obj1.id == $obj2.id That's what the universal Cid method is *for*. How universal are universal methods? That is, can a programmer override .id() in a user-defined class? If so, simply comparing .id for numeric equality isn't a good enough way of comparing object identity. I'd say that you can override .id, but if you do, you deserve what you get. That is to say, if your .id method lies, and somebody tests that two objects are the same with .id, you should be sure that you're prepared to accept all the complications of answering the way you do. Also, it's likely that .id will be implemented with a single Parrot opcode, so you'll loose a lot of efficency by overriding it. Another question. Consider the integer 17. There are two plausible representations for it -- one boxed, and one unboxed. There might also be several distinct boxed 17s that aren't object-identical. My question is whether all of those should have the same .id(). Here's my basic defintion of ID: Two things should have the same ID if-and-only-if they will behave exactly the same, now and forevermore. Thus, there should be one ID for all constants of the same value, which is different from all constants of different value. (This is probably unimplementable if we gaurntee IDs are of some constant length.) Two objects should only have the same ID if they are aliases of each-other: they always have the same instance values, and the same value (but) properties. Promotable, but unpromoted, Ints should have different IDs, because they may at some point, have different values. Any unconsidered cases? That is, should the programmer be allowed to determine whether two apparently-identical numbers have the same representation, or should .id() fudge the issue by pretending that all representations of a number of a given type are identical. Some of both. Not all constants of the same number neccessarly have the same reprensentation in PBC -- to whit, a constant float in different compilation units will get different slots in the constant table, but are really identical. The same is true of constant strings. (Constant integers are inlined, and thus this doesn't apply to them -- they really are identical.) -=- James Mastros
Re: Comparing Object Identity
On Thursday, December 12, 2002, at 10:49 am, Piers Cawley wrote:
Luke Palmer [EMAIL PROTECTED] writes:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Wed, 11 Dec 2002 19:21:35 -0500
From: John Siracusa [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
On 12/11/02 6:16 PM, Damian Conway wrote:
There's no need for special methods or (gods forbid) more operators.
Just:
$obj1.id == $obj2.id
That's what the universal Cid method is *for*.
I must have missed this (or forgotten it?) Any chance of it
becoming .ID or
.oid or even ._id? I'm kind of attached to using an id method on
objects
that represent things in a database... :-/
Well I use .str all the time, an .eq is one of my favorites! Don't
take those, put a prefix on them!
Theoretically, there are sufficiently few Object methods to warrant
normal names.
Right now there are 'sufficiently few' Object methods, but I'm betting
that before the game is over there's going to a be a whole pile
more, just take a look at any Smalltalk image if you don't believe
me. But that's no reason for upcasing said methodnames. Anyway, you
haven't lived 'til you've added a suite of methods to
UNIVERSAL/Object; it's how we make Pixie work for instance.
But in fairness we do distinguish our method names with a different
convention 'px_'. We prefix the methods more because people aren't
used to the UNIVERSAL::* hierarchy being mucked around in, and methods
suddenly cropping up may be surprising.
I think there may be a cultural issue here - in Smalltalk if someone
messes with a method higher up in the hierarchy its visible quickly by
virtue of the browser and the image. Adding a method in Smalltalk's
MetaObject/Class/Object hierarchy isn't going to be that dangerous,
because everybody can see that it has been added, and its therefore
culturally exposed and therefore subject to debate[0]. Not so in Perl.
Perl, of course, lets you stick a method that exists in any package
anywhere on the system[1]. You can add methods to UNIVERSAL from
anywhere, and this gets really complex when you start overriding
existing methods. For example, if you're not happy with UNIVERSAL::isa,
it can be replaced with a sub UNIVERSAL::isa {} pretty much
anywhere[2]. You may get a warning but its pretty easy to turn it off,
and tracking it down would be a real pain without some pretty serious
reflection capabilities.
Of course pretty serious reflection capabilities would be Very Nice
Indeed, but anyway...
--james.
[0] Read: argument.
[1] This is not a bad thing, its just a different thing.
[2] This probably is a bad thing in most circumstances.
RE: right-to-left pipelines
On Tue, 10 Dec 2002 13:02:18 -0800, Brent Dax wrote:
Peter Haworth:
# @b = @a.grep { /\S/ }, $c;
#
# how does the compiler know whether $c is an argument to grep,
# or another element to be assigned to @b?
The same way it does when it sees a normal sub?
I know, late binding and all that. But when you think about it, a lot
can be done to simulate the conditions otherwise. For example, with a
definition like this:
class Foo {
method bar($self: $baz) { ... }
}
And a call like this:
@b=$foo_obj.bar $baz, $quux;
Where we can see *at runtime* that $quux is too many arguments, we can
just append it to the end of bar()'s return value. (This would only
happen when there were no parentheses.)
But at runtime, we don't necessarily have a good idea of what the original
code looked like (we've compiled to bytecode, and the user may have stripped
all the useful metadata from the .pbc file), or a way to generate new bytecode
on the fly (the user may have opted to exclude the runtime eval capability).
For this to work, we'd have to compile every possible variation of the syntax
tree, and decide which of them was appropriate at runtime. Ick.
In a strictly typed language you can do this without too many surprises.
I don't think it's appropriate for Perl, except possibly for certain special
cases like blocks as the only argument.
--
Peter Haworth [EMAIL PROTECTED]
'As Annie Oakley almost said, Anything you can do, I can do meta.'
-- Larry Wall
Re: REs as generators
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Wed, 11 Dec 2002 17:24:54 -0800 From: Dave Storrs [EMAIL PROTECTED] Mail-Followup-To: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Disposition: inline X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/ On Thu, Dec 12, 2002 at 10:35:47AM +1100, Damian Conway wrote: Dave Storrs wrote: - the ability for the programmer to set limiters (??better name??) on the junction, which will specify how the junction should collapse--e.g. always collapse to the lowest/highest value that hasn't been supplied yet, or to the lowest/highest unsupplied value that causes a particular code block to return true, or whatever. Junctions don't collapse. They distribute. Remember: Junctions Aren't Quantum. Ah. Obviously, I don't know JAQ. (sorry) However, I don't believe this answers my question...or, more likely, I am just misunderstanding junctions. I believe that this code: my $i = one(7...); print $i; Is roughly equivalent to this English: - declare a lexical variable $i - create a junction. The states of the junction are (7..Inf). The type of the junction is one - assign the junction to $i - distribute the junction [that still doesn't sound right, but ok] by choosing one of the states (at random??) - print the number chosen in the previous step. No collapsing. Not without an explicit .pick. It would call Cprint with each of the values of $i (unless print was designed to accept a junction, in which case you'd get some stringification/serialization of the junction). Cprint would return a one() junction of whatever print returned after printing each value, but what do you care, they're all in the garbage anyway? :) First of all, am I correct about this? No. As I just explained. Second, what I was originally asking is this: could there be some way for the programmer to attach a (method/code block/sub/whatever) to the junction, such that when the state is chosen, the default method of choosing a state is overriden by the code supplied by the programmer. Your question is now irrelevant. Luke
[INFO] jit_debug
Stabs gdb support now can show parrot registers.
e.g. complicated program:
set I0, 10
set N1, 1.1
set S2, abc
(gdb) p I0
$2 = 10
(gdb) p N1
$3 = 1.1001
(gdb) p *S2
$4 = {bufstart = 0x815ad30, buflen = 15, flags = 336128, bufused = 3,
strstart = 0x815ad30 abc}
(gdb) p S2
$5 = (struct Parrot_String *) 0x81628a8
(gdb)
The view of strings is actually simplified in the stabs file, e.g.
showing strstart as string (which is handy) and omitting some members.
You can set parrot registers too in gdb.
When running inside JIT, the N and I-Registers might still be in
processor registers and therefore show old values inside gdb.
What fields would be useful for PMCs?
Have fun,
leo
PS attached dddp (usage: dddp j for running j.pbc and starting ddd
with symbols)
# run ddd parrot with given file
# gdb confirmations should be off
echo b runops_jit
r -d -j --gc-debug $1.pbc
n
n
n
n
add-symbol-file $1.o 0
s
.ddd
ddd --command .ddd parrot
Re: Properties
Simon Glover wrote: On Wed, 11 Dec 2002, Dan Sugalski wrote: Are in. You can now get, set, delete, and get a hash of PMC properties. (Hopefully) Alas, no tests. Working on that, but if someone wants to beat me to it, feel free. I would expect this: new P0, .PerlInt new P1, .PerlInt set S0, Brown set P0, Yes setprop P1, S0, P0 set S0, Black hash keys are only referenced not copied into the hash. So you reset here the first key to Black ... In fact, it prints: No No ... which explains this. Simon leo
Re: Properties
On Thu, 12 Dec 2002, Leopold Toetsch wrote: Simon Glover wrote: On Wed, 11 Dec 2002, Dan Sugalski wrote: Are in. You can now get, set, delete, and get a hash of PMC properties. (Hopefully) Alas, no tests. Working on that, but if someone wants to beat me to it, feel free. I would expect this: new P0, .PerlInt new P1, .PerlInt set S0, Brown set P0, Yes setprop P1, S0, P0 set S0, Black hash keys are only referenced not copied into the hash. So you reset here the first key to Black ... I see what you mean; changing the code to this: new P0, .PerlInt new P1, .PerlInt new P3, .PerlInt set S0, Brown set P0, Yes setprop P1, S0, P0 set S0, Black set P3, No setprop P1, S0, P3 new P2, .PerlString getprop P2, Brown, P1 print P2 print \n getprop P2, Black, P1 print P2 print \n end does indeed print: Yes No This still doesn't answer my question, though: is the fact that the keys are passed by reference a bug or a feature? Also, the above code (and the original version) still segfaults if I run it with --gc-debug. Simon
Re: Parrot v0.0.9 code freeze
Steve Fink [EMAIL PROTECTED] writes: Heads up. The weather report indicates a feature freeze on Sat 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to a release on Wed 2002-Dec-18. So if you have any feature changes that you want to get into 0.0.9 (and it isn't too destabilizing), please commit them before Saturday. Is it possible to put patch #18379 in? This patch brings languages scheme in the direction of a functional language. It shouldn't break anything, because its only a scheme - pasm translation. bye b. -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Properties
At 10:47 AM -0500 12/12/02, Simon Glover wrote: This still doesn't answer my question, though: is the fact that the keys are passed by reference a bug or a feature? Feature. The crashing, though, is a bug. And (D'oh!) I know where, too--the GC doesn't know about the prop hash member so it's not getting considered. I'll go fix. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot v0.0.9 code freeze
At 4:51 PM +0100 12/12/02, Juergen Boemmels wrote: Steve Fink [EMAIL PROTECTED] writes: Heads up. The weather report indicates a feature freeze on Sat 2002-Dec-14 at 20:00 GMT (12:00 PST, 15:00 EST, 21:00 CET), leading to a release on Wed 2002-Dec-18. So if you have any feature changes that you want to get into 0.0.9 (and it isn't too destabilizing), please commit them before Saturday. Is it possible to put patch #18379 in? This patch brings languages scheme in the direction of a functional language. It shouldn't break anything, because its only a scheme - pasm translation. It's in. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19031] [PATCH] befunge's Makefile autogenerated by configure
At 8:30 AM + 12/11/02, Jerome Quelin (via RT) wrote: Thanks to bf's example, I'm now writing Befunge Makefile while configuring Parrot. I hope that I did not miss sthg important. Please note that $PARROT/languages/befunge/Makefile should go (the patch only empties it AFAICT) - and I removed it from MANIFEST. Applied, thanks. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [INFO] Buffer/PMC unification
At 1:12 PM +0100 12/11/02, Leopold Toetsch wrote: Changes #6. - PMC_*_FLAGs are history. - I did remove the bogus looking, unused, untested and superfluous destroy from core.ops It's not actually superfluous. If for some reason someone wants to write part of the GC cleanup sweep in pasm, they'll need it. It's also needed when code needs to explicitly kill a PMC. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Properties
Simon Glover wrote: On Thu, 12 Dec 2002, Leopold Toetsch wrote: This still doesn't answer my question, though: is the fact that the keys are passed by reference a bug or a feature? hash.c works like this. If it's a bug or feature WRT properties - I don't know. Also, the above code (and the original version) still segfaults if I run it with --gc-debug. With my recent changes in dod.c/headers.c checked out from CVS? Simon leo
Re: Properties
On Thu, 12 Dec 2002, Leopold Toetsch wrote: Simon Glover wrote: Also, the above code (and the original version) still segfaults if I run it with --gc-debug. With my recent changes in dod.c/headers.c checked out from CVS? Yep. I've just double-checked with a completely fresh check-out. Simon
Re: [INFO] Buffer/PMC unification
Dan Sugalski wrote: At 1:12 PM +0100 12/11/02, Leopold Toetsch wrote: Changes #6. - PMC_*_FLAGs are history. - I did remove the bogus looking, unused, untested and superfluous destroy from core.ops It's not actually superfluous. If for some reason someone wants to write part of the GC cleanup sweep in pasm, they'll need it. It's also needed when code needs to explicitly kill a PMC. Just don't reference the PMC and it will go away. I can't imagine the some reason it will be dead slow. And, actively destroying something is dangerous. When there is a real need for it, ok - then add it again. leo
Re: Properties
At 11:29 AM -0500 12/12/02, Simon Glover wrote: On Thu, 12 Dec 2002, Leopold Toetsch wrote: Simon Glover wrote: Also, the above code (and the original version) still segfaults if I run it with --gc-debug. With my recent changes in dod.c/headers.c checked out from CVS? Yep. I've just double-checked with a completely fresh check-out. Weird. It doesn't die for me, which is annoying. We'll work it into a test and see where it does fail in the tinderbox. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Properties
On Thu, 12 Dec 2002, Leopold Toetsch wrote: Simon Glover wrote: On Thu, 12 Dec 2002, Leopold Toetsch wrote: Simon Glover wrote: Also, the above code (and the original version) still segfaults if I run it with --gc-debug. With my recent changes in dod.c/headers.c checked out from CVS? Yep. I've just double-checked with a completely fresh check-out. prot tests do segfault here[1] w/o the change in dod.c and don't segfault with marking metadata as in CVS - strange (your snippet runs fine too). Mystery solved; I'd botched writing the test, and it was segfaulting for a completely different reason (forgetting to create a PMC before assigning to it). With a properly written test, it now works as expected. Sorry for wasting your time, gentlemen. Simon
Re: Properties
Dan Sugalski wrote: At 11:29 AM -0500 12/12/02, Simon Glover wrote: Weird. It doesn't die for me, which is annoying. We'll work it into a test and see where it does fail in the tinderbox. The newly added test case #2 was -hmmm- somewhat wrong. leo - no segfault
Re: A work list! (Coming soon)
Dan Sugalski wrote: What I'd like is for folks to take the next day or three to think of the things that they need parrot to do that aren't working or designed yet, and throw them at the list. TODO: - badly needed: line numbers in packfile (implying PBC extensions) - run through KNOWN_ISSUES (which I updated not too long ago) and make this file as short as before my update ;-) - DOD with optimized parrot compile (mark processor regs) on $arch? - Design documents e.g. vtable var/value split I would like to have a docs/architectures.pod with all pecularities of all todo supported $arch's. Same would be fine for C-compilers. Enough for now, leo
Re: String Literals, take 3
On Tue, 10 Dec 2002 16:08:25 -0500, Joseph F. Ryan wrote:
Peter Haworth wrote:
On Thu, 05 Dec 2002 15:17:57 -0500, Joseph F. Ryan wrote:
Again, C STRING.split(' ') is different than
C STRING.split(/\s+/) . The latter will add an empty element to the
beginning of the string if there is leading whitespace, which is not the
behaivor will have (if it acts like qw(), at any rate.)
I hate this special case. Why is there no way of specifying the removal
of leading empty elements with any other separator string?
Given that strings and regular expressions are different types of objects,
maybe the single whitespace rule could be extended to any single
character delimeter
That's still an unchangeable special case. In some circumstances, I might
want leading empty fields when I specify space as the separator, and in
others I might want them stripped with any random separator string or
regex. There needs to be a way to explicitly specify whether leading blanks
are required.
--
Peter Haworth [EMAIL PROTECTED]
I think that was lobotomy rather than trepanation wasn't it? Important to
understand the difference if you're considering trepanning yourself at home
-- Robin Houston
Re: Help with setting up Perl6
On Wed, 11 Dec 2002, Jared Rhine wrote: In languages/perl6/t/compiler/1_1.err, I get: Can't find loader Parrot_DynOp_core_0_0_7: ../imcc/imcc: undefined symbol: Parrot_DynOp_core_0_0_7 which is suspicious for the 0_0_7 when I actually checked out 0_0_8. You're right on the mark here. If you re-checkout imcc from 2002/09/06 01:21:17 or later, the version number should be fixed, and things should work much better. /s
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/11/02 11:41 PM, Luke Palmer wrote: More generally, I really don't want to have too many (any?) system object method names squatting in my all-lowercase object method namespace. It's not hard to think of many kinds of objects that would naturally have an id attribute, but must now have foo_id and bar_id methods because the (probably rarely used) id method from UNIVERSAL (or whatever it is today) is hogging it. I'd argue that you'd better pick a better name than .id anyway. You wouldn't use .foo_id and .bar_id, you'd use .descriptor or .index (though that one's not too much more descriptive than .index). I'd say .id should be kept short and sweet, because it's going to be used on a wider variety of objects than your database .id. I use the id attribute of my database objects much more often than I compare object identities. IMO, common method names like id should be in the user's domain, to be used as is applicable to each kind of object. -John
RE: Comparing Object Identity
Piers Cawley:
# Luke Palmer [EMAIL PROTECTED] writes:
# Theoretically, there are sufficiently few Object methods to warrant
# normal names.
#
# Right now there are 'sufficiently few' Object methods, but
# I'm betting that before the game is over there's going to a
# be a whole pile more, just take a look at any Smalltalk image
# if you don't believe me. But that's no reason for upcasing
I'll probably burn in Hell for saying this, but in .NET System.Object
only has four methods. (One of those, however, is GetType(), which you
use to do things like UNIVERSAL::isa() in Perl.)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: right-to-left pipelines
It seems to me that the simplest disambiguating rule is to require the parentheses on methods. The way I see it, any sort of matching of what [multi-]?method is to be called, is automatically doomed to failure. But I don't think that means we need to require parentheses, except to override the default behaviour. There are three meanings I can see for parenthesisless calls that are completely regular and meaningful, easy to read, and quite (debatably) good things. 1) Always assume nulladic. That is, $obj.id is always parsed exactly like $obj.id(). The advantage here is that short simple things can be written short and simply. 2) Always assume monadic. Personally, I don't think this would be that useful, but I'm mentioning it for completeness. Any call that doesn't have parentheses scoops up the next argument only. 3) Always assume variadic. Basically a lot like the perl5 rule. If you call something without parentheses, the parser puts parentheses around pretty much everything after it. If you don't like it, put your own parentheses where you really want them. So foo bar baz quux; would be parsed as foo(bar(baz(quux(; and foo bar, baz; would be exactly like foo(bar(), baz()); and if foo is later determined to be something that can only take one argument, well then too bad. The idea is that leaving off the parentheses is just shorthand, and doesn't need to do any lookup to determine whether what's typed is valid, any more than if you had typed foo(bar(), baz()); If you want foo to be monadic, call it as foo(bar), baz; or the lispy (foo bar), baz; (with optional parens after bar and baz, since they don't have anything more they could eat anyway, unless someone gets crazy enough to write a unary comma operator). So basically we can leave off the parentheses in the usual cases, but they're still required when you're doing something unusual or that would otherwise be hard to read. -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ I have a very firm grasp on reality! I can reach out and strangle it any time!
Re: right-to-left pipelines
On Thu, Dec 12, 2002 at 09:43:26AM -0600, Adam D. Lopresto wrote: So basically we can leave off the parentheses in the usual cases, but they're still required when you're doing something unusual or that would otherwise be hard to read. Which is simpler? You don't need parentheses except in the case that you're doing something unusual or you always need parentheses Surely the latter. It seems to me that requiring the parens will cause less confusion in the long run. But, I'm just waiting to see what brilliant ideas Larry et alia come up with :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Everything is an object.
--- Dave Whipp [EMAIL PROTECTED] wrote:
We seem happy to structure objects (using
attributes, etc.), but verbs remain flat and uninteresting: just
arbitrary names.
As a result of this lack of expressiveness in the grammar, we find
ourselves saying that if a concept doesn't fit the everything
is an object worldview, then it needs to be a built-in.
This is a good point.
I think that to a certain extent, this can be handled with properties.
It's just that we haven't gotten used to thinking this way, yet.
Already we've borrowed the Spanish ser/estar model (is/but) to
differentiate between permanent and transient characteristics.
(Then I unpacked my adjectives... He was a hairy bear. He was a scary
bear...)
Prepositions are kind-of-there with properties, and with the
specially-named-blocks (first, last, etc.) for order-prepositions.
The cat sat on the TV.
The cat sat near the TV.
The cat sat beside the TV.
The @#$@#$ cat sat in front of the TV.
Currently, that's going to be
$cat.sit($TV);
$cat.sit($TV but 'near');
$cat.sit($TV but 'beside');
and:
$cat = $cat but '@#$@#$';
$cat.sit($TV but 'in front of');
Some adverbial work has been put into blocks-as-arguments, as with sort
(sort these *ascendingly*). But in general, adverbs aren't obviously
there, yet.
(Lolly Lolly Lolly, get your adverbs here!
Quickly quickly quickly, get your adverbs here!
Slowly surely really, learn your adverbs here!)
Another use of adverbs is as intensifiers.
$x = 'useless' but 'necessary';
$y = but very 'necessary'; # How do you say this, really?
$z = but very very 'necessary';
If there were some (automatic) mechanism that ordered objects according
to their necessity (like the new part() built-in!!), the intensifiers
should affect the order:
sub do_stuff(@honeydew)
{
my (@a, @b, @c) = part
{
when necessary ;
default;
when optional is reversed; #? syntax
} @honeydew;
do_list(@a);
do_list(@b);
do_list(@c);
}
Ideally, the @a list and the @c list should honor the intensifiers and
be ordered such that the very-very necessary come before the very
necessary come before the necessary come before the not-very ...
Likewise, adverbs as verb modifiers provides a way to avoid having
several functions with similar behaviors.
Csort does this with a block: cool. But adverbs like securely,
surely, quickly, and dynamically don't necessarily translate well to
blocks, and they don't set context.
Perhaps we need adverbial scope?
# From LWP
# Pass request to the user agent and get a response back
my $res = $ua-request($req) securely;
... somewhere in the bowels of LWP6? ...
my $pcl = http;
when securely { $pcl = https };
Thus anyone could suggest behavior, and it may-or-may-not be acted
upon in the subsequent code. But the overall activity (the verb, which
is to say the subs/methods) gets done, regardless.
Ideas?
=Austin
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
(This is a reply to a mail accidently sent to me personaly instead of the list. Buddha, care to resend your other mail? I havn't quoted it in total.) On 12/12/2002 9:43 AM, Buddha Buck wrote: James Mastros wrote: Here's my basic defintion of ID: Two things should have the same ID if-and-only-if they will behave exactly the same, now and forevermore. If I wrote the Perl6 code correctly (and no guarantees that I hit this moving target), then once created, a Complex object cannot be modified and is indistinguishable by behavior from any other Complex object with the same value: Is it reasonable to have $a.id == $b.id? No, as you can still change the properties of the objects independently. If you can't even do that, then yes. -=- James Mastros
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
(resent as requested)
James Mastros wrote:
Here's my basic defintion of ID: Two things should have the same ID
if-and-only-if they will behave exactly the same, now and forevermore.
Thus, there should be one ID for all constants of the same value, which
is different from all constants of different value. (This is probably
unimplementable if we gaurntee IDs are of some constant length.)
Two objects should only have the same ID if they are aliases of
each-other: they always have the same instance values, and the same
value (but) properties.
Promotable, but unpromoted, Ints should have different IDs, because they
may at some point, have different values.
Any unconsidered cases?
What about value objects (objects with no methods to change state after
creation?
class Complex {
# Hmmm, what's the attribute syntax this week?
attr .real is ro is public;
attr .imaginary is ro is public;
sub new($r, $i) {
my Complex $obj;
$obj.real = $r;
$obj.imaginary = $i;
return $obj;
}
method .magnitude { return sqrt($.real * $.real
+ $.imaginary * $.imaginary);
}
method .conjugate ( return Complex::new($.real, -$.imaginary); }
sub operator::* (Complex $a, Complex $b) is exported {
return Complex::new($a.real*$b.real-$a.imaginary*$b.imaginary,
$a.real*$b.imaginary+$a.imaginary*$b.real);
}
}
If I wrote the Perl6 code correctly (and no guarantees that I hit this
moving target), then once created, a Complex object cannot be modified
and is indistinguishable by behavior from any other Complex object with
the same value:
my Complex $a = Complex::new(5,4);
my Complex $b = Complex::new(5,4);
Is it reasonable to have $a.id == $b.id?
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On Thu, Dec 12, 2002 at 12:20:18PM -0500, James Mastros wrote: : (This is a reply to a mail accidently sent to me personaly instead of : the list. Buddha, care to resend your other mail? I havn't quoted it : in total.) : : On 12/12/2002 9:43 AM, Buddha Buck wrote: : : James Mastros wrote: : : Here's my basic defintion of ID: Two things should have the same ID : if-and-only-if they will behave exactly the same, now and forevermore. : : If I wrote the Perl6 code correctly (and no guarantees that I hit this : moving target), then once created, a Complex object cannot be modified : and is indistinguishable by behavior from any other Complex object : with the same value: : : Is it reasonable to have $a.id == $b.id? : : No, as you can still change the properties of the objects independently. : If you can't even do that, then yes. Which basically comes down to this: an id represents a location in memory for any objects that don't override the .id method. If you want to compare two immutable values to see if they're the same value, use a value comparison, not an id comparison! Whether two equivalent values will happen to have the same id should be considered an implementation detail, and should not generally be relied upon outside the class because it breaks encapsulation, insofar as it prevents a class from changing between shared and non-shared implementations of equivalent values. I see nothing wrong with having multiple objects with the same value, even if they happen to be immutable objects. It's up to the constructor to enforce identity of equivalent immutable values, if the class wants to do that. As for namespace pollution and classes that use .id in Perl 5, I don't think it's going to be a big problem. Built-in identifiers do not have a required prefix, but they have an optional prefix, which is C*. I think we can probably parse $a.*id == $b.*id if you really need to get to Object.id(). If our most-global splats start interfering with our list-flattening splats, we'll have to change one or the other. It's the concepts that are important, not the particular character. The general concept is that standard names should be easy to hide locally, but it should be almost as easy to get back to the standard definition. One extra character like * is good Huffman coding for that. Getting back to intermediate super or outer versions doesn't have to be so easy, so we have things like SUPER:: and OUTER:: for that. I'd almost be tempted to argue that if push comes to shove, it's the list splat star that gets shoved. Larry
Re: Everything is an object.
On Wednesday, December 11, 2002, at 06:56 PM, Simon Cozens wrote:
[EMAIL PROTECTED] (Michael Lazzaro) writes:
Wel... yes and no. You can make the same argument for operators
upon scalars, for example, since 'scalar' is arguably no more
universal than 'array'. And we could easily use that argument to
remove *all* builtins, period:
Now you're getting the idea.
Yes. But Java sucks. Me no like make Perl like Java.
I would still like to be able to do things in Perl6 like:
@out = sort map {...} grep { ... } @in;# [1]
Even though that technically means having sort, map, grep as builtins.
We can make that
@out = @in.grep({...}).map({...}).sort;# [2]
if we want to grind our OO axe, but I find that syntax disappointing.
I like that the idea is important enough in Perl to have it's own
grammar, but I realize the problem of namespace pollution involved in
having a bunch of builtins called grep, map, whatever.
The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can still
be called in a fashion similar to [1]. That would, I suspect, satisfy
everyone.
MikeL
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On 12/12/02 12:55 PM, Larry Wall wrote: As for namespace pollution and classes that use .id in Perl 5, I don't think it's going to be a big problem. Built-in identifiers do not have a required prefix, but they have an optional prefix, which is C*. I think we can probably parse $a.*id == $b.*id if you really need to get to Object.id(). That'll only work out if everyone always writes it as *id. If not, my Perl 6 objects that override id() won't work correctly with any other classes or functions that simply call id and expect it to really be *id But I suspect the reverse will happen. Everyone will just expect $a.id to be functionally the same as $a.*id, so no one will actually ever write $a.*id. And so I'm back to losing the ability to have id attributes on objects in Perl 6 that represent anything other than a place in memory, and back to my complaint about a system method hogging a common (IME) and sensible method name for many kinds of objects, using it to store information that is very infrequently accessed. Is one extra letter going to kill anyone? .uid? .oid? C'mon, throw me a bone here... :-} -John
RE: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
John Siracusa wrote:
On 12/12/02 12:55 PM, Larry Wall wrote:
As for namespace pollution and classes that use .id in Perl 5, I
don't think it's going to be a big problem. Built-in identifiers
do not have a required prefix, but they have an optional prefix,
which is C*. I think we can probably parse
$a.*id == $b.*id
if you really need to get to Object.id().
That'll only work out if everyone always writes it as *id.
If not, my Perl 6 objects that override id() won't work correctly
with any other classes or functions that simply call id and
expect it to really be *id
yes...
So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id;
I'm not sure I understand what Larry means by most-global... Do you mean
outer-most scope, root-of-method-inheritence, or both?
And what of the case we someone does want to explicitly override a builtin
method like UNIVERSAL::can? What is the Perl6 equivalent to:
*UNIVERSAL::can = sub { print qq{hello\n} };
sub foo {};
print main-can('foo');
And what will:
main.*can('foo')
result in?
Larry Wall wrote:
I'd almost be tempted to argue that if push comes to shove, it's
the list splat star that gets shoved.
Don't you suspect the list splat will be more common than most-global?
Re: A work list! (Coming soon)
Leopold Toetsch [EMAIL PROTECTED] writes: TODO: - badly needed: line numbers in packfile (implying PBC extensions) I have some toughts about PBC file extensions and some half working code. Unfortunaltly my day time job consumes an enormous amount of time at the moment. Lets see what i can to this evening. bye b. -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: A work list! (Coming soon)
Juergen Boemmels wrote: Leopold Toetsch [EMAIL PROTECTED] writes: TODO: - badly needed: line numbers in packfile (implying PBC extensions) I have some toughts about PBC file extensions and some half working code. Unfortunaltly my day time job consumes an enormous amount of time at the moment. Lets see what i can to this evening. No need to get it running today - tomorrow is early enough ;-) Thanks, would be greate. bye b. leo
[perl #19090] [PATCH] make parrot_v[sfn]*printf behave itself
# New Ticket Created by Sean O'Rourke
# Please include the string: [perl #19090]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19090
The following defines a macro VA_TO_VAPTR(x) to convert va_list arguments
to pointers in a platform-independent way. Works for me on Linux-ppc.
Could someone with another CPU give it a spin and/or make sure I hid the
macro in the right part of {config/,lib/Parrot/Configure,...}?
/s
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/45059/35500/f05e2e/va.patch
Index: misc.c
===
RCS file: /cvs/public/parrot/misc.c,v
retrieving revision 1.30
diff -p -u -w -r1.30 misc.c
--- misc.c 10 Dec 2002 14:24:12 - 1.30
+++ misc.c 12 Dec 2002 23:51:53 -
@@ -35,7 +35,7 @@ STRING *
Parrot_vsprintf_s(struct Parrot_Interp *interpreter, STRING *pat, va_list args)
{
SPRINTF_OBJ obj = va_core;
-obj.data = args;
+obj.data = VA_TO_VAPTR(args);
return Parrot_sprintf_format(interpreter, pat, obj);
}
Index: config/gen/feature_h/feature_h.in
===
RCS file: /cvs/public/parrot/config/gen/feature_h/feature_h.in,v
retrieving revision 1.1
diff -p -u -w -r1.1 feature_h.in
--- config/gen/feature_h/feature_h.in 12 Dec 2002 11:20:44 - 1.1
+++ config/gen/feature_h/feature_h.in 12 Dec 2002 23:51:55 -
@@ -15,6 +15,15 @@ if (${jit_i386} ${jit_i386} eq 'fcomi
print OUT #endif\n;
}
+if (${jitcpuarch} eq 'ppc') {
+print OUT 'END';
+#define VA_TO_VAPTR(x) (x)
+END
+} else {
+print OUT 'END';
+#define VA_TO_VAPTR(x) ((x))
+END
+}
#endif guard
print OUT \n\n#endif\n
Re: right-to-left pipelines
One possibility for R-to-L pipelines that would also solve the
namespace issues associated with reserving lots of keywords like map
and grep and part would be to have a quite literal inverse-C.
grammar. So instead of saying
$a.foo(args)
you could _always_ say an equivalent
foo(args) - $a;
Where the invocant $a is at the right, not the left.
(I know, I know... - is just a PLACEHOLDER. Ambiguous, etc.)
This would allow our visual R-to-L pipelines:
@out = sort {...} - map {...} - grep {...} - @in;
The primary advantage is that Cmap, etc. are *not* reserved keywords,
but simply object methods of @Array. You might even override Cgrep
for individual subclasses of Array, for example, perhaps to attach
additional variants.
The namespace issues are thus lessened considerably, as it takes the
specialness away from the particular Cmap-like keywords and puts it
in the grammar.
And parens might not be needed in the pipe, _if_ - is parsed as
grammar (similar to how postconditions work), not as an op.
But parsing it may be tricky, in that you can't get the invocant until
you've already parsed the method name and args. So methods must either
always have parens, or always slurp up all possible args -- anything
else is still ambiguous.
MikeL
Re: Everything is an object.
Date: Thu, 12 Dec 2002 10:11:00 -0800
From: Michael Lazzaro [EMAIL PROTECTED]
On Wednesday, December 11, 2002, at 06:56 PM, Simon Cozens wrote:
[EMAIL PROTECTED] (Michael Lazzaro) writes:
Wel... yes and no. You can make the same argument for operators
upon scalars, for example, since 'scalar' is arguably no more
universal than 'array'. And we could easily use that argument to
remove *all* builtins, period:
Now you're getting the idea.
Yes. But Java sucks. Me no like make Perl like Java.
I would still like to be able to do things in Perl6 like:
@out = sort map {...} grep { ... } @in;# [1]
Or, better yet:
@out = sort map grep @in: { ... }: { ... }:;
Hi Mister Maintainence Programmer :-P
Luke
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: John Siracusa wrote:
: On 12/12/02 12:55 PM, Larry Wall wrote:
: As for namespace pollution and classes that use .id in Perl 5, I
: don't think it's going to be a big problem. Built-in identifiers
: do not have a required prefix, but they have an optional prefix,
: which is C*. I think we can probably parse
:
: $a.*id == $b.*id
:
: if you really need to get to Object.id().
:
: That'll only work out if everyone always writes it as *id.
: If not, my Perl 6 objects that override id() won't work correctly
: with any other classes or functions that simply call id and
: expect it to really be *id
:
: yes...
:
: So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id;
If you wish to be precise, yes. But $a.id eq $b.id should work for most any
class that uses the the term id in the typical fashion.
: I'm not sure I understand what Larry means by most-global... Do you mean
: outer-most scope, root-of-method-inheritence, or both?
It's context dependent, just as the meaning of an identifier is context dependent.
In this case, it means root-of-method-inheritance, that is, Object. (That is
tne new name of UNIVERSAL.) So $a.*id is short for $a.Object::id. But $*foo
is short for $Global::foo or some such.
: And what of the case we someone does want to explicitly override a builtin
: method like UNIVERSAL::can? What is the Perl6 equivalent to:
:
: *UNIVERSAL::can = sub { print qq{hello\n} };
: sub foo {};
: print main-can('foo');
Any of:
method Object::can ($meth) { print qq[hello\n] }
or
*can := method ($meth) { print qq[hello\n] };
or
Object::can ::= sub ($object, $method) { print qq[hello\n] };
Hmm. Those don't really stand out enough. Maybe we should go with
OBJECT:: and GLOBAL:: just for a little more visual punch.
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's Main, not main. And it's a module, not a class,
so probably it fails, unless someone can think of something useful
for it to mean.
: Larry Wall wrote:
:
: I'd almost be tempted to argue that if push comes to shove, it's
: the list splat star that gets shoved.
:
: Don't you suspect the list splat will be more common than most-global?
That's why I said almost.
Larry
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/02 4:01 PM, Larry Wall wrote: On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote: : So we'll _have_ to write $obj.*id when we mean $obj-UNIVERSAL::id; If you wish to be precise, yes. But $a.id eq $b.id should work for most any class that uses the the term id in the typical fashion. I still feel like we're talking past each other here. What I was saying is that, regardless of any admonitions to the contrary, I think people will still write this: $a.id == $b.id and expect it to compare memory addresses. That is not the typical fashion for an object method named id to work, IMO. The need to compare memory addresses is so infrequent that warrants a much less common and/or longer method name than id. -John
RE: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
Larry Wall:
# Hmm. Those don't really stand out enough. Maybe we should go with
# OBJECT:: and GLOBAL:: just for a little more visual punch.
How about CORE:: instead of GLOBAL::? This helps stick with tradition
and minimize the number of reserved packages.
# : And what will:
# :
# : main.*can('foo')
# :
# : result in?
#
# These days it's Main, not main. And it's a module, not a
# class, so probably it fails, unless someone can think of
# something useful for it to mean.
I'd hope that Perl would allow me to do something like that to see if
Main::foo exists...
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: Comparing Object Identity
John Siracusa [EMAIL PROTECTED] wrote:
memory addresses is so infrequent that warrants a much
less common and/or longer method name than id.
Another reason for not making these synonymous:
Is the address of an object constant? Or might it be
remapped during the life of an object. For example,
arrays might move when they grow too big; distributed
objects may move as they transfer onto different hosts;
a persistent object might have a new address when
retrieved from backing-store).
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
If memory addresses can change over time, then we
need a more fundamental concept to act as the ID!
Dave.
Re: Comparing Object Identity
On 12/12/02 4:41 PM, Dave Whipp wrote: John Siracusa [EMAIL PROTECTED] wrote: memory addresses is so infrequent that warrants a much less common and/or longer method name than id. Another reason for not making these synonymous: [...] If memory addresses can change over time, then we need a more fundamental concept to act as the ID! Heh, it seems like you're supporting my position, but you're really not :) Whatever the this is the same object value actually is, I don't think it deserves to live under the method name id. -John
RE: Comparing Object Identity
Dave Whipp:
# Is the address of an object constant? Or might it be
# remapped during the life of an object. For example,
# arrays might move when they grow too big; distributed
# objects may move as they transfer onto different hosts;
# a persistent object might have a new address when
# retrieved from backing-store).
Under all systems I can think of, the memory address of an object's
header is constant. The data may move, but the header stays constant.
This is to minimize the insanity of pointer chasing in C.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
RE: Comparing Object Identity
--- Brent Dax [EMAIL PROTECTED] wrote: Dave Whipp: # Is the address of an object constant? Or might it be # remapped during the life of an object. For example, # arrays might move when they grow too big; distributed # objects may move as they transfer onto different hosts; # a persistent object might have a new address when # retrieved from backing-store). Under all systems I can think of, the memory address of an object's header is constant. The data may move, but the header stays constant. The '.id as memory address' scheme fails for any attempt to use id persistence (NOT object persistence, but ID persistence). That is, '.id-as-addr' is only useful for compare these two currently-in-memory objects, as opposed to have I EVER seen this object, or have I EVER-this-session seen this object, since recording the .id of the object in a cache doesn't preclude the object being GC'd when all other references go away. So the value of the current .id isn't much of an ID. Which does not remove the value of being able to quickly and easily say is this current-runtime-object the same as that one? It just suggests that the name .id isn't very well chosen. Other questions, like how do I generate a persistence-unique id?, also beg for .id as a non-reserved name (unless we propose to add macaddr and threadsafe timestamp as components of the standard .id -- not always a bad thing, but not a single opcode anymore...) =Austin
Re: Comparing Object Identity
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd have
to assure that no object id's are *ever* reused -- so mem addresses are
out, since the same address may be used for different things at
different points in time. It would literally have to be a unique
serialnum attached to every single object in the process' lifespan.
And if it were to work correctly for persistent objs, it'd have to be
unique even among all perl invocations. Eeew!
Whatever's behind 'id' is probably a meaningless blob with only one
use: to determine if two vars, $obj1 and $obj2, are in fact bound to
the same thing. You can't (meaningfully) store them for use elsewhere.
Anything else seems to imply icky overhead, yes?
MikeL
Re: right-to-left pipelines
Jonathan Scott Duff wrote: On Thu, Dec 12, 2002 at 09:43:26AM -0600, Adam D. Lopresto wrote: So basically we can leave off the parentheses in the usual cases, but they're still required when you're doing something unusual or that would otherwise be hard to read. Which is simpler? You don't need parentheses except in the case that you're doing something unusual or you always need parentheses Surely the latter. The former could be claimed to be analogous to use of parentheses with operators (or indeed in maths generally): there are precedence rules which mean that much of the time parens aren't needed (but you can always choose to add them), but when you want to do something else you need to put them in. When teaching programming I've encountered several people make decisions along the lines of It's always easier to put the parens in because then I keep full control and I'm not leaving it to 'chance' and I can see what's being done when without having to memorize the precedence table. I don't mind that in simple experssions, but if I see an expression with seven pairs of parens then I've got to stop for a couple of moments to check out which ones balance and what the expression is doing. Even if all seven pairs are redundant it still takes time to determine that, whereas a paren-less expression can be noted quickly as not doing anything odd. If six of those pairs of parens were superfluous but one of them was overriding precedence it isn't easy to spot which is which, when compared with an expression which only had the required pair. It seems to me that requiring the parens will cause less confusion in the long run. I think different people find different things confusing. Were Adam's rule to be in place, there's nothing to stop some people choosing to ignore it and include the parens all the time. (Just as in Perl 5 some people put parens on all built-in function calls all the time.) But, I'm just waiting to see what brilliant ideas Larry et alia come up with :-) Quite. Smylers
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
[EMAIL PROTECTED] (Larry Wall) writes: Which basically comes down to this: an id represents a location in memory for any objects that don't override the .id method. Aiee! No! Please don't let things override the address-in-memory method, as that makes foo.id == bar.id comparisons dubious at best and useless at worst. -- You stupid? All of Europe (maybe except those crazy Brits) prints on A4 paper. Crazy we may be, but not foolscap. -- James Kilfiger, ctt
Re: Everything is an object.
Michael Lazzaro wrote:
I would still like to be able to do things in Perl6 like:
@out = sort map {...} grep { ... } @in;# [1]
The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can
still be called in a fashion similar to [1]. That would, I suspect,
satisfy everyone.
What if the thing being Csorted (or whatever) is not an array but a
list?
@out = sort $scalar, @array, result_of_calling_function($param);
Would the list have to be stored in an array before it could be sorted?
That doesn't sound very nice ...
@out = [$scalar, @array, result_of_calling_function($param)].sort;
I think I'm in favour of things that operate on an arbitrary lists
remaining functions rather than becoming methods.
Smylers
Re: Comparing Object Identity
Dan Sugalski [EMAIL PROTECTED] wrote in message news:a05200f00ba1ebb73c6d2@[63.120.19.221]... There'll definitely be memory address reuse. If .id returns the current object's memory address, it shouldn't be cached any place, as otherwise you'll find things going bang with some regularity. In a multi-threaded environment, even a simple $a.id == $b.id may have significant time between the two lookups. If we are going to rely on addresses for id comparison, then we need to mandate that the address is constant for the life of the object. Brent indicated that he could think of no reason for the header address to change: but that isn't strong enough. We need a cast- iron guarantee. Otherwise we can't compare identity using .id. Dave.
Re: REs as generators
On Wed, Dec 11, 2002 at 06:53:20PM -0800, Randal L. Schwartz wrote:
Rich == Rich Morin [EMAIL PROTECTED] writes:
Rich On occasion, I have found it useful to cobble up a little language
Rich that allows me to generate a list of items, using a wild-card or some
Rich other syntax, as:
Richfoo[0-9][0-9] yields foo00, foo01, ...
Rich I'm wondering whether Perl should have a similar capability, using REs.
Well, here's a cheap way:
my @list = glob ('foo{0,1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9}');
:-)
Cheap in terms of programmer effort. But it uses a lot of RAM in perl5.
Enough the the golfers get upset that some of the shortest solutions don't
work because they run out of swap. IIRC Hugo is lucky because his auction of
an improvement for perl 5.10 could easily have ended up with a bidder who
wanted multiway globs to work in much less RAM.
Nicholas Clark
Re: Comparing Object Identity
At 2:42 PM -0800 12/12/02, Dave Whipp wrote: Dan Sugalski [EMAIL PROTECTED] wrote in message news:a05200f00ba1ebb73c6d2@[63.120.19.221]... There'll definitely be memory address reuse. If .id returns the current object's memory address, it shouldn't be cached any place, as otherwise you'll find things going bang with some regularity. In a multi-threaded environment, even a simple $a.id == $b.id may have significant time between the two lookups. No, that's not a problem, since neither $a nor $b can possibly go anywhere, as they're both being referenced. The GC is aggressive, but we do wait until a variable is at least dead before reaping it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Everything is an object.
On Thu, Dec 12, 2002 at 10:40:20PM -, Smylers wrote:
What if the thing being Csorted (or whatever) is not an array but a
list?
@out = sort $scalar, @array, result_of_calling_function($param);
Would the list have to be stored in an array before it could be sorted?
I would hope Perl would be smart enough to allow this:
@out = ($scalar, @array, result_of_calling_function($param)).sort
which Ruby does:
$ ruby -wle 'out = [foo, bar].sort; print out.join '
bar foo
but as I said, I find the Lisp flow style worth keeping.
@out = join \n, map {...} grep {...} sort {...} @foo
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Pancakes is the better part of valor.
http://www.goats.com/archive/971202.html
Re: Everything is an object.
On Thursday, December 12, 2002, at 02:40 PM, Smylers wrote:
What if the thing being Csorted (or whatever) is not an array but a
list?
@out = sort $scalar, @array, result_of_calling_function($param);
Would the list have to be stored in an array before it could be sorted?
I hope and expect that there is sufficient magic to treat a list as an
Array wherever necessary, such that Array method calls should be
allowed on any literal or Creturned list.
( $scalar, @array, foo() ).sort {...}; # [1]
my @a = ( $scalar, @array, foo() ); # [2]
@a.sort {...};
If we kept the current map syntax, the same should be true:
sort {...} $scalar, @array, foo(); # [1]
my @a = ( $scalar, @array, foo() ); # [2]
sort {...} @a;
Or if we can come up with a reverse-dot syntax that treats Csort as a
method of Array, and not a reserved keyword:
sort { ... } - $scalar, @array, foo(); # [1]
my @a = ( $scalar, @array, foo() ); # [2]
sort {...} - @a;
In each case, [1] should be marginally more efficient than [2], because
it's doing less.
Same magic for hashes, too. And maybe even for references upon
arrays/hashes:
(1,2,3,4,5).reverse; # returns (5,4,3,2,1)
[1,2,3,4,5].reverse; # returns [5,4,3,2,1]
But note:
@a.reverse;
@a .= reverse;# these two might mean different things?
my @a = (1,2,3,4,5);
@a.reverse; # OK
my $a = [1,2,3,4,5];
$a.reverse; # but this might be problematic
That last line would be OK only if the CRef type either didn't have
any methods of it's own (unlikely), or if CRef knew to look in the
methods of the referred-to obj if the method was not part of CRef
itself.
MikeL
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On Thu, Dec 12, 2002 at 01:50:37PM -0800, Brent Dax wrote:
: Larry Wall:
: # Hmm. Those don't really stand out enough. Maybe we should go with
: # OBJECT:: and GLOBAL:: just for a little more visual punch.
:
: How about CORE:: instead of GLOBAL::? This helps stick with tradition
: and minimize the number of reserved packages.
I don't like the Perl 5 tradition on top-level namespaces.
First of all, nobody really knows what core means anymore. Is it
just the built-in opcodes? Is it the functions that come with the
distribution? Neither of those map onto Perl 5 concept of CORE::
anymore. So Perl 6 doesn't have a CORE:: anymore. What used to
be in CORE goes into *, whever that means.
Second, in Perl 5 there are two global namespaces apart from CORE::.
If you say $::foo, you get $main::foo. If you say $STDIN, you
get some other namespace that has no name in Perl 5. In Perl 6,
the latter truly global namespace is combined with CORE to get what
main was trying to be in Perl 5. The former main namespace is
no longer intended to be used for globals, and the $::foo syntax is
no longer supported for that purpose. The translator will translate
$::foo to $Main::foo.
So $*IN really is considered to be in the global namespace, not
in the core namespace. You might argue that stdin is core in
some sense, but all global names go into *, not just built-ins.
This includes all user-defined package names. So the real name of
package Foo is GLOBAL::Foo. It's not Main::Foo, nor is it CORE::Foo.
It's short name isn't ::Foo, but *Foo. And you can just call it Foo
because the search for identifiers ends in GLOBAL (except for methods,
for which the search ends in OBJECT).
: # : And what will:
: # :
: # : main.*can('foo')
: # :
: # : result in?
: #
: # These days it's Main, not main. And it's a module, not a
: # class, so probably it fails, unless someone can think of
: # something useful for it to mean.
:
: I'd hope that Perl would allow me to do something like that to see if
: Main::foo exists...
Ordinarily you'd test for subs with one of
exists Main::foo
Main::foo.exists
As to whether .can should work for that, it should depend on whether
it's possible to invoke foo as a method in Main. This may or may
not be the same thing as having a sub declaration named foo.
Certainly classes will distinguish subs from methods. It may be
that modules will too, and you'd have to write package Main to
get Perl to confuse them like Perl 5 does. But that's not decided yet.
It's not clear what .can should return for a multimethod, either.
You'd have be able to return results like: yes int can mult, but
only if the second argument is an int or num. Basically, .can
has a bad syntax. We need a modifier on an ordinary multimethod
or subroutine call that says, Go through all the motions of calling
this, but don't really. To do that kind of almost-dispatch you often
need the actual arguments, or something resembling them. One is tempted
to say that taking a reference to a function call with arguments
does something like this:
\Main::foo(1,3)
The reference could be bound to the dispatch list, or be false if nothing
matched.
Except that syntax currently means something else, and doesn't work
for method calls. Maybe it's a good place for a question mark:
Main::foo?(1,3)
$foo.bar?(3)
and maybe even
$x +? $y
It's vaguely possible this should be unified with currying if the
construct actually returns a reference with prebound arguments.
It's also possible that it's not visible enough, and we should say
splashy like:
can { Main::foo(1,3) }
can { $foo.bar(3) }
can { $a + $y }
Exactly how much can-{} should do without doing anything is left as
an exercise for the reader. What would it do with this:
can { $a + $y + snort() }
I suppose one could set up a transactional structure in which can
actually does the side effects hypothetically, with the option of
committing later. Sort of what a try block would like to be when
it grows up...
Larry
Re: Everything is an object.
On Thu, Dec 12, 2002 at 04:17:44PM -0800, Michael G Schwern wrote:
: On Thu, Dec 12, 2002 at 10:40:20PM -, Smylers wrote:
: What if the thing being Csorted (or whatever) is not an array but a
: list?
:
:@out = sort $scalar, @array, result_of_calling_function($param);
:
: Would the list have to be stored in an array before it could be sorted?
:
: I would hope Perl would be smart enough to allow this:
:
: @out = ($scalar, @array, result_of_calling_function($param)).sort
It does, under the rule that says a comma list in a scalar context
assumes [...]. (The dot provides the scalar context to the comma
list--the outer list context is only meaningful to the sort.)
: which Ruby does:
:
: $ ruby -wle 'out = [foo, bar].sort; print out.join '
: bar foo
:
: but as I said, I find the Lisp flow style worth keeping.
:
: @out = join \n, map {...} grep {...} sort {...} @foo
That too. But you don't have to think of them as built-ins, except
insofar as any subroutine defined in * is a built-in. It's possible
the only real built-in is *sub. And maybe *rx.
Larry
Re: Everything is an object.
On Wed, Dec 11, 2002 at 06:50:12PM -0800, Michael Lazzaro wrote:
:
: On Wednesday, December 11, 2002, at 06:41 PM, Michael Lazzaro wrote:
:print $i; # ILLEGAL; use $STDOUT.print($i) or $i.print (?)
:reverse @a; # ILLEGAL; use @a.reverse;
:map {...} @a; # ILLEGAL; use @a.map({...});
:sort {...} @a; #
:keys %h;# ...etc...
:
: (And yes, I'm aware that (1 = N = 5) of those are going away already.)
Actually, N might be 0. The : may not always be required on single arg
methods in indirect object syntax. That is, if there's no sub matching
keys %h
it'll fall back to looking for
keys %h:
I have horrors of seeing programs full of things like
close $FH:;
Larry
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
On 12/12/2002 4:01 PM, Larry Wall wrote:
On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
: And what will:
:
: main.*can('foo')
:
: result in?
These days it's Main, not main. And it's a module, not a class,
so probably it fails, unless someone can think of something useful
for it to mean.
It would, logicaly, mean that the class Module has a method foo if
true -- applying can on an object tells you if the class of that object
can do somthing, and Main is an object of class Module... right?
(%Main:: is a hash, but Main (bareword) is an object, no?)
-=- James Mastros
Exists and hypotheticals (Was: Re: Comparing Object Identity)
On 12/12/2002 8:07 PM, Larry Wall wrote:
Ordinarily you'd test for subs with one of
exists Main::foo
Main::foo.exists
I thought that was now spelt exists %Main::{foo} -- that the symbol
tables were now just plain hashes? (And what's the methody syntax for
testing for hashkey existance -- %hash{key}.exists should get the key
element of hash, then run it's exists method, logicly. Is it
%hash.exists('key')?
I suppose one could set up a transactional structure in which can
actually does the side effects hypothetically, with the option of
committing later. Sort of what a try block would like to be when
it grows up...
Or hypothetical variables in a non-regex context...
-=- James Mastros
Re: Comparing Object Identity
On 12/12/2002 5:24 PM, Dan Sugalski wrote:
At 2:17 PM -0800 12/12/02, Michael Lazzaro wrote:
On Thursday, December 12, 2002, at 01:41 PM, Dave Whipp wrote:
I might want to write code such as:
$remembered_id = $obj.id;
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
I think if you do this, you're probably in a world of hurt. We'd have
to assure that no object id's are *ever* reused -- so mem addresses
are out, since the same address may be used for different things at
different points in time.
There'll definitely be memory address reuse. If .id returns the current
object's memory address, it shouldn't be cached any place, as otherwise
you'll find things going bang with some regularity.
And I'd say (but who asked me -- IMHO, of course) that it should be
perfectly valid to write code like the above. (That IDs should be
unique across a process over all time.) If that'd require that an
object's ID be a combination of the header address and a generation
counter, that's OK. It means a serilization point in the allocator, but
I think we'd need one no matter what (Dan?).
-=- James Mastros
Re: Everything is an object.
On Thursday, December 12, 2002, at 01:11 PM, Michael Lazzaro wrote:
We can make that
@out = @in.grep({...}).map({...}).sort;# [2]
if we want to grind our OO axe, but I find that syntax disappointing.
I like that the idea is important enough in Perl to have it's own
grammar, but I realize the problem of namespace pollution involved in
having a bunch of builtins called grep, map, whatever.
The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can still
be called in a fashion similar to [1]. That would, I suspect, satisfy
everyone.
Well, if the source file were considered to be just a big giant class,
sans
class main {
...
}
then it becomes as simple as having a method in Object, grep, something
like:
class Object {
method grep($a_closure, *@input) {
...
}
}
