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 C semantics should
> indicate "make whatever I'm actually gi
Murat Ünalan wrote:
> A very good idea, but i am afraid that this ML isnt the right
> audience.
>
> 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 w
[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 actua
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?
D
[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 ?
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 t
At 1:45 PM +1100 3/14/03, Damian Conway wrote:
Luke Palmer wrote:
Not that that couldn't be done with a closure anyway...
{
my Class %valClasses;
sub Val($N) returns Class {
my Class $rclass = %valClasses{$N} //= class {
multi *isa ($obj, $rclass $class) { $obj ~
--- 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
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 i
On Fri, Mar 14, 2003 at 01:45:56PM +1100, Damian Conway wrote:
: Oh, and I was wrong to originally write: C
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. And I do think
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 suggeste
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 nega
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 mech
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 t
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, t
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.
: furthermor
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 C<&infix:=> is really an operator on
: *containers*, not on *values*. So, in order t
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 to
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 correctin
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
>>>
In the tradition of Mr. Lazzaro, a chart:
For origin of the AUTOLOAD/DISPATCH stuff, see:
http://groups.google.com/groups?hl=en&selm=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.
Giv
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 dred
> 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,
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
> slur
--
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 typin
29 matches
Mail list logo
