Carp in perl 6
Will there be a way to achieve what the Carp module does in perl 6? I
like the functionality it gives me, but think that it should be
builtin. Perhaps it could work like this:
caller.throw('an error');
Could this:
throw('an error');
just be another way to say:
$?BLOCK.throw('an error');
?
The mechanism Carp has for throwing exceptions from further down the
call stack seems a bit clunky. The above would mean we could do:
(caller Method, :skip(2)).throw('an error');
and possibly
# use a closure to search back through the call stack
throw_from({.package !~ $OUTER::?package}, 'an error');
Does this make any sense? Apologies if any of this has been discussed before.
Tom
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 01:07:45AM -0600, Rod Adams wrote: : It's been defined that Perl 6.0.0 does not dispatch on named parameters, : for better or for worse. If you don't like it, talk to Larry. That's a little bit of an overstatement. I've only said 6.0.0 doesn't *have* to support MMD on named parameters. I haven't said it mustn't. If the first implementation of Perl 6 figures out a decent way to handle it efficiently, I'm all for it, provided it doesn't unduly delay 6.0.0. At the time we made the decision, it wasn't clear to any of us in the room how to do it efficiently, but it might be obvious to someone else. Or maybe it's even okay to take a speed hit, as long as we don't punish the innocent with the guilty. And the long and the short of it is that it really depends on whether someone is willing to work on implementing it. We hope to get there someday, but it's not top priority for 6.0.0 unless someone decides to make it top priority. There are a number of things we might negotiate away to make it easier to get 6.0.0 out the door quicker, and this is only one of them. My only stipulation is that we trim things in such a way as to not make them impossible later. Which means, in the case of named MMD, that it is required that you use a colon to separate positional arguments from named arguments until named MMD is implemented, because we don't want the meaning of signatures to suddenly change. After named MMD is implemented we can remove the colon. There are really two different problems here--it's also an issue that you can use named notation on position args. and I don't have as good an idea for how to future proof against that changing its meaning, other than telling people not to do it yet. *If* all the long names for a particular short name use the same parameter naming scheme, then we could probably do some kind of global optimization to know that a particular named parameter always maps to a particular position. But that's a big if. It's certainly possible that the best way to future proof it is to simply do it right in the first place, even if it's slow to begin with. People can always write the positional form for speed when they need it. Larry
Re: SEND + MORE = MONEY (works now in pugs with junctions!)
Rod Adams wrote: I have the philosophical problem with your use of junctions in this context due to the fact that you are completely ignoring the predicate of the junction. The C all(...) == one(...) is an excellent use of YES, and much clearer than when this test is buried under code that has to be written if you only have simple tests and boolean connectives. junctions, that makes use of the predicates when the junctions are evaluated. If you want threading without the predicate, I give you the hyperthreader (well, I'm trying to). I fully agree to this. I interpret the junctions as oracle values: the predicate is used to properly address them when you ask e.g. is any of your values greater than 10?. You shouldn't assume an inner structure. And as Rod points out, many examples are using the inner structure and the auto-threading while *ignoring* the predicate. Regards, -- TSa (Thomas Sandlaß)
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams [EMAIL PROTECTED] wrote:
While that's a nice feature to have in general, I feel better about
going ahead and predefining that the builtins are already members of
Num, Str, Array, Hash for the shear performance and documentation values
of it.
That's exactly the plan, when it comes to Parrot. I'd like to have a lot
of function-like opcodes factored out into classes/*.pmc as methods.
Given:
pmclass P6Num extends Float { # the P6Num isa(Float)
...
}
pmclass Float {
METHOD cos() { ... } # return cosine of Float SELF
the method call in PIR can be written as:
d = x.cos() # normal method call
d = Float.cos(x) # class method, argument shifted down
d = P6Num.cos(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
I'm not quite sure if the same scheme should apply to:
op cos(out NUM, in NUM)
i.e. to opcodes that take natural types. But eventually such opcodes can
be recompiled inline with the help of the JIT subsystem, so that there's
no function call overhead at all. For now they probably remain as
opcodes.
The other problem with case 5 is that the long name would be cos, not
cosNum, since the first parameter is optional. So you'd have to
expand the search beyond just the long name, which can get expensive.
The method lookup will be done just once per call site, it shouldn't
really matter.
-- Rod Adams.
leo
[1] PMC versions aren't implemented
Re: for @list sub;
[EMAIL PROTECTED] wrote:
for [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] - $x { say $x };
should work. Are there any non-slashy versions of this?
I'd guess
for @a; @b; @c - $x { say $x;}
or
for (@a; @b; @c) - $x { say $x;}
(are parens mandatory here?)
Miro
Re: The S29 Functions Project
Rod Adams wrote:
And then internally dispatch on what is defined and undefined.
Why all that burden if Perl 6 is getting a strong type system,
that can do the sub selection and compile in dynamic dispatch if
needed?
I imagine:
multi sub cos( Num +$angle ) returns Num where { -1.0 = $_ = 1.0 }
class Radians is Num
{
}
class Degrees is Num
{
postfix:° ( Num $x ) { return $x * PI / 180 }
multi sub cos( Degrees +$angle ) returns Num where { -1.0 = $_ = 1.0 }
{
return cos( $angle * PI / 180 );
}
}
Note that cos(30°) calls cosNum while cosDegrees is used for
cases like:
Degrees $angle = 30.0;
if cos $angle 2.0 { print HaloO typechecker! }
And I still wonder if the ones without '°' on their keyboard could
directly call 'cosDegrees $angle'.
Regards,
--
TSa (Thomas Sandlaß)
Re: The S29 Functions Project
On Sun, Mar 13, 2005 at 06:03:20PM -0800, Larry Wall wrote: : One thing I've already done is make a list of Perl 5 functions I cannot : address until some future Apocalypse/Synopsis is generated on the topic. : By far the bulk of this list falls on S16. Partly because IPC is a mess, : and partly because I lumped all I/O in there. At some point we're going to have to make a decision how many of these automatically show up in ::* and how many have to be imported, and whether there's some subset of the latter that can be auto-imported on demand, and whether that's a good idea at all. It feels like a sop, and I'm not sure how many sops we can afford in Perl 6 before things get soggy. I ran into this problem while creating a mini-list of S29 functions (which Rod's work supercedes, I suspect, and I'm very glad he's taking this on). What are some guidelines we could use in deciding which functions are automatically in ::* ? Or is this just a case where we need to use past experience and best guesses as our guide? Pm
Re: Adding linear interpolation to an array
Juerd wrote: Larry Wall skribis 2005-03-11 8:45 (-0800): On Fri, Mar 11, 2005 at 03:58:13PM +0100, Thomas Sandlaß wrote: : Int @i; : Num @n = @i; # type error? I think the naive user is going to expect that to work, and I also suspect the naive user is right to expect it, because it makes sense. This may be one of those areas where we can successfully hide the high-falutin' theory from mere mortals simply because it maps onto what they expect already. It'd be great if this were a standard feature you can also use for your own objects. I fully agree with what Larry said about constant and copied parameter types. There we can easily go with covariant subtyping. OTOH the idea of a container providing a view of the values is a very high ideal. I think it is worthwhile to implement in the standard library for ubiquitous value types like Str, Num and Int. But I doubt that it can be achieved such that the Array class does respect any (future) value type! One idea that formally pushes the problem out of the Array class is to require a role ArrayEntry from every entry. But that would need very neat defaults to have a chance to be acceptable in the community---I hear people say: What? I need to implement that complicated role just to put my Blahh into an Array?. OK, would could go with independend types when the entry doesn't ArrayEntry, but then we might hear a slightly different complain: I can't mix my Blahhs with other objects in an array!. So I'm at a loss here. I believe $foo.Num in this case should return the Num-ified version of $foo. And maybe the int method numbers have is redundant, and should be spelled Int instead. Or, well, if this is the case, int should return an int (not Int) for consistency. Maybe +$foo even maps to $foo.Num, and ~$foo maps to $foo.Str and ?$foo maps to $foo.Bool? Hm, are charsets representable as classes/roles? my Str::utf8 $bar = ...; my Str::latin1 $foo = $bar; In my mindset that would read as my Str[utf8] $bar = ...; my Str[latin1] $foo = $bar; # type error? Or dynamic compatibility test? $bar = $foo could be allowed if the typechecker knew that latin1 subtypes utf8. More interesting is actually the typing of string constants: $foo = äöü; # Str[latin1] my Str[ASCII] $ascii = äöü; # type error? Hmm, since what is compile to you is runtime for the compiler it might by a normal store attempt that is then rejected by the object and caught by the compiler---cool. Is there also an unchecked store operation that can be used when the typechecker knows the assignment is (type-)correct? Regards, -- TSa (Thomas Sandlaß)
Re: The S29 Functions Project
Thomas Sandla writes:
Rod Adams wrote:
And then internally dispatch on what is defined and undefined.
Why all that burden if Perl 6 is getting a strong type system,
that can do the sub selection and compile in dynamic dispatch if
needed?
I imagine:
multi sub cos( Num +$angle ) returns Num where { -1.0 = $_ = 1.0 }
Lose the + on $angle. + indicates a named-only parameter. You want
this to be positional.
class Radians is Num
{
}
class Degrees is Num
{
postfix: ( Num $x ) { return $x * PI / 180 }
You probably shouldn't define this inside the Desgrees class. And you
should probably tell me whether it's a sub, a method, a macro, a
submethod, or a small puppy.
multi sub cos( Degrees +$angle ) returns Num where { -1.0 = $_ = 1.0 }
{
return cos( $angle * PI / 180 );
}
I think that's defining Degrees::cos to be a multi, to be differentiated
from other Degrees::cos'es. But that may be right.
I'd just make it a method.
method cos($angle:) returns Num where { -1 = $_ 1 } {
cos($angle * PI / 180);
}
}
Note that cos(30) calls cosNum while cosDegrees is used for
cases like:
Degrees $angle = 30.0;
if cos $angle 2.0 { print HaloO typechecker! }
That's certainly an interesting way to do it.
And I still wonder if the ones without '' on their keyboard could
directly call 'cosDegrees $angle'.
cosDegrees($angle) or Degrees::cos($angle), depending on whether you
defined it your way or my way. Uh oh, I thought we were going to make
single-invocant multis and methods the same everywhere...
Luke
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
Hmm. It's probably a design bug. I'm wondering if we have to specify
that ordinary assignment not only copies logically but, in fact, always
does ** flattening (immediate flattening) like Perl 5
Except ** does not flatten recursively, so:
my $lines = [ =$fh ];
is still borked.
Do we want a *** nuke everything flat semantic device, if not the
operator? Or an eager context on the right hand side of =?
On the other hand, we can alternatively specify that closing a
file handle must force all thunks associated to it, i.e. in this
case fill @lines with real data. Pugs can do that just fine, but I
have no idea how parrot is to achieve that...
Thanks,
/Autrijus/
pgpEBaFEN7Eb3.pgp
Description: PGP signature
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: Given this Pugs program, t.p6:
:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
: running:
:
: pugs t.p6 t.p6
:
: produces no output. Move $fh.close() to after the for
: loop and all is well. Is this a bug?
Hmm. It's probably a design bug. I'm wondering if we have to specify
that ordinary assignment not only copies logically but, in fact, always
does ** flattening (immediate flattening) like Perl 5, and you *must*
use := binding to get lazy flattening. That is probably the course
of sanity. Since assignment is the primary means of violating FP's
no-side-effect idea, it makes sense that assignment is also what tries
its hardest to work around the issue when the user requests a side
effect like assignment. For example,
@foo = 1...;
would be an outright error, detectable at compile time in this case, while
@foo := 1...;
is perfectly fine. But my coffee isn't ready yet this morning,
so I reserve the right to be wronger than usual.
[Followups directed by default to p6l.]
Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 05:28:29PM +0100, Miroslav Silovic wrote: But it gets worse. my $lines = [ =$fh ]; seek($fh, 0); my $lines2 = [ =$fh ]; close $fh; $lines2 must somehow remember that seek has happened. That is fine because the three thunks are registered to the fh in evaluation order. What will be more fun is if they are all part of some other lazy lists, which may be accessed in some unpredictable order. That is why lazy languages typically use some sort of typechecking to avoid mixing computations with actions... :) Thanks, /Autrijus/ pgp0PQK7x77aI.pgp Description: PGP signature
Re: [Pugs] Closing a file handle surprised the heck out of me
Autrijus Tang writes:
On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
Hmm. It's probably a design bug. I'm wondering if we have to specify
that ordinary assignment not only copies logically but, in fact, always
does ** flattening (immediate flattening) like Perl 5
Except ** does not flatten recursively, so:
my $lines = [ =$fh ];
is still borked.
Do we want a *** nuke everything flat semantic device, if not the
operator? Or an eager context on the right hand side of =?
On the other hand, we can alternatively specify that closing a
file handle must force all thunks associated to it, i.e. in this
case fill @lines with real data. Pugs can do that just fine, but I
have no idea how parrot is to achieve that...
Perhaps lists by assignment are COW lazy. So they behave just like
ordinary COW objects, except they can be lazy at the end:
my @a = gather {
for 1... {
say;
take;
}
};
@a[10]; # says 1 2 3 ... 10
@a[5] = 42;
@a[20]; # nothing printed
I wonder if that's DingTRT though...
Luke
Thanks,
/Autrijus/
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: : I ran into this problem while creating a mini-list of S29 functions : (which Rod's work supercedes, I suspect, and I'm very glad he's taking : this on). What are some guidelines we could use in deciding : which functions are automatically in ::* ? Or is this just a case : where we need to use past experience and best guesses as our guide? You have the irritating habit of asking good questions I don't have an easy answer for. Please don't stop. Thinking about it a bit, it really comes down to an issue of pragmatics in the linguistic sense. The question is, if you glance at any particular function foo(), does it immediately pop into your head that this is probably a cultural meme, or does it sort of lazily evaluate to the possibility of a cultural meme. So by this main criterion, abs() is almost certainly the absolute value meme (unless you're at the gym), while dump() doesn't really mean much to people because it's too heavily overloaded. There are going to be several secondary criteria that modify the main criterion: * Sometimes we want to force a particular meme into the foreground. By the main criterion lock() isn't specific enough to be a keyword, but we can choose to force it to mean one thing. The fact that all such functions are the equivalent of Perl 5's 3rd-class keywords makes this easier, since the user can still override the meaning of lock() if they want to. (Or abs() for that matter.) * Another confounding factor is that memes tend to come in bundles, and you'd kind of like to keep the bundles together. So my earlier question really amounted to whether POSIX was really a valid bundle of memes. (Probably not.) On the other hand, the trig functions might well be a valid bundle, and we might want to keep them all together either in * or Trig. * On the other hand, maybe some meme bundles deserve to be split up into two bundles by the main criterion, with one bundle going into * and the other into Trig (or whatever). Arguably sin and cos are instantly recognizable, but the lesser known trig functions are more debatable. But these are all fuzzy boundaries, and people will see the boundaries in different places. * We're really talking about a three-way distinction here. In the middle we have the functions that are imported by default when you say use Trig rather than use Trig :all. There are some folks who would argue well-formed modules should never export any names by default, so that use Trig *only* makes sure that the Trig module is available, and you'd have to say use Trig :default or some such to get the default set. But that's just giving the middle memes a different collective name. * We do in fact have mechanisms for overriding any core feature, and we don't want Perl to turn into a language where you have to import a bunch of essential stuff at the top, it basically argues that in case of doubt, we should throw it into the core. We'll also have MMD to sort things out, so as long as things are well-typed, we shouldn't fall into a PHP function-name hell. * Backward compatibility with Perl 5 decisions certainly influences what Perl 5 programmers will expect, but not necessarily newcomers to Perl. We'll have to decide how to balance those where Perl 5 got it a little wrong. The upshot of all this is that, as you suspected, this is something we'll just have to work out as a community. What we can do right now is tell people not to be surprised when we move things around, and that we'll feel free to move things around until 6.0.0 is about to go golden. But maybe we could try to set some slushiness milestones on the road to hell freezing over... Larry
Re: The S29 Functions Project
Luke Palmer wrote: cosDegrees($angle) or Degrees::cos($angle), depending on whether you defined it your way or my way. Uh oh, I thought we were going to make single-invocant multis and methods the same everywhere... Sorry for messing up the syntax in my example code. What I wanted to achieve is to get a multi cos that has the same namespace as the rest of the standard functions. BTW, I'm unsure how packages, modules and classes roles interact with the type system and MMD. In particualr what can be put into the type slot of declarations/definitions: my SomeThing $x; Can SomeThing be a package? Ans if yes, what does it mean? -- TSa (Thomas Sandla)
Re: [Pugs] Closing a file handle surprised the heck out of me
On Tue, Mar 15, 2005 at 12:21:19AM +0800, Autrijus Tang wrote:
: On Mon, Mar 14, 2005 at 08:06:08AM -0800, Larry Wall wrote:
: On Mon, Mar 14, 2005 at 10:58:00PM +1100, Andrew Savige wrote:
: : my $fh = open(@ARGS[0]);
: : my @lines = =$fh;
: : $fh.close();
: : for @lines { print$_ }
: :
:
: Hmm. It's probably a design bug. I'm wondering if we have to specify
: that ordinary assignment not only copies logically but, in fact, always
: does ** flattening (immediate flattening) like Perl 5
:
: Except ** does not flatten recursively, so:
:
: my $lines = [ =$fh ];
:
: is still borked.
:
: Do we want a *** nuke everything flat semantic device, if not the
: operator? Or an eager context on the right hand side of =?
I don't like ***. As with in rules, at some point you bail out
and go alphabetic. So you might write that as
my $lines = [ $fh.slurp ]
That doesn't work so well for
my $lines = [ .slurp ]
though...
: On the other hand, we can alternatively specify that closing a
: file handle must force all thunks associated to it, i.e. in this
: case fill @lines with real data. Pugs can do that just fine, but I
: have no idea how parrot is to achieve that...
I think we have to recognize that close() is a very non-FP-ish
operation. It's essentially a kind of database commit, so that you
or someone else can reliable open the file and know what's going to
be there. (We've essentally got the same problem writing lazy lists
to a file.) So I guess the question is whether we can intuit the
intent of the programmer with the close. There's the I'm tired of
this filehande so close it logically but don't flush anything vs the
close this Right Now and flush everything Right Now and maybe even
fsync to disk to make jolly sure we're in a known state.
Since the earlier sentiment can be handled merely by letting the handle
go out of scope and get garbage collected someday, we probably have
to treat close as the more violent intention. So if we can autoflush
output, we can also autofill input, but probably only for iterators
that were used in list context. An iterator in scalar context expects
the close to truncate the rest of the input. A Perl 5 programmer
expects that
$foo = $input;
will stop working if you close $input, but will expect
@foo = $input;
to produce all the values as if it had been eagerly flattened, because
that's what list context means in Perl 5. In Perl 6, list context
merely means the promise of flattening, but in the case of
$foo = [ =$fh ];
it means we have to fulfill the promise when $fh is closed. It really is
a kind of COW situation, where close is construed as a write to the
effective length of the input. The situation doesn't apply to
$foo = [ 1... ];
because by default there's no handle to close on the infinite sequence.
Just as well, I suppose...
If we can capture the COW semantics, then we wouldn't necessarily have
to fix assignment, but it might be a good idea in any case to define
@foo = (bar())
as
@foo := [**bar()]
just to force programmers to make their eager/lazy intent clearer by
distinguishing = from :=. Then the fact that = also does a top-level
copy just sort of naturally falls out.
Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 09:52:06AM -0700, Luke Palmer wrote:
: Perhaps lists by assignment are COW lazy. So they behave just like
: ordinary COW objects, except they can be lazy at the end:
:
: my @a = gather {
: for 1... {
: say;
: take;
: }
: };
: @a[10]; # says 1 2 3 ... 10
: @a[5] = 42;
: @a[20]; # nothing printed
:
: I wonder if that's DingTRT though...
My feeling is that it prints
11 12 13 14 15 16 17 18 19 20
and then if you say [EMAIL PROTECTED] you'll get:
1 2 3 4 5 42 7 8 9 10 11 12 13 14 15 16 17 18 19 20
That is, once a value is generated, it's just an ordinary array value.
The generator is just attached at the end, and doesn't care what you
do with existing values.
On the other hand, maybe you have to use my @a := if we make = eager.
Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
The Principle of Maximum Differentiation of Similar Constructs also tends to argue for eager =. Plus there's the fact that it's the sort of restriction we can relax if we figure out how, but it would be hard to impose if people started to rely on lazy assignment and then we decided it was a bad idea. Larry
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 06:00:11PM +0100, Thomas Sandlaß wrote: : BTW, I'm unsure how packages, modules and classes roles interact with : the type system and MMD. In particualr what can be put into the type slot : of declarations/definitions: : : my SomeThing $x; : : Can SomeThing be a package? Ans if yes, what does it mean? Maybe it means that $x contains a Perl 5 style object, if not an actual Perl 5 object. Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
Larry Wall wrote: The Principle of Maximum Differentiation of Similar Constructs also tends to argue for eager =. Plus there's the fact that it's the sort of restriction we can relax if we figure out how, but it would be hard to impose if people started to rely on lazy assignment and then we decided it was a bad idea. Yep. Does that put =, := etc into a category of operators that are hard to (usefully) overload in classes? I mean the eager = doesn't look like letting the left and right hand side have much to do or decide in the process---other than provide and swallow the value or complain about not beeing able to due so. Regards, -- TSa (Thomas Sandlaß)
Re: [Pugs] Closing a file handle surprised the heck out of me
: Given this Pugs program, t.p6:
:
: my $fh = open(@ARGS[0]);
: my @lines = =$fh;
: $fh.close();
: for @lines { print$_ }
:
: running:
:
: pugs t.p6 t.p6
:
: produces no output. Move $fh.close() to after the for
: loop and all is well. Is this a bug?
I wonder if IO::All could provide some inspiration here? Not so much for
solving this specific bug - but making easy IO things easy and making file
handle funkiness hard?
Just a meme for the pool ...
Nige
Re: The S29 Functions Project
Larry Wall wrote: On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: : I ran into this problem while creating a mini-list of S29 functions : (which Rod's work supercedes, I suspect, and I'm very glad he's taking : this on). What are some guidelines we could use in deciding : which functions are automatically in ::* ? Or is this just a case : where we need to use past experience and best guesses as our guide? [snip] The upshot of all this is that, as you suspected, this is something we'll just have to work out as a community. What we can do right now is tell people not to be surprised when we move things around, and that we'll feel free to move things around until 6.0.0 is about to go golden. But maybe we could try to set some slushiness milestones on the road to hell freezing over... What I'm thinking of doing is creating a soft rule of: You can't declare a function into ::*. You have to create it elsewhere, and bind it in. Therefore, as I go through S29, I'll assign all functions to some module. I'll be using the P5/CPAN hierarchy as a strong guideline. We can then discuss what gets bound into ::*, and when, at some later point in time. -- Rod Adams
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 12:16:13PM -0600, Rod Adams wrote: : Therefore, as I go through S29, I'll assign all functions to some : module. I'll be using the P5/CPAN hierarchy as a strong guideline. : : We can then discuss what gets bound into ::*, and when, at some later : point in time. That's an excellent idea. We can encourage people to write the qualified name if they want to be future-proof past the 6.0.0 boundary. Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
On Mon, Mar 14, 2005 at 07:04:12PM +0100, Thomas Sandlaß wrote: : Yep. Does that put =, := etc into a category of operators that : are hard to (usefully) overload in classes? I mean the eager = : doesn't look like letting the left and right hand side have much : to do or decide in the process---other than provide and swallow : the value or complain about not beeing able to due so. I'd hazard a guess that it constrains the allowable signatures for such an operator. Larry
Re: [Pugs] Closing a file handle surprised the heck out of me
Larry Wall writes: The Principle of Maximum Differentiation of Similar Constructs also tends to argue for eager =. Plus there's the fact that it's the sort of restriction we can relax if we figure out how, but it would be hard to impose if people started to rely on lazy assignment and then we decided it was a bad idea. I use = as my no-thinking, catch-all assignment. I'd really like lazy lists to be pervasive enough that I don't have to think about them any differently than I think about any other kind of list. Making = lazy and making = eager both have the same disadvantage, but in different places. If we make = lazy, then people who don't think about lazy lists will use it in modules and whatnot, and it will (at best) die when they try to write them to files or print them or do other things that infinite lists can't really do. On the other hand, if we make = eager, then people who write modules who don't think about lazy lists will be denying the users of their module lazy access when it would be perfectly acceptable. And I can't decide which is worse. But I think the latter is worse. The former puts the decision of how to use lazy lists on the module user, where the latter puts the decision on the module author. Just like Cuse fatal, we want the user to call the shots, because they're the one who knows how the module fits with the rest of the program. I think that as long as lazy lists die when you do things that you can't do to them to them (sic.), and they die with a nice error message that says where they were created, that lazy assignment should be fine. We who write perl6 will have to work a little harder, but we know that from Perl's philosophy anyway. And by harder, I mean to make the close example work; to make a filehandle understand that it has lazy lists attached to it and to flush itself when necessary. Of course, there are dragons hiding in that too. If you tie a lazy list to a filehandle and only ever plan to use its first two elements, and you close the filehandle while the list is still in scope, then a 100 megabyte file will give you trouble you never asked for. Maybe it's best to let the array decide. There are some lazy lists which are healthy to throw around recklessly, like C1 There are others, like C , which have nasty ordering dependencies, and are best kept at the expression level and not assigned (only bound... but your ordering dependencies can bite you there, too). If arrays are lazy by default, that basically mean they're behaving as tied values (because you can do anything while you generate), and that we might as well outright remove the Cis tied optimization restriction. And then we should remove it for scalars and hashes too, and (please) let it propogate through assignment if it wants to. I've always wondered how much we could actually optimize if we know things aren't tied anyway Junctions already do tie-like things without being tied (even though it's the *value* which is doing those things). Whew... stop for a breath here... /ramble This is a hard problem. And it touches on a lot of my active concerns. For the time being, I'll buy your argument that it's easy to relax assigment to lazy, but hard to harden it up to eager. Luke
Re: Adding linear interpolation to an array
On Mon, Mar 14, 2005 at 04:15:35PM +0100, Thomas Sandlaß wrote: : Hmm, since what is compile to you is runtime for the compiler : it might by a normal store attempt that is then rejected by the object : and caught by the compiler---cool. Is there also an unchecked store : operation that can be used when the typechecker knows the assignment : is (type-)correct? I think any routine with a fancy signature with potential run-time checking also has an entry that assumes the checking was done by the caller or the compiler. The trick will be to discourage people from bypassing the necessary type checking when they think they know better but don't really. Larry
Re: Auto generated methods (was Re:The S29 Functions Project)
Leopold Toetsch wrote:
Rod Adams [EMAIL PROTECTED] wrote:
While that's a nice feature to have in general, I feel better about
going ahead and predefining that the builtins are already members of
Num, Str, Array, Hash for the shear performance and documentation values
of it.
That's exactly the plan, when it comes to Parrot. I'd like to have a lot
of function-like opcodes factored out into classes/*.pmc as methods.
Given:
pmclass P6Num extends Float { # the P6Num isa(Float)
...
}
pmclass Float {
METHOD cos() { ... } # return cosine of Float SELF
the method call in PIR can be written as:
d = x.cos() # normal method call
d = Float.cos(x) # class method, argument shifted down
d = P6Num.cos(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
This looks like it's taking
multi method Num::cos (Num|Str +$base) returns Num
and generating
multi sub cos (Num $x, Num|Str +$base) returns Num
Which I believe is the opposite direction of what Larry was doing, and
doesn't seem to address the $_ issue.
Part of me wants get rid of all the C ?$x = $CALLER::_ 's and tell
people if they want to use $_, they need to say C .cos . Then the
other part of me turns around and beats up the part that thought that.
The other issue in my head is
multi sub split (Rule $r, Str $s, Num +$limit) returns List of Str
I would want the following to be implied from it:
multi method Rule::split (Str $s, Num +$limit) returns List of Str
multi method Str::split (Rule $r, Num +$limit) returns List of Str
So what I'm thinking of for a solution is to have a
my Foo $bar;
$bar.baz;
call that gets past all the Foo AUTOMETHs is to then scan all the subs
in scope named baz, find the one with a required parameter of type most
compatible to Foo, ties being broken by appearing earlier on the
parameter list, and use that parameter as the invocant.
-- Rod Adams
Exists and Delete
How am I supposed to define a signature that says A scalar that refers to a hash or array element, but do not evaluate or autovivify the element? Or are these two are now strictly methods without functional forms? -- Rod Adams
Referencing a caller's slurpy array.
A06 says: If you |shift| or |pop| without an argument, it shifts or pops whatever slurpy array is in scope. Shall we assume that @_ is always an alias for this array, so I can say something like: multi sub pop (Array [EMAIL PROTECTED] = @caller::_) returns Scalar ? btw, is ?@ legal in a signature? It's not specifically mentioned in A/S04, but it makes sense it would be allowed along with ?%. -- Rod Adams
