Dave Whipp wrote:
> Perhaps an example will clarify my thoughts
>
> my $big_heavy_object = Foo.new;
> $big_heavy_object = add($big_heavy_object, $bar);
>
> If the context provides access to the lvalue, then it
> may be possible to optimize. Effectively, we have the
> information to create an
On Thu, 2002-11-28 at 14:59, Michael Lazzaro wrote:
> But my worries are that we could not keep P6L sufficiently focused,
> resulting in an even *bigger* tangle of threads; that we can't really
> *have* the discussions without posting the proposed documentation too;
> and that P6L would not respond
"Bryan C. Warnock" wrote:
>
> On Tue, 2002-11-26 at 13:36, Michael Lazzaro wrote:
> > The main difference is that p6-docs is intended to move very narrowly
> > from topic to topic, in a roughly predetermined order, focusing on each
>
> But not to move faster than the design of the language.
Yeah
"Bryan C. Warnock" <[EMAIL PROTECTED]> writes:
> Be kind to Piers.
Ah... Yes do. I need all the kindness I can get.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
On Tue, 2002-11-26 at 13:36, Michael Lazzaro wrote:
> The main difference is that p6-docs is intended to move very narrowly
> from topic to topic, in a roughly predetermined order, focusing on each
But not to move faster than the design of the language.
> one until the more dedicated members st
On Tue, 2002-11-26 at 09:17, Garrett Goebel wrote:
>
> p6d exists to document the language. A task which consists of going over the
> A&E's and Larry's posts to p6l, etc. and flushing them out into
> deliverables:
>
> o Perl6/Parrot regression tests
> o Language Specification derived from tests
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
> I'm trying to think of a counterexample, in which you have a context
> that _cannot_ be represented as a "type" according to this very broad
> definition. I don't think it should be possible, is it? If it _is_
> possible, does that represent a flaw/li
On Tuesday, November 26, 2002, at 12:47 PM, Dave Whipp wrote:
I writing these definitions, I came to the conclusion that a
context is more than a type. Others may disagree.
Hmm, I suppose it depends on how broadly we use the term "type"; I like
your definition, if I understand it correctly. :
"Larry Wall" <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 25, 2002 at 07:46:57PM -0500, Bryan C. Warnock wrote:
> : Should an explicit bool type be part of the language? If so, how should
> : it work? C storing only a truth property but
> : no value makes little sense in the context of the larger lang
Larry Wall writes:
> Note that the "true" property is not the same as the "true" function.
> This tells me that properties may need their own namespace distinct
> from either subs or classes. (We've talked about defining properties
> as subs or classes, but either way is problematic. If we ha
On Tuesday, November 26, 2002, at 09:47 AM, Larry Wall wrote:
: > (3) Context. How to determine it, how to force it. Hypothesis:
There
: > is a one-to-one relationship between Type and Context, such that
there
: > is a context that matches every type, and a type that matches every
: > contex
On Monday, November 25, 2002, at 04:46 PM, Bryan C. Warnock wrote:
On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote:
(2) The behavior of an explicit bool type, _if_ one exists, that
stores "truth", not "value". Such that C
stores true, not 0, and does so in "the most efficient way".
If yo
On Mon, Nov 25, 2002 at 07:46:57PM -0500, Bryan C. Warnock wrote:
: Should an explicit bool type be part of the language? If so, how should
: it work? C storing only a truth property but
: no value makes little sense in the context of the larger language. So
: does handling truth as something oth
On Tue, Nov 26, 2002 at 08:52:52AM -0600, Garrett Goebel wrote:
: On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote:
: > (2) The behavior of an explicit bool type, _if_ one exists,
: > that stores "truth", not "value". Such that C = (0 but true)> stores true, not 0, and does so in "the
: > most
On Monday, November 25, 2002, at 11:23 PM, Joseph F. Ryan wrote:
(1) String Interpolation. This was pretty well spelled out by A2, so
there shouldn't be much to do except write it up, unless we want to
make any additional requests. There's some issues that need to be
finalized wrt Unicode,
On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote:
> (2) The behavior of an explicit bool type, _if_ one exists,
> that stores "truth", not "value". Such that C = (0 but true)> stores true, not 0, and does so in "the
> most efficient way".
There is no explicit bool type.
Larry Wall wrote:
>
>
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
>
> If you don't already know whether it exists, or how it will
> roughly work (lexically), you shouldn't be discussing it on
> p6d. Kicked back to p6l.
[...]
> and again... what's the scope of p6d
p6d exists to document the language. A task whi
Michael Lazzaro wrote:
I think we've covered everything about nums that we're able to for the
moment. There are still issues with types/overflow/exception
handling. Internals is talking about them; let's revisit the issue
after they've figured out some of the preliminaries.
I'll attempt to
On Mon, 2002-11-25 at 20:00, Joseph F. Ryan wrote:
> I agree; perhaps before the argument begins, we should have something to
> argue over? :) (i.e., a first draft of these sections)
Sure. On perl6-language. :-)
--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)
Bryan C. Warnock wrote:
On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote:
Let's open these for discussion. Questions/proposals/issues, anyone?
and again... what's the scope of p6d, and how does it differ from p6l?
I agree; perhaps before the argument begins, we should have somethi
On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote:
> (2) The behavior of an explicit bool type, _if_ one exists, that stores
> "truth", not "value". Such that C stores
> true, not 0, and does so in "the most efficient way".
If you don't already know whether it exists, or how it will roughly wo
> Well... Perl5 didn't have typecasts primarily because it didn't have
> types. To the extent it _does_ have types, it has casting, too: it
> just is extremely limited.
>
> my $s = scalar ;
> my $s = list ;
>
> The above can be construed as typecasting: converting an expression
> to eit
On Monday, November 25, 2002, at 12:27 PM, Tanton Gibbs wrote:
Perl 5 did not have typecasts...probably for good reason. The quip in
the camel book says that no one likes to be typecast, anyway. I would
rather not have typecasts in Perl6 if we can get by without them.
Well... Perl5 didn't h
> (2) The behavior of an explicit bool type, _if_ one exists, that stores
> "truth", not "value". Such that C stores
> true, not 0, and does so in "the most efficient way".
I think before we can answer this question, we have to know how to extract
truth.
my int $x = (0 but true);
Now, how do yo
Luke Palmer wrote [reply to my Void type suggestion]
> It could also behave as our bool type. Something that you can attach
> properties to but doesn't need a value seems that it could be useful
> every once in a while.
>
> Just... what does a void literal look like? Perhaps just the word
> C?
>
Michael Lazzaro wrote:
I think we've covered everything about nums that we're able to for the
moment. There are still issues with types/overflow/exception
handling. Internals is talking about them; let's revisit the issue
after they've figured out some of the preliminaries.
I'll attempt to
> From: "Dave Whipp" <[EMAIL PROTECTED]>
> Date: Mon, 25 Nov 2002 11:35:40 -0800
>
> "Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> > [...] and a type that matches every
> > context (except void).
>
> Actually, it might be nice to have a void type. It might seem useless:
> but then, so does /dev/n
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> [...] and a type that matches every
> context (except void).
Actually, it might be nice to have a void type. It might seem useless:
but then, so does /dev/null.
An example, from another language, is C++ templates. Its amazing
how often I find myself
28 matches
Mail list logo
