Ingo Blechschmidt wrote:
Hi,
ReHi,
are the following assumptions correct?
I don't know in general. But see my assumptions below
for comparison. They are derived from my type theoretic
approach and as such might collide with Perl6's referential
semantics. In particular with the
This is another spin-off from the 'Exposing the Garbage Collector'
thread. Here is an enhanced version.
I wonder how the generic, lexically scoped invocant/owner is called.
I propose to call it $/ (other option is to call it $)and let the
former topicalizer become block owners and $_ the block
On 7/26/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Hi,
are the following assumptions correct?
sub foo ([EMAIL PROTECTED]) { @args[0] }
say ~foo(a, b, c); # a
Yep.
my @array = a b c d;
say ~foo(@array);# a b c d (or a?)
say ~foo(@array, z); # a b c
On 7/26/05, TSa (Thomas Sandlaß) [EMAIL PROTECTED] wrote:
Piers Cawley wrote:
I would like to be able to iterate over all the
objects in the live set.
My Idea actually is to embedd that into the namespace syntax.
The idea is that of looking up non-negativ integer literals
with 0 beeing
Luke Palmer wrote:
On 7/26/05, TSa (Thomas Sandlaß) [EMAIL PROTECTED] wrote:
Piers Cawley wrote:
I would like to be able to iterate over all the
objects in the live set.
My Idea actually is to embedd that into the namespace syntax.
The idea is that of looking up non-negativ integer
http://repetae.net/john/recent/out/supertyping.html
This was a passing proposal to allow supertype declarations in
Haskell. I'm referencing it here because it's something that I've had
in the back of my mind for a while for Perl 6. I'm glad somebody else
has thought of it.
Something that is
On 7/19/05, Damian Conway [EMAIL PROTECTED] wrote:
And now maybe you see why I am so disgusted by this metric. You see,
I'm thinking of a class simply as the set of all of its possible
instances.
There's your problem. Classes are not isomorphic to sets of instances and
derived classes
On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
I dunno. I'm inclined to say that it should default to Item|Pair, and
let people say Any explicitly if they really want to suppress autothreading.
Otherwise conditionals and switches are going to behave oddly in the
presence of
I just realized something that may be very important to my side of the
story. It appears that I was skimming over your example when I should
have been playing closer attention:
On 7/18/05, Damian Conway [EMAIL PROTECTED] wrote:
Consider the following classes:
class A {...}
[sorry Luke, I hit Send too soon]
On 7/27/05, Luke Palmer [EMAIL PROTECTED] wrote:
There is probably a better word than contains. I was thinking set
theory when I came up with that one.
What about derives?
Aankhen
Hi,
Luke Palmer wrote:
http://repetae.net/john/recent/out/supertyping.html
This was a passing proposal to allow supertype declarations in
Haskell. I'm referencing it here because it's something that I've had
in the back of my mind for a while for Perl 6. I'm glad somebody else
has
With the recent realization of the beginnings of a PIL-Javascript
emitter, it appears that my Perl6 program can run in a bizarre mix of
execution environments.
Forgive me if I missed this while trying to skim through the unearthly
number of perl6 messages so far, but...
It'd be nice if there
On 7/27/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Luke Palmer wrote:
role Complex
does Object
contains Num
{...}
I've probably misunderstood you, but...:
role Complex does Object {...}
Num does Complex;
# That should work and DWYM, right?
HaloO,
Ingo Blechschmidt wrote:
I've probably misunderstood you, but...:
role Complex does Object {...}
Num does Complex;
# That should work and DWYM, right?
My 0.02: Complex should provide e.g. a + that, when
called with two Nums, doesn't bother the return
value to carry on a
Randal L. Schwartz wrote:
This is similar to the OS-9's gestalt tables, which got smarter as
the operating system had more features, but was a consistent way to
ask do we have a color monitor here?.
Is something like this already planned?
From my bubble in the Perl6 Universe this thing is an
On Wed, Jul 27, 2005 at 07:09:41AM -0700, Randal L. Schwartz wrote:
: With the recent realization of the beginnings of a PIL-Javascript
: emitter, it appears that my Perl6 program can run in a bizarre mix of
: execution environments.
:
: Forgive me if I missed this while trying to skim through
On Wed, Jul 27, 2005 at 08:01:25PM +0800, Autrijus Tang wrote:
: On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
: I dunno. I'm inclined to say that it should default to Item|Pair, and
: let people say Any explicitly if they really want to suppress autothreading.
: Otherwise
Larry~
On 7/27/05, Larry Wall [EMAIL PROTECTED] wrote:
On Wed, Jul 27, 2005 at 08:01:25PM +0800, Autrijus Tang wrote:
: On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
: I dunno. I'm inclined to say that it should default to Item|Pair, and
: let people say Any explicitly if
On Wed, Jul 27, 2005 at 12:19:10PM -0400, Matt Fowles wrote:
While we are talking about words... I dislike having Object encompass
Juction. I get the feeling that some people will write functions that
take Objects and not expect Junctions to slip in. I suppose that
could be one of those
HaloO,
Larry Wall wrote:
Yes. The only thing I don't like about it is that any() isn't an Any.
Maybe we should rename Any to Atom. Then maybe swap Item with Atom,
since in colloquial English you can say that pair of people are
an item.
Since we are in type hierachies these days, here's my
On Wed, Jul 27, 2005 at 11:00:20AM +, Luke Palmer wrote:
: Let's say that Perl 6 does not provide a complex number class by
: default. How would you go about writing one? Well, let's do the
: standard Perl practice of making words that your users are supposed to
: say in their code roles.
:
On Wed, Jul 27, 2005 at 06:28:22PM +0200, TSa (Thomas Sandlaß) wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.
That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking. We're looking
for
Larry Wall wrote:
On Wed, Jul 27, 2005 at 06:28:22PM +0200, TSa (Thomas Sandlaß) wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.
That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking.
On Wed, Jul 27, 2005 at 09:12:00AM -0700, Larry Wall wrote:
Yes. The only thing I don't like about it is that any() isn't an Any.
snip
- Object
- Mumble
- Item
- ...pretty much everything
- Pair
- Junction
- num, int, str...
Hrm. I
At 9:12 AM -0700 7/27/05, Larry Wall wrote:
Yes. The only thing I don't like about it is that any() isn't an Any.
Maybe we should rename Any to Atom. Then maybe swap Item with Atom,
since in colloquial English you can say that pair of people are
an item. That would give us:
- Object
On Wed, Jul 27, 2005 at 12:19:10PM -0400, Matt Fowles wrote:
: While we are talking about words... I dislike having Object encompass
: Juction. I get the feeling that some people will write functions that
: take Objects and not expect Junctions to slip in. I suppose that
: could be one of those
LW == Larry Wall [EMAIL PROTECTED] writes:
LW Yes, but we just need to be careful not to recreate The Registry.
LW We're looking more for a place for everything and everything in
LW its place, but we're still trying to understand what that means.
LW As you say, whatever we end up with
Consider this:
sub id (Any $x) returns Any { return($x) }
sub length (Str $y) returns Int { ... }
length(id(abc));
Under standard static subtyping rules, this call will perform three
different typechecks:
1) abc.does(Any) # (abc as Str) === (Any $x) in id
2) $x.does(Any)
On Thu, Jul 28, 2005 at 03:55:55AM +0800, Autrijus Tang wrote:
Hrm. I thought the original motivation of forcing people to write
Any|Junction
was precisely to discourage people from accidentally write
sub foo (Any $x)
and have $x accept a Junction. In other words, any()
On Thu, Jul 28, 2005 at 05:03:05AM +0800, Autrijus Tang wrote:
Hence, it seems to me that there are only four ways out:
Some annotations copied from discussion in #perl6:
A) Omit the #3 check from compile time; at runtime, use the actual
type of $x. The returns type annotation will
On Wed, Jul 27, 2005 at 04:27:15PM -0400, Uri Guttman wrote:
: then why not name it something like *?ENV (not to be confused with the
: shell/exec env which is still %ENV i assume)?
Of course, the fact that you have to say not to be confused with
can be taken as indicating that people will in
LW == Larry Wall [EMAIL PROTECTED] writes:
LW On Wed, Jul 27, 2005 at 04:27:15PM -0400, Uri Guttman wrote:
LW : then why not name it something like *?ENV (not to be confused with the
LW : shell/exec env which is still %ENV i assume)?
LW Of course, the fact that you have to say not to be
On Thu, Jul 28, 2005 at 05:57:28AM +0800, Autrijus Tang wrote:
On Thu, Jul 28, 2005 at 05:03:05AM +0800, Autrijus Tang wrote:
Hence, it seems to me that there are only four ways out:
Some annotations copied from discussion in #perl6:
Last time I reply to myself on this thread, hopefully.
On Jul 27, 2005, at 6:18 PM, Uri Guttman wrote:
this thingy should encompass
all about this perl and the world it is in and the shell env is
part of
that.
How about *?PERL ?
if ( *?PERL.COMPILED_OS eq 'Unix') {...}
if ( *?PERL.CURRENT_OS eq 'Unix') {...}
*?PERL.Grammars{Regex} =
How can I create a lazy list from an object?
I have an object representing the sequence 1..Inf.
I tried creating a Coroutine, and then assigning the Coroutine to an
Array, but it only yielded 1:
my @a = $span.lazy; # 1
The coroutine worked fine in a while loop, but it didn't work in a for
Last night I had an idea about a possable pack API. Most likely when
Pugs gets signifigently powerfull I will attempt to implement it.
However I would like everyones input, below is a draft of its POD.
=head1 NAME
Pack - (un)pack structures as defined by a Template
=head1 SYNOPSIS
my Pack
As Perl 6's aggregate types are generics (Role that takes type
parameters), the problem of type variancy naturally arises.
The basic premise is that:
1. (Array of Item).does(Array of Int); # false
2. (Array of Int).does(Array of Item); # also false!
Intuitively, while an
37 matches
Mail list logo
