Re: is_deeply() is painful
On Apr 26, 2006, at 21:05, chromatic wrote: Multidispatch helps, but :multi( Array, Array ) or :multi( Hash, Hash ) don't work based on the capabilities of the PMC. That's fine. does_foo = does $Px, 'array' # 'hash' might help. There should be no problem with .Hash, but there are a lot of array types around. leo
Perl Summarizing
All~ It has become abundantly clear to me that I will not find the time to resume summarizing the perl lists. I doubt this surprises many of you given how long it has been since the last summary. Paradoxically, I have found myself wishing that there were summaries as there seems to have been a lot of movement lately and I have not had much time to read it all. In the hopes of inspiring someone to take my place, I would like to encourage any interested party to just start summarizing and thus become the official perl 6 summarizer. NB - I do not assume to speak for Piers in this, so interested parties may want to coordinate with him. Best of luck, Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: MSWin32 (Visual C++ 8.0) Test Results (r12017)
chromatic wrote: On Saturday 25 March 2006 07:47, Ron Blaschke wrote: t/configure/step.t $fromfile and $tofile needs to be closed before calling move_if_diff, as Windows can't delete open files. I forgot to check this in a while back, but fixed now as #16032 (I hope). Thanks, seems to work fine. Ron
Re: Win32 Env Mysteries
jerry gay wrote: On 12/22/05, Ron Blaschke <[EMAIL PROTECTED]> wrote: Tuesday, December 20, 2005, 8:09:32 PM, François PERRAD wrote: At 11:53 16/12/2005 +0100, you wrote: I can think of two ways to fix this: - Hide every env access behind the platform stuff. That is, add something like Parrot_environ. For me, this way sounds better. The platform/env.c already exists in only two flavors (generic & win32). Right. The format of GetEnvironmentStrings differs from _environ, so there's some conversion necessary. " LPVOID GetEnvironmentStrings(void); If the function succeeds, the return value is a pointer to the environment block of the current process. " Would this be a reasonable interface? char ** Parrot_get_environ(); void Parrot_free_environ(char **env); - Provide platform specific PMCs. That is, there are two different env.pmc implementations, depending on the platform. This would be simpler, more isolated and probably more efficient because it avoids another level of indirection. Ron sorry for the late response. this seems quite reasonable. patches welcome :) Great! I'll come up with something. Ron
MSWin32 (Visual C++ 8.0) Test Results (r12442)
Here's another round of test results on my box. I've also added the details for the tests that failed. The C and are not unexpected on Windows. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/doc/pod.t3 768 11663 0.26% 24 738 820 t/op/calling.t 1 256921 1.09% 91 t/pmc/complex.t1 256531 1.89% 33 t/pmc/env.t2 512122 16.67% 9-10 t/pmc/objects.t1 256731 1.37% 73 (22 subtests UNEXPECTEDLY SUCCEEDED), 17 tests and 361 subtests skipped. Failed 5/233 test scripts, 97.85% okay. 8/5860 subtests failed, 99.86% okay. t/op/calling.NOK 91# Failed test (t/op/calling.t at line 2327) # got: ' # 22 # 33 # ' # expected: '11 # 22 # 33 # ' # Looks like you failed 1 test of 92. t/op/calling.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 91 Failed 1/92 tests, 98.91% okay (less 1 skipped test: 90 okay, 97.83%) t/pmc/complexNOK 33# Failed test (t/pmc/complex.t at line 1024) # got: ' # ln(0+0i) # got -1.#INF00+0.00i # not -inf+0.00i # done # ' # expected: 'done # ' t/pmc/complexok 53/53# Looks like you failed 1 test of 53. t/pmc/complexdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 33 Failed 1/53 tests, 98.11% okay (less 3 skipped tests: 49 okay, 92.45%) t/pmc/envNOK 9# Failed test (t/pmc/env.t at line 168) # got: '0 # ' # expected: '3 # ' t/pmc/envNOK 10# Failed test (t/pmc/env.t at line 191) # got: '0.00 # ' # expected: '3.00 # ' # Looks like you failed 2 tests of 12. t/pmc/envdubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 9-10 Failed 2/12 tests, 83.33% okay (less 1 skipped test: 9 okay, 75.00%) t/pmc/objectsNOK 73# Failed test (t/pmc/objects.t at line 2122) # got: 'error:imcc:The opcode 'isa_i_p_kc' (isa<3>) was not found. Check the type and number of the arguments # in file 'D:\src\parrot\t\pmc\objects_73.pir' line 6 # ' # expected: '0 # ' # '.\parrot.exe --gc-debug "D:\src\parrot\t\pmc\objects_73.pir"' failed with exit code 18 # Looks like you failed 1 test of 73. t/pmc/objectsdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 73 Failed 1/73 tests, 98.63% okay (less 2 skipped tests: 70 okay, 95.89%) t/compilers/pge/p5regexp/p5rxok 290/800 skipped: bugs | errors | trailing modifiers, 22/800 unexpectedly succeeded t/doc/podNOK 24# Failed test (t/doc/pod.t at line 62) # D:/src/parrot/compilers/pge/PGE/P6Regex.pir (1236): You forgot a '=back' before '=head1' t/doc/podok 628/1166 # Failed test (t/doc/pod.t at line 62) # D:/src/parrot/compilers/pge/PGE/Regex.pir (28): Unknown directive: =over4 # D:/src/parrot/compilers/pge/PGE/Regex.pir (30): '=item' outside of any '=over' t/doc/podok 783/1166 # Failed test (t/doc/pod.t at line 62) # D:/src/parrot/compilers/pge/PGE/Exp.pir (39): '=item' outside of any '=over' t/doc/podok 1138/1166# Looks like you failed 3 tests of 1166. t/doc/poddubious Test returned status 3 (wstat 768, 0x300) DIED. FAILED tests 24, 738, 820 Failed 3/1166 tests, 99.74% okay
Re: MSWin32 (Visual C++ 8.0) Test Results (r12442)
On 4/27/06, Ron Blaschke <[EMAIL PROTECTED]> wrote: > Here's another round of test results on my box. I've also added the > details for the tests that failed. The C and > are not unexpected on Windows. > > Failed Test Stat Wstat Total Fail Failed List of Failed > --- > t/doc/pod.t3 768 11663 0.26% 24 738 820 fixed, r12443. > t/op/calling.t 1 256921 1.09% 91 > t/pmc/complex.t1 256531 1.89% 33 > t/pmc/env.t2 512122 16.67% 9-10 > t/pmc/objects.t1 256731 1.37% 73 these are all expected, at the moment. > (22 subtests UNEXPECTEDLY SUCCEEDED), 17 tests and 361 subtests skipped. pmichaud++ # more passing p5regex tests i'll update p5rx.t to un-todo these. thanks for reporting. ~jerry
[svn:perl6-synopsis] r8973 - doc/trunk/design/syn
Author: larry
Date: Thu Apr 27 09:33:20 2006
New Revision: 8973
Modified:
doc/trunk/design/syn/S06.pod
Log:
Clarify placeholders are illegal if conflicting with other signature.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podThu Apr 27 09:33:20 2006
@@ -1286,6 +1286,8 @@
-> $x,$y,$z { $y < $z && $x != 2 }
Note that placeholder variables syntactically cannot have type constraints.
+Also, it is illegal to use placeholder variables in a block that already
+has a signature, because the autogenerated signature would conflict with that.
=head1 Built-in Types
Re: [perl #38957] hash test failures
On Fri, 21 Apr 2006, Andy Dougherty wrote: > On Fri, 21 Apr 2006, Will Coleda wrote: > > > OSX 10.4.6, PPC > > > > This failure has been pretty persistent the past few weeks: > > > > t/src/hash.t1 256111 9.09% 6 > > > > # got: '42 > > # hash_6(4373,0xa000ed98) malloc: *** error for object 0x1d14140: > > incorrect checksum for freed object - object was probably modified > > after being freed, break at szone_error to debug > > # hash_6(4373,0xa000ed98) malloc: *** set a breakpoint in szone_error > > to debug > > # hash_6(4373,0xa000ed98) malloc: *** error for object 0x1d14140: > > incorrect checksum for freed object - object was probably modified > > after being freed, break at szone_error to debug > > # hash_6(4373,0xa000ed98) malloc: *** set a breakpoint in szone_error > > to debug > > # ' > > # expected: '42 > > That test has been dumping core for me (Solaris 8/SPARC) for quite a long > time (since last summer at least, I think). I tried to see if it's still > there in the current code, but my build & test script aborted at the > Configure.pl stage (due to the changed perl version requirements). This test still core dumps for me. I've traced it down a good bit -- it's a garbage collection problem. Specifically, in t/src/hash_6.c, the variable 'hash' is declared in the function 'the_test', and memory allocated with hash = PMC_struct_val(h); A big string 'big' is then created. The program then calls string_from_cstring(). The ensuing sequence is something like (This is all from printf() statements -- the debugger gets confused, as do I!): string_from_cstring() -> string_make_direct() -> Parrot_allocate_string() -> mem_allocate() -> Parrot_dod_ms_run() -> Parrot_forall_header_pools() -> sweep_cb() -> Parrot_dod_sweep() ... ??? ... mem_sys_free() -> free(from) where from == hash. (At the ??? point, I lose track of what's happening) Not surprisingly, the program crashes later on at hash_put(interpreter, hash, key, i); Unfortunately, this failure is in the dod_sweep() stuff, which I really don't understand at all, so I don't know how to proceed from here. -- Andy Dougherty [EMAIL PROTECTED]
Re: MSWin32 (Visual C++ 8.0) Test Results (r12442)
On Thu, 27 Apr 2006, jerry gay wrote: > On 4/27/06, Ron Blaschke <[EMAIL PROTECTED]> wrote: > > Here's another round of test results on my box. I've also added the > > details for the tests that failed. The C and > > are not unexpected on Windows. > > > > > Failed Test Stat Wstat Total Fail Failed List of Failed > > --- > > t/doc/pod.t3 768 11663 0.26% 24 738 820 > fixed, r12443. > > > t/op/calling.t 1 256921 1.09% 91 > > t/pmc/complex.t1 256531 1.89% 33 > > t/pmc/env.t2 512122 16.67% 9-10 > > t/pmc/objects.t1 256731 1.37% 73 > these are all expected, at the moment. They are? Is the list of "expected failuers" anywhere obvious? I don't see it anywhere obvious either in the source or in the recent perl6-internals archives. Perhaps I've missed it somewhere. -- Andy Dougherty [EMAIL PROTECTED]
[perl #39013] [PATCH] Two more uninitialized registers
# New Ticket Created by Andy Dougherty # Please include the string: [perl #39013] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=39013 > I've found two more tests that were relying on uninitialized registers being set to zero. I'm not sure if this is what the author of those tests intended, or if the wrong registers were used in the sub statement, but this at least lets these tests pass consistently for me. --- parrot-current/t/op/jitn.t Sat Feb 25 00:32:39 2006 +++ parrot-andy/t/op/jitn.t Thu Apr 27 15:25:01 2006 @@ -183,6 +183,7 @@ set N2,2 set N3,3 set N4,4 +set N5,0 set N0,N1 set N2,N3 set N0,N1 @@ -255,6 +256,7 @@ set N2,2 set N3,3 set N4,4 +set N6,0 set N0,N1 set N2,N3 set N0,N1 -- Andy Dougherty [EMAIL PROTECTED]
Re: MSWin32 (Visual C++ 8.0) Test Results (r12442)
On 4/27/06, Andy Dougherty <[EMAIL PROTECTED]> wrote: > On Thu, 27 Apr 2006, jerry gay wrote: > > > On 4/27/06, Ron Blaschke <[EMAIL PROTECTED]> wrote: > > > Here's another round of test results on my box. I've also added the > > > details for the tests that failed. The C and > > > are not unexpected on Windows. > > > > > > > > Failed Test Stat Wstat Total Fail Failed List of Failed > > > --- > > > t/doc/pod.t3 768 11663 0.26% 24 738 820 > > fixed, r12443. > > > > > t/op/calling.t 1 256921 1.09% 91 > > > t/pmc/complex.t1 256531 1.89% 33 > > > t/pmc/env.t2 512122 16.67% 9-10 > > > t/pmc/objects.t1 256731 1.37% 73 > > > these are all expected, at the moment. > > They are? Is the list of "expected failuers" anywhere obvious? I don't > see it anywhere obvious either in the source or in the recent > perl6-internals archives. Perhaps I've missed it somewhere. > ron has reported failing env (#37301) and complex tests before (recent list mail,) and they appear regularly on the smoke server (http://smoke.parrotcode.org/smoke). calling is failing due to a test checked in by patrick (:flat and named params, iirc,) and objects is failing due to an as-yet-unimplemented opcode (part of PDD21 changes, iirc.) both of these should be resolved when leo (or any other C coder with tuits) up to fixing them. i'm having trouble finding tickets for these others, but that may be because my network connection is horribly inconsistent at the moment, and not because they don't exist. ~jerry
Re: MSWin32 (Visual C++ 8.0) Test Results (r12442)
On 4/27/06, Andy Dougherty <[EMAIL PROTECTED]> wrote: > On Thu, 27 Apr 2006, jerry gay wrote: > > > On 4/27/06, Ron Blaschke <[EMAIL PROTECTED]> wrote: > > > Here's another round of test results on my box. I've also added the > > > details for the tests that failed. The C and > > > are not unexpected on Windows. > > > > > > > > Failed Test Stat Wstat Total Fail Failed List of Failed > > > --- > > > t/doc/pod.t3 768 11663 0.26% 24 738 820 > > fixed, r12443. > > > > > t/op/calling.t 1 256921 1.09% 91 > > > t/pmc/complex.t1 256531 1.89% 33 > > > t/pmc/env.t2 512122 16.67% 9-10 > > > t/pmc/objects.t1 256731 1.37% 73 > > > these are all expected, at the moment. > > They are? Is the list of "expected failuers" anywhere obvious? I don't > see it anywhere obvious either in the source or in the recent > perl6-internals archives. Perhaps I've missed it somewhere. > ron has reported failing env (#37301) and complex tests before (recent list mail,) and they appear regularly on the smoke server (http://smoke.parrotcode.org/smoke). calling is failing due to a test checked in by patrick (:flat and named params, iirc,) and objects is failing due to an as-yet-unimplemented opcode (part of PDD21 changes, iirc.) both of these should be resolved when leo (or any other C coder with tuits) up to fixing them. i'm having trouble finding tickets for these others, but that may be because my network connection is horribly inconsistent at the moment, and not because they don't exist. ~jerry
Perl 6 built-in types
A couple of questions and suggestions about Perl 6 built-in data types, following a look at the newest S06 ( http://svn.perl.org/perl6/doc/trunk/design/syn/S06.pod ) ... 1. There doesn't seem to be an immutable bit-string type, so unless I read something wrong, I propose adding one. Since all built-in types have one-word names, I suggest 'Raw', which doesn't currently seem to be in use. Unlike the immutable Str type, which is specifically defined to contain 'characters' (in the Unicode reportoire) or immutable bit or numeric types that hold a single bit or a single number respectively, the immutable Raw type would hold other kinds of data which isn't conceptually either character based or a number. Or more to the point, it would store data whose internal representation we don't want to know about for our purposes, or that is best stored as a bit string, such as perhaps a graphic or sound. I do not see this need being served by any of Str or Buf or Array of Bit or Seq or anything like that. I see there being as much validity for such a Raw type as I described as the Str type, which holds multiple characters, rather than us just having a Char type that holds one character and being expected to use a Buf or Array of Char or Seq type to represent a string of them. 2. While I grant that the module says it is going to be further updated, can I get a confirmation whether Pugs' ext/Set/lib/Set.pm is meant to implement the built-in Set type referred to in S06? If that is so, then they are currently out of sync such that S06 says a Set is an immutable type but Set.pm has public mutator methods like insert() and remove(). I propose that either the mutator methods be removed from Set.pm, or that there be 2 distinct types, one which is an immutable Set, and a similar type that is mutable, and that has a different name. Note that the mutable Hash type doesn't fill the role of a mutable set per se, because each distinct key has an associated value, but a set member doesn't have an associated value. If such a new type is created, it could potentially be named MutableSet, though that would break the pattern of built-in types having one-word names, but I haven't thought of any alternatives so far. Thank you. -- Darren Duncan
[svn:parrot-pdd] r12452 - in trunk: . docs/pdds/clip
Author: allison Date: Thu Apr 27 14:20:59 2006 New Revision: 12452 Modified: trunk/docs/pdds/clip/pdd22_io.pod trunk/docs/pdds/clip/pdd23_exceptions.pod trunk/docs/pdds/clip/pdd24_events.pod trunk/docs/pdds/clip/pdd25_threads.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Fixing headers in draft PDDs. Modified: trunk/docs/pdds/clip/pdd22_io.pod == --- trunk/docs/pdds/clip/pdd22_io.pod (original) +++ trunk/docs/pdds/clip/pdd22_io.pod Thu Apr 27 14:20:59 2006 @@ -1,9 +1,9 @@ # Copyright: 2001-2006 The Perl Foundation. -# $Id $ +# $Id: $ =head1 NAME -docs/pdds/pddXX_io.pod - Parrot I/O +docs/pdds/pdd22_io.pod - Parrot I/O =head1 ABSTRACT @@ -11,7 +11,7 @@ =head1 VERSION -$Revision $ +$Revision: $ =head1 SYNOPSIS Modified: trunk/docs/pdds/clip/pdd23_exceptions.pod == --- trunk/docs/pdds/clip/pdd23_exceptions.pod (original) +++ trunk/docs/pdds/clip/pdd23_exceptions.pod Thu Apr 27 14:20:59 2006 @@ -3,7 +3,7 @@ =head1 NAME -docs/pdds/clip/pddXX_exceptions.pod - Parrot Exceptions +docs/pdds/clip/pdd23_exceptions.pod - Parrot Exceptions =head1 ABSTRACT Modified: trunk/docs/pdds/clip/pdd24_events.pod == --- trunk/docs/pdds/clip/pdd24_events.pod (original) +++ trunk/docs/pdds/clip/pdd24_events.pod Thu Apr 27 14:20:59 2006 @@ -3,7 +3,7 @@ =head1 NAME -docs/pdds/clip/pddXX_events.pod - Parrot Events +docs/pdds/clip/pdd24_events.pod - Parrot Events =head1 ABSTRACT Modified: trunk/docs/pdds/clip/pdd25_threads.pod == --- trunk/docs/pdds/clip/pdd25_threads.pod (original) +++ trunk/docs/pdds/clip/pdd25_threads.pod Thu Apr 27 14:20:59 2006 @@ -3,7 +3,7 @@ =head1 NAME -docs/pdds/clip/pddXX_threads.pod - Parrot Threads +docs/pdds/clip/pdd25_threads.pod - Parrot Threads =head1 ABSTRACT
Re: MSWin32 (Visual C++ 8.0) Test Results (r12442)
On Thursday 27 April 2006 13:18, jerry gay wrote: > calling is failing due to a test checked in by patrick (:flat and > named params, iirc,) and objects is failing due to an > as-yet-unimplemented opcode (part of PDD21 changes, iirc.) both of > these should be resolved when leo (or any other C coder with tuits) up > to fixing them. These at least sound like TODOs. Oh mythical lurkers with some free time who want to contribute, there are a few of us who don't have time to code today but who do have time to apply good patches -- c
Re: Perl 6 built-in types
On Thu, Apr 27, 2006 at 01:10:05PM -0700, Darren Duncan wrote:
: A couple of questions and suggestions about Perl 6 built-in data
: types, following a look at the newest S06 (
: http://svn.perl.org/perl6/doc/trunk/design/syn/S06.pod ) ...
:
: 1. There doesn't seem to be an immutable bit-string type, so unless
: I read something wrong, I propose adding one.
:
: Since all built-in types have one-word names, I suggest 'Raw', which
: doesn't currently seem to be in use.
That word is too overloaded, I think. Blob maybe.
: Unlike the immutable Str type, which is specifically defined to
: contain 'characters' (in the Unicode reportoire) or immutable bit or
: numeric types that hold a single bit or a single number respectively,
: the immutable Raw type would hold other kinds of data which isn't
: conceptually either character based or a number. Or more to the
: point, it would store data whose internal representation we don't
: want to know about for our purposes, or that is best stored as a bit
: string, such as perhaps a graphic or sound.
I don't actually see much use for immutable random chunks of memory that
wouldn't just about as well be served by a readonly buf. It's not like
two sounds much care if they have the same identity. And most random
chunks of bits should probably be typed better than that anyway or you'll
end up comparing your graphic to your sound.
: I do not see this need being served by any of Str or Buf or Array of
: Bit or Seq or anything like that. I see there being as much validity
: for such a Raw type as I described as the Str type, which holds
: multiple characters, rather than us just having a Char type that
: holds one character and being expected to use a Buf or Array of Char
: or Seq type to represent a string of them.
That paragraph did not make any sense to me.
: 2. While I grant that the module says it is going to be further
: updated, can I get a confirmation whether Pugs' ext/Set/lib/Set.pm is
: meant to implement the built-in Set type referred to in S06?
:
: If that is so, then they are currently out of sync such that S06 says
: a Set is an immutable type but Set.pm has public mutator methods like
: insert() and remove().
Mathematical sets are immutable.
: I propose that either the mutator methods be removed from Set.pm, or
: that there be 2 distinct types, one which is an immutable Set, and a
: similar type that is mutable, and that has a different name.
:
: Note that the mutable Hash type doesn't fill the role of a mutable
: set per se, because each distinct key has an associated value, but a
: set member doesn't have an associated value.
The value of a set member is its existence, which is constantly true
for the set members. But why do you assume that a Hash has to store
a real value?
: If such a new type is created, it could potentially be named
: MutableSet, though that would break the pattern of built-in types
: having one-word names, but I haven't thought of any alternatives so
: far.
How about Bag, a set container? Alternately what we really want is
just a Hash where the type of the value is defined as 1, so it need
not be stored at all. Then most of the syntax for it just falls out
of Hash syntax, unless you like writing $x ∈ $bag instead of $bag{$x}.
Presumably we could make both work.
I'm just not sure every type we think of really needs a new name...
Larry
Re: Perl 6 built-in types
At 7:38 PM -0700 4/27/06, Larry Wall wrote:
On Thu, Apr 27, 2006 at 01:10:05PM -0700, Darren Duncan wrote:
: 1. There doesn't seem to be an immutable bit-string type, so unless
: I read something wrong, I propose adding one.
:
: Since all built-in types have one-word names, I suggest 'Raw', which
: doesn't currently seem to be in use.
That word is too overloaded, I think. Blob maybe.
Okay, avoiding 'Raw' due to overload is fine.
However, I would argue that the word 'Blob' is no
better because, taken at its original meaning of
"Binary Large OBject", we are implying that it is
only intended for storing large things. But I
intended for it to be used for small things too,
such as 1 or 20 or 400 byte chunks of data.
A better name is one that doesn't imply size.
Perhaps just 'Binary', if that isn't also
overloaded. Or perhaps 'BitStr' or 'Str::Bit'.
Though Binary sounds better, being a single word.
I don't actually see much use for immutable random chunks of memory that
wouldn't just about as well be served by a readonly buf.
How about data that 'pack' or 'unpack' work with?
That's often defined in terms of strings of bits.
And what about encrypted data? Likewise, often
as strings of bits.
It's not like
two sounds much care if they have the same identity. And most random
chunks of bits should probably be typed better than that anyway or you'll
end up comparing your graphic to your sound.
What you say about better typing is true;
however, if we want to have a system where one
can easily define their own custom immutable
types, which can be composed partly or entirely
of chunks of binary data, then such a Binary type
would be a good foundation on which to build them.
Fundamentally, I see it being valuable that users
can make any kind of custom data type that is
immutable, so that users or implementers of those
custom types can reap many or all of the same
benefits as those of immutable built-ins.
: 2. While I grant that the module says it is going to be further
: updated, can I get a confirmation whether Pugs' ext/Set/lib/Set.pm is
: meant to implement the built-in Set type referred to in S06?
:
: If that is so, then they are currently out of sync such that S06 says
: a Set is an immutable type but Set.pm has public mutator methods like
: insert() and remove().
Mathematical sets are immutable.
Thanks for the confirmation. So that would mean
that Set.pm in its current state doesn't
implement a mathematical set, since its objects
are mutable.
The value of a set member is its existence, which is constantly true
for the set members.
Yes, I agree.
But why do you assume that a Hash has to store
a real value?
Because in my experience that is what people have
always done with them, unless examples using
'undef' don't count as such.
Alternately what we really want is
just a Hash where the type of the value is defined as 1, so it need
not be stored at all.
Yes, that solution works for me.
I had been using constant values of 1 in my
coding before when I just used a hash like a set.
But the syntax of %foo{'bar'} = 1 still looked
like there were 2 things being associated, 'bar'
and '1'.
On the other hand, if these values indicate how
many times their key is in the hash, then a value
which is always 1 would happen to be correct.
But I won't dwell on this particular matter any longer.
: If such a new type is created, it could potentially be named
: MutableSet, though that would break the pattern of built-in types
: having one-word names, but I haven't thought of any alternatives so
: far.
How about Bag, a set container?
If we were still going the route of naming a
mutable set container, then 'Bag' is
inappropriate because the term is commonly used
to mean multi-set, an unordered sequence of
things where each thing can occur multiple times.
If we wanted an actual mutable Bag, the ordinary
Hash would suffice in the same way it does for a
mutable Set, but that each hash value is a number
that is >= 1 rather than just 1; the hash value
would count the number of occurances of the
multi-set member.
Then most of the syntax for it just falls out
of Hash syntax, unless you like writing $x Ž $bag instead of $bag{$x}.
Presumably we could make both work.
If people actually do commonly use hashes as
mutable sets, then it probably would be useful to
have those operators for consistency and
interchangeability with the immutable sets;
however, I won't push for them at this time.
I'm just not sure every type we think of really needs a new name...
Larry
Yes. In fact I appreciate the fact that Perl 6
has the variety of types that it does, which
mostly or fully cover the needs of any common
problem domain, and can be overloaded for a
variety of similar uses, though people may use
different names for them depending what
problem-solving domain they come from.
Thank you. -- Darren Duncan
Re: Perl 6 built-in types
> How about Bag, a set container? Alternately what we really want is
> just a Hash where the type of the value is defined as 1, so it need
> not be stored at all. Then most of the syntax for it just falls out
> of Hash syntax, unless you like writing $x ∈ $bag instead of $bag{$x}.
> Presumably we could make both work.
Please don't use bag as that is usually mathematically defined to be a
multi-set that can contain multiple copies of any given element. In
perl that would be a hash of Ints.
I'm not sure that immutable make any sense as a concept separate from
constant. A truly immutable object can't even be initialized, it has to
be born ex-nilo already with a value.
I think that only values (like 1, "ABC" and a set constant like
(1|2|5|9)) are immutable. So, we should just stick with variable and
constant (assigned once doesn't change afterwards) containers and not
use the term immutable at all.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Perl 6 built-in types
On 4/28/06, Larry Wall <[EMAIL PROTECTED]> wrote:
How about Bag, a set container? Alternately what we really want is
just a Hash where the type of the value is defined as 1, so it need
not be stored at all. Then most of the syntax for it just falls out
of Hash syntax, unless you like writing $x ∈ $bag instead of $bag{$x}.
Presumably we could make both work.
It seems like a hash whose values are the unit type. Does Perl have a
unit type? I suppose if it doesn't, we could define one:
subtype Unit of Int where 1;
(Assuming that "where" groks whatever "when" does).
Then your mutable set is:
my Hash of Unit $set;
Luke
Re: Perl 6 built-in types
On Fri, Apr 28, 2006 at 04:41:41AM +, Luke Palmer wrote: : It seems like a hash whose values are the unit type. Does Perl have a : unit type? I suppose if it doesn't, we could define one: : :subtype Unit of Int where 1; : : (Assuming that "where" groks whatever "when" does). : : Then your mutable set is: : :my Hash of Unit $set; Hmm, well, if values are just single-element subsets, then: my %set of 1; my 1 %set; Larry
Re: Perl 6 built-in types
At 9:07 PM -0700 4/27/06, Mark A. Biggar wrote: I'm not sure that immutable make any sense as a concept separate from constant. A truly immutable object can't even be initialized, it has to be born ex-nilo already with a value. Well, that depends on your philosophy. I would argue that, philosophically, all values that can possibly exist in the universal set have already existed and will continue to exist eternally. By definition, a 'value' is both unique and immutable. A value does not to be born in any sense because it is eternal. Moreover, every 'value' is of a type, where that type is defined as a subset of the universal set; a type can have values that are arbitrarily complex or large, and less complex values have no more claim to being a valid value than a more complex one. While every value is unique, each one can have multiple appearances, and for the sake of discussion, each appearance is the content of a container, whether that container is updateable/mutable or constant/immutable; each container is also of a type and can only hold an appearance of a value of its type. Moreover, every container always holds a value of its type at all times. For example, there is only one value that is the number 42. If you have a number variable containing 42, and you then update that variable to contain the number 45 instead, you have not changed the value 42 into a 45, but rather replaced its appearance in the variable with an appearance of 45. A related matter is that two things are considered equal if and only if they are in fact two appearances of the *same* value. So that's how things are conceptually, as I see it. In some sense, I suppose this all sounds like quantum physics. Now, our implementations of these concepts in a computer, regardless of how we phrase it with syntax, all involve containers that are some-how addressable; at some point in time, each is given an appearance of a value, then depending on whether we declare the container to be immutable/constant/non-updateable or mutable/variable/updateable, it can possibly be made to hold an appearance of a different value. An object is a container and it is reasonable on a per-class basis that objects of that class can be updateable or not. Long story shortened, if we consider the point in time where an "immutable" object's constructor returns as being when the object is born, then we have no problem. Any type of object is thereby immutable if it can not be changed after its constructor returns. So, we should just stick with variable and constant (assigned once doesn't change afterwards) containers and not use the term immutable at all. I may be fine with this idea if we want to do it. But in the mean-time, I will probably consider "immutable" and "mutable" to be synoymous with "constant" and "variable". I think that only values (like 1, "ABC" and a set constant like (1|2|5|9)) are immutable. Why stop there. I would argue that it should be possible to have a type of any level of complexity that is declared immutable, such that an object of that type isn't changed after its constructor finishes. Denying this possibility on some arbitrary basis like with your list makes as much sense as taking several things larger than a bit and saying that some are atomic while others aren't. -- Darren Duncan
