Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Simon Cozens <[EMAIL PROTECTED]> wrote: > [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. Java-like final methods in core classes ? (And even in Java, Object.hashCode(), which returns the object's memory address in its base implementation, is overridable.) And by the way, doesn't Perl 6 allow C<\$foo == \$bar> ? (I missed the beggining of the thread.)
Re: Everything is an object.
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 12 Dec 2002 17:33:06 -0800
> From: Larry Wall <[EMAIL PROTECTED]>
> Mail-Followup-To: [EMAIL PROTECTED]
> Content-disposition: inline
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> 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.
Yay!
Luke
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
> Date: Thu, 12 Dec 2002 17:07:21 -0800 > From: Larry Wall <[EMAIL PROTECTED]> > > 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. Perhaps currying could be our aide: can(&foo.assuming(1, 3)); The only question is, what happens when not all the arguments are curried? Perhaps it could return true if the rest of the arguments matched any multimethod. So: can(&bar); Without any currying would be true if bar is a sub, and false if it isn't. I think that generalizes nicely. Luke
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
> Date: Thu, 12 Dec 2002 16:26:28 -0500
> From: John Siracusa <[EMAIL PROTECTED]>
>
> 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.
And presumably, anyone who overrides .id in their own class knows what
they're doing. They, in fact, I statements like that to behave
that way. Junction, by delegation, will override that method to
return a junction of the .ids of its states.
Speaking of which, how do you code delegation?
class Disjunction is Junction {
has @.states is public;
# ...
# Use the class's AUTOLOAD?
method AUTOLOAD($name, *@args) {
any(map { $_.$name.(*@args) } @.states);
}
# Or use some kind of DELEGATE method, taking a curried
# function with only the invocant left blank.
method DELEGATE(&func) {
any(map { $_.&func } @.states);
}
}
I rather like the latter.
Luke
Re: Everything is an object.
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> 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.
What's wrong with:
class Array {
method grep ( &block ) {
foreach .values {
yield $_ if &block($_);
}
}
method grep ( Rule $rule ) {
foreach .values {
yield $_ if /$rule/;
}
}
...
}
sub grep (Object $obj, @*ary) { @ary.grep($obj); }
AFAICT, (modulo getting the laziness done right, this should allow
you to write)
grep { ... } @ary;
grep /.../, @ary;
Writing the
grep foo($_), @ary
form in Perl 6 is left as an exercise to the interested reader, I get
the feeling it's going to have to wait until you can write 'special
form' subs.
sub grep ( rx// $expr, @*ary ) {
grep $expr.as_block, @ary
}
Might be one approach, but I'm waiting for Larry.
Re: [perl #19090] [PATCH] make parrot_v[sfn]*printf behave itself
On Thu, 12 Dec 2002, Sean O'Rourke wrote:
> # New Ticket Created by "Sean O'Rourke"
> # Please include the string: [perl #19090]
> # in the subject line of all future correspondence about this issue.
> # 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,...}?
Works fine for me on Linux/x86.
Simon
Re: Comparing Object Identity
On 12/13/02 5:09 AM, Luke Palmer wrote:
>> From: John Siracusa <[EMAIL PROTECTED]>
>> 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.
>
> And presumably, anyone who overrides .id in their own class knows what
> they're doing. They, in fact, I statements like that to behave
> that way.
I think you're missing my point. I'm saying that there are many kinds of
objects that naturally want to have an "id" method or attribute that has
nothing whatsoever to do with "this is the same object" comparisons. But if
"id" is chosen as the name of the global "this is the same object" method in
Perl 6, then no one can safely use a method named "id" (overridden or
otherwise) for anything but "this is the same object" comparisons.
I think this is a bad idea because "this is the same object" comparisons are
relatively rare, and do not deserve to be hogging the short, direct method
name of "id".
Example: Instead of getting a user id via $user.id and a product id via
$product.id, Perl 6 programmers will be forced to mark-up their methods
names ($user.uid, $product.pid) and then deal with the differences in any
heterogeneous collection:
# Too bad the method named "id" is taken by a value that
# you're rarely interested in, huh :P
for @users, @products, @transactions, @mixed -> $thing
{
print $thing.type, " id ";
given $thing.type
{
when 'user'{ print $thing.uid }
when 'process' { print $thing.pid }
when 'transaction' { print $thing.tid }
...
}
print "\n";
}
As opposed to:
# Ah, blessed sanity...
for @users, @products, @transactions, @mixed -> $thing
{
print $thing.type, " id ", $thing.id, "\n";
}
(Yes, you could just decide that all your objects will use "oid" or
something else, but that would be another symptom of the problem: Perl 6 is
forcing you to (slightly) obfuscate your code. Your first thought was to
simply use the well understood name "id" like you always have, but you're
out of luck.)
Using the method/attribute named "id" for "this is the same object"
comparisons is just plain bad Huffman coding. The "this is the same object"
method/attribute should have a name that reflects the relative rarity of its
use.
-John
RE: Comparing Object Identity [x-adr][x-bayes]
John Siracusa wrote: > > I'm saying that there are many kinds of objects that > naturally want to have an "id" method or attribute > that has nothing whatsoever to do with "this is the > same object" comparisons. [...] > Using the method/attribute named "id" for "this is > the same object" comparisons is just plain bad > Huffman coding. The "this is the same object" > method/attribute should have a name that reflects > the relative rarity of its use. Other common names for the proposed .id are: UUID: Universal Unique Identifier (DCE) http://www.opengroup.org/onlinepubs/9629399/apdxa.htm GUID: Globally Unique Identfier (EFI) http://ulita.ms.mff.cuni.cz/pub/techdoc/ia64/EFISpec_092.pdf (page 319) Of the 2, usage of "GUID" seems to be more common IMHO. Both of the above are identical in implementation. And won't rollover until 3400AD ;) -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Comparing Object Identity [x-adr][x-bayes]
On 12/13/02 10:49 AM, Garrett Goebel wrote:
> John Siracusa wrote:
>> Using the method/attribute named "id" for "this is
>> the same object" comparisons is just plain bad
>> Huffman coding. The "this is the same object"
>> method/attribute should have a name that reflects
>> the relative rarity of its use.
>
> Other common names for the proposed .id are:
>
> UUID: Universal Unique Identifier (DCE)
> http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
>
> GUID: Globally Unique Identfier (EFI)
> http://ulita.ms.mff.cuni.cz/pub/techdoc/ia64/EFISpec_092.pdf
> (page 319)
>
> Of the 2, usage of "GUID" seems to be more common IMHO. Both of the above
> are identical in implementation. And won't rollover until 3400AD ;)
...and if we also (or instead) want to have a universal method for getting
Perl 5-style memory address hashes ("FOO(0x12345)"), then that should have a
name without the phrase or idea of "identifier" anywhere in it, IMO:
"memhash", "memaddr", etc.
-John
RE: [perl #19090] [PATCH] make parrot_v[sfn]*printf behave itself
Sean O'Rourke:
# +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
# +}
How in the world does that...? Never mind, I don't think I want to
know. Might make my head explode or something. :^)
--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 #19090] [PATCH] make parrot_v[sfn]*printf behave itself
Sean O'Rourke (via RT) wrote:
+if (${jitcpuarch} eq 'ppc') {
Shouldn't that better be ${cpuarch}. When JIT is disabled, ${jitcpuarch}
seems to be 'i386'. Also in case of 'miniparrot', ${cpuarch} is set to
'unknown' - suboptimal (s. config/auto/jit.pl).
leo
Re: Comparing Object Identity
On Friday, December 13, 2002, at 06:56 AM, John Siracusa wrote: I'm saying that there are many kinds of objects that naturally want to have an "id" method or attribute that has nothing whatsoever to do with "this is the same object" comparisons. But if "id" is chosen as the name of the global "this is the same object" method in Perl 6, then no one can safely use a method named "id" (overridden or otherwise) for anything but "this is the same object" comparisons. I agree 100%. I use .id *often* in my coding. Or more accurately, I must connect regularly with database tables that have 'id' as a field I need to extract. :-( (And postgresql uses 'oid' as a globally unique id.) I think this is one (rare) case where an UPPERCASE or unusual name might not be a bad idea, so it will BRING ATTENTION to the fact that you're using a unusual method. $obj.ID; $obj.IDENTITY; If don't think we'll have much of a chance at teaching people to _always_ use ($obj.*id == $obj.*id) instead of ($obj.id == $obj.id). MikeL
Re: Comparing Object Identity
On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote: 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?). I'm more worried about storing them than creating them. The good thing about using memaddresses is that they're free; you don't need to store a separate ID in each and every object you ever create, on the off chance that something will want to use it. Having an actual internal ID associated with every object would mean you'd have to store all those IDs, which could get very big very fast. I think the odds of you wanting a truly unique ID for any given class are so low that we'd probably be better off leaving it as a DIY project. MikeL
RE: Comparing Object Identity
Michael Lazzaro:
# On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote:
# > 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?).
#
# I'm more worried about storing them than creating them. The
# good thing
# about using memaddresses is that they're free; you don't need
# to store
# a separate ID in each and every object you ever create, on the off
# chance that something will want to use it.
Generating the Ids on request (i.e. the first time you call .id) would
help, but it would still mean having a slot for the information.
Honestly, I think a unique-across-the-object's-lifetime ID is probably
fine for many purposes. Perhaps we could have a sort of weak reference
that would null itself out when its referent was destroyed, if this is a
problem. (Don't know how that would work with the whole immutable hash
keys thing, though...)
--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
On 12/13/02 12:44 PM, Michael Lazzaro wrote: > On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote: >> 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?). > > I'm more worried about storing them than creating them. The good thing > about using memaddresses is that they're free; you don't need to store > a separate ID in each and every object you ever create, on the off > chance that something will want to use it. > > Having an actual internal ID associated with every object would mean > you'd have to store all those IDs, which could get very big very fast. You could always just autovivify them. Since most objects will never have their "UUID"s accessed, the overhead should be very small. > I think the odds of you wanting a truly unique ID for any given class > are so low that we'd probably be better off leaving it as a DIY project. I think it's important enough to be in the "core", if only to prevent fragmentation in the world of object persistence. -John
Re: Everything is an object.
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.
On Friday, December 13, 2002, at 03:07 AM, Piers Cawley wrote:
What's wrong with:
class Array {
method grep ( &block ) {
}
sub grep (Object $obj, @*ary) { @ary.grep($obj); }
AFAICT, (modulo getting the laziness done right, this should allow
you to write)
grep { ... } @ary;
grep /.../, @ary;
The only issue is that it still treats C as a universal sub --
it's just giving you an identically named C method of Array, too.
The ideal solution IMO is one that would remove C, C, etc.
_entirely_ from the main/core/Object, and leave it _solely_ as a method
of Array. Not because C is inherently evil, but because that
would give us a completely generic way to make other "piped" grep-style
functions, like C, without polluting the core namespace.
A (placeholder for a) R-to-L "dot-like" operator:
grep {...} <- @foo;
would be intended to be the *exact* equiv of
@foo.grep {...};
but with a reversed syntax for the invocant. So grep-like functions
could be nested, and new ones could be created by making new methods of
Array, AND we could get rid of the "specialness" of the Perl5 map/grep
syntax -- the syntax isn't special to a few list-munging functions, it
can be used for anything.
@out = sort <- map {...} <- grep {...} <- @in;
So it's almost what we had in Perl5, but more regular.
Of course, maybe '<-' is just spelled post-"given", and we're done:
@out = sort
given map { ... }
given grep { ... }
given @in;
Or would that be @out = .sort given .map ...etc...?
MikeL
Re: purge: opposite of grep
Damian Conway writes:
> Famous last words. ;-)
>
>
> > Was it ever decided what C would look like with multiple streams?
>
> for zip(@x, @y, @z) -> $x, $y, $z {...}
>
> and its operator version:
>
> for @x ¦ @y ¦ @z -> $x, $y, $z {...}
>
>
> > Maybe we could just use the stream delimiters in the C like we do
> > in C?
>
> No. We gave up special stream delimiters in Cs,
> in preference for general zippers.
>
> Damian
>
but one can think of zip(...) being able to be l-value
@x ¦ @y ¦ @z := map { /foo/ && $_ but unzip(0),
/bar/ && $_ but unzip(1),
/zap/ && $_ but unzip(2),
}, @source;
where argument of unzip is index of the stream to which to "direct"
the value . but then I am not sure where the actual "nzipping" happens
and what does it mean binding to the l-value function.
arcadi
Re: Exists and hypotheticals (Was: Re: Comparing Object Identity)
On Thu, Dec 12, 2002 at 09:39:18PM -0500, James Mastros wrote:
> 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
Or this:
http://search.cpan.org/src/SIMONW/Whatif-1.01/README
--Dks
Re: Comparing Object Identity
On Fri, Dec 13, 2002 at 09:56:15AM -0500, John Siracusa wrote: > Using the method/attribute named "id" for "this is the same object" > comparisons is just plain bad Huffman coding. The "this is the same object" > method/attribute should have a name that reflects the relative rarity of its > use. FWIW, I have agreed with John throughout this entire thread, but I felt that he was stating things quite clearly and I didn't have anything further to add. I just want to chime in so he doesn't feel like a lone voice in the wilderness. --Dks
Re: Comparing Object Identity [x-adr][x-bayes]
On Fri, Dec 13, 2002 at 09:49:44AM -0600, Garrett Goebel wrote: > Other common names for the proposed .id are: > > UUID: Universal Unique Identifier (DCE) > GUID: Globally Unique Identfier (EFI) > > Of the 2, usage of "GUID" seems to be more common IMHO. Both of the above > are identical in implementation. And won't rollover until 3400AD ;) Which is actually rather a shame, since "Global" has multiple common meanings in programming, which "Universal" does not. --Dks
Re: Comparing Object Identity
Michael Lazzaro wrote: I think this is one (rare) case where an UPPERCASE or unusual name might not be a bad idea, so it will BRING ATTENTION to the fact that you're using a unusual method. $obj.ID; $obj.IDENTITY; If don't think we'll have much of a chance at teaching people to _always_ use ($obj.*id == $obj.*id) instead of ($obj.id == $obj.id). I agree. My understanding of what Larry was proposing would have the majority of cases where people would want to use $obj.*id, $obj.id would work as well. If that is the case, there is no incentive for the majority of programmers to be careful enough to use the longer form $obj.*id instead of the shorter $obj.id form. Especially when explaining what the * in *id does has to be done. I feel that, in cases were $obj.id would have a natural interpretation in the class meaning something other than an object-specific ID, developers would be bit too often by careless use of $obj.id when $obj.*id is needed. MikeL
Literal tests [was: Help with setting up Perl6]
Jared> In languages/perl6/t/compiler/1_1.err, I get: Jared> Jared> Can't find loader Parrot_DynOp_core_0_0_7: ../imcc/imcc: Jared> undefined symbol: Parrot_DynOp_core_0_0_7 Jared> Jared> which is suspicious for the 0_0_7 when I actually checked out Jared> 0_0_8. Sean> You're right on the mark here. If you re-checkout imcc from Sean> 2002/09/06 01:21:17 or later, the version number should be Sean> fixed, and things should work much better. Ok, thanks! Following this lead, I checked out the head again and it built this time. My dod.c error must have gotten addressed since last night, cool. (I'm positive I actually did a completely fresh checkout of the head yesterday). On to some tests, although I'm curious to see how tests of literals turn out. Probably a lot of comparisons between different representations of the same thing. Are we archiving our docs like the latest Literals doc somewhere official, or should I just pick it out of the list archives? -- [EMAIL PROTECTED] "Tiger gotta hunt. Bird gotta fly. Man gotta sit and wonder why, why, why. Tiger gotta sleep. Bird gotta land. Man gotta tell himself he understand." -- Kurt Vonnegut Jr.
Re: Literal tests [was: Help with setting up Perl6]
On Thursday, December 12, 2002, at 01:39 PM, Jared Rhine wrote: Are we archiving our docs like the latest Literals doc somewhere official, or should I just pick it out of the list archives? Just grab it from the archives. We'll archive the approved sections somewhere, but probably not the drafts (at least not yet). MikeL
Re: Literal tests [was: Help with setting up Perl6]
On Thu, 12 Dec 2002, Jared Rhine wrote: > On to some tests, although I'm curious to see how tests of literals > turn out. Probably a lot of comparisons between different > representations of the same thing. Warning: most of the tests won't work now because the languages/perl6 is woefully incomplete, and because a lot of it was implemented before literals existed in their current form. If someone wants to get up to speed on the languages/perl6, this would be a great way to do it. If not, I'll put these on top of the stack for next time I have Parrot time (hopefully over break). /s
Re: [perl #19090] [PATCH] make parrot_v[sfn]*printf behave itself
On Fri, Dec 13, 2002 at 09:16:34AM -0500, Simon Glover wrote:
> On Thu, 12 Dec 2002, Sean O'Rourke wrote:
> > 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,...}?
>
> Works fine for me on Linux/x86.
Works fine for me on Linux/sparc and sparc Solaris
This is failing for me on both sparc machines:
t/pmc/perlhash..NOK 17# got: ''
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# '
The Solaris box has:
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs
gcc version 2.95.3 20010315 (release)
The Debian box has:
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
MASSIVE rewrite of Jako compiler is in
Dan --
OK.
The big rewrite is "done". There are still plenty of warts on the current
implementation,
not the least of which is a bunch of dead code that I still need to
remove. But, most
of the examples compile and run, including the ever popular (hi, acme!)
mandelzoom.
Queens.jako still doesn't work right, and now neither does primes.jako.
I've printed
out primes.{jako,imc,pasm} to see if I can locate the problem there.
Queens will
have to remain a mystery (not surprising, really -- mystery of royalty and
all) until I
solve primes (there's a thought...).
As a special treat, Jako now has a language feature for telling it about
ops that are
not among the basic set supported by imcc. For example, the test programs
I use
now have sub prototype lines like these in them:
sub print {op} (str s);
That thingee in the curly braces is a single entry in the compile-time
properties for
the sub being declared. The more general form, eventually intended to
support
loadable oplib stuff, is:
sub num coversine { oplib = "obscure", op = "covers" } (num x);
Limitation: You'll really want to be able to tell jakoc about different
versions of the same
op, with different arg types. The renaming notation above could help until
something
cooler comes along. But, in the case of print, you can just use
interpolated strings:
sub print {op} (str s);
const int x = 10;
print("$x\n");
which has the advantage of actually working, even though its not the most
efficient
thing to do (you can see the generated imc code to watch the string be
compiled).
I haven't looked lately at the IO stuff you want (I will soon). But, you
might be able to
do some fiddling with this feature, although be aware that I've not done
any testing
at all with the 'obj' type, which probably means jakoc will throw itself
on the floor and
go into a fit of convulsions and cursing when you try it...
BTW, the same syntax is intended for eventual use with the Native Call
stuff:
sub int BlitSurface { fnlib = "libsdl", fn = "SDL_BlitSurface" } (
obj { nat = "p" } src,
obj { nat = "p" } srcrect,
obj { nat = "p" } dst,
obj { nat = "p" } dstrect
);
Although that is brainware only for now.
This will all be much more useful when the Jako compiler has an include
mechanism. In
anticipation of this, there are a few .jako files in the languages/jako
directory that have
declarations of op-subs for various corners of the core op set.
Regards,
-- Gregor
Re: Everything is an object.
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> >> 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.
>
> On Friday, December 13, 2002, at 03:07 AM, Piers Cawley wrote:
> > What's wrong with:
> >
> > class Array {
> > method grep ( &block ) {
>
> > }
> >
> > sub grep (Object $obj, @*ary) { @ary.grep($obj); }
> >
> > AFAICT, (modulo getting the laziness done right, this should allow
> > you to write)
> >
> > grep { ... } @ary;
> > grep /.../, @ary;
>
> The only issue is that it still treats C as a universal sub --
> it's just giving you an identically named C method of Array,
> too. The ideal solution IMO is one that would remove C, C,
> etc. _entirely_ from the main/core/Object, and leave it _solely_ as a
> method of Array. Not because C is inherently evil, but because
> that would give us a completely generic way to make other "piped"
> grep-style functions, like C, without polluting the core
> namespace.
To what end? Actually, if we have multimethods correctly sorted, one
could envisage a CunningCollection class:
class CunningCollection {
method grep ( Object $obj ) { .as_array.grep($obj) }
sub grep ( Object $obj, CunningCollection $coll ) is exported {
$coll.grep($obj);
}
}
And it's trivial to do the same with any other syntax-like generic
function you care to come up with, no need for an extra syntactic wart.
>
> A (placeholder for a) R-to-L "dot-like" operator:
>
> grep {...} <- @foo;
>
> would be intended to be the *exact* equiv of
>
> @foo.grep {...};
>
> but with a reversed syntax for the invocant. So grep-like functions
> could be nested, and new ones could be created by making new methods
> of Array, AND we could get rid of the "specialness" of the Perl5
> map/grep syntax -- the syntax isn't special to a few list-munging
> functions, it can be used for anything.
>
> @out = sort <- map {...} <- grep {...} <- @in;
>
> So it's almost what we had in Perl5, but more regular.
>
> Of course, maybe '<-' is just spelled post-"given", and we're done:
>
> @out = sort
> given map { ... }
> given grep { ... }
> given @in;
>
> Or would that be @out = .sort given .map ...etc...?
Both of your proposed options are, frankly, vile. The
multimethod/generic function approach has the advantage of putting the
'burden' of writing the generic function on the implementor rather
than on the user. Given that implementation happens once and something
is used countless times, that seems like a decent trade off to me.
Re: Comparing Object Identity
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > > I'm more worried about storing them than creating them. The good > thing > about using memaddresses is that they're free; you don't need to > store > a separate ID in each and every object you ever create, on the off > chance that something will want to use it. > > Having an actual internal ID associated with every object would mean > you'd have to store all those IDs, which could get very big very > fast. > I think the odds of you wanting a truly unique ID for any given class > > are so low that we'd probably be better off leaving it as a DIY > project. Not necessarily. People who don't know any better can use .memaddr (or some other unique-internally method that needs only one opcode). People who use .id are either going to be paying too-high a price for their simple comparisons, or are going to want to pay the price. The information itself could be attached as a property, so every object doesn't have to pay the 16 bytes of overhead. =Austin
RE: Comparing Object Identity
Michael Lazzaro wrote: > > I'm more worried about storing them than creating them. > The good thing about using memaddresses is that they're > free; An UUID could be free up until the point where you request it. > I think the odds of you wanting a truly unique ID for any > given class are so low that we'd probably be better off > leaving it as a DIY project. I thought we wanted to be able to guarantee a unique identifier across the life of the object? -Objects may outlive processes... I'd rather trust the implementation than DIY'ers. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Everything is an object.
--- Piers Cawley <[EMAIL PROTECTED]> wrote: > > Both of your proposed options are, frankly, vile. The > multimethod/generic function approach has the advantage of putting > the > 'burden' of writing the generic function on the implementor rather > than on the user. Given that implementation happens once and > something > is used countless times, that seems like a decent trade off to me. Dictionary.com sez: "vile adj. vil·er, vil·est 1. Loathsome; disgusting: vile language. 2. Unpleasant or objectionable: vile weather. See Synonyms at offensive. 3. - a. Contemptibly low in worth or account; second-rate. - b. Of mean or low condition. 4. Miserably poor and degrading; wretched: a vile existence. 5. Morally depraved; ignoble or wicked: a vile conspiracy." Is this one of those BOFH things where you insult the hell out of someone and then give them a pat on the head, and six months later they're arrested while sneaking into the London Zoo wearing a leather corset and silk panties? (*) Otherwise, I'm left to wonder. As I read Mike's post, he's proposing that we regularize a feature of the language, make it extensible, and potentially use a conceptual framework based on an existing syntactical element. Yours, on the other hand, gives (I hope) the extensibility, doesn't require the syntactic bits but does appear to require that every such method be implemented twice. I'm going to need some more convincing. =Austin (*) Because if so, I'm all for it!
Re: Literal tests [was: Help with setting up Perl6]
Sean O'Rourke <[EMAIL PROTECTED]> wrote: On Thu, 12 Dec 2002, Jared Rhine wrote: > On to some tests, although I'm curious to see how tests of literals > turn out. Probably a lot of comparisons between different > representations of the same thing. Warning: most of the tests won't work now because the languages/perl6 is woefully incomplete, and because a lot of it was implemented before literals existed in their current form. If someone wants to get up to speed on the languages/perl6, this would be a great way to do it. If not, I'll put these on top of the stack for next time I have Parrot time (hopefully over break). I was planning on getting back to work on languages/perl6 as well, since I too am now on break. I'll update the literal defs if noone else wants to; however, I was hoping to clean up IMCC.pm before I do any more damage to the parser ;) _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: Everything is an object.
Austin Hastings <[EMAIL PROTECTED]> writes:
> --- Piers Cawley <[EMAIL PROTECTED]> wrote:
>
> >
> > Both of your proposed options are, frankly, vile. The
> > multimethod/generic function approach has the advantage of putting
> > the 'burden' of writing the generic function on the implementor
> > rather than on the user. Given that implementation happens once
> > and something is used countless times, that seems like a decent
> > trade off to me.
>
> Dictionary.com sez:
>
> "vile
> adj. vil·er, vil·est
> 1. Loathsome; disgusting: vile language.
> 2. Unpleasant or objectionable: vile weather. See Synonyms at
> offensive.
> 3.
> - a. Contemptibly low in worth or account; second-rate.
> - b. Of mean or low condition.
> 4. Miserably poor and degrading; wretched: a vile existence.
> 5. Morally depraved; ignoble or wicked: a vile conspiracy."
I choose 2.
> Is this one of those BOFH things where you insult the hell out of
> someone and then give them a pat on the head, and six months later
> they're arrested while sneaking into the London Zoo wearing a
> leather corset and silk panties? (*)
I gave him a pat on the head? I told him that his proposed solutions
were unpleasant or possibly loathsome, and that he should throw them
away and stick with my proposed generic subroutines solution and you
call that a pat on the head? Coo.
> Otherwise, I'm left to wonder. As I read Mike's post, he's proposing
> that we regularize a feature of the language, make it extensible,
> and potentially use a conceptual framework based on an existing
> syntactical element.
>
> Yours, on the other hand, gives (I hope) the extensibility, doesn't
> require the syntactic bits but does appear to require that every
> such method be implemented twice.
Um. Not really implemented twice no. One subroutine implementation
can act as the facade for an awful lot of overloaded methods in the
class. Look at the grep implementation again:
class Array {
method grep ( Block &block ) {...}
method grep ( Rule $rx ) { ... }
method grep ( rx// $expr ) { ... }
sub grep ( Object $selector, @*ary ) is exported { ... }
}
A single generic sub is used to provide a functional interface to a
bunch of methods. Now, when we add grep behaviour to the
'CunningCollection' class, we will need to overload the generic sub
so that, in the case of
grep .selector, $some_cunning_collection;
the $cunning_selector doesn't just get stuffed into an array. One
could also imagine a scenario where someone implements a new
'selecting' object:
class NewSelector {
method grep ( $self: @*args ) {
grep $self.as_block, *@args;
}
sub grep ( NewSelector $selector, @*args ) is exported {
$selector.grep( *@args );
}
}
And I fail to see how Mike's proposed syntax will deal with
this. Remember that the one time (per class admittedly) cost of
setting up a generic sub buys us a good deal of not having to use
gratuitous punctuation (or ghod help us 'is given') at use time.
map { .[0] }
sort { $^a[1] cmp $^b[1] }
map { [ $_ => some_transform($_) }
grep /.../, @array
happily stays as it is; I fail to see what recasting that as
map { .[0] } <-
sort { $^a[1] cmp $^b[1] } <-
map { [ $_ => some_transform($_) } <-
grep /.../, @array
or any other 'noisy' suggestion buys us. It just seems like the wrong
kind of Laziness to me.
