Re: Access to the perl6 parser

2000-08-29 Thread Damian Conway
Regardless, you can already do this in perl 5, and will undoubtedly be able to do it in perl 6, with source filters. (If Damian can write perl that looks like Latin or Klingon, then python ought to be simple... :) I have a module (Language::Pythonesque) on that... :-) Damian

Re: Access to the perl6 parser

2000-08-29 Thread Damian Conway
Damian Conway wrote: Regardless, you can already do this in perl 5, and will undoubtedly be able to do it in perl 6, with source filters. (If Damian can write perl that looks like Latin or Klingon, then python ought to be simple... :) I

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

2000-09-10 Thread Damian Conway
I *still* think it should be "unmerge"! ;-) Damian

Re: RFC 225 (v1) Data: Superpositions

2000-09-14 Thread Damian Conway
Do any() and all() have some magic around how they are implemented in von Neumann computers that make them faster than standard CS searching techniques? I'm probably naive here but shortcuts in a non-parallelized (classical) implementation rely on the usual

RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

2000-08-28 Thread Damian Conway
(Or, was it already intended that the implementation of 'use invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. The use invocant was proposed as a way to

RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

2000-08-28 Thread Damian Conway
What I meant to say was more along the lines of "if this could be done as a macro, does it need to be a pragma, or could it be part of a standard macro package?" And, secondly, "if this *is* part of a standard macro package, wouldn't it be cool to let it shove arbitrary

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

2000-08-28 Thread Damian Conway
The use invocant was proposed as a way to maintain backwards compatibility and yet give everyone the invocant access syntax he or she personally favours. ...while also giving the compiler enough information to allow such invocant access to execute in an optimized

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )

2000-08-28 Thread Damian Conway
I was talking about the hypothetical situation where you're (re)using or modifying a bunch of code or classes written by different people and you constantly have to be aware of which self-thingie to use in which file or package or whatever. Yeah, you can just glance up to the use

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

2000-09-01 Thread Damian Conway
What happens on reblessing? An excellent question, and one that has been exercising my mind for some time now. I have come to the conclusion that a reblessing must either: * invoke the old class's DESTROY(s) and then invoke the new class's SETUP(s), or * invoke

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-02 Thread Damian Conway
private $self-{data} = $derdata; should be $derdatum here? Yes. Thanks. Damian

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread Damian Conway
I'm still not totally convinced that its so horrid to make the File::LockAndKey DESTROY call $self-SUPER::DESTROY manually... Believe me, it is in a large, deep, and/or MI hierarchy! but it does break encapsulation. Exactly. If you can figure a way out of the dilema I

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers anddestructors

2000-09-02 Thread Damian Conway
The "multiple inheritance paths" one is good. I like that part a lot. But the rest makes me really nervous if there's no way to override or change it. There is. I'll try and get the Cuse delegation RFC out today. One thing nobody's brought up is this: What if you decide you

Re: RFC 189 (v1) Objects : Hierarchical calls to initializers and destructors

2000-09-02 Thread Damian Conway
Also, its not entirely clear why method chaining is desired only for constructor and destructors. What about every other method? Constructors and destructors are special. They're not about *doing* something; they're about *being* (or not being) something. A "doing" method *may* wish to

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-01 Thread Damian Conway
From [EMAIL PROTECTED] Sat Sep 2 08:16:14 2000 Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1]) by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id IAA21970 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 08:16:14 +1100 (EST) Received: from

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-04 Thread Damian Conway
Given that is happens when bless is called and that all other builtin methods are anmed after what is being called, not what it is being used for, then I would say that it should be called BLESS for consistancy reason. this may seem confusing because you are thinking of one

Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-04 Thread Damian Conway
Damian, I think it would be worth at least mentioning BLESS and REBLESS in an "Alternative Names" section in the RFC. Enough people have voiced concerns over this that I think these two are worth putting in there. As I mentioned in another message, I'll be doing that. Then

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-04 Thread Damian Conway
PRL One powerful application of delegation is as a replacement for PRL inheritance where the internals of a prospective base class are PRL inaccessible or inconvenient, or the base class was not designed PRL to be inherited and yet it must be. isn't this a HAS_A

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Damian Conway
Is this not just a module which creates the necessary subs in the calling package ? The catchall can be done with an AUTOLOAD sub. That's certainly how Class::Delegation is implemented. It isn't quite adequate however, because if you trigger the AUTOLOAD and it *fails* to delegate, you

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Damian Conway
When I see those empty arrayrefs, I think "delegate to *no* methods in those classes stored in attr3 and att4," rather than "delegate all method calls to those attributes." Just in the name of greater clarity, I might like to see something like URI suggested: attr3 =

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Damian Conway
When you want to turn off an inherited delegation in an ISA situation? Um, I don't think I understand the question. I'm confused by the question, too. Delegation is not inherited. Any module you inherit from you won't use for delegation, AFAIK. They're two different

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-05 Thread Damian Conway
mark the entire hash as non-autovivifying (except via future calls to Cprivate -- see below) This bothers me. Name an operation in perl that, when applied to a single element of an aggregate, affects all other elements of the aggregate (especially future, as-yet-unborn

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-06 Thread Damian Conway
print keys %hash, "\n"; exists $hash{key}{subkey}; print keys %hash, "\n"; Or did that get fixed when I wasn't looking? No, the - operator has not been changed to do lazy evaluation. That's not required. All that is necessary is for Cexists nodes in the op

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-06 Thread Damian Conway
Why can't we just apply the same warnings on hashes as we do on variables in Perl? Maybe a new lexical pragma: no autoviv; # any autovivification carps (not just # hashes) no autoviv 'HASH'; # no new

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-06 Thread Damian Conway
That seems reasonable--except that I don't believe exists() merits any special treatment. More specifically, I think all non-lvalue context use of - should be non-autoviv, whether exists or anything else. I agree entirely. In fact, I shall extend RFC 128 to allow

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Damian Conway
It may make sense to pass a leading argument to TIE which is the type of variable being tied. tie Some::Class $foo, @args; would produce: TIE('SCALAR', 'Some::Class', @args); Or, better still, pass a reference to the actual variable being tied.

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-10 Thread Damian Conway
Also notice that I suggested the TIE be called as a method, so that it can be inherited if necessary (maybe you had that idea already???) The tie *can* currently be inherited. Yes, I was aware. It's just that you wrote: tie Some::Class $foo, @args;

Re: Draft RFC: my Dog $spot is just an assertion

2000-09-12 Thread Damian Conway
Piers wrote: The behaviour of the my Dog $spot syntax should simply be an assertion of the invariant: (!defined($spot) || (ref($spot) $spot-isa('Dog))) (!defined($spot) || (ref($spot) $spot-isa('Dog'))) Otherwise, AMEN! Damian

Re: RFC 218 (v1) Cmy Dog $spot is just an assertion

2000-09-13 Thread Damian Conway
I was hoping Damian would be able to suggest a Perlish way of handling typechecking and polymorphism. If you mean static typechecking, then it is the natural enemy of polymorphism. Either you give up interface polymorphism (a grievous loss) or you give up static type-checking.

Re: RFC 218 (v1) Cmy Dog $spot is just an assertion

2000-09-14 Thread Damian Conway
Piers wrote: I'm kind of tempted to look at adding another pragma to go with 'use base' along the lines of: use implements 'Interface'; Which is almost entirely like Cuse base 'Interface' but with 'Interface' consisting of nothing but:

Re: RFC 189 (v2) Objects : Hierarchical calls to initializers and destructors

2000-09-14 Thread Damian Conway
=head2 The CBUILD method =head3 The CREBUILD method Hey! You left out the alternative names NEW / RENEW and BLESS / REBLESS that we all like! :-( Oops. You're correct. I will rectify that. Damian

Re: RFC - Interpolation of method calls

2000-09-18 Thread Damian Conway
my $weather = new Schwern::Example; print "Today's weather will be $weather-{temp} degrees and sunny."; print "And tomorrow we'll be expecting ", $weather-forecast; You are wicked and wrong to have broken inside and peeked at the implementation and then relied

Re: RFC 218 (v1) Cmy Dog $spot is just an assertion

2000-09-18 Thread Damian Conway
I'm not going to have time to produce an RFC on this in time for the cutoff point. (Which seems painfully soon tbh). I will be struggling to find the time too. I'll do my best. Damian

Re: RFC 188 (v2) Objects : Private keys and methods

2000-09-19 Thread Damian Conway
The problem with specifying them as attributes is that I do not believe there is any way (or even any proposed way) of applying attributes to a hash entrie or a hash slice, nor is there any way of *retrospectively* applying an attribute to a hash that has already been declared elsewhere. Damian

Re: RFC 254 (v1) Class Collections: Provide the ability to overload classes

2000-09-20 Thread Damian Conway
I haven't (and won't) have time to go into this in detail :-( I feel that this proposal is solving the wrong problem. The issue is that the original Forest and Frog (or DBI and DBI::st) classes are not *designed* for user-definable Frogs (DBI::st's). If that functionality is widely needed, the

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-20 Thread Damian Conway
Thanks for getting this RFC together, Piers. A few comments: * I suggest you remove my alternative C:must(Foo) suggestion. It's too ugly to live, inless you just want to use it as a scare tactic to encourage Larry to chose the Cinterface syntax instead ;-)

Re: RFC 254 (v1) Class Collections: Provide the ability to overload classes

2000-09-20 Thread Damian Conway
In all sincerity, your Lingua::Romana::Perligata module is a good example. Although not many people may desire to code perl in Latin, it is certainly conceivable that modules similar to Perligata may allow programming perl in a variety of languages native to the

Re: RFC 251 (v1) Interpolation of class method calls

2000-09-18 Thread Damian Conway
print "There are Dogs-num_dogs() species of dogs."; would interpolate as: print 'There are '.Dogs-num_dogs().' species of dogs.'; I suggest that the requirement be: print "There are Dogs::-num_dogs() species of dogs."; I.e. use the unambiguous form of

Re: RFC 265 (v1) Interface polymorphism considered lovely

2000-09-24 Thread Damian Conway
* There's also no need to distinguish Cuse base and Cuse interface, since you've previously distinguished them by keyword. I would suggest that either Cuse base be used for both types of inheritance, or else the definition of an interface specification just

Re: RFC 319 (v1) Transparently integrate Ctie

2000-09-26 Thread Damian Conway
Somewhat to my own surprise, I really like this RFC. My only disagreement is that I think it's a mistake to defer the call to TIEWHATEVER until the first access. It ought to be done when the typed variable is declared, so that it's easy to determine where a variable is tied. There is also the

Re: RFC 307 (v1) PRAYER - what gets said when you Cbless something

2000-09-25 Thread Damian Conway
RFC 189 covers this. Damian

Re: Stupid Newbie Question

2001-11-09 Thread Damian Conway
Schwern explained: Going away? No way, it's SPREADING! We might wind up with AUTOGLOB, too. http://dev.perl.org/rfc/324.pod Though it won't be called AUTOGLOB (globs *are* going away), and its semantics might be closer to those portrayed in:

Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching

2000-09-25 Thread Damian Conway
Wouldn't this interact rather badly with the /gc option (which also leaves Cpos set on failure)? This question arose because I was trying to work out how one would write a lexer with the new /z option, and it made my head ache ;-) As you can see from the example code, the program flow

Re: RFC 97 (v1) prototype-based method overloading

2000-08-15 Thread Damian Conway
Why would anyone want to select a different method based upon the arguments. Have you seen Class::Multimethods? This kind of despatch can be very useful. Of course, the existence of Class::Multimethods proves that it can be done already so there may be no need to put it

Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments

2000-08-18 Thread Damian Conway
An argument would be associated with a named parameter by prefixing it with a standard Perl label (i.e. an identifier-colon sequence). For example: @mapped = doublemap(args: @list, mapsub: ^a+^b); I persoanlly would prefer '=' to be used here instead of

Re: RFC 132 (v1) subroutines should be able to return an lvalue

2000-08-18 Thread Damian Conway
But why introduce a new keyword "lreturn"? What about something like this? sub foo { my $lvalue : lvalue; ... return $lvalue if want('LVALUE'); } Error proneness? (Is that a word?) It is now :-) Besides, context can't always

Re: RFC 132 (v1) subroutines should be able to return an lvalue

2000-08-18 Thread Damian Conway
Besides, context can't always tell: bar ( foo ); Should foo return a copy or an alias? want() obviously needs an additional parameter: how deep to go back in the call stack. Which begs also for a way to find out how deep is the call stack. That

Re: RFC 132 (v1) subroutines should be able to return an lvalue

2000-08-18 Thread Damian Conway
How about recursive calls to want(), similar to multiple $$$'s? if (want(want(want))) eq 'HASH' ) No, that's heading in the wrong direction (both figuratively and literally :-) Cwant with no arguments returns a list of valid contexts. Cwant with arguments expects a list of

Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes

2000-08-23 Thread Damian Conway
So if all I want to do is make sure that certain attributes are positive integers, I have to do this: [ admittedly ungainly solutions snipped ] I'd much prefer a solution where the positive-only logic was in a method belonging to the class, rather than being

Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes

2000-08-23 Thread Damian Conway
I would have assumed that a pre/post/invariant would not be used regularly, but rather under optional control. So this would lose that feature. The option is to opt out of preconditions, not opt in. Besides, I intend to propose an attribute that makes them un-opt-out-able: sub

Re: RFC 174 (v1) Parse Cfunc($obj, @args) as Cfunc $obj (@args)

2000-08-30 Thread Damian Conway
This whole thing is actually a deep and complicated imbroglio--as I know you, Damian, are aware. I don't know your ideas for untangling it. Sure you do: indirect objects MUST DIE! ;-) But I freely admit that's not a satisfactory solution. Meanwhile, thank-you for the masterly

Re: RFC 132 (v3) Subroutines should be able to return an lvalue

2000-08-31 Thread Damian Conway
I've been thinking about this for a couple days. The only problem I see is that this doesn't allow me to do this: $oldpath = $tree-path('L','R') = 'R'; @document = ($title, $junk, $r-xml_extract) = STDIN; I would still have to use some yeechy combination with

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Damian Conway
This proposal makes length() an un-prototypable (and therefore unoverridable). Do you have a proposal for how to handle that? Pray to Damian for a prototype that supports this? :-) If you'd been studying the holy writings properly, young Torkington, instead of those wicked

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Damian Conway
The only RFC on prototype extensions we have is Andy Wardley's #57. Except, of course for #128, which already covers it. ;-) Damian

Re: RFC 212 (v1) Make length(@array) work

2000-09-13 Thread Damian Conway
Who has time to read all the crap you write, Damian? :-) Indeed. ;-) Sorry I missed that one. Thanks for pointing it out. I've just submitted an updated version which will probably hit the archive in the next few hours. For those who can't wait, the latest versions of all my RFCs are

Re: RFC 238 (v1) length(@ary) deserves a warning

2000-09-15 Thread Damian Conway
I'm surprised there hasn't be a good overhaul of the prototyping system proposeed yet. What exactly didn't you like about RFC 128??? Damian

Re: RFC 238 (v1) length(@ary) deserves a warning

2000-09-15 Thread Damian Conway
What exactly didn't you like about RFC 128??? Ummm... the fact that its title doesn't match /proto/. My bad. In fact it proposes that "prototype" be banished as a term of reference. :-) Okay, its a proposal to overhaul prototyping, cool. But I don't see anything to

Re: RFC 23 (v5) Higher order functions

2000-09-19 Thread Damian Conway
Let me ask you: foo('a','b', 'c') Is 'b' the 1st parameter or the 2nd? This is the classical mistake of confusing indices and ordinals. The 1st argument is bound to the parameter whose index is [0], The 2nd argument is bound to the parameter whose index is [1], etc. So,

Re: RFC 23 (v5) Higher order functions

2000-09-23 Thread Damian Conway
DC ^1 means $_[1], NOT $_[0] [snip. Last message repeated too many times.] If you have to do that, that is a good argument to follow the 'natural' inclination. Not until $_[0] follows the natural inclination. Again, why insist on an index when it really is

Re: Object oriented Perl6?

2000-08-02 Thread Damian Conway
Also read Damien Conway's "Object Oriented Perl" if you want to go further. Unlike the famous title by Hesse, in this case that would be spelled DamiAn, actually. :-) Yes, I'm named after a leper, not the AntiChrist ;-) I think I can with safely predict that sixth

Re: RFC for recursive regexps

2000-08-02 Thread Damian Conway
In perl5, /(??{ $FOO })/ delays the interpolation of $FOO, so as to be able to have recursively defined regexps. Of course, that example might in itself be sufficient reason to completely redesign the regex syntax! Damian PS: I'll probably have a RFC on that issue

Re: RFC: Request For New Pragma: Implicit

2000-08-02 Thread Damian Conway
Let me reiterate my view of pragmas. They can warp the language any way you please, as long as they don't impact other modules. I wouldn't even mind if someone wrote a pragma that lets you program Perl in Latin. Now you're just being silly! ;-) Damianus

Re: named parameters

2000-08-03 Thread Damian Conway
Fair enough. If we were going to do it I would like to see it extend to: sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) { } Is there an RFC for this yet? If not, I think there needs to be. I think this would be really cool. I'll have a proposal out

Re: RFC: lexical variables made default (revised)

2000-08-03 Thread Damian Conway
However, I do think there's something to be said for a "quick-and-dirty" script out of the box that can distinguish between sub{} vars and other vars ala C: $user = 'nwiger'; sub whois { ($user) = @_;# different var # ... }

Re: New Group proposed: subs (was Re: named parameters)

2000-08-04 Thread Damian Conway
I also hope that sub func : method { my( $self, $foo, @bar ) = @_ ; blah ; } will become: sub func : method ( $foo, @bar ) { blah ; } (with $self automatically supplied) One of my many RFCs

Re: switch/case (c) vs. case (pascal)

2000-08-04 Thread Damian Conway
Please, please, *PLEASE* read through Damian's fine paper on this entire matter before rendering judgment. URL? http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt Damian

Re: New Group proposed: subs (was Re: named parameters)

2000-08-04 Thread Damian Conway
What about '$me'? It ties in nicely with 'my' (although perhaps for the wrong reasons), it's half as much typing as 'self' or 'this' and we get to annoy both sets of religious zealots at once. :-)= You took the words right out of my...err...fingers! Although, of course, it will

Re: switch/case (c) vs. case (pascal)

2000-08-04 Thread Damian Conway
Damian Conway wrote: http://www.csse.monash.edu.au/~damian/TPC/2000/switch/paper.txt Curried operators might be a nice way of generalizing the switch syntax. When we write: I'm just about to post an RFC proposing exactly that (albeit with a quite different syntax). Damian

Re: New Group proposed: subs (was Re: named parameters)

2000-08-04 Thread Damian Conway
One of my many RFCs will include a proposal for a $SELF variable along those lines. Why not allow for the choice of the name of self, perhaps through a pragma? use self = 'self'; use self = 'this'; or something along those lines -- since it's currently up

Re: Proposed sublist: flowcontrol

2000-08-04 Thread Damian Conway
i think damian's influence on perl6 is our real triple top secret weapon. This realization has hit me on the head really hard. My prediction is that Perl6 will have to be dual-credited. I doubt it: Lucifer doesn't get a by-line on the Bible. There's only one Larry.

Re: RFC 24 (v1) Semi-finite (lazy) lists

2000-08-04 Thread Damian Conway
From [EMAIL PROTECTED] Sat Aug 5 04:36:31 2000 Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id EAA20410 for [EMAIL PROTECTED]; Sat, 5 Aug 2000 04:36:31 +1000 (EST) Received: from

RE: RFC 22 (v1) Builtin switch statement

2000-08-04 Thread Damian Conway
Could a way be found to control the flow so that the next case (not always the one next in the order of the statment) could be executed? For example you have cases 1-10. You want all odd cases to also execute case 9 and the even cases to also execute case 10. So in case 3 you

Re: RFC 22 (v1) Builtin switch statement

2000-08-04 Thread Damian Conway
Does "goto odds" mean start evaluating all cases after the "odds:" label? Meaning that the below is equivalent to the above? I think this is what the original poster was asking; if not, I'd like to ask it! That's exactly what it means. switch ($val) {

Re: RFC 25 (v1) Multiway comparisons

2000-08-04 Thread Damian Conway
I suspect it already has a different meaning, based on operator precedence rules, left to right evaluation, etc., but I strongly doubt there is much use of it in that manner, and would encourage this redefinition to be used instead. It's currently an error (even if you redefine

Re: RFC 23 (v1) Higher order functions

2000-08-04 Thread Damian Conway
Thanks for the useful insights and pointers, Ken. Top stuff (as usual :-) I particularly liked the currying context and notions of explicitly marking curries. Obviously I'll need to de-jetlag a little more and run my brain over it again. However, implicit currying is so damn handy that I

Re: RFC 23 (v1) Higher order functions

2000-08-04 Thread Damian Conway
Unless I'm missing something here, you're not filling in the args correctly. I think you mean: $check = sub (;) { @_==0 ? __ 2 + __ * atan($pi/__) or die __ : @_==1 ? $_[0] 2 + __ * atan($pi/__) or die __ : @_==2 ? $_[0] 2 + $_[1] *

Re: RFC 24 (v1) Semi-finite (lazy) lists

2000-08-04 Thread Damian Conway
This RFC proposes that the right operand of a C.. operator may be omitted in a list context, producing a lazily evaluated semi-finite list. It is further proposed that operations on such lists also be carried out lazily. Why only the right operand? What's wrong with

Re: RFC 22 (v1) Builtin switch statement

2000-08-04 Thread Damian Conway
None of these perform more than one operation per pair of types. By doing the factoring, you are constraining the type and specific value of the left hand expression in your matching operation, limiting the set of operations that can be performed quite severely. [snip]

Re: RFC 22 (v1) Builtin switch statement

2000-08-05 Thread Damian Conway
Oh, the table thing. The switch statement is useful without learning the complete table so I don't think complexity is a big problem. People can learn what they need and ignore the rest. I agree with you that it might be nice to have an array membership operator (like "in") so

Re: RFC 37 (v1) Positional Return Lists Considered Harmf

2000-08-05 Thread Damian Conway
=head1 TITLE Positional Return Lists Considered Harmful The solution is simple: return hashes instead of lists. Yes, one still has to know how the fields are named, so the proposed solution is still not perfect. I *fully* support this idea. A suggestion though:

Re: Deep copy

2000-08-06 Thread Damian Conway
Another one for my wish list: deep copying support built in. A devil inside me thinks this should be a new assignment operator. Damian? Sounds like this is up your alley. I want to do a sanity check before taking up RFC space. Regardless of how this looks, it has

Re: Deep copy

2000-08-06 Thread Damian Conway
I *really* like this idea. There should also be a default CLONE for the majority of classes that just want ordinary deep copying on whatever object representation they're using. UNIVERSAL::CLONE. Damian

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

2000-08-06 Thread Damian Conway
I think I opened a bigger can of worms than I intended :-) As MJD as pointed out to me in private email, if we are serious about this feature, we probably want to go the whole hog and look at Haskell's notion of list comprehensions. See http://www.haskell.org/tutorial/goodies.html

Re: RFC 23 (v1) Higher order functions

2000-08-06 Thread Damian Conway
$root-traverse( $sum += __ ); There's a syntactic ambiguity here. I assumed that __ "poisons" an expression so that an entire parse tree gets transformed into a closure. If you isolate the parse tree based on expression precedence, then I'm not sure why the

Re: RFC 37 (v2) Positional Return Lists Considered Harmf

2000-08-05 Thread Damian Conway
The solution is simple: return hashes instead of lists. I still think returning lists *or* hashrefs according to context gives the same benefits *plus* backwards compatibility. Damian

Re: RFC 49 (v1) Objects should have builtin string SCALA

2000-08-06 Thread Damian Conway
STRINGIFY would have my vote. "It's a string!!!". A string is a very specific subtype of scalar. How about TO_STRING? Little less geeky. AS_STRING. It doesn't convert, it translate. Or just STRING. It's a verb to, you know ;-) How would this play with overload.pm? What

Re: RFC 23 (v1) Higher order functions

2000-08-06 Thread Damian Conway
But the expression __ 2 + __ * sin(__ / 2) or die __ curries to sub { $_[0] 2 + $_[1] * sin(sub { $_[0] / 2 }) or die $_[2] } That's very odd. No. You got it exactly right. :-) I really hope I'm missing something, but __ the way you use it

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-06 Thread Damian Conway
Okay. I'll rework the proposal with the consensus syntax. Damian

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-06 Thread Damian Conway
I concur with Mike. If we *have* to have a prefix (and I *still* prefer a naked __, gumble, grumble, pout), then I'd certainly rather ^ that . What we *really* need are some more types of brackets: $range = Ç__È ÇvalÈ ÇvalÈ Ç__È; ;-) Damian

Re: Language RFC Summary 4th August 2000

2000-08-04 Thread Damian Conway
It definitely is, since formats do things that can't be done in modules. Such as??? Well, the easy binding of variables for later use. When one declares a format, variables in it are saved for later use without needing refs. Formats are sort of like a quote

Re: Language RFC Summary 4th August 2000

2000-08-04 Thread Damian Conway
What I'm planning to RFC is a simple format() built-in (probably in a pragma) very similar to the form() subroutine described in: http://www.csse.monash.edu.au/~damian/TPC/2000/Autoformat/paper.html Damian

Re: Treating filehandles like strings

2000-08-07 Thread Damian Conway
...and as for matching regexen against streams, I have a more general proposal for matching against subroutines that should allow for that as a special case. Damian

Re: RFC 53 (v10) Built-ins: Merge and generalize Cindex

2000-08-07 Thread Damian Conway
Can anyone come up with a good example when you'd want to use both these parameters at the same time? Second "foo" after the last "bar": index $text, "foo", index($text,"bar",0,-1), 2); Damian

Re: RFC 54 (v1) Operators: Polymorphic comparisons

2000-08-07 Thread Damian Conway
This RFC proposes that numeric comparison operators default to stringwise comparison when both arguments are non-numeric strings. The problem with this, is that we're removing orthogonality from the language. ROTFL. Do we want to say: $num1 == $num2 works

Re: RFC 54 (v1) Operators: Polymorphic comparisons

2000-08-07 Thread Damian Conway
This seems to be adding a special case. (I.e. only if _both_ are non-numeric will it switch to a cmp operation.) Well, I'd prefer it to always switch, but I thought that might be argued against. Since, *this* is being argued against, maybe I'll extend my proposal :-) I currently

Re: Safer OO inheritance

2000-08-07 Thread Damian Conway
I'm more in favor of a mechanism that makes it easy to build field names from the package name, for those rare cases where you want scoped fields. There were discussions about this a couple of years ago on p5p. For example: package Foo; sub new { bless {

Re: RFC 53 (v10) Built-ins: Merge and generalize Cindex

2000-08-07 Thread Damian Conway
$last = index $string, $substring, -1, -1; # last occurence Err... shouldn't that be $last = index $string, $substring, 0, -1 # last occurrence $first = index $string, $substring, -1, -1 # first occurrence found

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-07 Thread Damian Conway
Anyway, There is at least one case where you need this true value: if the file accidently is empty (or equivalent). I've had that happen. A true value indicates that the file is indeed valid Perl. So is an empty file! :-) Damian

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-07 Thread Damian Conway
On Tue, 8 Aug 2000 06:44:00 +1000 (EST), Damian Conway wrote: A true value indicates that the file is indeed valid Perl. So is an empty file! :-) That is precisely the problem. You won't get a syntax error if this happens. Now, bringing

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-07 Thread Damian Conway
As for the regexp issue, just to clarify there's only one ambiguous case we need to work out that I can see: /.*^foo/; # ok But:/.*^foo/m; #ambiguous We could undo the ambiguity like so: /^{foo}/; # like ${foo} and @{foo} and %{foo} In fact,

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-07 Thread Damian Conway
And there's no argument about having anonymous, positional, and named placeholders in the redraft...? There's *always* arguments! ;-) Personally, if we have positional placeholders I don't see the need for named ones too. But I'm willing to be convinced. Damian

  1   2   3   4   5   6   7   8   9   10   >