Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all the
summaries after all. I just hope that a chunk of it ends up in Larry's
pocket.
Does anyone know if TPF is set up to allow earmarked contributions?
brad
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
By distinguishing a parameter that *requires* a particular type, from
a parameter that *ensures* a particular type (by coercion if
necessary). I've suggested that using Cis copy semantics should
indicate make whatever I'm actually
[EMAIL PROTECTED] (Aldo Calpini) writes:
any (possibly meaningful) feedback will be very appreciated.
I think Type should be called Value, and that arrays should possibly be a
mixin of lists, but apart from that it looks fine. Oh, and you missed
out Grammars; and I don't know if macros are
Brad Hughes [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all the
summaries after all. I just hope that a chunk of it ends up in Larry's
pocket.
Does anyone know if TPF is set up to allow earmarked contributions?
Dunno. But
[snip]
PS: But before reinventing a wheel, i would like to suggest to
adopt the .NET/Java object hierarchy.
uhm. either I am completely wrong or you are totally out
of track. I really don't understand what you're talking about :-)
Urgs. Hopefully i didn't trapped into a dunghill ? But
At 3:07 PM + 3/14/03, Piers Cawley wrote:
Brad Hughes [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all the
summaries after all. I just hope that a chunk of it ends up in Larry's
pocket.
Does anyone know if TPF is set up to
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:07 PM + 3/14/03, Piers Cawley wrote:
Brad Hughes [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all
the
summaries after all. I just hope that a chunk of it ends up in
Simon Cozens wrote:
...and I don't know if macros are actually objects and can be tossed
around, or if they're just part of the compilation process.
they have their proper place in the diagram Larry put in A6.
furthermore, he says:
These syntactic forms correspond the various Routine types in
On Fri, Mar 14, 2003 at 01:45:56PM +1100, Damian Conway wrote:
: Oh, and I was wrong to originally write: Cmulti *isa ...
Sorry, you're not even wrong. :-)
: Multimethods live in their own namespace. No * required.
Alternately, we require the C* in order to accurately document
their scope.
On Thu, Mar 13, 2003 at 10:52:04PM +0100, Anton Berezin wrote:
: On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
:
: By distinguishing a parameter that *requires* a particular type, from
: a parameter that *ensures* a particular type (by coercion if
: necessary). I've suggested
On Thu, Mar 13, 2003 at 10:37:36PM -0600, david nicol wrote:
:
: However, if you access the last element using the length of the array,
: it may try to flatten, and fail:
:
: my @flat = (1..Inf, 1..10);
: $last = @[EMAIL PROTECTED] - 1]; # Kaboom!
:
: How about negative
On Thu, Mar 13, 2003 at 07:36:00PM -0800, Brent Dax wrote:
: I think that there should be two types of arg typing[1]: 'strict' and
: 'loose'. Strict arg typing doesn't coerce, except to turn subclasses
: into superclasses; loose arg typing, on the other hand, coerces whenever
: possible. The
OK, divide conquer. We seem to be spasming about this and trying to
talk about N things at once, so here's an issue summary. We're talking
about at least two separate cases, (1) inferring type where none has
been specified, and (2) coercing a typed value into another type.
Let's take these
Friday 14 March 2003 20:06, Michael Lazzaro wrote:
3) If an untyped var is used for a typed parameter, a simple
dataflow analysis is used to determine whether the compiler can
guarantee that, at that point, an untyped var will _always_
contain values of a known, specific type. If so, the type
On Fri, Mar 14, 2003 at 05:21:46PM +0100, Aldo Calpini wrote:
: Simon Cozens wrote:
: ...and I don't know if macros are actually objects and can be tossed
: around, or if they're just part of the compilation process.
:
: they have their proper place in the diagram Larry put in A6.
:
On Fri, Mar 14, 2003 at 01:20:28PM +1100, Damian Conway wrote:
: Luke Palmer wrote:
:
: So, now that we have binding, is it possible to overload the
: assignment operator?
:
: Not really. The problem is that Cinfix:= is really an operator on
: *containers*, not on *values*. So, in order to
I apologize for not including a previous message thread -- I
fumble-fingered myself out of all the relevant ones
Still, I'd just like to cast my tiny vote regarding inferences.
I'd like to be able to write classes that can take advantage of
screaming speed, and types contribute.
I'd like
On Friday, March 14, 2003, at 11:06 AM, Michael Lazzaro wrote:
AFAICT, these are the *only* possible solutions to the problem. At
last count, Larry was leaning towards #2. Damian was countering with
#1. Some Lowly Grubs were suggesting #3. Am I missing anything?
Whoops! That needs
Michael Lazzaro wrote:
3) If an untyped var is used for a typed parameter, a simple dataflow
analysis is used to determine whether the compiler can guarantee that,
at that point, an untyped var will _always_ contain values of a known,
specific type. If so, the type is inferred (silently or
At 8:07 AM -0800 3/14/03, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:07 PM + 3/14/03, Piers Cawley wrote:
Brad Hughes [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all
the
summaries
In the tradition of Mr. Lazzaro, a chart:
For origin of the AUTOLOAD/DISPATCH stuff, see:
http://groups.google.com/groups?hl=enselm=3E6E853D.9090604%40conway.org
Does this make sense as far as the Rules of Dispatch? Ive included a
few suggestions where capability or sequence was unclear.
On Friday, March 14, 2003, at 12:21 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
3) If an untyped var is used for a typed parameter, a simple
dataflow analysis is used to determine whether the compiler can
guarantee that, at that point, an untyped var will _always_ contain
values of a known,
on boston.pm a thread arose about having named subs inside subs. of
course perl5 can do it but they don't do anything useful but they do
have some odd implemenation defined closure behavior.
someone brought up lisp and scheme and how they do it (differently from
each other).
well, i want to
on boston.pm a thread arose about having named subs inside subs. of
course perl5 can do it but they don't do anything useful but they do
have some odd implemenation defined closure behavior.
someone brought up lisp and scheme and how they do it (differently from
each other).
well, i want
A simple question, I hope...
From A6, Calling Subroutines, comes the following:
multi push(@array, +$how, [EMAIL PROTECTED]) {...}
push(@a, how = 'rapidly', 1,2,3); # OK
push(@a, 1,2,3); # WRONG, $how == 1!
Oops! What you really wanted to say was:
multi
When calling a sub that has both named params and a slurpy list, the
slurpy list should always come last. If a sub has both a slurpy hash
and a slurpy list, the slurpy list should still always come last. You
simply can't credibly have anything after the slurpy list, or it'll be
slurped.
--
On Fri, 14 Mar 2003 10:08:15
Larry Wall wrote:
On Thu, Mar 13, 2003 at 07:36:00PM -0800, Brent Dax wrote:
: I think that there should be two types of arg typing[1]: 'strict' and
: 'loose'. Strict arg typing doesn't coerce, except to turn subclasses
: into superclasses; loose arg typing,
27 matches
Mail list logo
