HaloO,
Larry Wall wrote:
On Wed, Apr 16, 2008 at 04:29:23PM +, [EMAIL PROTECTED] wrote:
: my Dog $spot = .new();
:
: to
:
: my $Spot = Dog.new();
:
: when you remove the declaration.
You'd also break multiple dispatch rather badly...
Sorry, why that? Isn't the dispatch on the dynamic
HaloO,
Mark J. Reed wrote:
Type checking in both js2/ecma4 and p6 is not merely documentation.
It is enforced, but only if present. This is a tricky thing to
achieve, which is why I suggested reading the js stuff to see how they
went about it.
I like the 'like' operator that does a
Perl doesn't quite meet that because of
inferred method dispatch on .new(). you need to change
Isn't it generally the case that assignment is
dispatched on the *static* type of the lhs? I surmise
that binding cannot be overloaded and this really is
where the type checker kicks in. But what exactly
On Thu, Apr 17, 2008 at 09:24:47AM +0200, TSa wrote:
HaloO,
Larry Wall wrote:
On Wed, Apr 16, 2008 at 04:29:23PM +, [EMAIL PROTECTED] wrote:
: my Dog $spot = .new();
: : to
: : my $Spot = Dog.new();
: : when you remove the declaration.
You'd also break multiple dispatch rather
HaloO,
Mark J. Reed wrote:
It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page). I therefore assume that they have done so, but
others would benefit by doing likewise. :)
Do I get that right: you imply
Thom Boyer thom-at-boyers.org |Perl 6| wrote:
Mark J. Reed wrote:
It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page). I therefore assume that they have done so, but
others would benefit by doing
the optimizer can't do even if it thinks it could.
As a degenerate case, not being allowed to assign or bind something is
certainly an impact on behavior.
If MMD is based on actual dynamic types, then static types don't affect
the result, other than to prevent the program from loading the wrong
thing
that this is the case with Perl 6, or is it?
My understanding is that Perl6 uses static typing as such (i.e. not
merely comments) when it is provided.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED
that this is the case with Perl 6, or is it?
My understanding is that Perl6 uses static typing as such (i.e. not
merely comments) when it is provided.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED
You should look at Common Lisp. it's definition of optional typing is that
if you take a correct program and remove all the type declarations, then it
still works correctly, although it may be significantly less efficient. Larry
and i have discussed this and that was his goai in Perl. Now
On Wed, Apr 16, 2008 at 04:29:23PM +, [EMAIL PROTECTED] wrote:
: You should look at Common Lisp. it's definition of optional typing is that
if you take a correct program and remove all the type declarations, then it
still works correctly, although it may be significantly less efficient.
HaloO,
John M. Dlugosz wrote:
This needs to be fleshed out. Decisions need to be made.
Anyone want to discuss it with me?
I want to. But give me time. Meanwhile you could read
e.g. http://www.dcs.shef.ac.uk/~ajhs/classify/index.html.
This deals with F-bounded polymorphism in a tutorial
It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page). I therefore assume that they have done so, but
others would benefit by doing likewise. :)
On 4/15/08, TSa [EMAIL PROTECTED] wrote:
HaloO,
John M.
I apologize for the vagueness; I was away from browser when I sent
that. Go to http://www.ecmascript.org for the nitty gritty on
ECMAScript 4th Edition, a.k.a. JavaScript 2, which is what I was
talking about. White papers, specs, reference interpreter.
The link from the Firefox developers page
Mark J. Reed wrote:
It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page). I therefore assume that they have done so, but
others would benefit by doing likewise. :)
Could you be a little more specific
I posted my thoughts as a sort of white paper here:
http://www.dlugosz.com/files/static-type.pdf
This needs to be fleshed out. Decisions need to be made. Anyone want to
discuss it with me?
--John
HaloO,
I'm still trying to understand the concept of context
in Perl6 from a typing perspective. My current interpretation
let me to coin three levels of typing in Perl6: syntactic, static
and dynamic. I guess the latter two are well known but the syntactic
type is new---at least do I hope so
Larry Wall writes:
Er, how would LEAVE detect that this was the *last* time you're ever
going to call this routine?
On the other hand, if we renamed FIRST and LAST to ENTER and LEAVE,
then FIRST would become available to mean my very first time...
and LAST will mean just before
--- arcadi shehter [EMAIL PROTECTED] wrote:
Larry Wall writes:
Er, how would LEAVE detect that this was the *last* time you're
ever going to call this routine?
On the other hand, if we renamed FIRST and LAST to ENTER and
LEAVE, then FIRST would become available to mean my
suppose I want this behaviour :
sub new_counter($start=0) {
my $cnt = $start;
my sub incr {
++$cnt;
};
my sub decr {
--$cnt;
};
return sub (str $how=incr)
{
given
Matthijs van Duin writes:
A nice example is:
sub a {
state $x;
my $y;
my sub b { return $x++ + $y++; }
return b; # is a \ before b needed?
}
Every call to sub a will return a different closure. The $x in each closure all
refer to the same variable.
,
#so presumably , this is created
#anew every time closure is created
return ++$cnt;
}
}
Interesting notion. However, given that $cnt is static, this seems
like one of those places where a good optimizer might
Matthijs van Duin [EMAIL PROTECTED] writes:
On Sat, Mar 22, 2003 at 10:24:09PM +0200, arcadi shehter wrote:
sub a {
state $x;
my $y;
my sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
will all b refer to the same $z ?
yes,
At 12:05 PM -0600 3/24/03, Jonathan Scott Duff wrote:
On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
The purpose of a state variable is to keep state across multiple calls
to the same scope, so I'd say the proper semantics on closures is
to treat the generation of a closure as a
On Mon, Mar 24, 2003 at 01:37:01PM -0500, Dan Sugalski wrote:
Since I'd as soon not encourage this, how about INSTANTIATE? Nice and
long and therefore discouraging. :)
Nothing a macro can't fix :-D
--
Matthijs van Duin -- May the Forth be with you!
On Mon, Mar 24, 2003 at 12:05:13PM -0600, Jonathan Scott Duff wrote:
: On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
: The purpose of a state variable is to keep state across multiple calls
: to the same scope, so I'd say the proper semantics on closures is
: to treat the
At 10:34 AM -0800 3/24/03, Larry Wall wrote:
On Mon, Mar 24, 2003 at 12:05:13PM -0600, Jonathan Scott Duff wrote:
: On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
: The purpose of a state variable is to keep state across multiple calls
: to the same scope, so I'd say the proper
Matthijs van Duin writes:
A nice example is:
sub a {
state $x;
my $y;
my sub b { return $x++ + $y++; }
return b; # is a \ before b needed?
}
Every call to sub a will return a different closure. The $x in
each closure all refer to the same variable.
On Sat, Mar 22, 2003 at 10:24:09PM +0200, arcadi shehter wrote:
sub a {
state $x;
my $y;
my sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
will all b refer to the same $z ?
yes, they will
does it mean that this is legitimate
sub
block. Perhaps we should just go with that:
property $foo = 0;
Or whatever word we choose, I don't care:
prop $foo = 0;
What about:
prof $foo;
$foo = 0;
Is this equivalent to prof $foo = 0? If it is not, I would claim
this to be a major violation of the principle of
On Wed, Mar 19, 2003 at 01:18:48PM +0100, Angel Faus wrote:
: Is this equivalent to prof $foo = 0? If it is not, I would claim
: this to be a major violation of the principle of minor surprise.
:-)
: Maybe it would be saner to use:
:
: prop $foo is default(0);
I suspect you mean
On Tue, Mar 18, 2003 at 01:53:59PM +1100, Damian Conway wrote:
Function Assign unless...
true||=
defined //=
exists h
One is almost tempted by something like C??=. Well, almost.
Nonono.. ??= is already for conditionals
, but suddenly it doesn't seem so simple. It
doesn't help that when you do this in a module, you probably don't see the
problem (because 'use Foo;' effectively does a require in a BEGIN block).
I'd argue that the requirement for BEGIN when you want a so-called-static
variable in your main program (and you
Merely for the one small thing I might possibly contribute
Would it be useful to have a convenient place to do polls?
I suspect there already is one somewhere, but I'm unaware of it.
I don't want to undermine the authority of the core planning team, but
thought they might like to have a
$a ??= $b :: $c;
Are you serious?
That's completely unnecessary, but so is
$a ||= 1;
I *LIKE* it!!! =o)
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Larry Wall writes:
Another question is whether a class containing methods containing
has would be confusing. The $s vs $.s distinction seems to help
a bit there. That would seem to imply that
class foo {
has $s;
has $.t;
}
declares a class attribute vs an
sub foo() {
env $s ??= 0;
$s ++ ;
}
Although I still prefer calling it a trait on the data, I must admit
that I like env...perhaps even better than is retained.
Well, maybe not. But it's a cool thought that it's the environment.
Damian Conway wrote:
[...]
Hence, I would argue, one ought to simply mark it with a trait:
sub foo() {
my $s is retained = 0;
$s++;
}
Other possible trait names:
is kept
is preserved
is permanent
is reused
is saved
is stored
is restored
is
On Tuesday, March 18, 2003, at 06:49 AM, Paul wrote:
Merely for the one small thing I might possibly contribute
Would it be useful to have a convenient place to do polls?
I suspect there already is one somewhere, but I'm unaware of it.
I don't want to undermine the authority of the core
|our|temp|let] group. While I, too, immediately understood what
'has' meant, I can't help but feel many people won't get it.
As others have pointed out, the problem with 'static' is not only that
(a) it has too many C++ meanings, but (b) the word itself implies
'constant', not 'persistent'. I
attribute here which is not
the
same in my mind as
my $s is static = 0 ;
which is private to the sub (and any nested subs).
DC Hence, I would argue, one ought to simply mark it with a trait:
my use of is static was a trait. i chose 'is' for that reason. it was
a compile time trait
that pull for static will be pulling for
just that -- a storage class specifier.)
As others have pointed out, the problem with 'static' is not only
that
(a) it has too many C++ meanings, but (b) the word itself implies
'constant', not 'persistent'. I would really, really like for us
Michael Lazzaro [EMAIL PROTECTED] writes:
As much as people hated it, I think the P6 Operators thread was
*quite* beneficial. It lead to the saving of ^ xor, and the hyper
syntax, and quite a few other improvements, and got things pinned down
squarely. I wouldn't mind seeing more of that
Damian Conway writes:
on the second thought : its quite strange ( though cute ) that
currently the only way to make lexical persistent variable is based on
garbage collector. it is referenced -- hence it is kept.
may be it have to be more explicit like that
sub counter(){
daemon $s;
Larry Wall writes:
I guess the real question would be, is it an overall simplification to
allow has anywhere? There *is* an object out there representing each
abstract closure (pre-instantiation), but it's a bit of a stretch from
Every block is a closure to Every block is a closure
on the second thought : its quite strange ( though cute ) that
currently the only way to make lexical persistent variable is based on
garbage collector. it is referenced -- hence it is kept.
this brings to the following : every subroutine may have a
daemon object of some sort associated with
Larry Wall writes:
Larry Wall writes:
I guess the real question would be, is it an overall simplification to
allow has anywhere? There *is* an object out there representing each
abstract closure (pre-instantiation), but it's a bit of a stretch from
Every block is a closure to Every
On Mon, Mar 17, 2003 at 10:03:29PM -0500, Uri Guttman wrote:
: but that is a good name IMO. $s is static vs dynamic (on the stack). the
: other overloaded meanings of static from c/c++ are baggage we can drop.
Gee, if static var makes a subroutine stateful, maybe it's just:
state $s = 0
Larry wrote:
Gee, if static var makes a subroutine stateful, maybe it's just:
state $s = 0;
That's very nice, and (unlike Chas) it's verbose enough.
It would also work well for creating class-private shared state.
And for things like loop counters:
while @list {
(state
block.
Perhaps we should just go with that:
property $foo = 0;
Or whatever word we choose, I don't care:
prop $foo = 0;
have $foo = 0;
this $foo = 0;
here $foo = 0;
block $foo = 0;
static $foo = 0;;-)
But my gut feeling says if it's scoped differently, it had better
LW == Larry Wall [EMAIL PROTECTED] writes:
LW On Mon, Mar 17, 2003 at 10:03:29PM -0500, Uri Guttman wrote:
LW : but that is a good name IMO. $s is static vs dynamic (on the stack). the
LW : other overloaded meanings of static from c/c++ are baggage we can drop.
LW Gee, if static var
' { warn direly; continue; }
default{ return 0 }
}
}
have $foo = 0;
Please, no. Far too close to Chas.
this $foo = 0;
here $foo = 0;
block $foo = 0;
static $foo = 0;;-)
I still think Cprop is the way to go.
Actually has/have is kinda cute
to it. A static variable
should be like a my variable except that it is only initialized once and
is not destroyed when it goes out of scope.
Joe Gottman
it's interesting that has have more or less required scope -- its
visible only from object methods and it keeps its value , so maybe
Uri Guttman writes:
talking about nested subs brought up another related idea, static (not
on the stack) lexicals inside subs. the current solution in p5 is to
declare them in a surrounding block and that is slightly ugly. and if
you want multiple subs to share them they all have
, foo, foo;
That's a *very* interesting idea, but I would have to convince myself
that we're not merely overloading has the way C overloaded static.
I suppose I could convince myself that there is some permanent subish
descriptor object that can have the attribute.
Another question is whether
as
my $s is static = 0 ;
which is private to the sub (and any nested subs).
DC Hence, I would argue, one ought to simply mark it with a trait:
my use of is static was a trait. i chose 'is' for that reason. it was a
compile time trait that the var was to be allocated (and optionally
initialized
Uri Guttman wrote:
but that is a good name IMO. $s is static vs dynamic (on the stack).
I don't think that names that describe implementation are nearly as good as
names that describe behaviour. Not in a Very High Level Language, like Perl.
other overloaded meanings of static from c/c
DC == Damian Conway [EMAIL PROTECTED] writes:
DC Uri Guttman wrote:
but that is a good name IMO. $s is static vs dynamic (on the stack).
DC I don't think that names that describe implementation are nearly as
DC good as names that describe behaviour. Not in a Very High Level
DC
to me static IS a behavior. its value is static from call to call.
other overloaded meanings of static from c/c++ are baggage we can drop.
I can see the potental for alot of ambiguaty between the meaning of 'is Static' and
'is Constant' (unless your a c/c++ programmer so your mind
talking about nested subs brought up another related idea, static (not
on the stack) lexicals inside subs. the current solution in p5 is to
declare them in a surrounding block and that is slightly ugly. and if
you want multiple subs to share them they all have to be in that block.
so a simple
Uri Guttman wrote:
talking about nested subs brought up another related idea, static (not
on the stack) lexicals inside subs.
Doesn't Cour give you this?
Dave.
--
http://dave.whipp.name
- Original Message -
From: Dave Whipp [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, March 15, 2003 1:35 PM
Subject: Re: is static?
Uri Guttman wrote:
talking about nested subs brought up another related idea, static (not
on the stack) lexicals inside subs.
Doesn't Cour
to it. A static variable should be like a my variable except
that it is only initialized once and is not destroyed when it goes
out of scope.
Better to make it a my() with an accessor, and have everything use the
accessor... but it *does* slow things down
On Sat, Mar 15, 2003 at 08:05:03PM -0500, Joe Gottman wrote:
:
: - Original Message -
: From: Dave Whipp [EMAIL PROTECTED]
: To: [EMAIL PROTECTED]
: Sent: Saturday, March 15, 2003 1:35 PM
: Subject: Re: is static?
:
:
: Uri Guttman wrote:
: talking about nested subs brought up
Larry Wall wrote:
On the other hand, is static would be instantly recognizable to
C programmers. Maybe they're due for a sop...
Bah! No sop for them! Cstatic has so many overloaded meanings in
C/C++ that who's to say this meaning is really the one that's worth
codifying? (I always felt
LW == Larry Wall [EMAIL PROTECTED] writes:
LW It is likely that if we have is static, the compiler would translate
LW my $pi is static = 3
LW to something like
LW our $foo__Xdeadbeef will init {.set(3)}
LW I really hate the word static though, which is why I suggested
LW
On Tue, Oct 23, 2001 at 03:41:27AM -0400, Michael G Schwern wrote:
Some of you may remember (and some wish we could forget) a ramble I
posted about six months back about traffic lights and language design
and all the weird ways we get meaning out of such a small # of
symbols. One of the
Brent Dax [EMAIL PROTECTED] writes:
Garrett Goebel:
# my int ($pre, $in, $post) is constant = (0..2);
#
# Means that you are asking for compile time optimizations, and
# agreeing not
# to bless references to, or ascribe run-time properties to
# those scalars. So
# we've already got
On Thu, Nov 01, 2001 at 10:13:22PM -0500, Ken Fox wrote:
On the other hand, people live with C's preprocessor
and its #undef/#define of constants. If C programmers
don't mind having different parts of a program compiled
with different values for the same constant, then why
should Perl
From: Ken Fox [mailto:[EMAIL PROTECTED]]
Here in the 10-step Perl 6 program we don't talk about
resolution. We just learn to cope with change. ;)
;) I'm still working to grok the changes. I thought I was getting generally
clued in after reading the Apocalypses/Exegesises... but discussions on
Garrett Goebel wrote:
Just does compile-time typing for $foo? Not inlining the constant?
You can't assume that the value associated with the symbol is
the same each time through the code, so how can it be inlined?
I was thinking lowercase typed variables couldn't be rebound, because
they
On Wed, 31 Oct 2001, David Nesting wrote:
On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote:
: Yep, but in Perl5, this was never very clean or obvious to the
: casual programmer. Constants have been coming of age in Perl,
: and they're kind of scary if they're not constant.
On
On Thu, 1 Nov 2001, Garrett Goebel wrote:
On Wed, 31 Oct 2001, David Nesting wrote:
On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote:
: Yep, but in Perl5, this was never very clean or obvious to the
: casual programmer. Constants have been coming of age in Perl,
: and
From: David M. Lloyd [mailto:[EMAIL PROTECTED]]
On Thu, 1 Nov 2001, Garrett Goebel wrote:
On Wed, 31 Oct 2001, David Nesting wrote:
On Tue, Oct 30, 2001, Aaron Sherman wrote:
: Yep, but in Perl5, this was never very clean or obvious
: to the casual programmer. Constants have been
Garrett Goebel:
# my int ($pre, $in, $post) is constant = (0..2);
#
# Means that you are asking for compile time optimizations, and
# agreeing not
# to bless references to, or ascribe run-time properties to
# those scalars. So
# we've already got variables with constant values.
#
# I guess my
Garrett Goebel wrote:
worried about the loss of data-hiding with Perl6's lexicals.
Was that ever resolved?
Here in the 10-step Perl 6 program we don't talk about
resolution. We just learn to cope with change. ;)
There were two issues I had. As a Perl 6 user I felt
uncomfortable that Perl 6 is
with "wantarray" and "ref" we have polymorphism but it has to be very late.
During official RFC time I (and others) suggested ways to do polymorphic
optimizations early, like in C/C++.
A few days ago I came up with a way to defer the optimization but make it
if it is needed, entirely under
77 matches
Mail list logo
