Re: RFC 254 (v2) Class Collections: Provide the ability to overload classes
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Class Collections: Provide the ability to overload classes
>
> =head1 VERSION
>
> Maintainer: Greg Williams <[EMAIL PROTECTED]>
> Date: 17 Sep 2000
> Last Modified: 1 Oct 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 254
> Version: 2
> Status: Frozen
>
> =head1 ABSTRACT
>
> Currently, class methods can be overloaded through sub-classing. This
> functionality is perhaps the most compelling aspect object oriented
> programming offers. This mechanism allows one to extend the functionality
> of pre-existing code without significant copying or rewriting. However,
> there exists situations in which it is desirable not to extend methods, but
> entire classes.
>
> It is proposed that classes be able to be grouped into collections.
> Collections would have the ability to inherit from other collections just
> as classes inherit from other classes. A sub-collection would overload
> super-collection classes exactly like subclasses overload superclass
> methods.
Hmm... I'm really not keen on this idea. Not keen at all. And I can't
for the life of me see what's wrong with just making a factory method
(or factory class):
package Forest;
sub new {
my $class = shift;
my $location = shift;
my $frog = FrogFactory->appropriate_frog($location);
bless( { frog => $frog }, $class );
}
package FrogFactory;
my %local_breed = (
...
Nagano => 'Frog::Japanese',
...
);
sub appropriate_frog {
shift;
$local_breed{shift}->new();
}
Or even simply:
package Forest;
sub new {
my $class = shift;
my Frog $local_frog_class = shift || 'Frog';
my Frog $frog = $local_frog_class->new;
bless({ frog => $frog }, $class);
}
> I am unaware of any OO language that allows overloadable classes as
> described here, and have seen them described only once, but have run into
> many situations in which they would make sense. I suggest this as a
> solution to the problem described here for perl 6.
As far as I can see, the standard technique for this is either to use
Factory methods and/or interface polymorphism. After all, the Forest
class doesn't care *what* class its Frog is in, so long as it croaks
like a Frog. So don't have the Forest instantiate its frog directly.
(Or if it does have it instantiate only a default frog but allow
client code to pass a different frog in)
>
> =head1 IMPLEMENTATION
>
> Let it be said that I am not an internals person, nor do I claim to know
> enough about the current or planned perl internals to comment on this
> authoritatively. However, there are two areas of concern I am aware of to
> which an implementation of class collections must direct its attention:
>
> =over 4
>
> =item * Class Names Would No Longer Be Unique
>
> A namespace alone would no longer reference a unique stash, as many stashes
> might contain code and data for one namespace (such as 'Frog'). Therefore,
> a namespace and collection name pair would be needed to specify a unique
> stash.
This would be nasty.
> =item * Method Lookup
>
> Method lookups would need to examine the collection inheritance tree to
> determine which class (that is, in which collection) to dispatch method
> calls to.
So would this.
Seriously, the problem you refer to is already solved. Check out
Design Patterns for a whole host of ways of getting rid of 'tight'
coupling between classes.
--
Piers
Re: RFC 344 (v2) Elements of @_ should be read-only by default
On Mon, Oct 02, 2000 at 10:40:28AM +0100, Piers Cawley wrote: > Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > > Unprototyped subs should not be allowed to modify their callers' data > > simply by assigning to elements of the arg array. > > > > =head1 COMMENTS ON FREEZE > > > > This RFC generated no discussion in 3 days I missed reading it. My fault. > I'd just like to put in an 'ick' vote on this one. I might come up > with something a little longer and more reasoned later, but I'm > supposed to be writing shopping basket code. Possibly part of the ick might be that with the current implementation plus this, adding a prototype to foo to give sub foo($$); to allow pass-by-reference stops you calling foo @bar with a 2 element array. You'd now have to go &foo(@bar); which doesn't feel nice. Subroutine attributes instead? Default to current behaviour, use strict; and you have to specify (in some way, prototype, attribute...) whether each function has read-write or read-only @_? Nicholas Clark
Re: Expunge "use English" from Perl?
On Wed, 27 Sep 2000, Nathan Wiger wrote: > Yeah, I've never liked the _ syntax, I've always thought it was weird > (to say the least). I think grouping file tests would be much cleaner. As long as you are okay with having to restat for 'or' clauses. (There are work arounds, and supposedly 'this or that' is less common for file tests.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 303 (v1) Keep C, but make it work.
Alan Gutierrez <[EMAIL PROTECTED]> writes: > On 27 Sep 2000, Piers Cawley wrote: > > > Simon Cozens <[EMAIL PROTECTED]> writes: > > > > > On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote: > > > > Don't change "use less" to "use optimize". We don't > > > > need to ruin the cuteness. > > > > > > "use less 'rolled_loops';" sounds really weird. > > > > We obviously need to introduce a synonymous > > C for when we want to be grammatically > > correct. Or am I just being silly now? > > C< use less 'recursion' > sounds just find to me. > > The negation of C< use less 'rolled_loops' >, C< use more > 'unrolled_loops' >, does not sound very weird at all. Weren't we > planning on haveing a use more as an opposite of use less? If so, > let cuteness prevail! And this opens the door to stuff like C< no more 'rolled_loops' >. I'm not entirely sure that that would be a good thing. -- Piers
Re: RFC 344 (v2) Elements of @_ should be read-only by default
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Elements of @_ should be read-only by default > > =head1 VERSION > > Maintainer: John Tobey <[EMAIL PROTECTED]> > Date: 28 Sep 2000 > Last Modified: 1 Oct 2000 > Mailing List: [EMAIL PROTECTED] > Number: 344 > Version: 2 > Status: Frozen > > =head1 ABSTRACT > > Unprototyped subs should not be allowed to modify their callers' data > simply by assigning to elements of the arg array. > > =head1 COMMENTS ON FREEZE > > This RFC generated no discussion in 3 days I'd just like to put in an 'ick' vote on this one. I might come up with something a little longer and more reasoned later, but I'm supposed to be writing shopping basket code. -- Piers
Re: Undermining the Perl Language
On Sun, Oct 01, 2000 at 11:49:51AM -0700, Randal L. Schwartz wrote: > Please take your paranoia elsewhere. I think if you actually sat down > and had lunch with each of the parties involved, and those further out > but well-informed, you'd find a consistent view of reality that > doesn't match ANY of your delusions. Worked for me! -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."
Re: RFC 335 (v1) Class Methods Introspection: what methods does this object support?
[EMAIL PROTECTED] (Johan Vromans) writes: > Piers Cawley <[EMAIL PROTECTED]> writes: > > > Actually, I'd like to see something similar done to Universal::can > > my @methods = $class->can(pattern) > > where pattern is a perl pattern matching method names. For a full > list, use > > $class->can(); > > or > > $class->can(qr/./); That wasn't the similar thing I meant. I was talking about walking the @ISA tree. But having C work like that too would be neat. -- Piers
Re: RFC 265 (v3) Interface polymorphism considered lovely
David Grove <[EMAIL PROTECTED]> writes: > > Java is one language that springs to mind that uses interface > > polymorphism. Don't let this put you off -- if we must steal something > > from Java let's steal something good. > > Interface inheritance is probably the least dignified thing to steal > from Java. If we have true multiple inheritance, interfaces don't > apply. (As a C++ programmer, I've always had to consider the > interface OOP of Java and Delphi as flawed and incomplete. Whereas I've always thought of multiple inheritance as a complete pain in the arse in most cases. But then I started doing OO programming with Objective C on a NeXT which doesn't do multiple inheritance (or strict interface checking come to that). -- Piers
Re: RFC 331 (v2) Consolidate the $1 and C<\1> notations
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Consolidate the $1 and C<\1> notations I still say that this is a pointless change to scratch an itch that only exists for woolly thinkers. -- Piers
Re: RFC 326 (v1) Symbols, symbols everywhere
On 09/27/00 Ken Fox wrote:
> Dave Storrs wrote:
> > It isn't terribly clear to me either
>
> Well, he does give a couple references that would clear it up.
> X11 Atoms are well documented.
>
> > saying is that you can qs() a method name, get a "thingie" out, store the
> > thingine in a scalar, and then that scalar becomes a direct portal to the
> > method...somewhat like a coderef, but without a required deref.
>
> Actually it's more trivial than that. When you "intern" a symbol, you're
> adding a string-to-integer mapping to the compiler's symbol table. Whenever
> the compiler sees the string, it replaces it with the corresponding
> integer. (The type stays "symbol" though; I'm sort of mixing implementation
> and semantics.) Think of it like a compile-time hash for barewords.
Not only that: every time the compiler sees another symbol with the
same string representation, it uses the already created symbol, so
it doesn't use more memory.
A non-trivial program probably will use several packages (or binary
modules that use several packages, ie Gtk). Let's look at the DESTROY
method. Currently a string is malloc()ed (in the symbol table for
every package), so that takes 8 bytes for the string + the malloc
overhead (at least 4 bytes, probably 8 on 32 bit systems). This
doesn't consider other memory that could be saved using hash tables
optimized for symbols (ie integers instead of strings).
Repeat that for all the duplicated method names in a class hierarchy
and you'll easily gain several KB of memory.
As a bonus you'll get faster performance (as integer compare is
faster than a strcmp).
As for the possible uses in the language I should have used a
better example. Let's consider an XML/SGML file with all that
ugly tags and attributes we love (well, no!). An XML parser
loads the file and stores the tags and attributes names as
strings: a lot of tags appear many times in an XML file
leading to a huge memory consumption problem. Now, if the
parser could use symbols, the memory for a tag name would
be allocated only once (so it's also faster because it
doesn't call malloc() that often).
Walking the tree in your perl program you could use integer
comparison instead of string comparison.
use Benchmark;
$num1 = 10;
$num2 = 20;
$string1 = 'htmltag';
$string2 = 'htmltag';
$string3 = 'buffy';
timethese(1000, {
'number' => '$num1 == $num2',
'stringe' => '$string1 eq $string2', # worst case
'string' => '$string1 eq $string3', # best case: length differs
});
Gives:
Benchmark: timing 1000 iterations of number, string, stringe...
number: 4 wallclock secs ( 3.87 usr + 0.00 sys = 3.87 CPU)
string: 6 wallclock secs ( 4.28 usr + 0.01 sys = 4.29 CPU)
stringe: 7 wallclock secs ( 5.97 usr + 0.00 sys = 5.97 CPU)
In the internals using C the performance gains are way more than
the 30% average here.
So, both for internal use and as a language feature there are
advantages, implementation is easy. If no one shows a significant
drawback, it's a deal:-)
The only real problem I see is choosing the single character for
using symbols in the language. I suggested ^ or :, but * may work
as well if typeglobs go away.
Thanks,
lupus
--
Paolo Molaro, Open Source Developer, Linuxcare, Inc.
+39.049.8043411 tel, +39.049.8043412 fax
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
Re: A tentative list of vtable functions
> > > Don't forget bigrats.
> >
> > I'm not too familiar with the concept of rational numbers in a computing
> > complex. What's your definition of a (big)rat? Fixed point??
>
> bigint1 / bigint2. Possibly represented as a triad of bigints,
> bigint1 + bigint2 / bigint3.
I'm tempted to suggest that bigrats, like complex numbers, fall into
the category of 'only mostly compatible'.
ie
1 ($bigrat1 op $bigrat2) accurately gives $bigrat3
2 ($bigrat1 op [any numeric scalar that can be accurately extracted
using get_realn()]) accurately gives $bigrat3
3 ($bigrat1 op $daves_different_but_smaller_bigrat_implementation2)
gives a bigrat, but its accuracry depends on (2)
> Remember also abnormalities like NaN.
I think this depends largely on how we standardise the arbitrary
real represenation as retrieved by get_realn - if our format allows
NaN et al, then get_realn() on a Nan should get a NaN, otherwise an
exception should be thrown. Of course, get_intn() on a NaN should always
throw an exception.
>
> > IE should bigint_subtract(bigint1,bigint2)
> >
> > 1) always return a new bigint SV
> > 2) a bigint normally, but an int if it happens to know that its result
> >will fit in a standard int, or
> > 3) a bigint or an int depending on some as yet undefined external context?
> >
> > My own feeling is that it should just stick with (1) - if someone has some
> > code that uses bigints, the chances are that the results of bigint
expressions
> > are most likely to fed into further bigint expressions, so demoting
> > to int then promoting again would probably less efficient; also if
> > you're working with bigints in the first place, then I'd expect cases
> > where the result of an op fits in an IV would be the minority.
> > But never having worked with bigints myself, I could be speaking from
> > my derierre ;-)
>
> Likewise. But having such a reduction/collapsion code is very natural
> because we need to have the 'inverse' of that logic to know when to stop
> using ints and start using bigints;
Hmmm, 2**1000. raises some interesting issues.
Cureently the perl language itself has no builtin support for big numbers,
and all I have been proposing so far is an scheme for the numerical
part of the vtable API that in principle allows other people to write their
own large types which (mostly) interoperate with standard perl numeric types.
Also, the current Perl language has no general mechanism for telling an op
what type it should return, and I've sort of come to the conclusion that
it would hard/messy to do so.
Perl currently has the syntax
my Bigint $b = ...;
but that is a compiler hint that $b is a reference to an object of
type Bigint - not that $b is a scalar with vtable type bigint.
I had vaguely assumed that if someone wrote a Bigint scalar type, they would
also provide a perl-level constructor.
So,
$x = 2^1000;
would evaluate 2^1000 at compile time, and if it didnt fit into an NV
(or IV if 'use integer' is in effect), create a compile-time error.
The compiler has no way of knowing that you want a compile-type bigint
constant.
To do proper bigint arithmetic, you might do
use Bigint;
$x = bigint(2)^1000;
where bigint is a function imported from Bigint that returns a bigint scalar
(as opposed to a Bigint object ref).
This code would be evaluated as follows:
a standard SV with value 1000 is pushed on the stack.
a standard SV with value 2 is pushed on the stack
bigint is called, and returns a new SV of type bigint, with value 2.
This is pushed on the stack.
pp_exp is called. It examines its 2 args; then as defined by precison(),
the bigint is 'bigger' than the std scalar, so
bigint_power() is called.
This evaluates 2^1000 and returns the result to pp_exp as a new bigint SV.
pp_exp then pushes this value on the stack.
pp_assign is then called, whihc blows away the current contents of $x,
and relaces them with the return value from pp_exp.
Without language extensions, perl XS functions are essentially the only
way to create values of a user-defined type. As long as this remains the
case, it might be wise for ops not to 'degrade' their results.
For example,
$b1 = bigint(99);
$b2 = bigint(00);
$b3 = $b2 - $b1; # happens to be 99, but could just as easily be 10^100
$b4 = $b3 ^ 10;
In this case, $b3 *sometimes* gets downgraded a std int, which means that
*sometimes* the last line will die.
On the other hand, if ops never downgrade, there needs to be a manual
way of converting a bigint to a standard one for the odd occasion
when the programmer needs it. We could argue that it up to the author
of Bigint to provide a perl-level function that does this, eg
big2int(), whihc might be used a context like this:
if ($b >= 0 and $b < 2^32) {
freeze(big2int($b);
} else {
freeze($b);
}
(Of course a lot of the time, extracting the integer value from a bigint
would be automatic, eg
eg
Re: A tentative list of vtable functions
> $x = 2^1000; > > would evaluate 2^1000 at compile time, and if it didnt fit into an NV > (or IV if 'use integer' is in effect), create a compile-time error. For the record: I hate the current policy of defaulting to NVs for arithmetic ops. If I say '2' I do mean an IV of 2, not an NV of 2.000. Currently if I say $a = 2; $b = 3; $c = $a + $3; the $c will be an NV of of 5.000, or thereabouts, een while $a and $b are IVs. I think one should stay within one type/class of numbers for as long as possible. Similarly for literals: if I say $x = 10715086071862673209484250490600018105614048117055336074437503883703510511249361224931983788156958581275946729175531468251871452856923140435984577574698574803934567774824230985421074605062371141877954182153046474983581941267398767559165543946077062914571196477686542167660429831652624386837205668069376; I would prefer getting a bigint, not an NV. I am happy with requiring a use bigint; for this to happen, though. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: A tentative list of vtable functions
> For the record: I hate the current policy of defaulting to NVs for > arithmetic ops. If I say '2' I do mean an IV of 2, not an NV of > 2.000. Currently if I say > > $a = 2; > $b = 3; > $c = $a + $3; > > the $c will be an NV of of 5.000, or thereabouts, een > while $a and $b are IVs. I think one should stay within one > type/class of numbers for as long as possible. Assuming that the perl parser generated IV SVs rather than NVs for the 2 constants 2,3, then my scheme would handle this fine; the IV version of add() would be called, and an IV SB would result. However, my current scheme crashes and burns for the following: $a = 2; $b = 33; $c = $a ** $b; The way perl5 handles these cases is that $a + $b, $a * $b etc just silengly ignore any overlow and return an int, while $a ** $b appears to automatically upgrade to a float. My system currently says nothing about upgrades, although it would be faily simple to specifiy that certain standard int ops should automatically pass their args to the std real type if theres any change of overflow. > Similarly for literals: > if I say > > $x = 10715086071862673209484250490600018105614048117055336074437503883703510511249361 22493198378815695858127594672917553146825187145285692314043598457757469857480393 45677748242309854210746050623711418779541821530464749835819412673987675591655439 46077062914571196477686542167660429831652624386837205668069376; > > I would prefer getting a bigint, not an NV. I am happy with requiring a > > use bigint; > > for this to happen, though. I presume that with bigint in force, even $x = 2 would make $x a bigint? One way to implenment this is for there to be a vtable entry for each class called say from_string(), which would return an SV of its own type from a numeric literal. [ NB - I'm not clear whether conversion from a string like '2' to a constant SV value is performed - during parsing or execution. If necessary, replace the word 'parse' as appropriate below...] The parsing process would have a concept of 'who is responsible for parsing numeric literals in the current block' - ie a current pointer to someone's vtable. On startup this would point to vtable_standard_nv; 'use integer' would change it to vtable_standard_iv; 'use bigint' would change it to vtable_bigint etc. Then when a numeric literal needs converting to an SV, the current from_string() method is called.
RE: RFC 357 (v1) Perl should use XML for documentation instead of POD
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]] > > On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote: > > =head1 TITLE > > > > Perl should use XML for documentation instead of POD > > I'll just add my voice to the others. POD is more readable than XML. > As Nathan Wiger said, just read the HTML vs the POD for the RFCs. XML is not HTML. Someone could make DTD which defines XML elements using the pod =commands. Then again, if you're using XML, why not have it keep track of nested =head and get rid of =over and =back? Some arguments for XML: - Done right, it could be easier to write and maintain - Why make people learn pod, when everyone's learning XML? - Pod can be translated into XML and vice versa - Standard elements could be defined and utilized with the same or greater ease than pod for build and configuration. Module::Name 0.01 short description =head1 long description =head2 heading foo Type in some text here... Eliott P. Squibb Joe Blogg none Distributed under same terms as Perl define your own section blab here > But, why not suggest SDF instead of XML? SDF addresses most of POD's > deficiencies whill still retaining readability. (I don't have a URL > for SDF handy, but I'm sure a quick search on google.com would turn it > up) http://www.mincom.com/mtr/sdf/ Why change anything at all? POD is good enough. Sure, it requires a learning curve... but it is a small one. I'd never heard of SDF until you mentioned it, but there's the "everyone else is doing it" argument form XML. And XML/DocBook does look set to be the lingua franca documentation format. In the end, all that I'd like to see is the ability to churn out DocBook documentation from whatever intermediary notation is used. That doesn't require changing anything, just adding a new pod2docbook tool. So while I "like" the idea of adopting XML as an addition to POD... There's no driving need that it fulfills. Garrett
Re: RFC 346 (v2) Perl6's License Should be (GPL|Artistic-2.0)
On 2 Oct 2000 00:48:45 -, Perl6 RFC Librarian wrote: > Status: Frozen and >A copyright lawyer has I looked at this license yet. I sent it to Eben >Moglen, but he is very busy and hasn't been able to reply due to lack of >time. I hope we find some copyright lawyers to look it over pro-bono and >make sure it does what we want. I don't get it. One one hand, this note clearly marks the RFC as "preliminary". OTOH, the status is marked as "frozen", meaning that it can no longer change. The only reason for the existence of this conflict is in the 1 October deadline, and that eveything not frozen will be treated as retracted. Isn't this whole business just plain silly? -- Bart.
Re: A tentative list of vtable functions
> > version of add() would be called, and an IV SB would result. > > "The IV version of add()"? Beware of combinatorial explosion: > addII, addIU, addUI, addUU, addIN, addNI, addNN, addblahbah Ah, but you've forgotten the point of my orginal posting (back in prehistory ;-) where given 2 mixed args, the add() method associated with the 'biggest' arg (as determined by precison()) is called. if sv1 is an IV and sv2 is an NV, then adding them causes sv2->add(sv2,sv1,1) to be called, ie the NV version of add is run. Within this method, sv1->get_real(sv1) is called, which demands that the IV return an NV representation of itself. > > I presume that with bigint in force, even > > > > $x = 2 > > would make $x a bigint? > > Not necessarily. The tokenizer is able to tell the difference > It currently does this by using UVs if a positive IV wouldn't > be enough, and NVs if even a UV wouldn't be. 'use bigint' could > be a hint saying "don't go NV unless absolutely unavoidable", such > as "sin(2)". For division such as 2/3, NV could still be be default > unless a "use bigrat" is in effect. We start running into lots of problems here. First, the parser would need to know a fair bit about particular user-defined types that have been loaded in, on order to make clever interpretations of literals. Second, my scheme currenly has no general way for expresssions to be automatic upgraded when they fail to fit the current representation. So in use bigint; $x = 2_000_000_000; # $x is just an IV $y = $x ** $x; how does the IV version of exp() (which is the one that gets called, since both args are IV), know not to try this itself, but instead pass the whole job over to the bigint verson of exp()? Personally I think automatic upgrades whould be avoided as far as possible, except for built-in IV/UVs -> built-in NVs, to keep perl5 code happy.
Re: A tentative list of vtable functions
> >the $c will be an NV of of 5.000, or thereabouts, een > >while $a and $b are IVs. > > Note: integers have an exact representation in floating point. There is ...as long as they are [minint, maxint]. > no "thereabouts". It is exactly 5.000. Yeah, bad example. Yours is slightly better. I think I was thinking something like computations losing precision. > However, 0.2 + 0.3 is not exactly 0.5, because 0.2 and 0.3 are both > approximations. 0.5 has an exact representation in FP, as has 1/1024. > > Since FP calculations on modern processors are at least as fast as > integer calculations, there is hardly any reason to prefer integers to FP. ...if one is concerned only about speed. > Bigints, that's another matter. Yes, let's not sacrifice precision. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: A tentative list of vtable functions
> would need to know a fair bit about particular user-defined types that have > been loaded in, on order to make clever interpretations of literals. Precisely. Assume I want $a = 2 + 3i; to work... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: A tentative list of vtable functions
> > would need to know a fair bit about particular user-defined types that have > > been loaded in, on order to make clever interpretations of literals. > > Precisely. Assume I want > > $a = 2 + 3i; > > to work... Which I what I suggest we abandon attempts to make the parser do intellignet decisons on numeric liternal, and instead just grab all the characters that appear to make up thye string constant, and pass the whole lot to the from_string() method of the current defualt numeric type (as defined by use integer et al) to deal with. NB - there's no reason why the from_string method of complex number class couldnt have a private convention that 2 _'s separate out real and imaginary parts, eg use complex; my $c = 2__3; # 2 + 3i although this wouldnt work if both compnents were floats. So, I strongly suggest that when use xtype is in force, all numeric literals are created as type xtype, to avoid madness!
Re: RFC 308 (v1) Ban Perl hooks into regexes
> I'm trying to stick to a general philosophy of what's in a reg-ex, and I can
> almost justify assertions since as you say, \d, ^, $, (?=), etc are these
> very sort of things. I've been avoiding most of this discussion because
> it's been so odd, I can't believe they'll ultimately get accepted. Given
> the argument that it's unlikely that (?{code}) has been implemented in
> production, I can almost see changing it's symantics. From what I
> understand, the point would be to run some sort of perl-code and returned
> defined / undefined, where undefined forces a back-track.
>
The proposal that MJD and I were working on still has a lot of rough
edges, which may not be resolvable before the deadline. It proposes a
mechanism which allowed the programmer to set up a block in which the
flow of control was determined by the success or failure of statements
within the block.
Regex matches always determined whether flow would continue forward or
back up; arbitrary Perl code did whatever it did; and a special
function (which we called 'test' for the lack of a better name) allowed
the programmer to use true/false conditions to force backtracking as
required.
MJD has had to withdraw from the development of the RFC, and it is not
absolutely complete, but I'm still interested in trying to see if it
can be generalized sufficiently to be a useful extension to the
language.
--- Joe M.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, Oct 02, 2000 at 09:21:51AM -0700, Glenn Linderman wrote: > Indeed, this is the key problem with human use of XML. HTML was originally > simple enough to be human writable, its later, more powerful incarnations > start losing that (but you can always use a subset for simple things, and > XML never had human writable simplicity and never will. XML is intrinsically no more or less difficult to write than HTML. Comparing XML to HTML is pointless, however; they are not the same thing. Rather, compare XML to SGML, and specific XML DTDs (XHTML, for example) to HTML. XHTML is certainly no more difficult to write than plain HTML. The only real difference is that tags like become -- hardly a major difference. Indeed, I would consider the XHTML version to be a bit simpler to understand. - Damien
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, 2 Oct 2000 10:51:28 -0700, Damien Neil wrote: >> XML never had human writable simplicity and never will. > >XML is intrinsically no more or less difficult to write than HTML. The problem with XML is that it is so unforgiving; I think somebody already mentioned that. Improperly nested tags, or one character it doesn't recognize... and the parser says "nyet". -- Bart.
Re: RFC 331 (v2) Consolidate the $1 and C<\1> notations
On Sun, 1 Oct 2000, Bart Lateur wrote: > It's not clear to me why you picked @/ as the name for the array. For > mnemonic reasons, i.e. similarity with existing special variables, @& or > @+ (see $& and $+) would make more sense. Well, @+ is taken... Well, the main reason is that @/ worked best for my particular brain. If you want another reason...well, @+ is taken, as you say, and @& wouldn't be quite the right match...after all, $& contains the _string_ that was last matched, while @/ contains the pattern and all the subelements that matched, but does not actually contain the entire matched string (unless you explicitly capture it, of course). Dave
RE: RFC 349 (v1) Perl modules should be built with a Perl make program
These references should have made it into the RFC: cons http://www.dsmit.com/cons/ pmake http://www.cpan.org/modules/by-authors/id/N/NI/NI-S/Make-1.00.tar.gz Mark Leighton FisherThomson Consumer Electronics [EMAIL PROTECTED] Indianapolis, IN, USA "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
Re: RFC 326 (v1) Symbols, symbols everywhere
At 03:42 PM 10/2/00 +0200, Paolo Molaro wrote: >On 09/27/00 Ken Fox wrote: > > Dave Storrs wrote: > > > It isn't terribly clear to me either > > > > Well, he does give a couple references that would clear it up. > > X11 Atoms are well documented. > > > > > saying is that you can qs() a method name, get a "thingie" out, store the > > > thingine in a scalar, and then that scalar becomes a direct portal to the > > > method...somewhat like a coderef, but without a required deref. > > > > Actually it's more trivial than that. When you "intern" a symbol, you're > > adding a string-to-integer mapping to the compiler's symbol table. Whenever > > the compiler sees the string, it replaces it with the corresponding > > integer. (The type stays "symbol" though; I'm sort of mixing implementation > > and semantics.) Think of it like a compile-time hash for barewords. > >Not only that: every time the compiler sees another symbol with the >same string representation, it uses the already created symbol, so >it doesn't use more memory. Ah, I see what you're asking. Whether this sort of thing is user-visible is a separate issue (and one for -language). Personally I don't think it should be--there's reasonably little value at the user level. For the internals, though... This would be very useful, and it's a feature I'd really like to implement. Basically you're asking for pre-computed, indirect, shared hash keys. This sounds like a Good Plan to me. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 125 (v2) Components in the Perl Core Should Have Well-Defined APIs and Behavior
At 04:34 PM 9/29/00 -0400, John Porter wrote: >Dan Sugalski wrote: > > > > I've no experience with UML, though. Got a pointer to a quick overview? > >Without a doubt, "UML Distilled" is the bible of the genre. I'll have to go pick that up on Thursday and add it to the Darned Big Pile of books I need to read. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 335 (v1) Class Methods Introspection: what methods does this object support?
[Quoting Piers Cawley, on October 2 2000, 09:44, in "Re: RFC 335 (v1) Cla"] > > $class->can(qr/./); > > That wasn't the similar thing I meant. I was talking about walking the > @ISA tree. But having C work like that too would be neat. Exactly. 'can' walks the ISA tree searching for a name and returning a ref to the method if found. I seems straightforward to extend that to a pattern search, and return a list instead. -- Johan
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > I'll just add my voice to the others. POD is more readable than XML. Don't forget: more _writable_ as well. -- Johan
Re: RFC 125 (v2) Components in the Perl Core Should Have Well-Defined APIs and Behavior
"Peter Buckingham" <[EMAIL PROTECTED]> writes: > ... but it may be simpler than just doing everything from > scratch in xfig. Check Tgif (http://bourbon.cs.umd.edu:8001/tgif/). -- Johan
Re: RFC 136 (v3) Implementation of hash iterators
At 11:12 PM 9/30/00 +0200, Bart Lateur wrote: >On 28 Sep 2000 19:40:01 -, Perl6 RFC Librarian wrote: > > >=head2 How iterators might work in perl 6 > > > >In perl 6 the keys and values functions should no longer use the > >same iterator as the each function - each use of keys and values > >should use it's own private iterator instead. > >Is that per Damian? The iterator stored in the syntax tree? So, what >happens if there's a recursive function call, to a function containing >keys()? I'd rather not store the iterator in the optree or, if we do, make it lexically scoped. I'd actually *really* like to make iterators explicit objects all by themselves, but it's too much work for most uses of iterators... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: RFC 357 (v1) Perl should use XML for documentation instead of POD
From: Tom Christiansen [mailto:[EMAIL PROTECTED]] > > >- Done right, it could be easier to write and maintain > > Strongly disagree. Ok, you disagree. There are differing opinions here. Can we agree to disagree? Or must all people who believe XML is easier to write and maintain leave the room? Oh... and don't forget to mention or acknowledge areas where a common ground might be reached. Lets only focus on negative things shall we? Garrett Goebel wrote: > In the end, all that I'd like to see is the ability to > churn out DocBook documentation from whatever intermediary > notation is used. That doesn't require changing anything, > just adding a new pod2docbook tool. So while I "like" the > idea of adopting XML as an addition to POD... There's no > driving need that it fulfills. Before I was strongly in the "why bother" camp. Now I'm shifting toward the "why not let people chose?". The change of heart is probably an irrational response to hearing all dissenting opinions crapped on. Give me 24 hours and I'll probably be back to "why bother". Horror of horrors: why not support both? Long live: TMTOWTDI. If XML documentation fails to thrive, cut it from Perl 6.1. If both thrive, keep 'em. As everyone has said XML can be converted to pod and vice versa. Pod tools could be made to coexist with XML. The more militantly people state TIOMWTDI (There Is Only My Way To Do It), the more I hear the opinions of others in a postive light. I agreed and do agree that there is no driving need to support use of xml to annotate scripts. But to quote you out of context concerning your violent opposition to anything other than pod: > I guarantee you that you will drive people away with this crap. Tom Christiansen wrote: > >- Standard elements could be defined and utilized with the > > same or greater ease than pod for build and configuration. > > > [...] > > > > That is an excellent description of why THIS IS COMPLETE > MADNESS. Being able to parse for well-definedness, DTD validation, and schema constraints are postive things. Also, I imagine it'd be easier for xml to grow to meet future unforeseen needs. I find debugging pod to be a nuisance and the error messages to be vague and unhelpful. Then again, pod is so darn easy it doesn't talk long to debug anyway. Just because XML wouldn't win any contests for brevity or beauty doesn't qualify it for being commited to a sanitarium. Garrett
Re: data storage and representation when designing bytecode (and VM)
At 07:21 AM 10/2/00 -0500, Jarkko Hietaniemi wrote:
>[random thoughts I had one week ago at YAPC::Europe and am jotting down now;
> was unsubscribed from the p6 lists during that time, awfully sorry if this
> subject has already been beaten to death]
We haven't touched this yet. Bytecode's on the list of things to get beaten
to death soon. (I hope, otherwise folks will have to make do with what I
plan on... :)
>When designing the bytecode of Perl 6 special care and planning should
>be directed towards data storage and representation. In more concrete
>terms, we should have bytecodes for example for
>
> newpvn
> newiv
> newuv
> newnv
> newav
> newhv
> newrv
>
>(using perl5ish terms like pv here just for the sake of clarity;
>whether those terms carry over to perl6 remains to be seen). The
>above list is not complete and it is there just for the sake of
>discussion.
Absolutely, yes. And the bytecode for the variables also needs to encode
attributes, name, and scope.
>Having such bytecodes available is essential for the proposed
>functionality of dumping the state of a live and running Perl virtual
>machine and breathing life into that later.
Or bits of it. Can't serialize objects without being able to do that...
>The knowledge gathered from writing the modules Storable,
>Freeze::Thaw, and Data::Dumper, should be studied very carefully.
>Of course also the other bytecodes like JVM, Emacs Elisp, and so on,
>should be researched. For example, have there been any backwards
>incompatible format changes? If so, why? What forced that change
>and how can we try to avoid such embarrassments?
Yep, that's something to investigate. I'd like to encode the bytecode
version at the head of any bytecode stream. There's also been a request for
creator tags in the bytecode. ('Creator' here being the version/tag of the
lexer&parser, bytecode creator, and optimizer)
>The data created by the bytecode should be stored in a binary format
>for speed and compactness. (At least so far) Perl's approach to data
>portability issues like integer width, character encoding, and
>floating point format has been 'do the what comes naturally for the
>current runtime platform', as opposed to Java's strict specification
>that e.g. an int is 32 bits, and floats are IEEE 32-bit. There are
>benefits to this approach, but I think it's wrong.
I agree, platform native is a good idea generally, as long as we have some
means of indicating how the platform encodes the data. The bytecode needs
to be transportable across platforms--I want the same bytecode to be able
to run on a VAX, x86, Alpha, and PowerPC box.
Also, transportable floats are rather problematic. It's one thing to tag an
integer with size and endianness. It's rather another to deal with floating
point formats. I have at least six available to me on my Alpha box, and who
knows how many elsewhere. I'd rather not have to have code to deal with all
of them in everyone's perl. (Of course, I'm not sure what the alternative
is...)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC 136 (v3) Implementation of hash iterators
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> I'd rather not store the iterator in the optree or, if we do, make DS> it lexically scoped. I'd actually *really* like to make iterators DS> explicit objects all by themselves, but it's too much work for DS> most uses of iterators... that brings up a thought. most (%90+ ?) cases hash iteration would work fine with the setup we have now. so leave it as is. but for the coder who needs finer control, let them have explicit iterator objects. we can even make those objects iterate over other stuff as well (like some other languages support). now we still have the problem of designing a clean iterator object that will work with perl hashes. the usual questions arise: what happens if you modify the hash during the iteration? where is the state of iteration stored (in the object most likely)? how can the iterator state be accessed/managed? uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: data storage and representation when designing bytecode (and VM)
On Mon, Oct 02, 2000 at 04:35:29PM -0400, Dan Sugalski wrote: > I agree, platform native is a good idea generally, as long as we have some > means of indicating how the platform encodes the data. The bytecode needs > to be transportable across platforms--I want the same bytecode to be able > to run on a VAX, x86, Alpha, and PowerPC box. > > Also, transportable floats are rather problematic. It's one thing to tag an > integer with size and endianness. It's rather another to deal with floating > point formats. I have at least six available to me on my Alpha box, and who > knows how many elsewhere. I'd rather not have to have code to deal with all > of them in everyone's perl. (Of course, I'm not sure what the alternative > is...) Benjamin Stuhl (I think) for perl bytecode as of ByteLoader 0.04 decided that the best thing to deal with this sort of intra-platform incompatibility was to store floats as ASCII strings. If there's a way of tagging what is "native" format of float, and hence reader knowing whether writer's format is the same, one possibility could be to write out native & ASCII Then reader can fall back to parsing in the ASCII if the binary isn't edible. Nicholas Clark
RE: RFC 357 (v1) Perl should use XML for documentation instead of POD
Garrett Goebel (Today): > Horror of horrors: why not support both? Long live: TMTOWTDI. If XML > documentation fails to thrive, cut it from Perl 6.1. If both thrive, keep > 'em. As everyone has said XML can be converted to pod and vice versa. Pod > tools could be made to coexist with XML. But why extend the syntax for such a niche application? * POD can be easily converted to XML. * POD can contain XML. * Advanced concepts that POD cannot contain that the XML junkies might want to be used can be embedded. (=for XML) An interested party could easily write another pod2* that did the job using the XML-specific sections. (podxml2man, maybe?) I'm struggling to see; is there anything here we can't already do? ~ j.
Re: RFC 331 (v2) Consolidate the $1 and C<\1> notations
On Mon, 2 Oct 2000 12:46:06 -0700 (PDT), Dave Storrs wrote: > Well, the main reason is that @/ worked best for my particular >brain. But you cannot use it in an ordinary regex, can you? There's no way you can put $/[1] between slashes in s/.../.../. BAckslashing it doesn't work. >@& >wouldn't be quite the right match...after all, $& contains the _string_ >that was last matched, while @/ contains the pattern and all the >subelements that matched, but does not actually contain the entire matched >string (unless you explicitly capture it, of course). No, but it's closer. $& is closer in meaning to $1 than is, for example, $/. *Much* closer. -- Bart.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, Oct 02, 2000 at 02:44:56PM -0600, John Barnette wrote: > But why extend the syntax for such a niche application? > > * POD can be easily converted to XML. > * POD can contain XML. > * Advanced concepts that POD cannot contain that the XML junkies > might want to be used can be embedded. (=for XML) Now, if I could use POD to get the job done more lazily, but switch to XML if I needed something more than pod can do (tables more sophisticated than can be tersely expressed in monospace ASCII being the only one so far) then I'd be happy. Oh, and my code would be more likely to be documented full stop than if I had to fight XML. I speak only for myself here. (oh, and my boss, who thought the same) Nicholas Clark
RE: RFC 357 (v1) Perl should use XML for documentation instead of POD
> > same or greater ease than pod for build and configuration. > > > > > > [...] > > > > > > > That is an excellent description of why THIS IS COMPLETE > > MADNESS. Maybe I'm reading too much into the comment, but I thought the big deal was that the example given was not only verbose, but wouldn't parse correctly: (from the section you elided:) > > > Eliott P. Squibb > > > Joe Blogg Whoops. We need a tag there. > Just because XML wouldn't win any contests for brevity or beauty doesn't > qualify it for being commited to a sanitarium. True. And the fact that the example wasn't written properly isn't a conclusive proof that it's not easy to do. But it isn't exactly an encouraging sign, either. Dirk P.S. Isn't this all supposed to be done, now?
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On 10/2/00 4:44 PM, John Barnette wrote: > * Advanced concepts that POD cannot contain that the XML junkies > might want to be used can be embedded. (=for XML) Yeah, but then you get =for HTML, =for XML, =for 3DHOLOGRAM, whatever. No one does that because no one wants to make 50 versions of the table they have in their docs, one for each document type they happen to be able to think of at the moment. The do it in ASCII art an are done with it because they realize the futility of making 5 different versions. POD is supposed to be the common format that can be transformed into other representations. Instead, you have to add the different representations yourself if you do anything remotely complex. People are looking for POD alternatives because doing complex things in POD is so hard and/or annoying. And those that do add neat little =for HTML bits so their docs look nice in pod2html or whatever are basically pigeonholing themselves in the land of HTML. What everyone wants here is some standard format that is rich enough to be converted to anything: a format that can handle complex items like tables and hyperlinks and embedded images and all that good stuff. "It can be done" in POD, but there are so many varying ways to do it that it creates a barrier to users. So people stick to Plain Old POD, sans fancy =for business, 90% of the time. XML is probably not the answer, but I really do think POD needs to evolve along with the rest of Perl. -John
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote: >> Improperly nested tags, or one character it >> doesn't recognize... and the parser says "nyet". > >I read that as "the machine will tell me when I messed up". > >I'd rather have a machine tell me than have to figure it >out myself. I think I claim some of the Good Laziness there :-) That's not my experience with XML::Parser. It gives some weird error message, mentions a line number and a column number that doesn't even exist... and that's it. It's not very helpful. You usually don't even get any output so you can see where and how you messed up. It's the same Good Laziness that tells me it's no good. -- Bart.
RE: RFC 357 (v1) Perl should use XML for documentation instead of POD
From: Myers, Dirk [mailto:[EMAIL PROTECTED]] > > Maybe I'm reading too much into the comment, but I thought > the big deal was that the example given was not only > verbose, but wouldn't parse correctly: > > (from the section you elided:) > > > > > Eliott P. Squibb > > > > Joe Blogg > > Whoops. We need a tag there. Yes, and it'd be patently obvious to the parser where the problem is and easier to generate a specific and meaningful warnings to boot. Not to mention if you use a gui editor incorporated color coding, it'd be easier to read and see errors. Emacs cPerl doesn't handle pod very well... anyone know why that is? > True. And the fact that the example wasn't written properly isn't a > conclusive proof that it's not easy to do. But it isn't exactly an > encouraging sign, either. Can you see the problematic extra space here? No... I didn't think so... =pod =head1 Header =cut
Re: data storage and representation when designing bytecode (and VM)
> Yep, that's something to investigate. I'd like to encode the bytecode > version at the head of any bytecode stream. There's also been a request for This version info could quite naturally live in my proposed 'declaration block' or 'bytecode header'. > I agree, platform native is a good idea generally, as long as we have some > means of indicating how the platform encodes the data. The bytecode needs > to be transportable across platforms--I want the same bytecode to be able > to run on a VAX, x86, Alpha, and PowerPC box. I agree on your agreement. > Also, transportable floats are rather problematic. It's one thing to tag an > integer with size and endianness. It's rather another to deal with floating > point formats. I have at least six available to me on my Alpha box, and who > knows how many elsewhere. I'd rather not have to have code to deal with all Ouch, too true... -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD
>XML, on the other hand, uses & as the escaping mechanism, helping >a reader sort-out deeply-nested escapings. ... >POD has a good advantage in that it's design allows for it to >embed well into code. If documentation is to be alongside >code, a direction to consider is to have the Perl >program be an XML document itself, with the code inside of it, >between designated tags. This would allow for the entire >Perl program/document to be rendered in a unified manner, using >one tool, and conforming to one meta-language, XML. By making a Perl program an XML document, the programmer is forced to read the XML. It should be noted that XML isn't supposed to be read by a person - it is meant to be read by a computer. The W3C document "XML in 10 points" states this as point three. From http://www.w3.org/XML/1999/XML-in-10-points : >XML files are text files, as I said above, but even less than HTML >are they meant to be read by humans. They are text files, because >that allows experts (such as programmers) to more easily debug >applications, and in emergencies, they can use a simple text editor >to fix a broken XML file. .greg -- Greg Williams| If you wish to live a life free from sorrow, Cnation | think of what is going to happen as if it had [EMAIL PROTECTED] | already happened.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, Oct 02, 2000 at 10:59:46PM +0200, Bart Lateur wrote:
> On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote:
>
> >> Improperly nested tags, or one character it
> >> doesn't recognize... and the parser says "nyet".
> >
> >I read that as "the machine will tell me when I messed up".
> >
> >I'd rather have a machine tell me than have to figure it
> >out myself. I think I claim some of the Good Laziness there :-)
>
> That's not my experience with XML::Parser. It gives some weird error
> message, mentions a line number and a column number that doesn't even
> exist... and that's it. It's not very helpful. You usually don't even
> get any output so you can see where and how you messed up.
>
> It's the same Good Laziness that tells me it's no good.
That is a deficiency in XML::Parser (a tool) not with XML.
I find that nsgmls (with an XMLified SGML Declaration) does
a good job. I always check XML data with nsgmls first.
(nsgmls is an SGML parser, not a XML parser, but I've never
come across bad XML that it lets by...
)
XML::Parser gives bad messages, so XML is bad.
The Blue Screen Of Death is bad, so computers are bad?
[ Puhleeeze don't think that I am defending XML over POD. I am
firmly in the POD camp. So many others are in that camp, that
I just haven't added my Me too! ('til now :-)
]
--
Tad McClellan SGML consulting
[EMAIL PROTECTED] Perl programming
Fort Worth, Texas
Re: RFC 136 (v3) Implementation of hash iterators
In message <20001002221632$[EMAIL PROTECTED]> Uri Guttman <[EMAIL PROTECTED]> wrote: > hmm, that means 'next' does a lookup based on the key passed > in. currently next uses the iterator state which is much faster. i think > next should be faster than a regular lookup but the semantics don't > specify that. your idea still fails when the hash gets modified during > iteration (does any iterator survive munging during iteration? other > than full copies?) It's possible to design an iterator such that it freezes state by copying (possibly only on demand) but other than that it is difficult to give guarantees that changing the data structure won't damage active iterators. Some data structures (eg balanced trees) are better than some others (eg hash tables) in this regard but they all have prolems with at least some changes. I do agree with you though that having to do a lookup on the old key for each next could be horribly expensive, especially for a tied hash where you might have to do a database lookup or something. > i agree. but we all seem to want better than we have now. i think > stateful is good but probably only in external iterators. just having > that will solve most of the iterator problems we see. munging during > iteration is bad in general and should be forbidden. > > so to recap my previous letter, let's keep one stateful iterator > attached to the hash, and support external (stateful?) iterators on > demand. other than munging during iteration, IMO that solves most (%99+ > ?) of the iteration issues. I fully agree that the current one iterator per hash situation is not a major issue from the point of view of explicit iterator use by the user, but I see iterators as a possible way of implementing many internal things related to lazy evaluation and such like in an efficient way so I think it's quite important to provide for a general system of iterators with multiple iterators per data structure. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...There is very little future in being right when your boss is wrong.
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
> >However, making it a UNIVERSAL method also dictates that this:
> >
> >my SomeType @a :someattr;
> >
> >*must* be either:
> >
> >1. a builtin type
> >2. tied
> >
> >To get its attributes back out. I'm not sure this is going to always be
> >true.
>
> It must be my sinuses. I don't get that at all. Firstly, @a can't be tied
> before that statement since you only just declared it; the tie would have
> to follow. Secondly, if the declaration declares @a as belonging to class
> SomeType, then unless SomeType.pm is perverse enough to override the
> attributes() method, why won't @a->attributes go through to
> UNIVERSAL? Whether or not SomeType is builtin?
>
> Or are we talking apples and oranges and the above declaration is intended
> to declare that any *member* of @a is of SomeType, never mind the array
> itself?
Yes, I think that second sentence hits the point. Currently, there's
ambiguity as to whether or not a type declaration on an array/hash means
to be applied element-wise or whole-component-wise.
If it's the latter, then there's no problem. And I suspect that's how
we'd want it to play out. I was just raising the concern that with the
current ambiguous non-definition of types (it's "conceptware" at this
point :), it could mean either one.
I pushed a lot of these issues in RFC 319 and 337, which would let you
say something like:
my Pet @pets :mean; # integrated implicit tie
@pets->attributes('mean') # "true", like 'can'
Although, if we got verb tenses right I'd really like that to be:
$spot->has('meanness');
:-)
-Nate
Re: RFC 136 (v3) Implementation of hash iterators
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Also, don't assume that the key passed in is just a string. It could well
> be a string/hashval pair, or a string/hashval/magic triple, and we use the
> fast method with the others as fallbacks.
In other words, it's just a generic iterator state object... The
way I'd like to see things work is that hashes, arrays etc have a
vtable method that returns an iterator object. That iterator object
then has whatever opaque data is needed to maintain position plus
it's own vtable that can advance the iterator, return the current
value, etc. So we get something like this:
it = hv->new_it()
while (it->valid())
{
sv = it->value();
...
it->next();
}
Whether we choose to expose this internal behaviour by allowing
multiple iterators at the language level is, to me, a completely
separate issue.
If iterators are (internally) first class objects like this then
they can be used in places where arrays are otherwise used - if an
iterator is found where an array is expected it is simply advanced
to completion to recover the values to operate on. Of course this
can, where possible, be done lazily.
So grep on an iterator might just construct a new iterator that
encapsulates the original iterator and a condition and has a next
method that skips any values from the underlying iterator that
don't match the condition.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...Hey, don't ask me, I'm just an Anthropomorphic Personification.
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
At 03:55 PM 10/2/00 -0700, Nathan Wiger wrote:
> > Or are we talking apples and oranges and the above declaration is intended
> > to declare that any *member* of @a is of SomeType, never mind the array
> > itself?
>
>Yes, I think that second sentence hits the point. Currently, there's
>ambiguity as to whether or not a type declaration on an array/hash means
>to be applied element-wise or whole-component-wise.
>
>If it's the latter, then there's no problem. And I suspect that's how
>we'd want it to play out. I was just raising the concern that with the
>current ambiguous non-definition of types (it's "conceptware" at this
>point :), it could mean either one.
>
>I pushed a lot of these issues in RFC 319 and 337, which would let you
>say something like:
>
>my Pet @pets :mean; # integrated implicit tie
>@pets->attributes('mean') # "true", like 'can'
I may be raining on your RFC 337 parade here (sorry I didn't get to it
earlier - travel), but I think it entirely reasonable to want to specify a
type for an array different from the type of thing it contains. But what
syntax will you use? If I make one up for the sake of illustration:
my DogPound(Dog) @kennel :homeless;
then @kennel->municipality, but $kennel[37]->breed. Make sense, or should
I just go back to bed?
--
Peter Scott
Pacific Systems Design Technologies
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
> I may be raining on your RFC 337 parade here (sorry I didn't get to it
> earlier - travel), but I think it entirely reasonable to want to specify a
> type for an array different from the type of thing it contains. But what
> syntax will you use? If I make one up for the sake of illustration:
>
> my DogPound(Dog) @kennel :homeless;
>
> then @kennel->municipality, but $kennel[37]->breed. Make sense, or should
> I just go back to bed?
In short: I don't see that as a problem. RFC 337 and 279 together
explicitly say that this syntax should now be viable:
my Pet @pets;
$pets[0] :fluffy = "kurt";# assign explicit attribute
my Dog $pets[1] :mean = "spot"; # re-type a specific element
It's unchartered territory. But I don't see why it wouldn't work. The
only troublesome one is that last one, since it requires re-lexicalizing
the scope, which has no meaning for individiual array/hash elements
currently. So perhaps an alternate syntax:
$pets[1] :type('Dog') = "rufus"; # re-typing
(with :type being a special builtin attribute) would be needed. Most of
this is in RFC 279 (except that :type thing, I just thought of that :-).
-Nate
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
Nathan Wiger wrote:
> I pushed a lot of these issues in RFC 319 and 337, which would let you
> say something like:
>
>my Pet @pets :mean; # integrated implicit tie
>@pets->attributes('mean') # "true", like 'can'
Blech.
exists @pets:mean # true
--
John Porter
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
Peter Scott wrote: > > Maybe I'm just being dense, but why shouldn't arrays and hashes inherit > attributes from UNIVERSAL? I think, rather, they should inherit from some other root class, since UNIVERSAL is for blessed things. > Hmm, am I saying that I should be able to > write @array->method()? Of course you already can, just not with that syntax: scalar(@array) $#array keys(%hash) values(%hash) etc. etc. -- John Porter By pressing down a special key It plays a little melody
Re: RFC 339 (v1) caller->eval BLOCK
Greg Williams wrote:
> as I remember, the C pragma, when used, would simply act as if the
>enclosing scope were not in place, enabling such things as:
> if ($ints) {
> no scope;
> use integer;
> }
Hmm. C could be implemented in terms of the rfc 340 C like
so:
$scope_out_here = with;
if ($ints) {
with $scope_out_here {use integer}
};
C is about subroutine calls.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."
Re: "0", true or false? (was: PERL6STORM #0052)
Bart Lateur wrote: > Bitwise and, or and xor do distinguish strings from numbers, and return > entirely different kinds of results. Why can't anything else? Absolutely. There is such a thing as Too Much Convenience. I think BOOL as a context or an accessor method should be separate from STRING and NUMBER so that if you know, you can suggest which behavior you want out of a particular scalar variable, or stick with the misguidable default. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "After jotting these points down, we felt better."
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, Oct 02, 2000 at 03:36:20PM -0500, Garrett Goebel wrote: > From: Tom Christiansen [mailto:[EMAIL PROTECTED]] > > >- Done right, it could be easier to write and maintain > > > > Strongly disagree. > > Ok, you disagree. There are differing opinions here. Can we agree to > disagree? No. Agreeing to disagree about this is like agreeign to implement Perl with three parts C, two parts Eiffel, two parts Python and one part Objective C. TMTOWTDI can't always be invoked simply because this project is named Perl. > Or must all people who believe XML is easier to write and maintain > leave the room? There are huge cultural, technical and practical limitations for Perl to adopt XML as a documentation syntax, or code all docs in =xml...=cut blocks. If you want to use XML, Latex, Texinfo or raw *roff for your docs, then by all means do so. Understand that Perl can't be made to magically ignore embedded Texinfo, and Perl contributors realistically can't be made to understand/patch/correct multiple markup formats. This is why we invented POD. This is why we use POD. > Horror of horrors: why not support both? Long live: TMTOWTDI. If XML > documentation fails to thrive, cut it from Perl 6.1. XML docs *have* failed to thrive among those who document Perl. They have failed to thrive among that group for over two years, especially since all that's missing is someone thinking about a definitive POD->XML conversion. (Sorry, I'd chip in, but I'm a little busy this week.) > > That is an excellent description of why THIS IS COMPLETE > > MADNESS. > > Being able to parse for well-definedness, DTD validation, and schema > constraints are postive things. And none of them *require* XML. There's no reason why POD can't be well-defined, validated and schema correct. Z.
Re: RFC 339 (v1) caller->eval BLOCK
At 18:43 -0500 2000/10/02, David L. Nicol wrote:
>Hmm. C could be implemented in terms of the rfc 340 C like
>so:
>
> $scope_out_here = with;
> if ($ints) {
> with $scope_out_here {use integer}
> };
>
>C is about subroutine calls.
Interesting! I have a few questions (meandering thoughts) though
The example in the RFC gives:
sub A{
my $A = shift;
return with;
};
$context1 = A(3);
print "$context1"; # something like CONTEXT(0XF0GD0G)
print "$A" with $context1; # prints 3
with $context1{print "$A"}; # same thing
This implies that &A is now something akin to a closure, correct?
That is to say, the meaning of C becomes changed by the
presence of C so that $A is something in between a
lexical scoped to &A and a lexical scoped around &A ({ my $A; sub A
{} }). $A is held in existence by the presence of the context
object. Presumably $A would 'go out of scope' and be destroyed at
the same time as the associated context object? This worries me, but
I admit it's neat ;)
What is more worrying to me is this: with a C pragma, you
can only go up /your/ scope. Consider this:
package Nasty;
my $context;
{
package Unsuspecting_Package;
$context = with;
}
use integer with $context;
Spooky action at a distance to be sure! Also, integer (and others)
is a compile time issue. Using C can be easily (it would
appear) implemented for compile-time since it's merely another
pragma. On the other hand, C strikes me as more of a run-time
beast. (at this point, I'm not sure if I have any idea of what I'm
talking about, so excuse me if this has digressed into rambling :)
So I like the idea of C, but am not sure it is compeltely
suitable for invoking pragmata such as integer.
.greg
--
"Push to test."
"Release to detonate."
Re: Draft RFC: new pragma: C
Graham Barr wrote: > > I would suggest that anyone want to contribute to this discussion should > first read the thread about the addition of this pragma to perl5 in > the perl5-porters archives > > >http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespace+pragma&errors=0&case=on&maxfiles=100&maxlines=30 > > Graham. package chroot would be more powerful than use namespace. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "After jotting these points down, we felt better." =head1 TITLE package chroot =head1 VERSION Maintainer: David Nicol <[EMAIL PROTECTED]> Date: 02 OCT 2000 Version: 1 Mailing List: [EMAIL PROTECTED] status: DEVELOPING Number: =head1 ABSTRACT C is to Perl packages as C is to filesystem directories. This allows us a way to implement package name spaces hidden from each other, and also a way to hide some methods of a package which is installed within a "chroot jail." =head1 DESCRIPTION to rewrite perldoc -f package: =item package chroot =item package chroot NAMESPACE [, IMPORTKEY1 => IMPORTVAL1 [, IMPORTKEY2 => IMPORTVAL2 [, ...]]] Declares the namespace root of the compilation unit as being in the given namespace. The scope of the chrooting is from the declaration itself through the end of the enclosing block, file, or eval (the same as the C operator). All further C declarations within the chroot have the NAMESPACE prepended to their NAMESPACEs. Further C declarations will nest. Within a chrooted environment, there is no way within the perl language to access a variable from outside the chrooted environment without an explicit accessor. =item IMPORT PAIR list Each item in the hash that follows the name of the new root package name space is an alias mapping. The key is the name in the new name space and the value is the name of the object in the old name space which is being imported with the new name. Variables, subroutined, and entire packages may be imported into the chroot, usually with their own names. Situations in which one would want to change the names of imported items are easy to imagine, for instace translations to other languages, or mocking up of emulation environments in which one would like to hide perl keywords that collide with keywords in the emulation. =item KEY,VALUE the key in the import pair is the name in the virtual space, the value is the name in the general space. This is so you can add an entire set of functionality, like CORE::, to the virtual space, and then take parts of it away. =item wild cards in import pairs a wild-card character * is defined in the import pair language. This allows all of the semantic descendents of a package to be imported together. For instance: package orig; # we are now in package orig:: package chroot C, # from here on in, all # globals will have C:: prepended # to their names CORE:: => CORE::, # but builtins will be visible 'A::*' => 'A::', # and everything in A:: and A::... 'B::' => 'E::',# all symbols E::... will be aliased to C::B::... '$frog' => '$cat'; # and $C::orig::frog will be $orig::cat but not @C::orig::frog or &C::orig::frog '*main::frog' => '*main::frog';# and $C::main::frog will be $main::frog, and so will other whatzits associated with that name. $A::inA = 'inA';# sets $C::A::inA, AKA $A::inA $B::inB = 'inB';# sets $C::B::inB, BKB $E::inB $A::B::inAB = 'inAB'; # sets $C::A::B::inAB, AKA $A::B::inAB $B::A::inBA = 'inBA'; # sets $C::B::A::inBA only $cat = 'meow'; # sets $C::orig::cat $frog = 'meow'; # sets $C::orig::frog, AKA $orig::cat A reference within the jail to a symbol that has appeared in an imported package since the importing will refer to the same item as it would outside: if you want to import only the symbols which exist at import time you need to list them explicitly. =head1 CONFLICTS The requirement of an explicit namespace argument allows package chroot; to switch the current package to chroot:: like it does in Perl5. =head1 IMPLEMENTATION The root of the global symbol table becomes replacable. C will need to recognize this as a special case. Wildcard imports could be implemented by adding code to the symbol resolver so that it knows that the package C is "within" C. the implementation of Packages may need to be altered so package has a meaning greater than "what is by default prepended to otherwise unqualified variables" =head1 REFERENCES Discussion around RFC 254 on overloading classes
Re: RFC 348 (v2) Regex assertions in plain Perl code
> Maintainer: Bart Lateur <[EMAIL PROTECTED]>
> Date: 28 Sep 2000
> Last Modified: 1 Oct 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 348
> Version: 2
> Status: Frozen
> [can't find a good quote]
It'd be somwhat useful, I think, if you could return somthing like \matched
to
let paren-catching of the ?{} thingy have somthing other then "". (Remember,
a ref is always true.)
For example, that would let you parse somthing inside a regex that
requires a complicated decision only once, with only common
regexish stuff outside the regex itself.
Of course, auto-deref is evil, but you can't just use the return value, or
you couldn't return things that aren't true, but match.
> Replace the old implementation of (?{...}). Optionally, throw out all
> the "localizing" code. Do not set any special variables.
It'd possibly be useful if the entire regex was considered to be a scope
WRT lexicals. This lets you pass data around the regex without ugly
action at a distance (not much of a distance, anyway) without having
special rollback code -- any rollback needed either normal to local,
or it's not our job. It feels like "transactional variables" may be a
Good Thing here.
If you don't remember transactional varables, the idea is that
if the block succeeds, the variables retain their values as set in the
block,
and if the block dies, they get reset to their initial condition. The
difference
here is that the "exception" raised is when the block gets rolled back.
This requires thinking about it after the fact, which might be harder.
(but no harder then the current situation.)
Basicly, it'd be like the current local situation, but with explicit naming,
fitting in with a wider feature (just slightly different).
> The new feature should:
>
> have a zero width impact on matching in the regex
I think it would be very nice to have some sort of way of making the
bit 'o code have nonzero length. You can do that now, but it Isn't Pretty:
(?{somecodeeatingstuff; $numate=3}).{$numate}
This is fairly straightforward, but it's modifing a global varable, which is
a
Bad Thing.
The question, of course, is how to implement such a thing. An "eat" builtin
would be pretty cool, but alas, too useful a name for other things.
> either succeed of fail, depending on the returned value as a boolean
> scalar: true means it's ok to continue, false means a veto, causing the
> regex to immediately backtrack.
And if you die, it will abort the regex?
Sorry to bring this stuff up after freeze -- I let my perl6 mail pile up too
much.
Oh, and assuming that I'm not making some stupid mistake, and with eat and
returning a ref, here's a killer app:
/([$matchingpairs])(.*?)(?{local $_=eat 1; $_ eq ${$matchingpairs[$1]} &&
\$1)/
It doesn't handle nesting thingies, but it's close.
(Assumes $matchingpairs{'('}=')'..., and $matchingpairs=join '', keys
%matchingpairs.)
-=- James Mastros
