chromatic <[EMAIL PROTECTED]> writes:
> On Fri, 2004-04-23 at 05:42, Dan Sugalski wrote:
>
>> Since any type potentially has assignment behaviour, it has to be a
>> constructor. For example, if you've got the Joe class set such that
>> assigning to it prints the contents to stderr, this:
>>
>>
At 12:14 AM -0700 4/26/04, Jeff Clites wrote:
On Apr 25, 2004, at 11:59 PM, Luke Palmer wrote:
Jeff Clites writes:
I don't (right off) know of any other language which has something "in
between" variables and objects. That is, containers. They're feeling a
bit artificial.
Well... Perl 5.
Well, the
On Apr 25, 2004, at 11:59 PM, Luke Palmer wrote:
Jeff Clites writes:
I don't (right off) know of any other language which has something "in
between" variables and objects. That is, containers. They're feeling a
bit artificial.
Well... Perl 5.
Well, there's that. :)
But--how does that manifest its
Jeff Clites writes:
> I don't (right off) know of any other language which has something "in
> between" variables and objects. That is, containers. They're feeling a
> bit artificial.
Well... Perl 5.
Luke
On Apr 25, 2004, at 11:01 PM, Piers Cawley wrote:
Jeff Clites <[EMAIL PROTECTED]> writes:
On Apr 23, 2004, at 11:04 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Jeff Clites) writes:
So what does "$foo = 12" in that context actually mean in Perl6?
Another interesting question is "in Perl 6, are var
Jeff Clites <[EMAIL PROTECTED]> writes:
> On Apr 23, 2004, at 11:04 AM, Simon Cozens wrote:
>
>> [EMAIL PROTECTED] (Jeff Clites) writes:
>>> So what does "$foo = 12" in that context actually mean in Perl6?
>>
>> Another interesting question is "in Perl 6, are variables typed,
>> values typed,
>> o
On Fri, Apr 23, 2004 at 03:14:47PM -0400, Dan Sugalski wrote:
: It also depends on whether the type is on the name or the container.
: Which is your call. :-P (Though, given my druthers, I'd leave it on
: the container)
We should certainly leave them on the container. The sin of rebinding
a nam
At 11:53 AM -0700 4/23/04, Larry Wall wrote:
On Fri, Apr 23, 2004 at 11:47:28AM -0700, Jeff Clites wrote:
: That's my worry--whether we have a problem. (No problem with typed
: values, of course.) If variables are typed, _and_ that typing is
: lexically scoped, then I think that we don't have a pro
At 7:04 PM +0100 4/23/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Jeff Clites) writes:
So what does "$foo = 12" in that context actually mean in Perl6?
Another interesting question is "in Perl 6, are variables typed, values typed,
or a little of both?"
It seems that Parrot has been working primaril
On Fri, Apr 23, 2004 at 11:47:28AM -0700, Jeff Clites wrote:
: That's my worry--whether we have a problem. (No problem with typed
: values, of course.) If variables are typed, _and_ that typing is
: lexically scoped, then I think that we don't have a problem, and it can
: be handled at the compi
On Fri, Apr 23, 2004 at 12:46:04PM -0400, Dan Sugalski wrote:
: Sure, that's doable, as are a number of other things. Depends on the
: semantics of assignment to uninitialized types, though that's on a
: per-type basis. This all gets somewhat messy when you mix in objects
: and types, since what
On Apr 23, 2004, at 11:04 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Jeff Clites) writes:
So what does "$foo = 12" in that context actually mean in Perl6?
Another interesting question is "in Perl 6, are variables typed,
values typed,
or a little of both?"
It seems that Parrot has been working pr
[EMAIL PROTECTED] (Jeff Clites) writes:
> So what does "$foo = 12" in that context actually mean in Perl6?
Another interesting question is "in Perl 6, are variables typed, values typed,
or a little of both?"
It seems that Parrot has been working primarily on the assumption that it's
values that a
At 10:35 AM -0700 4/23/04, Jeff Clites wrote:
On Apr 23, 2004, at 8:54 AM, Larry Wall wrote:
On Fri, Apr 23, 2004 at 08:42:28AM -0400, Dan Sugalski wrote:
: Since any type potentially has assignment behaviour, it has to be a
: constructor. For example, if you've got the Joe class set such that
:
On Apr 23, 2004, at 8:54 AM, Larry Wall wrote:
On Fri, Apr 23, 2004 at 08:42:28AM -0400, Dan Sugalski wrote:
: Since any type potentially has assignment behaviour, it has to be a
: constructor. For example, if you've got the Joe class set such that
: assigning to it prints the contents to stderr,
At 9:30 AM -0700 4/23/04, chromatic wrote:
On Fri, 2004-04-23 at 05:42, Dan Sugalski wrote:
Since any type potentially has assignment behaviour, it has to be a
constructor. For example, if you've got the Joe class set such that
assigning to it prints the contents to stderr, this:
my Joe $f
On Fri, 2004-04-23 at 05:42, Dan Sugalski wrote:
> Since any type potentially has assignment behaviour, it has to be a
> constructor. For example, if you've got the Joe class set such that
> assigning to it prints the contents to stderr, this:
>
> my Joe $foo;
> $foo = 12;
>
> should p
On Fri, Apr 23, 2004 at 08:42:28AM -0400, Dan Sugalski wrote:
: At 11:29 PM +0100 4/22/04, Simon Cozens wrote:
: >[EMAIL PROTECTED] (Dan Sugalski) writes:
: >> my Joe $foo;
: >>
: >> emits the code that, at runtime, finds the class ID of whatever Joe's
: >> in scope, instantiates a new object o
On Apr 23, 2004, at 5:42 AM, Dan Sugalski wrote:
At 11:29 PM +0100 4/22/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
my Joe $foo;
emits the code that, at runtime, finds the class ID of whatever
Joe's
in scope, instantiates a new object of that class
Uh, is that right?
On Fri, 2004-04-23 at 08:42, Dan Sugalski wrote:
> Since any type potentially has assignment behaviour, it has to be a
> constructor. For example, if you've got the Joe class set such that
> assigning to it prints the contents to stderr, this:
>
> my Joe $foo;
> $foo = 12;
>
> should p
At 11:29 PM +0100 4/22/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
my Joe $foo;
emits the code that, at runtime, finds the class ID of whatever Joe's
in scope, instantiates a new object of that class
Uh, is that right? I don't think that "my" is a constructor, more a ty
[EMAIL PROTECTED] (Dan Sugalski) writes:
> my Joe $foo;
>
> emits the code that, at runtime, finds the class ID of whatever Joe's
> in scope, instantiates a new object of that class
Uh, is that right? I don't think that "my" is a constructor, more a typing
declarator.
--
Hi, this is Ken. Wh
On Thu, 2004-04-22 at 15:37, Luke Palmer wrote:
> But Perl 6 is tightly coupled with Parrot. Perl 6 will be a Parrot
> program (even if it calls out to C a lot), and can therefore use the
> compreg opcodes. That means that any code executing in Parrot can call
> back out to the Perl 6 compiler,
Aaron Sherman writes:
> But according to A12 as I understand it, the part BEFORE that, which
> looked innocently like a definition:
>
> class Joe { my $.a; method b {...} }
>
> would actually get turned into a BEGIN block that executes the body of
> the class definition as a closure in clas
On Thu, 2004-04-22 at 14:44, Dan Sugalski wrote:
> At 1:05 PM -0400 4/22/04, Aaron Sherman wrote:
> >This is in direct contradiction to what I'm hearing from you, Dan.
> >What's the scoop?
>
> The scoop is that
>
> my Joe $foo;
>
> emits the code that, at runtime, finds the class ID of what
At 1:05 PM -0400 4/22/04, Aaron Sherman wrote:
On Thu, 2004-04-22 at 11:22, Dan Sugalski wrote:
At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
>More to the point, Perl 6's compiler will have to parse "class Joe",
>create a new object of type Class, parse and execute the following
>block/closu
On Thu, 2004-04-22 at 11:22, Dan Sugalski wrote:
> At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
> >More to the point, Perl 6's compiler will have to parse "class Joe",
> >create a new object of type Class, parse and execute the following
> >block/closure in class MetaClass, assign the result in
On Thu, Apr 22, 2004 at 12:42:49PM -0400, Dan Sugalski wrote:
: But that's completely irrelevant to the original question, about
: lexical variable classes. I presume you've got a point you're making?
Yes, my point is you didn't actually answer his question.
Larry
At 9:20 AM -0700 4/22/04, Larry Wall wrote:
On Thu, Apr 22, 2004 at 11:22:32AM -0400, Dan Sugalski wrote:
: Erm... no. Not even close, really. There's really nothing at all
: special about this--it's a very standard user-defined type issue,
: dead-common compiler stuff. You could, if you wanted, re
On Thu, Apr 22, 2004 at 11:22:32AM -0400, Dan Sugalski wrote:
: Erm... no. Not even close, really. There's really nothing at all
: special about this--it's a very standard user-defined type issue,
: dead-common compiler stuff. You could, if you wanted, really
: complicate it, but there's no reas
On Thu, Apr 22, 2004 at 10:48:51AM -0400, Aaron Sherman wrote:
: 1. Have a feedback loop between Parrot and Perl 6 that allows the
: compiler to execute a chunk of bytecode, get the result as a PMC
: and store it for future use. This will probably be needed
: regardless
> "Dan" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> More to the point, Perl 6's compiler will have to parse "class Joe",
>> create a new object of type Class, parse and execute the following
>> block/closure in class MetaClass, assign the result into the new Class
>> object named Joe and th
At 10:48 AM -0400 4/22/04, Aaron Sherman wrote:
Ok, so I got to thinking about Parrot and compilation last night. Then
something occurred to me, and I'm not sure how it works.
When Perl sees:
class Joe { my $.a; method b {...} }
my Joe $j;
Many things happen and some of them will r
Ok, so I got to thinking about Parrot and compilation last night. Then
something occurred to me, and I'm not sure how it works.
When Perl sees:
class Joe { my $.a; method b {...} }
my Joe $j;
Many things happen and some of them will require knowing what the result
of the previous
34 matches
Mail list logo
