At 4:40 PM -0700 5/29/07, Larry Wall wrote:
Hmm, maybe we should just rename Object to something more generic.
There are plenty of candidates:
Top
Idea
Noun
Item
Proto
Thing
Notion
Concept
Subject
Reality
Invocant
Universal
EveryThing
Abstr
Author: larry
Date: Tue May 29 17:38:24 2007
New Revision: 14408
Modified:
doc/trunk/design/syn/S06.pod
Log:
Extensibility of "is cached" explained, as requested by gabriele renzi++
Modified: doc/trunk/design/syn/S06.pod
===
> Well, yes, "Everything is an Object" is the politically correct mantra. :)
True, but junctions aren't usually in the scope of CS PC...
OK, so let me see if I can wrap a conceptualization around this.
Logically, the type "Object" is itself a junction, that of all
possible types, while "Any" me
On Tue, May 29, 2007 at 06:46:21PM -0400, Mark J. Reed wrote:
: My counterintuition just went off again. The more restrictive type is
: called "Any"? Object includes junctions?
Well, yes, "Everything is an Object" is the politically correct mantra. :)
And in Perl 6, "Any" does not really mean
Jonathan Lang wrote:
From S02:
--
Perl 6 includes a system of B to mark the fundamental
structural type of a variable:
$ scalar (object)
@ ordered array
% unordered hash (associative array)
& code/rule/token/regex
:: package/module/class/role/subset/enum/type/grammar
On Tue, May 29, 2007 at 05:29:18PM -0400, Chas Owens wrote:
: Okay, obviously I have more synopsis to read, but currently Pugs says:
: pugs> my $posinf = *
: Inf
: pugs> my $neginf = -*
: -Inf
:
: which made me think * is Inf in scalar context. Is this a bug in Pugs then?
Yes, basically. * shou
My counterintuition just went off again. The more restrictive type is
called "Any"? Object includes junctions?
On 5/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: larry
Date: Tue May 29 14:18:27 2007
New Revision: 14407
Modified:
doc/trunk/design/syn/S02.pod
Log:
Clarificati
On 5/29/07, Larry Wall <[EMAIL PROTECTED]> wrote:
On Tue, May 29, 2007 at 04:43:20PM -0400, Chas Owens wrote:
: Just an odd corner case, but
:"foo" x -*
: should return an empty string and
:"foo" xx -*
: should return an empty list, right?
I'm doubt &prefix:<->:(Whatever) is defined at a
Author: larry
Date: Tue May 29 14:18:27 2007
New Revision: 14407
Modified:
doc/trunk/design/syn/S02.pod
Log:
Clarification of relationship of Any and Object types requested by dduncan++
Modified: doc/trunk/design/syn/S02.pod
===
On Tue, May 29, 2007 at 04:43:20PM -0400, Chas Owens wrote:
: Just an odd corner case, but
:"foo" x -*
: should return an empty string and
:"foo" xx -*
: should return an empty list, right?
I'm doubt &prefix:<->:(Whatever) is defined at all, so that's probably
a run-time failure unless som
On 5/29/07, Larry Wall <[EMAIL PROTECTED]> wrote:
On Tue, May 29, 2007 at 04:05:39PM -0400, Chas Owens wrote:
: On 5/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
: snip
: >+If the count is less than 1, returns the null string.
: >+The count may not be C<*> because Perl 6 does not support
:
On Tue, May 29, 2007 at 04:05:39PM -0400, Chas Owens wrote:
: On 5/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
: snip
: >+If the count is less than 1, returns the null string.
: >+The count may not be C<*> because Perl 6 does not support
: >+infinite strings. (At least, not yet...)
: snip
On 5/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
snip
+If the count is less than 1, returns the null string.
+The count may not be C<*> because Perl 6 does not support
+infinite strings. (At least, not yet...)
snip
Does "may not be c<*>" mean that the compiler should throw a fatal
erro
Author: larry
Date: Tue May 29 12:03:39 2007
New Revision: 14406
Modified:
doc/trunk/design/syn/S12.pod
Log:
Allow closures as indirect methods as suggested by blazer++
Modified: doc/trunk/design/syn/S12.pod
==
--- d
On 5/29/07, Mark J. Reed <[EMAIL PROTECTED]> wrote:
My expectation before reading the delta was that negative counts
would do a reversal:
"123" x -1 = "321"
('a', 'b', 'c') xx -3 = ('c', 'b', 'a', 'c', 'b', 'a', 'c', 'b', 'a');
I don't know why I think that makes sense, but it was honestly my
On 5/29/07, Larry Wall <[EMAIL PROTECTED]> wrote:
The main rationale for going with null return is that the biggest use of
replication has generally been something like:
say $foo, ' ' x (20 - $foo.width), $bar
and it would be counterproductive to degrade to "negative" spaces in
such a case.
On Tue, May 29, 2007 at 02:21:37PM -0400, Mark J. Reed wrote:
: My expectation before reading the delta was that negative counts
: would do a reversal:
:
: "123" x -1 = "321"
:
: ('a', 'b', 'c') xx -3 = ('c', 'b', 'a', 'c', 'b', 'a', 'c', 'b', 'a');
:
: I don't know why I think that makes sense,
On 29 May 2007, at 19:21, Mark J. Reed wrote:
My expectation before reading the delta was that negative counts
would do a reversal:
"123" x -1 = "321"
('a', 'b', 'c') xx -3 = ('c', 'b', 'a', 'c', 'b', 'a', 'c', 'b', 'a');
I don't know why I think that makes sense, but it was honestly my
first
My expectation before reading the delta was that negative counts
would do a reversal:
"123" x -1 = "321"
('a', 'b', 'c') xx -3 = ('c', 'b', 'a', 'c', 'b', 'a', 'c', 'b', 'a');
I don't know why I think that makes sense, but it was honestly my
first thought. Does it make sense to anyone else? I
Author: larry
Date: Tue May 29 11:14:43 2007
New Revision: 14405
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarification of x and xx semantics requested by chas.owens++
Modified: doc/trunk/design/syn/S03.pod
==
---
Author: larry
Date: Tue May 29 09:18:54 2007
New Revision: 14404
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
Log:
Applied s:g{ '[-1]' } = '[*-1]' patch from Dataweaver++
Modified: doc/trunk/design/syn/S02.pod
21 matches
Mail list logo
