# New Ticket Created by Jason Gloudon
# Please include the string: [perl #21577]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21577 >
This patch adds support for vtable calls in sun4/JIT as well as providing
additional o
--
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
On Fri, 14 Mar 2003, Dan Sugalski wrote:
> At 6:59 PM -0800 3/13/03, Robert Spier wrote:
> > > If we can't find anothr home for it, I can make a spot on
> >> ftp.sidhe.org for it. Not a *fast* home, since it's either 128k or
> >> 192k upstream (depending on which interface is active, don't ask)
> 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
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
> 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,
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 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
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
At 10:40 AM + 3/11/03, "Jürgen" "Bömmels" (via RT) wrote:
Hello,
next part in the move to PIO.
open and close.
This uses interpreter->piodata to store and retrieve the
Filehandels, as they are used for stdin, stdout, stderr. ATM there is
no resizelogic so the number of open filehandles is limi
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
>>>
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 9:17 PM -0800 3/13/03, Darren Duncan wrote:
I have a question, and sorry if it is redundant. (I can't seem to
find a search function on http://archive.develooper.com like I
thought used to be there.)
Google's got the list, though I don't remember off-hand how to
restrict google searches by U
At 6:59 PM -0800 3/13/03, Robert Spier wrote:
> If we can't find anothr home for it, I can make a spot on
ftp.sidhe.org for it. Not a *fast* home, since it's either 128k or
192k upstream (depending on which interface is active, don't ask) but
it will work.
Maybe when 0.10 is released, Clinton w
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
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 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
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
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
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
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
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
Darren Duncan wrote:
[snip]
> I decided that I shouldn't waste my time with the Perl 5 XS system and
> go straight to using the corresponding Parrot extension mechanism
> instead. Partly this is because the latter should be more mature by
> the time I am ready to write the C, and also because it s
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 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
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
--- 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
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 ~
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
[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 ?
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
[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
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
I have a question, and sorry if it is redundant. (I can't seem to find a search
function on http://archive.develooper.com like I thought used to be there.)
P.S. Please CC any replies to [EMAIL PROTECTED] as I'm not subscribed to this mailing
list.
For background, I am currently building a com
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
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
36 matches
Mail list logo
