Re: formats and localtime
On Mon, 31 Jul 2000, [EMAIL PROTECTED] wrote: > How about a Format module that works pretty much exactly the same way > but isn't actually in the Perl core? > One of the original suggestions, I believe. In this case, because other stuff *does* exist, the Format.pm mod should just attempt (to the best of its ability) to replicate Perl 5 formats as much as possible, and whatever additions to text formatting be consolidated in a new module, (abilities to be determined. Multiple column output, for instance.) > >Language > > -> Unixcentrism > > -> 1.PROBLEM: localtime's behaviour is non-intuitive for non-Unix people > > > >How can this be changed and still preserve any semblence of backward > >compatiblity? > > By adding a Date module to the standard library and encouraging its use? > Certainly. It would probably be a good module to work out overloading on as well. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: perl 6 requirements
On Mon, 31 Jul 2000, Edwin Wiles wrote: > Theoretically, we do have a list now. I'm going to try using it. It's > also a personal experiment, since I'm subscribed to 'all', but not to > 'language'. > Works for me. Thanks, Ask! > Not if I can help it! I've run into some fairly complex binary data > structures before. (Working on store&forward fax switches. In that > case, we not only had , but also > , , , ..., > , , ... > > In some of the cases, the variable length portions were nested within > each other, recursively. > > Honestly, if you're dealing with something that complex, perhaps writing > C code or something is a better idea. Still, we can give it a look! Same here, for the most part. Perl probably shouldn't compete with C (or assembler) for raw bit-processing power. But it should be a little better at it than a factor of 500. I do/did packet processing for signals processing - certainly something of questionable production value in Perl. But I had a difficult time simply prototyping a new algorithm in Perl - which it is usually wonderful for. Perl provides the bitwise ops, and pack and unpack, and that's about it. One of my submissions to Horos's list was the ability to have a little more hooks in for raw buffer manipulation. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: formats and localtime
On Mon, 31 Jul 2000, Matthew Persico wrote: > The original format stuff HAS to be kept. Don't document it so as not to > encourage its use. Play up Text::Autoformat::form if you wish, but there > will be way too much breakage/too little updateage if hundreds of old > web log scripts have to be ripped out upon installation of Perl6. > > Ditto for localtime - I say don't touch localtime at all. Document it as > an old function that is deprecated in 6.0.0 and will be dropped in > 6.X.Y. Promote one new object in the core called Date that returns 1 for > Jan and the full four digit year. Give it strftime capabilities. > > Hmm, that's another point - if you change localtime, doesn't strftime > have to change too? As does the implementation of scalar(localtime()). I don't think we're advocating its (their) complete demise, just the transition out of the core. (Which would, of course, still require a change to the scripts to 'use Format;'. Hmmm, perhaps all of formatting that is left in the core would be to 'use Format;' when you see format creation.) Could localtime() suffer a similar fate? (Is it POSIX?) Perhaps a Unix::(Tools|Calls|Toys) module? Of course, this may actually be a little off topic for this list, and better suited for internals. (ie, it shouldn't matter how Perl implements it as long as it works, no?) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: What is Perl?
On Tue, 01 Aug 2000, Alan Burlison wrote: > > Threading constructs built into the language > > The majority of perl programs won't be threaded - beware of making > simple things harder. That is, to me, a backwards way of thinking about it. Every perl program is threaded. Most just have one thread. ;-) I'll have an RFC on this for the internals group if I don't stumble across one later. -- Bryan C. Warnock ([EMAIL PROTECTED])
RFC: Request For New Pragma: Implicit
The librarian address doesn't seem to be working, so I'm injecting this here. =head1 TITLE Request For New Pragma: Implicit =head1 VERSION Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]> Date: 01 Aug 2000 Version: 1 Mailing List: perl6-language Number: TBD =head1 ABSTRACT Perl 6 should add a new pragma called C. =head1 DESCRIPTION I am lazy. I am spoiled by the implicit $_. I like the implicit $_. Implicit $_ good. Ugh. I also came to the sysadm / programming world in a long, circuitous route. I never programmed with toggle switches. I've never seen a punch card. My first programming was in Commodore 64 Basic. C64 Basic. No safe-signals there, either. ;) It did have one good thing, though. One very useful thing, for lazy people like me. C could be written like C. It just rolled off the fingers. C<10 ?"Port Perl for the 64!">. Of course, those days have gone. I've seen the light. I'm a *nix head and JAPH. But how I still hate typing out print. Particularly because I do it so much. Oh, sure, I could play games with HERE docs and the ilk, but I'm too lazy. But I digress. There should be an C pragma that gives new life and meaning to void context constructs. In my case, I want it to print to the default filehandle, (which is also implicit, I might add.) Scoping needs to be tightly controlled, of course. Don't want someone else's void context to show up on your display, now do you? And, of course, it would be defaulted to off. It could continue to ignore constant 0s and 1s. (But those pre-pod embedded comment strings just B to go.) Ideally, I'd like to use it for printing, but I suppose some other lazy person may want to use it for something else. =head1 MOTIVATORS Laziness, pure and simple. =head1 IMPLEMENTATION The front-end would have to detect void usage and either arrange to have the results passed to a callback, (in which case, would you know what wantarray() wants to know?) or inject the appropriate term in the optree. =head2 SUMMARY OF IMPLEMENTATION I've no real concrete ideas on this, sorry. =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of C and the sematics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What about subs? Backticks? Things that return meaningless printable information, like system()? C would put it on the user. After all, he doesn't have to use it. =item * Would C<;> print the contents of $_ to the default filehandle? ;-) =back =head1 REFERENCES None, currently. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: What is Perl?
On Tue, 01 Aug 2000, Matthew Cline wrote: > Doesn't tying slow things down? If you did compile time type > checking, this would take no perfromance hit. Also you could, say, > add some opcodes for doing runtime checking, so that runtime > checking would be faster than doing it with tying, but wouldn't bog > SVs down with having to carry around too much more extra info. > (At least, this is the impression I get from my limmited knowledge > of Perl internals). Except perl, because it is perl, and does perlish things, always needs to do runtime checking. Removing automatic runtime checking in favor of an op indicating runtime checking will double the size of the optree, and make regular perl that much slower with everything else. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Tue, 01 Aug 2000, Tom Christiansen wrote: > >3. It no longer has a unix specific flavour (PS I am not anti-unix in any > >sense) so Mac, VMS and Windows users feel less confused. > > Did it get decided that we were *supposed* to make Unix and C programmers > feel more confused and less at home with Perl? Forget the Unix and C programmers, what about the Perl programmers? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Tue, 01 Aug 2000, J. David Blackstone wrote: > How about this: perhaps we should compile a list of system calls > that _should_ remain in the core language. I think it will probably > be very small. I would suspect no more than the ones that perl needs internally for itself, excluding, of course, self-definition. Perl, internally, will need some form of I/O handling. Therefore, since it's already going in anyway, that same I/O should also be available to script space. Less code to break or fix. In theory. I suppose you could put it in a module and reference back into the perl core. Would that be too evil? Shared memory, to pick one, probably won't be needed inside perl proper, and can be unloaded to a external module. Some of the variables should probably stay, just for completeness's sake, in the core, whether Perl needs them or not. ($EUID and $EGID come to mind. $EUID is used, but I'm not sure about $EGID. Either way, they probably shouldn't be separated.) I would like to see some way of replacing or overriding what Perl core provides with something external, so if some foolhardy^H^H^H^Hbrave scripter wanted to replace standard Perl I/O with, say, O/I, they could. I suppose whatever ends up as 'Perl 5 mode' would auto-include the modules the former core functions disappeared into. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC: Request For New Pragma: Implicit
On Wed, 02 Aug 2000, Chaim Frenkel wrote: > (Walks away shaking head, in wonder and amazement.) Hey, it took me two weeks to hack the parser into doing this at work. (Well, to some extent. It isn't module friendly.) But you may as well kill-file me now, 'cause there are sure to be more. My Perl didn't come with instructions, just a little tag that said, "Use me." -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC: Request For New Pragma: Implicit
On Thu, 03 Aug 2000, Chaim Frenkel wrote: > Its my maintainence hat on. > > Picture some poor shmo, the regular guy is off on his two week vacation, > in some out the way place without his cell phone. And a production problem, > or the million dollar client, needs this yesterday. > > And he doesn't notice the use printvoidvalues. > > So the previous occupant was real careful never to use grep in void context, > and sprinkled (void) all over the perl code. > > But there he will be having strange output show up from nowhere. > > Yes, its fixable, yes, he should know what he is doing, yes, its the > same issue with all pragmas. > > But this effect bothers me. > > I'll slink off now. > > And that two-week vacation will be muuuch longer, I bet. I don't think even I'd be crazy enough to ab^H^Huse this in production code, but I guess anything and everything can be dangerous. (Hence the warning on the Pop-Tart sleeves that tell you to remove the wrapper before putting them in the toaster.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 2 (v1) Request For New Pragma: Implicit
On Thu, 03 Aug 2000, Chaim Frenkel wrote: > What would be the method to _avoid_ emitting something? > > What would be the result of > > open(Foo, "Bar")# Prints FILEHANDLE=0xdeadbeef > $x++; # Prints 3 > > What makes something a 'real' void so that it would print. Vs. not > having something that would catch the return value? no implicit; (Or 'no implicit print;' after rev 2 comes out. ;-) If you really only wanted to turn it off for one line, you could assign the result to undef. undef = open(Foo, "Bar"); undef = $x++; I tend to use this in a variety of places, but not for a big block of code. (Mostly because I don't have the scoping issue fixed, so I get all the spurious dumps from calls I make as well. I'll have an RFC for that, too, which will hopefully allow me to impliment this as a module vice a pragma; I've another RFC coming with a similar, (but more valid, you'll be glad to know) issue); mumkin tomorrow.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 16 (v1) Keep default Perl free of constraints su
On Thu, 03 Aug 2000, Simon Cozens wrote: > On Thu, Aug 03, 2000 at 08:36:01PM -0700, Nathan Wiger wrote: > > > Keep default Perl free of constraints such as warnings and strict. > > > > I second this. > > I third this. Perl is not, nor do I believe it ever should become, a B&D > language by default. "Making easy things easy", remember that? I'll go a step further and state that Perl shouldn't mutate any of its features, at least on the language side. Delete deprecated (or heavily warned against) features? Sure, if they're that old or that bad. Add features? Sure, that's okay, too. But change how Perl reacts, when nothing else has changed? The previous discussion about localtime had it right - if you want to change the indexing, or the semantics, create something other than localtime(). (I even disagree with changing the return value of system(), the blasphemer I am.) Change will be inevitable, I'm sure, and the changes that the Perl community and Larry want I'll support. I'm probably suggesting changes myself that will change the look of feel of "classic" Perl, rather than extending it, though I try hard not to. It's more than just backwards compatibility for a myriad scripts that concerns me - I'm sure we'll come up with a software solution for that. I'm concerned about the myriad scriptors that we aren't going to be able to patch. To make a bad analogy, it's like a TV show amidst a recast. Add a new character out of the blue? Well, okay, I can buy that. Kill a character off? Umm, I can live with that too, I guess. But to tell me that Dick York and Dick Sargent are the same Darrin Stephens? It's a little disconcerting to look at. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 17 (v1) Organization and Rationalization of Perl
On Fri, 04 Aug 2000, Peter Scott wrote: > The punctuation versions do at least have the merit of i18n :-) I don't > see any "use French" scripts out there yet... > I had a tentative 'use Arabic;' module, but couldn't figure out how they'd say "setuid". (Plus, my Arabic skills have drastically waned.) :-( -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 16 (v1) Keep default Perl free of constraints su
On Fri, 04 Aug 2000, Jeremy Howard wrote:
> OK, so maybe I'm taking up an unwinnable cause, but I
> un{fourth,third,second,nominate} this. Maybe it's my mod_perl bias
> speaking--the CGI scripts people post to the mod_perl list and say 'will
> this work under mod_perl?' sometimes make me need a cup of tea and a good
> lie down...
>
I wouldn't say it's unwinnable. I'll have an RFC on your mod-perl
issue tonight.
> When I'm showing someone how to program for the first time, they more often
> get things right the first time with 'use strict', and when something goes
> wrong, they tend to find what's gone wrong faster. More importantly, when
> they haven't had the mentoring to learn to 'use strict', and eventually
> manage to cobble together a program that works, attempting to maintain that
> down the track is near impossible.
>
That's an issue with the mentoring, not the language. That's why you
should teach someone with 'use strict'.
> Hey, I'm just as Lazy as the next perl hacker. But how hard is it to write
> 'no strict' if you want to? As I said in another thread, the People Who Know
> What They're Doing know when it's OK to do this, whereas Mere Mortals can
> use some hand holding, particularly when they're starting off.
>
About as hard as writing 'use strict'. Minus a letter.
IME, I find it more dangerous to do behind-the-scenes hand holding than
to simply teach them the hows and whys of the "right way."
> Not sit down before I share with you this...--I've heard a nasty rumour that
> there are even some people that think perl is a write-once, read many
> language . Well, we all know it doesn't have to be. So, let's
> encourage the use of the perl we respect, while still making the perl we
> keep in a dark place for when we're feeling naughty available for when we
> want it.
>
Of course, once you write something once in Perl, it doesn't need to be
rewritten. :-P
The key word above is "encourage". You're not really encouraging
anything - you're now having the language mandate particular constructs,
without the added benefit of teaching people why these constructs are
important.
> Or wouldn't perl without the bad reputation really be perl anymore?...
I find that the only bad rep Perl really gets is that it is too
powerful from a UI perspective. People are afraid of TMTOWTDI.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: RFC 2 (v1) Request For New Pragma: Implicit
On Fri, 04 Aug 2000, Bart Lateur wrote: > I think it's a bad idea. I would rather do it as the C64 did: use a very > short function name as an alternative to "print". > > P "This gets printed!", "\n", "Yeah!\n"; > Unfortunately (for you), you can't use '?' because it would be > ambiguous WRT the ?PATTERN? syntax. Well, actually, I *did* start off using '?' for print. (As Damian has proven time and again, import filters are wonderful toys. :-) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
On Sat, 05 Aug 2000, Nathan Wiger wrote: > > Here in my pre-caffiene morning trance it occurs to me that a few of > > the "fringe" features of perl should be removed from the langauge. > > Here's a few things that I would venture to say that none of the > > "perl5 is my first perl" people have probably ever actually used. > > > > reset # How often do you clear variables wholesale? > > dump > > study # never been a win for me. Perl5 is my first Perl. I use study on occasion. > > ?pattern? # one-time match > > split ?pat? # implicit split to @_ Which is currently labeled as deprecated, I believe. Most things labeled (or treated, such as pre-pod embedded docstrings) as deprecated should/could be removed. > > What's everyone's feeling on removing these from perl6? How often are > > they used? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 42 (v1) Request For New Pragma: Shell
On Sun, 06 Aug 2000, [EMAIL PROTECTED] wrote: > On Sat, Aug 05, 2000 at 09:14:49PM -, Perl6 RFC Librarian wrote: > >=head1 TITLE > > > >Request For New Pragma: Shell > > Pragmas have lower case names by convention, so this should be "use > shell". Yes, it's lc 'shell' everywhere but the title. It's that damned disconnect between English and, English. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 42 (v1) Request For New Pragma: Shell
On Sun, 06 Aug 2000, Johan Vromans wrote: > Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > > > There are times when one may need (or desire) to change the shell used > > for interpretation, as well as force shell interpretation, regardless > > of optimization, for consitency's sake. > > print `fancysh -c 'your uninterpreted and unoptiomized shell command'`; > > Or am I overlooking something? Well, for me, the lazyness factor. :-) There is the potential (for someone, I'm sure, as I haven't yet) to want to run all system commands through an alternate command interpreter - including the ones you didn't write. Me, I just want to run most of them in a couple of applications. @results = shell_me($shell_command); # With the appropriate sub backing it up is, to me, the entire point behind the backticks. @results = `$shell_command`; It's intuitive, quick, and DWIM. Surely, Perl on Windows doesn't require /bin/sh, does it? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Sun, 06 Aug 2000, Gisle Aas wrote:
> How about using a float (fractional second) instead of $msec, $nsec.
Or in addition to.
The problem with fractional seconds is that you can't really tell
exactly how precise your measurements are.
Here, at least, you could have an undef for the measurements the
platform doesn't support.
Or maybe a fractional second, drop the smaller fields, and include a
resolution field that would tell you how many digits are valid?
printf "%.${digits}f", $sec;
perhaps?
>
> --Gisle
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: Language RFC Summary 4th August 2000
On Fri, 04 Aug 2000, Uri Guttman wrote: > >>>>> "s" == skud <[EMAIL PROTECTED]> writes: > > s> Up for grabs: > s> - > s> Formats out of core > Somehow, I missed this message. I don't think that's a language issue. Whether Perl continues to support formats certainly is, but its location within Perl is more of an internals thing. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 53 (v10) Built-ins: Merge and generalize C
On Mon, 07 Aug 2000, Damian Conway wrote: > > > $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 >># in a perverse way >> >> Or am I seeing double negatives where I shouldn't? > > No. You're missing the fact that the third argument of rindex specifies > the last character at which the match can be found (as opposed to index's > third arg which specifies the *first* character from which to search) Is this one of those "Magic Eye" things where if you stare at it long enough, you'll eventually see the picture? .. .. .. .. .. .. Oh, now I get it. I understand now, but that certainly wasn't my first, second, or third interpretation of it. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 55 (v1) Compilation: Remove requirement for fina
On Mon, 07 Aug 2000, iain truskett wrote: > Who here has actually used something other than a constant '1' in a > package? > > If so, why? (Possibly cite the code.) I have. I've used 34. (Just 'cause I like the number.) I've also used the filename before. (I wanted to watch the order of various modules being used, and was testing out my implicit print hack. :-) Neither case should be considered justification for any decision being made. I tend to be a fringe programmer, and do things just because I can. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
On Tue, 08 Aug 2000, Leon Brocard wrote: > Martyn J. Pearce sent the following bits through the ether: > > > I use this in one-liners, and it's _dead_ handy > > May I suggest that Perl6 will be a different language? I've seen the > "I use it, don't change it" argument a couple of times now and it's > not a strong enough argument. The whole point is to clean up the > language. Most of the requests for deletion seem to begin with, "This isn't used..." To which, "*I* use it." is a very valid argument. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 50 (v1) BiDirectional Support in PERL
On Tue, 08 Aug 2000, Roman M . Parparov wrote: > It's not only the browser in the end. > It'd expand the capabilities to any output device presumed LTR. > > > It sounds like a hack. Should Perl support such hacks in the core? > > > > Is this sofisticated enough, or do we need something more low-level? > > > > $ltr = join '', reverse split /($sequence|.)/, $rtl; > > > It won't work with a mixed text, and there the pain in the ass begins. > Numbers, Latin char strings, here we go. > To explain for those who haven't handled a RTL language, numbers look the same as in LTR for most RTL languages, and I believe numerical prefixes also appear the same. The number is 1,358. alrqm ?w 1,358. Or, to compensate for a LTR display, .1,358 w? mqrla Also, .-1,358% w? roala mqrla I've never done anything but the simplest math in Arabic, so I don't know if evaluation order is reversed. x = 4 / 8; 1/2? Or 2? This has the potential for opening up a huge batch of problems (but making a lot of people happy.) The more I think about, the more I'd like to see at least hooks for handling this. After all, in some cases it's more than just a scalar reverse. Formatting, Text::Wrap, etc, for instance, has to wrap the other way. Perhaps a sub-list to hash out how we can do this without bloating Perl too much? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Error handling
On Tue, 08 Aug 2000, Brad hughes wrote: > > Why not? Throw and catch are familiar to programmers. > > Not all programmers. > Oops, correct. My mistake. Even more reason not to introduce yet another lexicon. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Things to remove
On Tue, 08 Aug 2000, Casey R. Tweten wrote: > Today around 6:55pm, Bryan C. Warnock hammered out this masterpiece: > > : chop, chomp, (champ, chimp, chump, chap, and chip, which, respectively, > : deletes all leading and trailing whitespace characters, all leading > : whitespace characters, all trailing whitespace characters, the first > : and last character, and the first character) are all efficient string > > Where, oh where, did you find these? And why, oh why, haven't I found > them on CPAN already? I wrote them. (One of my first exercises in XS and Perl internals, as a matter of fact.) They're quite trivial to produce, not taking variations of what constitutes whitespace into account. Because no one has submitted them, I guess. I don't have a PAUSE account. I keep meaning to request one, but the justification requirement keeps getting in my way. :-( (Not that that should change. CPAN's got enough trouble as it is.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 65 (v1) Add change bar functionality to pod
On Wed, 09 Aug 2000, Hildo Biersma wrote:
> > =head1 DESCRIPTION
> >
> > Making what's changed in documentation stand out's quite useful,
> > something I'm coming to appreciate more and more as the RFCs are
> > flying back and forth. The standard way to do this is to mark the
> > changed sections with one or more vertical bars on the left margin.
> >
> > Since changes can themselves be changed, multiple levels of change bar
> > can occur. This mirrors the common practice in printed documentation.
>
> I have a strong feeling this is a bad idea, because:
> - Not everyone is interested in the changes
Some of us have to add them anyway. :-)
The real question is whether the distributed Perl docs will include
change bars.
> - Human authors are fallible, and it's easy to forget changebars
Yep. (Although human authors are fallible, and it's easy to ^_foo,
or whatever the current currying syntax is now.)
> - We don't want the pods to grow indefinitely
Yep. (I think we keep the last five versions, so we simply filter out
/^\|{6,}/.
>
> Instead, it should be pretty trivial to write a tool that compares the
> pods for the current and (any) previous version, generate the
> changebars, then writes that out as a separate document - for those who
> want it. It may be desirable to include that with the default module
> distribution, or we may want to make this a web-based CPAN resource, but
> boy this should not clutter up every module out there.
We tried this, too. It worked, but was a little too awkward for our
use. (And failed the requirements in the end anyway.)
FFT.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: chomp & unchomp
On Wed, 09 Aug 2000, Ed Mills wrote: > Here is the argument- > > Perl has (had?) chomp(). It removes \n at the end of a line. That's > something we often need to do. We ALSO often need to ADD \n to the end of a > line. This usually looks something like: > > print "$kitty\n"; Chomp removes one or more line separators from the end. > > Hence my println() suggestion. Maybe instead it should be: > > unchomp; > print; > > Where unchomp ADDS \n to the end of text if it isn't already there. How many? Ideally, since you're looking for an inverse, you'd want to replace however many were chomped off, right? > > If there is chomp there should be unchomp- the reasons for including it are > the same as for including chomp. If chomp is optimized so too can unchomp. > > Having chomp without unchomp would be like having <= but not having >= > [see note]. Sure you can get by without it- just change the order of the > args, but why would you want to? If you have one, the other needs to be > there for, if nothng else, parity. > chomp() uses $/, I believe. $\ is the inverse of $/, and is used automatically. And it's fewer characters. $\="\n"; print; -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: chomp & unchomp
On Wed, 09 Aug 2000, John Porter wrote: > Bryan C. Warnock wrote: > > > > Chomp removes one or more line separators from the end. > > It does? You're using a different version of Perl than I am. Sorry. You're correct. I was rolling the string, list, and paragraph mode removals all into one argument. :-( Chomp *sometimes* remove one or more newlines from the end of a string. #!/usr/local/bin/perl -w $/=""; $a = "Hello\n\n\n\n\n\n"; $foo = chomp($a); print "$foo chomped, >$a<\n"; Whammo> perl gork 6 chomped, >Hello< I may be slow, but I make mistakes. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: vector and matrix calculations in core? (was: Re: Ramblings on "base class" for SV etc.)
On Wed, 09 Aug 2000, Jeremy Howard wrote: > Of course, if the user wants to overload this behaviour, we should let them. > In the multiplication example, however, I would have thought that 'x' is a > more suitable inner product operator... And that seems to be where most of the critics of non-scalar arithmetic and operator overloading have most of the problems. (Provided, of course, that you're limited to operator overloading and not operator creation, as I believe Smalltalk allows.) DWIM is hardly ever DWYM. For instance, two common uses for arrays are as vectors and sets - but the operations for vectors and sets aren't congruent, and oftentimes the cleanest symbology - given a limited set of symbols - will give someone fits if applied to the wrong framework. And that's with each other. There's also classic Perl to consider. @b = qw/a b c d e f/; @c = qw/1 2 3 4 5/; @a = @b . @c; $a = @b . @c; @a = @b x @c; $a = @b x @c; Not knowing what @b and @c really are to represent, what would the most logic interpretation of the above statements be? To the Perl purist (looking for parallel operations between scalars and arrays), this could conceivably be the same as the following real Perl expressions. @a = (@b, @c); # @a = qw/a b c d e f 1 2 3 4 5/; $a = scalar (@b, @c); # $a = 11; @a = (@b) x scalar @c; # @a = qw/a b c d e f a b c d e f a b . f/; $a = scalar ((@b) x scalar @c); # $a = 30; But they're not. Which makes sense, if you know Perl, but doesn't (er, may not), if you don't. Instead, they're the same as this: @a = ((scalar @b) . (scalar @c)); # @a = qw/65/; $a = scalar @b . scalar @c; # $a = 65; @a = (scalar @b x scalar @c); # @a = qw/6/; $a = scalar @b x scalar @c; # $a = 6; Of course, to someone trying to doing inner and outer products, or union and intersection, none of the above are correct. (Yes, & and | are probably better symbols for U and upside-down U. But you get the drift.) Perl could probably get away with better defining a strict (and consistent) set of operations of vectors (vectors in a CS sense of the word, vice a strictly math sense of the word) that behaved in a Perlish way, and not necessary a mathematical way, but I think matrix manipulation unadorned in bare Perl code will be difficult to make consistent with the rest of the language, or even accurately represented. I like the work that PDL has done, and would like to see a way to make (at least simple) matrix calculations more inline, but it may end up too counter-intuitive (or obtrusive) to programmers using lists and arrays in another context. Hmm, maybe I should have changed the subject back to rambling -- Bryan C. Warnock ([EMAIL PROTECTED])
RE: RFC 58 (v1) C changes.
On Wed, 09 Aug 2000, Brust, Corwin wrote: > So, kids, whatcha doing with that return value? (the number of characters > removed by the operation)? Store it (in paragraph mode) so I know how many \n's to append back on when spitting the output back. (Provided that matters. Otherwise, I just ignore it.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Overloading && ||
On Wed, 09 Aug 2000, Peter Scott wrote: > I guess it's getting too incestuous with the lexer. On Wed, 09 Aug 2000, Nick Ing-Simmons wrote: > That is the root of the problem. On Wed, 09 Aug 2000, Damian Conway wrote: > User-defined operators are a can of rattle-snakes that I *seriously* > recommend we don't open. On Wed, 09 Aug 2000, Nathan Torkington wrote (out of context here): > This was probably to avoid too much lexercest. But. It seems to me the generally inability to influence the lexer is the one general weakness in Perl. Yes, there is many very valid reasons on why this is an evil, evil, thing, and I agree with most of them. But, and this may just be the drugs talking here, it seems that the bulk of the RFCs deal with one of two issues: how Perl works internally, or how the Perl lexer needs to be able to handle something new. It makes sense, after all, because if it's not strictly an internal problem, and it's not really a lexer issue, than it can most likely already be included in the language via a module. Perl is extremely easy to extend. The Perl lexer is most heinous to extend. A lot of discussions (and two of my RFCs) are centered around adding a pragma to the language to influence the lexer to do this, or do that, so that we don't trample on anybody else. Perl will soon have more pragmas than keywords, and this makes it unfriendly and inconsistent. In addition, some many different people use Perl in so many different ways. Some people, like me, use Perl in so many different ways simultaneously. The mudpuppies want the down and dirty Perl that we know and love - how to get Perl to scratch my ass in 108 characters, of which only 11 are alphanumeric. The CS application type folks want a stricter language - more strict typedeffing, mandatory variable declaration, mandatory scoping declaration, no runtime constructs. In their world, this is all a good thing. The middle-of-the-road type folks want to stay the middle-of-the-road. Obviously, someone is going to be unhappy. Life isn't fair. I just wish it was unfair in my favor. Anyway, these are all lexer issues. Sort of. Mostly. Perl allows you to change the runtime semantics of Perl to your heart's content - to extend, manipulate, mutilate, Perl to do your bidding. But for compile time semantics, you're stuck with what Perl gives you. Allowing user extensions to the lexer is a very powerful ability that will inevitably shoot many people in the foot. It will probably shoot many people in many feet. The biggest problem, I think, is that you can't really allow "a couple" changes. Once that door is open, it's wide open, and anything goes. Damian will see to that. But it would certainly address a lot of the language list. The counter-argument is, of course, if you change the lexer, you change the language. If you change the language, why don't you just go create your own? This was the RFC that I never found the gall to write, because I've identified no solutions, and have found only problems. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Overloading && ||
On Wed, 09 Aug 2000, Dan Sugalski wrote: > I've not seen a pragma yet that affects lexing, though I may have missed > some. (I don't consider the lexical/package thing a lexer issue, since it's > not) They change the behaviour of the generated code, yes, but not the > lexing/parsing/whatever of the perl source. Funny you should mention that I just had a most interesting/horrible dream. Nick (who I've never meet, seen, nor heard) spoke to me in a voice very reminiscent of Obi-Wan Kenobi, and said, "Luke, you are an idiot." Anyway, down in my dream-state, I realized that I was not making a distinction between lexing and parsing, which apparently is a common problem among people who a) are heavily drugged, and b) don't know what they're talking about. I was hoping to get back to the list before some caught my error, but alas, I did not. :-( But, I'm awake now, so I might as well get back to work. So, ignore my entire post on lexing, and consider it to be a spewage on parsing, with a sidetrack on whatever it is I actually wrote. What I was trying to say, is that I think most of the language RFCs could be addressed (in one way) by affecting whether and how the parser interprets what the lexer gives to it. There are some internal issues, like how lexical scoping would be handled, but for the most part parser extensions would simply limit what standard opcodes (or their ilk) would be generated. Examples, I hope: POP (Plain Old Perl): $a = "foo"; my $b = "bar"; Lexes and Parses without an issue. The optree the interpreter generates is (roughly) "foo" to global scalar a. "bar" to this block's scalar b. Perl with Perl Parser Pragma Module NaziRules::Scopage $a = "foo"; my $b = "bar"; The Parser will error out with "Must have explicit scope for $a, line #..." Once it's fixed, "$main::a, or our $a, or Scopage::SuperGlobalInUmpteenDifferentInterpreters::global $a = "foo"; the optree it spits out will *still* be valid Perl whatever that is. Regardless of whether this is any clearer, I've still no idea how this could be done. And I'm sure TMTOWTDI outside of all this. -- Bryan C. Warnock ([EMAIL PROTECTED])
And A Parser In A Pared Tree (was Re: Overloading && ||)
On Thu, 10 Aug 2000, David L. Nicol wrote: > "Bryan C. Warnock" wrote: > > > This was the ass that I never found the gall to scratch, because I've > > identified no solutions, and have found only problems. > > > > -- > > Bryan C. Warnock > > ([EMAIL PROTECTED]) While I appreciate the creative combination of several key points in my post, I'd appreciate it more if you wouldn't state that I actually wrote that. Or perhaps you were making your own point. :-) The rest of your paraphrasing is pretty much on, I guess. Perl already is two (similar, but distinct) languages, of which only one is required to work in Perl. They are Perl, the defined language, and the internal API to Perl. (Okay, so that's still fuzzy, but you should get the idea.) Ideally, it wouldn't involve Yet Another Language, but could be done in one of the two Perl already has. (Or both, I suppose.) What I don't believe should be the goal, although it may be an unfortunate side-effect, is to, in essence, write the parser in Perl, and to require writing a full parser for every case That would, in essence, require dropping the user parser inline between the lexer and the real parser, capturing all the tokens coming out, doing the necessary identification and modifications, and passing the new token stream to the real parser. I think this was one of Nat's hook areas, and is similar to what Chaim suggested with how macros could work. This could work with very simple requirements, and could even partially extend to adding lexer extensions. Otherwise, why not just rewrite the parser in its entirety, and drop it in as a new front end? Alternately, to keep things simple, you could have a signature callback type mechanism, where the parser only calls your code upon certain rule reductions. This requires the lexer to have already sent the data to the parser, which could make for some icky situations, particularly with inspection and modification of what the parser has already done. Or, to keep things really simple, have parser pragma types that affect the parser internals runtime much like the rest of Perl modules affect Perl runtime. (This would, of course, require the parser to be able to support much deeper introspection than it does now. Yet Another Language, more complexity. But would allow for only a limited number of hooks, which would be a little easier to contain and a little less scary to deal with.) This last was basically what I was looking for with RFC 40. This would allow people to write their own pragmas, as long as they only needed what hooks were available. More radical changes would involve adding more hooks. I'll ponder all this today, and maybe give some examples this evening, perhaps showing how some of the current RFCs could be addressed. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 83 (v1) Make constants look like variables
On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote: > This method of creating constants has three serious drawbacks: They're also quite heavy, although I think that CONSTSUB was to take care of that. What I never understood, although I'm sure there's a very simple reason, is why it wasn't simply made a read-only scalar. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 85 (v1) All perl generated errors should have a
On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote: > All perl generated errors should have a unique identity. So that > changes in the text should not cause breakage in code. > Good idea. A lot of programs do this. It could make it easier to handle error callbacks. (If you ever get a 'no space left on device' type error, call remove_my_entire_directory_tree();) What about compartmentalization of Perl space and user space, though, when dealing with use of the actual mechanisms? Gentlemen's agreement? User space caveat scriptor? > =head1 DESCRIPTION > > Currently many programs handle error returns by examining the text of > the error returned in $@. This makes changes in the text of the error > message, an issue for the backwards compatibility police. > > An added benefit, depending upon the actual method of identifing > errors selected could be a classification scheme for errors. > > =head1 IMPLEMENTATION > > Each unique identifier once assigned as part of a stable release > of perl will be guarenteed never to be changed, or if the error > text is removed, never to be reused. > > =head2 Encodings > > I have listed some possiblities. But none of these are ideal. > > =head3 A unique number > > Each error message will be assigned a unique number. The number > could be made accessible via the $@ in a numeric context. This would, at least, parallel $!'s magic. Or new pair value, I suppose. (RFC - Request From Conway, Required For Conway :-) > =item As a floating point number > > The integer part would be the actual identifier. The fractional > part could encode some classification scheme. Depending on whether you wanted an error to meet multiple classifications, it may make more sense to switch the two. CLASS.ERROR This may make it easier for users to register their own errors under pre-existing classes. Another idea would be two shorts, one for each. (Where you could either handle numbers or bitmaps.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 48 (v2) Replace localtime() and gmtime() with da
To nick some pits On Fri, 11 Aug 2000, Nathan Wiger wrote: > Here is the justification. As most people write dates, they write > something like this: > >1/20/1976 2:34:02 >4/5/981 11:05:09 > > Very few people I've met write dates like this habitually in the real > world: > >01/20/1976 02:34:02 >04/05/0981 11:05:09 > > And I've never seen anyone write this: > >1/20/1976 2:34:2 >4/5/981 11:5:9 > > Notice that the hours/mins are always padded but the rest isn't. I think you meant minutes/seconds. > > If you're writing a program that uses the date as an actual date (and > not as a file suffix, for example), you'll probably want to present what > people are used to seeing, in this case the first one. And if you want a s/people/your audience/; > file suffix, use what I suggested in the RFC: > >$backup_suffix = date time, '%Y%m%d%H%M%S'; > > Which would return something like "20001104120309". > > I've gone back and forth about this. I ultimately think that the above > approach will end up with date() being more usable in more situations, > even though it seems a little inconsistent. I think it returns what > people want, it's just that people are inconsistent. I would say that various pockets of people are inconsistent with other pockets. > > Remember, localtime is already a very consistent interface from a lot of > aspects, but it is horribly unusable because it doesn't return stuff in > the form you want it. Nothing returns stuff in the form I want. That's why I use Perl. ;-) As long as this transformation remains simple, and the strftime interface is simple enough, I don't care what the interface is. Although, (and this may have already been mentioned/suggested/accepted/rejected), if you're going to have an object interface, perhaps the constructor can take the strftime string for use as the default scalar output? -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: named parameters
Internals added to cc: On Fri, 04 Aug 2000, Nathan Wiger wrote: > Point taken. But part of the goal was moving a lot of stuff out of CORE > and making Perl faster. New features are great, but we should figure out > whether or not they're truly CORE-worthy. Sticking it in a pragma like > strict helps to solve this issue, but as always TMTOWTDI. > BTW, I use CORE to mean "perl" and not "perl.tar.gz". Hmmm, is that the generic "we"? (It seems to me that whether something is CORE-worthy is really a decision for the internals team. Whether something should be a valid, meaningful construct in Perl, regardless of the implementation, is the focus of the language team. Perhaps a better job of making this distinction will keep the language list from its current bloat, as skud pointed out. The language list keeps migrating from "why" to "how".) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Tue, 15 Aug 2000, John Porter wrote:
> Yes. OTOH, if it doesn't add *enough* information, it's not cost-
> effective. Most of proposals, such as highlander types and this 109,
> reduce the amount of info carried by the symbol to the point that it
> isn't worth having. Furthermore, if the OO nature of perl, as
> foreshadowed by perl5's tie-ing and lvalue subs, realizes its full
> potential, then being a "scalar", as indicated by a $, conveys
> essentially zero information.
Composer::Post.assumes(Iterator.each(Iterator.all(List)=="Programmers")
->programs=(Language::Programming.uses("Perl")==true &&
Methodology.implemented(Style.OO==true,Time.all==true)))==true;
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: Language WG report, August 16th 2000
On Wed, 16 Aug 2000, [EMAIL PROTECTED] wrote: > The language group has generated the vast majority of the 100+ RFCs in > existence, and is suffering under the deluge of 100-200 posts a day. I > would prefer this to be down around 50, but no luck yet :-/ Part of the > problem seems to be timezone related... the lag time between an RFC > being posted, me seeing the thread and realising the need for a sublist, > and Ask actually creating that list, means that you get 2-3 days of > traffic before it can be moved elsewhere, and a single RFC can easily > generate 50 posts. I think that all this... > > Several sublists have been spawned, but we're not sure how successful > they are yet. They seem to have low traffic, which could mean that they > simply aren't working (because nobody wants to use them), or that they > *are* working (because the people previously discussing the subject on > -language weren't deeply interested and just joining in for the hell of > it, and the sublists scare off the dilletantes). I think that an NNTP > interface would be *seriously* useful to the sublists. ... is the cause for this. All the discussion is taking place in the master list before the sublists are spawned. You can only express the opinion that foo is not bar and never should be so many times. (To be fair, I collapse my lists, and don't pay attention to what is posted to what list.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 111 (v1) Whitespace and Here Docs
On Wed, 16 Aug 2000, Perl6 RFC Librarian wrote: > This will ignore all leading white space on each line until the end terminator > is found. It effectively does s/^\s*// before processing each following line. I don't agree with this, but > It also ignores whitespace (but not the line termination) after > the terminator. ...I agree with this. > > Personally I find such blocks very usefull for cgi programming, when delivering > large blocks of fixed html. Personally, I find such blocks very useful for lots of things. The majority of my uses require/desire maintaining relative indentations, and not the arbitrary removal of all leading whitespace. Wasn't there a recipe for this? (Although I wouldn't mind seeing it implicit to the language.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Mon, 14 Aug 2000, Nathan Wiger wrote:
>1. time() would still return UNIX epoch time. However, it
> would not be in core, and would not be the primary
> timekeeping method. It would be in Time::Local for
> compatibility (along with localtime and gmtime).
>
>2. mjdate() would return MJD. It _would_ be in core, and
> it _would_ be the internal timekeeping method. All
> of the new date functions would be designed to be based
> off of it.
>
> So, just to clarify:
>
>1. The Perl 5 way in Perl 6:
>
> use Time::Local;
> $date = localtime time();
>
>2. The Perl 6 native way:
>
> $date = date mjdate();
Now, are we talking about the new default/de facto standard that the
users are being presented with? Or are we talking about the true
internal structure? ("and it _would_ be the internal timekeeping
method.")
I don't have an OS that reports time in MJD. It seems
counter-productive (IMHO) for Perl (internally) to convert from
whatever the native platform time measurement is to MJD, only to
convert it back to the native format again, if that never is presented
to the users.
For example:
# From 5.6 perlfunc
$now = time;
utime $now, $now, @ARGV;
Under this proposal, time would (under Unix), return the number of
epoch seconds, which would then be converted to MJD internally. This
stored MJD would then have to be converted back to the original epoch
seconds, (perhaps twice), for the argument to utime? Alarms and
timers, file tests - any time interface outside of Perl itself - these
*all* will be converted to MJD internally?
(Assuming, of course, that you don't explicitly change the arguments to
utime to accept MJD, although it would still have to be converted to
native format anyway.)
I can understand wanting to present the user with a common,
multi-platform, consistent date/time interface, but I don't understand
extending that to the internals.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: RFCs (Re: Ideas that need RFCs?)
On Fri, 18 Aug 2000, David L. Nicol wrote: > There will Be No Perl7 Of course not. Odd numbers are the development releases. The next Perl after 6 will be 8. Seriously, while a worthwhile goal, this is rather short-sighted. The industry and the world will continue to change in spite (or because!) of our efforts here. We can make it easier for the users to adapt, but Perl will need to continue to evolve, as well. (As spoken by a one-eyebrow, knuckle-dragging Neanderthal) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Tue, 15 Aug 2000, Nathan Wiger wrote: > Jarkko Hietaniemi wrote: > > > > > Is Perl currently using different epochs on different platforms? If so, I > > > > Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition, > > just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?), > > VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical > > reason IIRC. > > This is the real point I'm trying to address. Nothing else. :-) > > There seems to be a groundswell against this idea, which is fine by me > (heck, just because it's my idea doesn't me it's a GOOD one!). > > Here's a different proposal, same vein: "Standardize all Perl platforms > on the UNIX epoch". > > Sound better? Only if all the OSes are rewritten to use the standard UNIX epoch as well. Internally, you should use whatever the platform you're running on uses. Externally, you can use whatever you'd like. > > -Nate -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Tue, 15 Aug 2000, Karl Glazebrook wrote:
> or one could just *use* english plurals...
>
I tried this once with filters. It sort of worked.
(With the obvious bombs, of course.)
> my $speaker = 'Jim';
> my $speakers = ('Fred','Bill','Sally','Betty');
>
> my $male_speakers = $speakers[0:1]; # If perl supported this style of range - see
>RFC coming soon
>
> # BUT:
>
> my $image = read_huge_2d_list_of_numbers('file');
>
> my $favorite_pixels = $image[10:20,50:100];
> my $best_pixel = $image[11,55];
>
>
> Karl
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: Things to remove
On Wed, 23 Aug 2000, Buddha Buck wrote: > Perhaps someone should RFC the new special variable &ME, which is > predefined to be the whole program. Who knows? Perhaps it would then make > sense to use @_ at the top level, as if the program was invoked as > "&ME(@ARGV);"... Doesn't a lot of OO work (esp. on the Mac) tend to do this? The first thing they do in their application is instantiate an application (mainly, itself, without the application instantiation) and run it. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: ... as a term
On Wed, 23 Aug 2000, Bart Lateur wrote: > On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: > > >If you want to save the world, come up with a better way to say "www". > >(And make it stick...) > > "The world"? This problem only exists in English! > > We pronounce it something similar to "way way way". I, personally, prefer the Stoogian "Whoop whoop whoop!" Although it's hard to stop at three. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, 24 Aug 2000, Nathan Torkington wrote: > You'd obviously want to have a module that collected together your > favourite new operators. But if they were lexically scoped, they'd > be lexically scoped to the module they were defined in, i.e. your > collection rather than your main program. We're going to have to > think of a way to consistently say "do this in my caller's lexical > scope" without it becoming a nasty upvar hell. Not that it adds much information, but this is the lament of RFC 40. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 2 (v3) Request For New Pragma: Implicit
On Wed, 30 Aug 2000, Michael Maraist wrote: > Good idea, but you have it backwards.. If anything, there should be an > "explicit" keyword.. > Remember, we want > > % perl -p -e 's/foo/bar/g' file.txt Oh, I know. I threw it in because someone mentioned wanting to turn it off. (There may have been some confusion in the default settings. The implicit arg would be 'on' by default. To turn it off would require: no implict arg; Use could then turn it back on again.) Trust me, I've no desire of removing the features that won me over in the first place. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 50 (v1) BiDirectional Support in PERL
On Tue, 08 Aug 2000, Roman M . Parparov wrote: > This is a tough one. But it is known that the numerical game scores and > likewise are being written RTL. As for math, I've seen it being written > both ways. I am not a native hebrew speaker and I consulted some natives > at work and no consensus was reached. It means some expanded and very > precise spec should be written on how a pure RTL and RTL with portions of > LTR have to look like. > Sounds like a road trip to me. ;-) I'm not a native speaker, either. (As if the name didn't give that away.) All my bi-dir GUI work has had support of a RTL widget set that handled the display rules automatically.) I think we're just looking to make sure that Perl can fake RTL without outside RTL support, no? > Besides, speaking of Arabic, they do have even their own digits, but then, > I think they behave just like letters. > Arab numerals behave exactly like arabic numerals - is that confusing? - in that they're written LTR in number form. Yes, they have different characters, but that's actually where our evaluation order came from. Farsi has the same requirements. There may be other RTL languages that don't, however. To use numbers that are (easily) transliterated. 1,547,956.17 = 1,OEV,9O7.1V > > Perhaps a sub-list to hash out how we can do this without bloating Perl > > too much? > > > I think not at this stage. We need to decide how important this is for > PERL and after we're done with ths more or less general stage, > we'll roll out the Specs and then it'd be possible to start coding. > > Currently, an item for the discussion IMHO is - whether to empower > existing print to handle visual RTL output, whether to write a core > output function rtlprint, or to reduce ourselves to a Text:: module? > I.e. - WHAT are we going to do, but not yet - HOW. Well, I think what we can do depends on how we can do it. This should, IMHO, be possible in Perl, but not necessarily core, but there are some potential core issues that need to be addressed. For instance, if formats are relegated to a module, then it would simply be a matter of supplanting that module to give you your correct semantics. If, however, it's still internal, then the core will need to have hooks to allow visual RTL. (s/will need to/should/, I suppose.) I doubt that many people on the list have a personal involvement in this issue, and shouldn't care one way or another if we can implement it without penalty to everyone else. It may be that we just add this as another reason to do foo() like bar. (Hence my suggestion to get it down out of everyone's way.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Error handling
On Tue, 08 Aug 2000, Peter Bevan wrote:
> However, with the birth of the new Perl, I think it is time to bury those
> ideoms in the language and
> start inventing new ones..
>
Two words: "New Coke"
I think that Perl survived its first through fifth births because the
idioms it chose to implement were familiar.
One could conceivably create a semantically pure language with
no platform or OS dependencies, but then no one would use it.
Creating new idioms is fine. I'm all for it. If you can do it in a
language, why not do it? What's wrong with map{} in a void context?
;-)
Be careful destroying old idioms out of spite, or just because you've
created a new one.
In most cases, you haven't created a replacement, but a substitute.
There's a difference.
> Error handling should be supported by it's own keyword
i.e.: >
> trap {
> #CODE
> }
> release (error) {
> # ERROR
> }
>
> (just because I didn't want to steal throw and catch)
Why not? Throw and catch are familiar to programmers.
Creating brand new vocabulary may potentially hinder a Foo->Perl and
Perl->Foo transition for someone. Use what people know.
(Today, one of my coworkers couldn't understand why 'next;' wasn't
working in a C++ while loop.)
>
> Timeouts, shouldn't be reliant on UNIX. (Although I dont think they should
> be in the language eigther. A system is easily developed using threads.
> something which I hope to develop when perl6 is ready...)
>
I don't understand this paragraph.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: Things to remove
On Tue, 08 Aug 2000, Ed Mills wrote: > As long as were culling, might want to consider removing chomp() and > possibly chop(). The language provides other ways to accomplish those thru a > simple regex, Then we should remove regexs instead. :-) > and if the "println" suggestion I made was "too specific" then > certainly chomp() is as well. > > Just a thought to chomp on.. As has been demonstrated, it is certainly trivial for you to impliment println() yourself. Maybe even contribute it to CPAN for others to use. The effect on the Perl community as a whole will be nil, as no one is using this yet. chop, chomp, (champ, chimp, chump, chap, and chip, which, respectively, deletes all leading and trailing whitespace characters, all leading whitespace characters, all trailing whitespace characters, the first and last character, and the first character) are all efficient string idioms for which a regular expression is overkill. If external modules become as efficient as we hope they are, there is no reason that *any* of the above should be CORE perl, but chop and chomp should certainly remain in the core distro. As is. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa
On Tue, 08 Aug 2000, Nathan Wiger wrote:
> There's two ways I see it:
>
> 1) do {} block
>
>$val = do {
> $x = 10;
> # ... stuff happens ...
> $y;
>};
>
> In which case $val = $y.
>
> 2) explicit our() scoping
>
>$x = 10;
>our $y = 10;
>{
> $x = 5; # auto-my'ed
> $y += $x; # $y already our'ed above
>}
>print "$y"; # 15
>
> Remember, you can still override the scopes I propose with an explicit
> my or our. Admittedly, 'blocks' is not nearly as big a benefit as 'subs'
> is, but has some applications, particularly if you're a "likes anonymous
> blocks" kind of person (which some people are).
This could lead to some ugly problems down the road.
You have the following block, with your above rules:
while($x)
{
$y += foo($x);
$x = bar($x);
$big_global_variable = analyze($y,$x);
}
This leaves you with three variables that may or may not be dependent
on the upper scope for resolution by default.
As written, $y, for instance, is local to the while loop, and is reset
on every iteration.
But, you could add a completely independent $y outside, (my, our, or
global), that then changes the context of $y inside the loop, which you
didn't even look at, and this is bad.
Compare to the old rules, where every variable is *always* dependent
on the upper scope, unless it's explicitly ignoring the upper scope.
While its true you can suffer a similar fate by supplanting a global
variable with a lexical variable in an intermediate scope, you're not
changing the scope context of the lower-level variables.
It's one thing to call a wrong number. It's another when the phone
company changes your number for you.
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: Things to remove
On Tue, 08 Aug 2000, Bennett Todd wrote: > If perl6 substantially fails to fill the important roles that perl5 > fills, we should stop screwing everybody up by calling it "perl", > and call it something else. Hmmm. I vote for "Edsel." -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 195 (v1) Retire chop().
On Thu, 07 Sep 2000, Michael G Schwern wrote: > Awww, does this mean we won't be seeing chip() and chimp() in Perl 6? Someone, (and I've lost who, exactly) was interested in taking those off my hands for a String::Utils module. I believe it was quite clear, however, that my root-and-measure-derived naming convention would be replaced with something a little more... Anglican. So yes, but no. Or no, but yes, since the question was asked in the negative. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 42 - Request For New Pragma: Shell
On Wed, 13 Sep 2000, Michael G Schwern wrote: > Sooo... what happens to the existing Shell.pm? The RFC title notwithstanding, the pragma would be, by convention, lowercase. (As reflected in the abstract.) Of course, should language features be added to allow scoping to be easily controlled, it could also be just as easily rolled in, although I think that might be counter-intuitive. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 42 - Request For New Pragma: Shell
On Wed, 13 Sep 2000, Michael G Schwern wrote: ...many good points, all of which I should have known. :-( I will modify the RFC to reflect that /\bshell\b/i is a poor name, due to the current Shell module. Personally, I don't particularly care what it's called - after all, I don't name things very meaningful anyway, now do I? All I care about is the underlying functionality. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulous builtins
On Wed, 20 Sep 2000, Damian Conway wrote: > This RFC proposes the builtin functions that return a large number of > values in an array context should also detect hashref contexts (see RFC > 21) and return their data in a kinder, gentler format. You may want to add a reference to the various existing modules that provide this type of interface. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: IDEA: my() extensions and attribute declarations
On Wed, 20 Sep 2000, Nathan Wiger wrote: >my int ($x, $y), char $z; # mix classes >my int ($x, $y) :64bit, char $z :long; # and attrs my (int ($x, $y), char $z); my (int ($x, $y) :64bit, char $z :long); -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Fri, 22 Sep 2000, Glenn Linderman wrote: > In my opinion, which you probably will also not agree with, attempting to > toggle between the current undef semantics and tristate semantics is like > trying to stuff three values into one bit. This comment assumes that the > current undef is implemented by a bit in a variable structure; when the bit is > in one state, it means the value is undef, and when the bit is in the other > state, it means the value is not undef. If this is what you're assuming, no wonder there's a disconnect. Explore overloading. I think it's where you're likely to find your solution. (Particularly with vtables behind them.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Non-RFC: Revisit (Un)signed Integer Bit Ops?
There have been several suggestions and RFCs to consider implementing
stronger typing -- C -- and attributes -- C -- for Perl.
Should we consider revisiting how current perl handles bit operations
on numbers, ie, based on the C pragma?
>From perlop:
---
Used on numbers, the bitwise operators ("&", "|", "^", "~", "<<",
and ">>") always produce integral results. (But see also the
Bitwise String Operators entry elsewhere in this document.)
However, `use integer' still has meaning for them. By default,
their results are interpreted as unsigned integers, but if `use
integer' is in effect, their results are interpreted as signed integers.
For example, `~0' usually evaluates to a large integral value.
However, `use integer; ~0' is `-1' on twos-complement machines.
---
The implementation is documented and is understandable, but is arguably
not readily apparent. (After all, bitwise operators already produce,
as it states above, integral results - it seems slightly confusing and
counter-intuitive to apply an integer pragma and have it potentially
alter the outcome.)
In some cases, this extends beyond simple reporting of the number as
signed or unsigned - it alters the behavior of the right shift (on some
platforms?)
Attribute? :signed, :unsigned, plus whatever additions allow you to set
and query attributes?
Typing? unsigned int, signed int, plus whatever additions allow you to
cast types?
New keywords? int() and uint(), for example?
New operator for right-shifting (sign-bit propagation)? >>>?
Stay the course?
--
Bryan C. Warnock
([EMAIL PROTECTED])
Re: RFC 361 (v1) Simplifying split()
On Sun, 01 Oct 2000, Sean M. Burke wrote:
> If you want to remove trailing fields, under Perl 6 you should have to
> do it explicitly:
>
>Perl 5: @x = split /:/, $bar;
> be synonymous with
>Perl 6: @x = split ':', $bar;
> while(@x and !length $x[-1]) { pop @x }
Which, to me, is a good reason to keep the current behavior.
--
Bryan C. Warnock
([EMAIL PROTECTED])
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: [FWP] sorting text in human-order
On Fri, 05 Jan 2001, Piers Cawley wrote: > But, but... 0.21 is *not* 'point twenty one', it's 'point two one', > otherwise you get into weirdness with: .21 and .210 being spoken as > 'point twenty one' and 'point two hundred (?:and)? ten' and all of a > sudden the '2' in that figure has gained an order of magnitude which > is just plain *wrong*. Then it would be "one eight zero zero point two one." Yes, at least the U.S. used to teach that the gratuitous use of "and" was wrong - "one thousand eight hundred twenty-one," but the rules have been loosened for integer numbers. One thousand eight hundred twenty-one. One thousand eight hundred and twenty-one Eighteen hundred and twenty-one. One thousand eight hundred and twenty-one hundredths. One thousand eight hundred and two million, one hundred thousand ten millionths. How did we get on this subject? Oh, yes, sorting by the number spelled out... That should throw several cultures for a loop. Four and twenty blackbirds, baked 'e' and 'pi'. > > Ghod knows how this GST would have you pronounce 5.6.0, 'five and six > and oh'? The computer kulture has its own rules for written and spoken grammar. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re:
On Wednesday 31 December 1969 18:59, Branden wrote: > Yes. Packaging is what's important. I actually expect to not have to install > the `par' and have perl6's magic filehandles decompress a file from the > package `on-the-fly'. I think zip is the way to go! Is there any > platform/license or any other restricting issues we should care about zip? > Is it ported to all platforms Perl currently runs on? Is there a Perl module > for handling zips? I've always handled this by slapping the .tgz package into the DATA section of a perl script that DWIMs. Sort of a self-executable zip file. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
On Sunday 11 February 2001 19:08, Jan Dubois wrote: > However, I couldn't solve the problem of "deterministic destruction > behavior": Currently Perl will call DESTROY on any object as soon as the > last reference to it goes out of scope. This becomes important if the > object own scarce external resources (e.g. file handles or database > connections) that are only freed during DESTROY. Postponing DESTROY until > an indeterminate time in the future can lead to program failures due to > resource exhaustion. But doesn't resource exhaustion usually trigger garbage collection and resource reallocation? (Not that this addresses the remainder of your post.) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Garbage collection
crossed to -internals Jan Dubois: > Not necessarily; you would have to implement it that way: When you try to > open a file and you don't succeed, you run the garbage collector and try > again. But what happens in the case of XS code: some external library > tries to open a file and gets a failure. How would it trigger a GC in the > Perl internals? It wouldn't know a thing that it had been embedded in a > Perl app. But that would be the point of the API, no? Even in XS, you'd interface through perl for memory or file management. So the core would still be able to invoke the GC. Granted, these are last-ditch efforts anyway - what would really be needed to trigger? E[MN]FILE? ENOMEM? Weird cases of ENOSPC? If you happen to hit one, force a GC pass, and retry whatever the call was. Even if the GC is unsuccessful (at resource reclamation), wouldn't you still want Perl to panic, vice the XS code anyway? > > This scheme would only work if *all* resources including memory and > garbage collection are handled by the OS (or at least by a virtual machine > like JVM or .NET runtime). But this still doesn't solve the destruction > order problem. Well, no. My thought would be if A needed to be destroyed before B, then B wouldn't/shouldn't be marked for GC until after A was destroyed. It might take several sweeps to clean an entire dependency tree, unfortunately. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Auto-install (was autoloaded...)
On Monday 12 February 2001 10:36, Branden wrote: > The problem is that we cannot access individual files inside the archive > without decompressing the whole archive, what is possible with .tar (not > ..gz) and .zip. Then we can assign a perl filehandle to access a file from > inside the archive and decompress it on-the-fly. Is that '.tar and .zip' as in '.tar and .zip' or '.tar or .zip'? Aren't most tars still unindexed, requiring a full file scan anyway? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Thursday 15 February 2001 19:21, Edward Peschko wrote: > How many times have I wanted to put 'use strict' in a module and forgotten > about it? Then it isn't, technically, a perl problem. > How many times have I wanted to use '-w' but was not able to because > of all the junk that comes out of it? That also, technically, isn't a perl problem. > > Make it by default and a large portion of the problem is solved. Define "large portion" and "the problem." > > If you get really used to -q, then it rolls off the fingertips: > '/usr/local/bin/perl -q'. If you really get used to "use strict;", then it rolls off the fingertips, too. > of course, but they will fix a large part of them. You'd be amazed how many > errors will be caught with 'use strict' and 'use warnings'... You'd be amazed how many errors *aren't* caught with strict and warnings. > > > If we're interested in increased CPAN quality, there's a bunch of stuff > > we can do. We can have a standard test suite that's run against every > > module uploaded to check if it's installable and compiles basically. We > > can check for -w, -T, use strict, and tons of other stuff. We can check > > But we don't want to check for '-w' and 'use strict'. We want to leave that up > to the module owner. All I want is a clear policy towards warnings and strict. > Thats a hell of a lot easier to achieve with something proactive. What can be more proactive than "Your code should work."? > > As for '-T', well, some modules don't *want* to be run in '-T' mode. Why not? Evvery module should handle untainted data, just in case, right? That is potentially far more dangerous than using a global in the wrong package, no? > In my experience, its always been the proactive policies which work the best. > Reactive policies have lots of shortcomings and are hard to set up. Which is > easier to do - prevent a fire or put one out after its started? Well, speaking from experience, put one out. There are an unbelievable number of ways a fire can start, a lot of them unforeseeable. But most fires themselves fall into a half-dozen classes, with fairly standard firefighting techniques. > And the more I think about it, you cannot make the project you describe > proactive - ie: we will not accept your module *until* conditions x,y,z occur - > this would be too onerous to accept for module developers. So you want to force people to adhere to strict rules, but it would be too onerous to force them to adhere to strict rules? (Personally, I don't care about the extra warnings, as long as I can shut them up. That doesn't really change perl's behavior. Forced strictness does.) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Closures and default lexical-scope for subs
On Friday 16 February 2001 07:36, Branden wrote: > But it surely isn't > consistent with the rest of the language. It's consistent with "our" and "local", which are really the only other things in the language that parallel its use. -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Closures and default lexical-scope for subs
On Friday 16 February 2001 09:24, Branden wrote: > I said: > > Anyway, I don't see why `local' (and `our' and `my') should bind more > > strongly than , and = . Because the implicit global scope declarator binds that tightly. Because you lose the ability to mix scope declarators in an assigment. (my $a, $b, local $,, my $c) = @_; I suppose the counter argument is you could then write that as (my($a),our($b),local($,),my($c)) = @_; Surely that would then allow (my $a, $b, $c) = @_; to be the same as my ($a,$b,$c) = @_; Oh, wait, commas are now implicitly parenthesized, so that (my $a, $b, $c) = @_; can be written as my $a, $b, $c = @_; That's going to affect some compound expressions, but those can easily be fixed by liberal uses of the 'scalar' operator, er, function, er, term. Oh, wait. That also doesn't behave quite right. That can also be tweaked, I'm sure. But what does that give you? You've now taken several existing behaviors of the language and completely changed it for no *net* improvement to the language. (Okay, that may be subjective, but feel free to argue how what you've added significantly outweighs a) what you've changed, and b) the fact that you changed it.) Now, admittedly, I've not done very much language design, but even in generic software design: - you think hard before adding functionality, and that added functionality had better provide a net improvement to the product, - you think even harder before removing functionality, and that the removal of functionality had better provide a larger net improvement to the product, - you do a complete brain drain before changing existing functionality, and that change had better provide a huge net improvement to the product, - you don't make any of these decisions arbitrarily. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
On Friday 16 February 2001 11:20, Branden wrote: > proposal. I don't think it works, because > > $a, $b, $c = @_;# $c gets 10 for @_=(1..10) > > mean a different thing that > > my $a, $b, $c = @_; # $c gets 3 for @_=(1..10) It does? > > The last code should behave as > > my $a, $b, ($c = @_); It doesn't? > > ie. $a, $b and $c are lexicals, and @_ is assigned to $c in scalar context. > I'm sure I posted this example a while ago. It didn't make sense then, either. Are you saying you wish to declare three lexical variables ($a and $b in void context, and $c to be the scalar value of @_?) > `my' DWIMs. But DWYM ne DWIM ne DWEM ne DWMPM ne DWSPM. This solution is like trying to solve the world's financial problems by taking the richest guy's wealth and distributing it among everyone else. It doesn't solve anything, it just redistributes the problem. > I know this is bad for who already writes Perl code. Then why is it being discussed? > But it would be very > good for who learns Perl and doesn't understand exactly when he should and > when he should not put parenthesis around `my's list of variables. Then maybe the documentation should be improved. Maybe makng a clearer delineation and how and why and when these work are in order. Particularly once attributes come out in full force, which will also bind more tightly than , or =. Simply offloading and compounding the problem isn't a viable solution. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Friday 16 February 2001 11:38, Branden wrote: > > (my($a),our($b),local($,),my($c)) = @_; > > What is it, anyway? A joke? (There's Perl poetry, why can't be there Perl > jokes?) Who writes this kind of code anyway? Okay, you caught me, it was a contrived exampled. The actual code was (my($foo),local($"),our($bar),my($baz)) = @_; ;-) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 14:45, Stephen P. Potter wrote: > Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]> whispered > : > | Yep; the perl manpage has said, since time immemorial, that > | the fact that -w was not on by default is a BUG. > > I don't know that I would say time immemorial. It wasn't in the man for > 4.036. I can only find man pages back to 5.002 right now, so I can't > check any earlier than that in the 5 tree. However, it was meant to be > (more than) slightly tongue-in-cheek. And there's a difference between warnings originating because something has gone wrong and those originating because I'm doing something particularly perlish. Unfortunately, -w doesn't (and probably can't) tell the difference. A friend of mine was attempting to install some commercial program (a D&D character generator, IIRC) on a Windows box - one that didn't have a sound card. It wouldn't run. It always crashed while trying to talk to the sound card. He procured someone else's laptop to do a demo install, and it ran fine - there are open and close window sound effects, and this voice-over guy that gives instructions. The first instruction given in the setup box? If you'd like to turn off the voice, click this box. Nothing else is sound dependent. Somehow I think there's a lesson to be learned here. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 16:03, John Porter wrote: > Bryan C. Warnock wrote: > > > > And there's a difference between warnings originating because something has > > gone wrong and those originating because I'm doing something particularly > > perlish. Unfortunately, -w doesn't (and probably can't) tell the > > difference. > > Can you give me an example of the former? > I can't think of any off the top of my head. Scalar value @foo[$bar] better written as $foo[$bar], for one. (But you probably would have thought of that if I had said something better than "something has gone wrong" which doesn't describe the above at all. I'm sorry, a completely horrible phrasing of what I was trying to say - I'll take me out back and shoot me now.) I'll try this again - the difference between a perceived user error, and a misused perl construct. The above error reflects an inability to distinguish between mulitple typos: either $foo or a list index. If part of Perl's breeding is autovivication and interpretation of undef as 0 or "" in the appropriate context, why should Perl bitch at me if I use it as such? Why should I have to ask permission to do so? I would rather say, and I think it would be more perlish to say, "I'm not feeling particularly perly today, can you check for anything clever, cause if there is, chances are it's a mistake." -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 22:03, Edward Peschko wrote: > > I *like* the interpretation of undef as 0 and "". It's useful. Sometimes. > > Sometimes it's not. And that's fine. > > No that's NOT fine. It leads to 'find the needle in the haystack' sort of > problems. If you get 1450 'use of undef value' errors, they are all useless. > > If you get 10 of them, and you know that the only time you are going to get > 'use of undef value' errors, they are very valuable. And how valuable they > are grows as the size of your project increases. > > > There's no reason in the world why that should replace undef -> 0 and "". > > See above. > > > > Or how about "I'm feeling particularly lazy today, I think I'll sleep in. > > Lets > > > worry about any mistakes I might make another day." > > > > Well, Laziness is One of the Three. > > Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by > default, because warnings and strict are great teaching tools. > > > Let me rephrase. > > Perl shouldn't bitch at me for valid perl. > > '-q'. None of that is the point. I don't disagree that having loads of warnings are a good thing. I don't disagree that having strict parsing rules, variable declarations, and the ilk are a good thing. There is no technical reason why warnings and strictness can't be the default. You with me so far? Everything you have said is perfectly valid, and if we were designing a brand-spanking new language, I might be arguing *for* you. But we're not, we're tweaking Perl. Perl, remember that language? The language that advertised all the above laziness? That the above laziness was part of its drawing power? This isn't an addition to the language that you're talking about - it's changing some of the fundamental behavior of the language. It's saying that no longer is Perl a loose, powerful language - oh, you want B&D? well, we can do that for you too - but rather that Perl is just another conventional programming language, (although if you flip this switch, you'll get its old, horrible behavior.) Sure, it will be easier to learn - it had better be, because *e-v-e-r-y-o-n-e* is going to have to learn it. Again. Look, most folks are probably sick of us going round and around about this, so I'll sum up my position. 1. There is no technical reason why warnings and strict can't be on by default, why undef must be able to promote to 0 or "", or just about any other feature a computer language can have. No technical reason. It may break some things, but those things can be fixed in their own right. 2. There are many non-technical reasons not to change codified behavior. This is why the last serious revamp of English spelling and grammar rules were aborted by the publication of the dictionary, why Americans adamantly refuse any doings with the metric system (except the 2 liter bottle), and why sports fans hate the instant replay. To change what some consider the philosophical essence of Perl is akin to a bait-and-switch, and I, for one, would feel cheated, (and if you'll allow me to wax melodramatic, betrayed). 3. While the argument is internal to us, I will remain steadfast in my stance against any arbitrary, widespread reversal of the language. 4. Should the Perl cabal deem that, for Perl to improve, it *must* undergo these radical changes, I will, to the best of my meager abilities, attempt to implement them. My position may seem a bit extreme - after all, didn't I, in the second RFC, attempt to autoprint statements in a void context? I started in the middle of the road, but as arguments like this have continued, I've moved wy to the minimalist's side. Hey, overhaul Perl to your heart's content so that you're able to do x, y, and z; just so long as Perl itself doesn't do x, y, and z. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Schwartzian transforms
On Wednesday 28 March 2001 11:47, Dan Sugalski wrote: > At 11:22 AM 3/28/2001 -0500, John Porter wrote: > >Dan Sugalski wrote: > > > It doesn't really matter if the functions inside the sort function are > > > idempotent--what matters is whether it's OK for us to go and memoize > > > the things (or whatever else we might choose to do) > > > >Exactly, that's what I've been trying to say. > >And that's why I propose the :constant/:function/:pure/:stateless > >attribute, so that perl only has to trust the programmer to say > >which functions can be memoized. > > I'm actually considering whether we even need to care what the programmer's > said. If we can just flat-out say "We may optimize your sort function, and > we make no guarantees as to the number of times tied data is fetched or > subs inside the sort sub are called" then life becomes much easier. > But you can't. A complex sort can currently by simplified, if desired. To invert the behavior (simplification first), you'd still need a way to recomplexify it, for the folks who need a fetch every time. > Of course, we may not be able to say that, in which case hints of any sort > are a Good Thing. Yes. One way or t'other. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Schwartzian transforms
Since I'm supposed to be summarizing this thread for Simon's weekly write-up,
let me make sure I have the four(?) basic suggestions/stances.
1) There are too many variations/problems/issues to bother having Perl try to
handle them all. If folks want an optimized sort, they should continue to
use the ST, or roll something similar.
2) Perl should create some form of special syntax explicitly for doing an ST
on data. (Other than the special syntax of the ST, of course.)
3) Perl should provide a general memoization mechanism, usable outside sort,
but that could be used to get ST-like behavior from a regular sort routine.
sort { f'($a) f''($b) &| ... &| f``($a) f`($b) } @list; or
sort { $a->f' $b->f'' &| ... &| $a->f`` $b->f` } @list;
Each value in list would have the results for f() cached for subsequent
comparisons within the sort. This would eliminate the need for the ST.
4) Should should grok a sort as an ST.
sort { f'($a) f''($b) &| ... &| f``($a) f`($b) } @list; or
sort { $a->f' $b->f'' &| ... &| $a->f`` $b->f` } @list;
Perl should see this and think aha!
map { $_->[0] }
sort { $a->[1] $b->[2] &| ... &| $a->[-2] $b->[-1] }
map { [$_, f'($_), f''($_), ... , f``($_), f`($_)] } @list;
Did I grossly miss anyone's position?
On Wednesday 28 March 2001 15:02, Dan Sugalski wrote:
> At 11:59 AM 3/28/2001 -0500, John Porter wrote:
> >Dan Sugalski wrote:
> > >...
> > > subs inside the sort sub are called" then life becomes much easier.
> >
> >Easier for perl. Don't we want to make life easier for the programmer?
> >I mean, in general, it would be nice if there were a way to have
> >perl memoize for us, rather than have to arrange it ourself.
> >It could benefit a lot of situations besides sorting.
>
> I'm not talking about making it easier on perl so much as making it faster.
> Basically to give us the wiggle room to recognize some simple constructs
> like
>
> foo($a) <=> bar($b)
>
> or
>
> foo($a) cmp bar($b)
>
> and optimize them to a table build and sort. This would work for plain perl
> data structures as well, as we might potentially be doing a fair amount of
> data conversion through the variable vtable interface. (Not to mention the
> issues of data mangling for proper Unicode sorting support)
>
> Dan
>
> --"it's like this"---
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Dot can DWIM without whitespace
On Wednesday 25 April 2001 18:33, Edward Peschko wrote: > On Wed, Apr 25, 2001 at 06:30:37PM +0100, Simon Cozens wrote: > > On Tue, Apr 24, 2001 at 07:38:50PM -0700, Brent Dax wrote: > > > IMHO, . can DWIM in most cases even if it's both object deref > > > _and_ concat--without paying any attention to whitespace. > > > > Please, no. Some of us have to *teach* this language. > > Then I guess that either space sensitive '.' is the answer, or '_'. I > personally prefer the space sensitive '.' because it is compatible > with perl5, and I think people would have less difficulty with it > even if it was doing double duty in the language. And its visually > easy to spot the difference between the two constructs. '.' is already, to some extent, space sensitive anyway, because it has to pull double duty as a decimal point, as well. '4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Dot can DWIM without whitespace
On Wednesday 25 April 2001 21:37, Edward Peschko wrote: > > '.' is already, to some extent, space sensitive anyway, because it > > has to pull double duty as a decimal point, as well. > > > > '4.5' (4.5) vs '4 .5' (45) vs '4. 5' (missing operator) > > beautiful. Then extending this is simple, consistent, easy to read, > compatible with perl5.. I'm not sure that that was the point I was trying to make. If nothing else, the '.' would then be responsible for *three* different actions. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Apoc2 - concerns
On Saturday 05 May 2001 19:28, Uri Guttman wrote: > the proposed qh only fails with a key or value of => which is highly > unlikely and can be worked around as a value by inserting another => > > %foo = qh( foo bar => => baz ) > > is: > > %foo = ( foo => 1, bar => '=>', baz => 1 ) Or it could be %foo = ( foo => 1, bar => 1, '=>' => 'baz' ) But I like the concept of a quote hash. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: what I meant about hungarian notation
On Wednesday 09 May 2001 10:44, David Grove wrote:
> I used to request hungarian notation from programmers who worked for me,
> until I saw the actual compliance with that request culminate in a local
> variable named l_st_uliI. Of course, that's an "static unsigned int i"
> used as a simple iterator in local scope. Of course, written more
> appropriately, this would have just been "static unsigned int i". At that
> point, Hungarian notation fell apart for me. Its strict use adds (IMO) as
> much confusion as MicroSoft's redefinition of C, with thousands of
> typedefs representing basic types ("LPSTR" and "HWND" come to mind as the
> most common).
Not mention the hoop-jumping required to keep variable names in sync with
code changes. (signed-ness, short->int->long, etc)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Damian Conway's Exegesis 2
On Tuesday 15 May 2001 21:07, Damian Conway wrote: > John Siracusa wrote: >> Okay, this part has me confused. > > And rightly so: it was a screw-up. I lost track of whether I was keeping > the property on the value or on the node reference and ended up doing > both. What? You didn't test it before you posted it? For shame! ;-) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Damian Conway's Exegesis 2
On Tuesday 15 May 2001 21:17, Simon Cozens wrote: > On Tue, May 15, 2001 at 09:11:21PM -0400, Bryan C. Warnock wrote: > > What? You didn't test it before you posted it? For shame! ;-) > > Bah. Damian and I are working on ways of prototyping the Perl 6 > interpreter in Perl 5 for testing. We have the variable semantics sorted > out, but properties might be a little more difficult. my $surprise is zero; -- Bryan C. Warnock [EMAIL PROTECTED]
Parsing perl > 6.0
Jumping the gun a little
With the pluggable parser architecture, would it be a Good/Bad/Ugly Thing to
freeze the parser itself after each Perl release?
One of the omnipresent arguments against any change is how it affects legacy.
Although Perl 6[.0] is a recognizable departure from Perl 5.x syntax, so have
been Perl 5.x from Perl 5.(x-1) and will be Perl 6.x from Perl 6.(x-1), if
only to a lesser extent.
Perl 6 is planning on addressing the bulk of the Perl 5 legacy issue with a
pluggable parser capable of parsing Perl 5.n. Why not do the same thing in
the future with minor revs?
Currently, with each release, the parser is extended/fixed/modified in place
with the development of the next version. Instead, why not freeze the parser
in place at each release, and then use it as a jumping off point for the next
parser? The frozen parser could then be CPANned as a legacy parser.
Bennies:
- Guaranteed language basis for the future. Code written explicitly for Perl
6.0 will be parsed according to Perl 6.0 rules.(1) Code written generically
for perl can easily be "rolled back" if the next version of Perl breaks some
reliance on the older parsing rules.
- Fits within the "mix and match" module munging that is being planned. Perl
6.0 code could potentially interface with Perl 7.0 modules/packages/classes,
and vice versa.
- By definition, doesn't need to be maintained.(2) Once it's frozen, it's
frozen. This is behavior that people expect, however intentional or not the
behavior actually is. Er, was.
Troublespots:
- (1) Parsing would be consistant, but obviously runtime behavior could still
change, depending, for instance, on whether the parse-tree optimizer would be
coupled with the parser or with the underlying architecture. Future
optimizers may subtly change the behavior of a legacy parse-tree. This is
the same issue that will plague "compiled" code, so it needs to be addressed
somehow anyway.
- (2) Obviously, opcode deletion (or something similar) may require the
parser's output to be changed.
- Who wants umpteen different perl parsers lying around their code base?
Other impacts:
- C semantics would have to be changed. Or whatever the parser
identifier will be. You'll need to differentiate between an exact match and
a minimum match.
use perl 6.0;
use >= perl 6.0; # or use perl >= 6.0?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: my $howmany=wantarray; while($howmany--){push @R,onemore};
On Friday 01 June 2001 11:06 pm, David L. Nicol wrote: > having wantarray return the number of items needed, or -1 for > all of them, would work very nicely for user-written partial returners. > > Did anyone RFC that? RFC 21's expectation counts, I believe. (Except it's ~0 vice -1 for all items.) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: my $howmany=wantarray; while($howmany--){push @R,onemore};
On Saturday 02 June 2001 11:21 am, Bryan C. Warnock wrote: > On Friday 01 June 2001 11:06 pm, David L. Nicol wrote: > > having wantarray return the number of items needed, or -1 for > > all of them, would work very nicely for user-written partial returners. > > > > Did anyone RFC that? > > RFC 21's expectation counts, I believe. > (Except it's ~0 vice -1 for all items.) On a side note, I was having difficulty finding an RFC yesterday as well, so I put together this rough index. Once I clean it up and verify the categories, I'll see if Ask can hang it off the main RFC page. (Some of the categories are still fairly hefty, I'm afraid. But 40 is better than 340.) Arrays, Lists, and Slices 21 Subroutines: Replace C with a generic C function 24 Data types: Semi-finite (lazy) lists 37 Positional Return Lists Considered Harmful 51 Angle brackets should accept filenames and lists 52 List context return from filesystem functions 81 Lazily evaluated list generation functions 82 Arrays: Apply operators element-wise in a list context 90 Arrays: merge() and unmerge() 91 Arrays: part and flatten 94 Rename @ARGV to @ARGS 105 Remove "In string @ must be \@" fatal error 109 Less line noise - let's get rid of @% 118 lvalue subs: parameters, explicit assignment, and wantarray() changes 134 Alternative array and hash slicing 148 Arrays: Add reshape() for multi-dimensional array reshaping 151 Merge C<$!>, C<$^E>, C<$@> and C<$?> 152 Replace invocant in @_ with self() builtin 166 Alternative lists and quoting of things 169 Proposed syntax for matrix element access and slicing. 175 Add C keyword to force list context (like C) 177 A Natural Syntax Extension For Chained References (aka Multidimensional Arrays/Hashes) 179 More functions from set theory to manipulate arrays 186 Standard support for opening i/o handles on scalars and arrays-of-scalars 202 Arrays: Overview of multidimensional array RFCs (RFC 203 through RFC 207) 203 Arrays: Notation for declaring and creating arrays 204 Arrays: Use list reference for multidimensional array access 205 Arrays: New operator ';' for creating array slices 206 Arrays: @#arr for getting the dimensions of an array 207 Arrays: Efficient Array Loops 212 Make length(@array) work 231 Data: Multi-dimensional arrays/hashes and slices 238 length(@ary) deserves a warning 268 Keyed arrays 272 Arrays: transpose() 282 Open-ended slices 283 C in array context should return a histogram 299 C<@STACK> - a modifyable C 344 Elements of @_ should be read-only by default 360 Allow multiply matched groups in regexes to return a listref of all matches Building and Development 46 Use features of portable, free compilers and libraries 50 BiDirectional Support in PERL 55 Compilation: Remove requirement for final true value in require-d and do-ed files 61 Interfaces for linking C objects into perlsubs 121 linkable output mode 141 This Is The Last Major Revision 160 Function-call named parameters (with compiler optimizations) 172 Precompiled Perl scripts. 184 Perl should support an interactive mode. 210 Data/Binary Dumping and Freezing 225 Data: Superpositions 227 Extend the window to turn on taint mode 281 The Perl 6 Development Log 287 Improve Perl Persistance 292 Extensions to the perl debugger 297 Attributes for compiler hints 301 Cache byte-compiled programs and modules 304 C algorithm to be selectable at compile time 305 C<$^C> should be true when compiling 314 A parser is a many-layered thing Comments, POD, and documentation 5 Multiline Comments for Perl. 11 Examples encoded with =also for|begin|end POD commands 44 Bring Documentation Closer To Whatever It Documents 65 Add change bar functionality to pod 79 The Predefined POD Streams are C, C, and C 102 Inline Comments for Perl. 176 subroutine / generic entity documentation 216 POD should tolerate white space. 217 POD needs a reorder command. 240 Form a documentation working group to edit, clean, and produce documentation 280 Tweak POD's CEE 286 Add a "emit pod" runtime option to Perl 306 User-definable POD handling 325 POD and comments handling in perl 357 Perl should use XML for documentation instead of POD Context 21 Subroutines: Replace C with a generic C function 45 C<||> and C<&&> should propagate result context to both sides 52 List context return from filesystem functions 82 Arrays: Apply operators element-wise in a list context 98 context-based method overloading 118 lvalue subs: parameters, explicit assignment, and wantarray() changes 128 Subroutines: Extend subroutine contexts to include name parameters and lazy arguments 175 Add C keyword to force list context (like C) 226 Selective interpolation in single quotish context. 259 Builtins : Make use of hashref context
Re: as long as we are discussing 'nice to have's...
On Monday 23 July 2001 14:05, Dave Storrs wrote: > No, I do not mean something like Devel::DProf; that is a > module. I mean something that is in the core binary, the same way that > the perl debugger is in the core binary. Except that the perl debugger is not in the perl binary. There are hooks in the binary that a program may use for debugging, profiling, and such. perl -d simply invokes one of those programs by default. In some sense, these hooks could simply be replaced by the previously mentioned (BEGIN|END) (BLOCK|STATEMENT) structure - since that is mainly what they are. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: if then else otherwise ...
Linguistically, "if then else, otherwise" doesn't make sense, since 'else'
and 'otherwise' are synonymous.
? : : suffers from the same problem, just in terms of the ternary ?:
operator (which of course, wouldn't be ternary anymore) instead of English.
I'm not sure if there will be ambiguity where the standalone colon is being
used elsewhere, but I suspect that it would make parsing more difficult.
(At least in a BNF grammar.)
Regardless of how you perceive the results of <=> and cmp, it's still two
conditionals. Something has to make the differentiation between positive
and negative.
You're simply asking for another way of writing 'if {} elsif {} else {}',
because you don't like 'elsif'. Fine. As has been said before, use a
switch.
given ($cond) {
when 1:
when 0:
when -1:
}
Is the marker still ^_?
given ($cond) {
when ^_ > 0:
when ^_ < 0:
default: # Or whatever default will be named.
}
Still too verbose? Let's look at your example
> $whereCond = $cond ? ' field > $x AND ' : '' : ' field < $x AND';
> $Query = qq{ SELECT FROM ... WHERE $whereCond ...};
I think if you specify WHERE you need a clause.
'SELECT foo FROM bar WHERE' doesn't make sense.
my @c = qw( = > < );
$x = 60;
foreach my $cond (40 <=> $x,60 <=> $x,80 <=> $x) {
$query = qq{ SELECT ... FROM ... WHERE field $c[$cond] $x };
print "$query\n";
}
Even less to type. Maybe not all *that* clear, but no less than ?:, ?::,
and ?:?: all meaning different things.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: if then else otherwise ...
On Sunday 29 July 2001 04:32 pm, raptor wrote:
> index(ref $var, 'A') - 1 ? SCALAR-LVALUE-case : HASH-case : ARRAY-case;
That one is actually rather clever
Most of your examples, however, look like you are attempting to bandage some
poorly designed code upstream. (Perhaps not, but writing logic built around
<=> or cmp as a control flow is rarely a good idea.)
>
> $x = $a <=> $b ? $a : $default : $b;
>
This was your lone example that actually made some sense, and the only
non-standard answers (by which I mean conventional control flow methods) I
can think of are:
$x = ($default,$a,$b)[$b<=>$a]; # Much like I did before
($x) = sort { $a <=> $b or $default } ($a,$b);
# Since <=> and cmp were created more-or-less specifically for sort
The former is faster than the latter, but neither are as quick as the more
conventional structures.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Lexicals within statement conditionals
Yes, this is semi-related to the 'my $a if 0;' behavior.
Out of morbid curiosity (since I'm working on documentation), given the
program that the following program generates:
#!/your/path/to/perl -w# perl 5.6.1
my @l = ('a' .. 'g');
my $my = 0;
for my $v (@l) {
my @a = map { "\$$v .= '$_'" } @l;
$a[$my++] = "my $a[$my]";
print shift @a, ";\n{\n",
join (", ", @a[@a/2 .. $#a]), " if ",
join (", ", @a[0 .. @a/2-1]), ";\n";
print <<"EOF";
print "$v: \$$v\\n";
}
print "$v: \$$v\\n";
EOF
}
__END__
I'm found tests B, C, and D a little surprising. I expected 'befg/acd',
'cefg/abd', and 'defg/abc' (lexical/global answers, respectively).
Although I now understand what it does, I'm still fuzzy on the why and how.
Can someone in the know give a clear enough explanation that I can document?
The rest of you can debate whether or not this behavior should change for
Perl 6.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Lexicals within statement conditionals
On Monday 30 July 2001 05:37 am, Me wrote: > In a nutshell, you are viewing: > > foo if bar; > > as two statements rather than one, right? > Yep. The 5.7 docs explain it rather well, I think. Too bad I didn't read them until *after* I had posted and taken off for work. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: if then else otherwise ...
On Monday 30 July 2001 07:29 am, Bart Lateur wrote: > On Sun, 29 Jul 2001 19:36:43 -0400, Bryan C. Warnock wrote: > >$x = ($default,$a,$b)[$b<=>$a]; # Much like I did before > > Note that > > $x = cond? a : b > > does lazy evaluation, i.e. the value for a or for b is only fetched when > it's actually needed. In your construct, they're all fetched anyway, > before the condition is even checked. Excellent point. Something to remember for the future. -- Bryan C. Warnock [EMAIL PROTECTED]
Extending POD (was (indented tables))
(migrated from perl-qa) On Wednesday 01 August 2001 03:10 pm, David L. Nicol wrote: > "Bryan C. Warnock" wrote: > > I didn't have a good solution for tables, mainly because I didn't like a > > tab, comma, or pipe separated solution. (Which isn't intended as > > commentary on Ziggy.) > > Here's a possibility -- new rows are indicated by a flush-left line, > each column has a line. (this happens to be how I like to lay out > my data data.) > > Table of Students: > > Last Name > First Name > Exam Grade > Semester Grade > Cup Size > Aardvark > Chris > D > B > A > > > The thing might end at the first blank line. It's too awkward to read and write, particular if you have a lot of columns. I toyed with automatic column detection for a while - (convert any tabs to spaces, convert whitespace to 1s, non-whitespace to 0s, and & all the lines together. Splitting on /(1+)/ allows determination on each individual column width, as well as the space between columns. Then generate the appropriate format on the fly, and fill it in with the heavy use of substrs. It was supposed to allow table creation in the same vein as "I'll figure out what you're trying to do, just do it.", and it worked fairly well for me. Couldn't handle multiline entries, was my biggest problem. Then I realized that I was doing it all in a fixed width font, and the whole thing was worthless in the customer's WYSIWYG environment. But I digress...) I basically came to the conclusion that there was no real easy way to produce a table without resorting to input that makes you focus more on the table itself than the data you're putting in. And when it comes to documentation, the latter is much more important than the former. Unlike Ziggy, however, we didn't have a lot of tables to produce, so the customer was content with table production in a spreadsheet, which I could then process during page generation. Obviously, that won't work for POD, and I do feel that POD needs table support. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: stealing something from plan9 os
On Wednesday 01 August 2001 10:04 pm, David L. Nicol wrote: > I hope this isn't too stale to talk about. > This is perl6-language. Nothing, it seems, is too stale to talk about. We're still brainstorming, even though the RFC period ended 10 months ago. > Please restrain from telling me that the discussion is over > and the "." decision is made ond over, for the moment. Okay, but. > > James Mastros wrote: (on June 21) > > > I still fail to see why "." is such an advantage over ->. > > The only real benifit I see is typing ease, and -> isn't that > > hard to type. That's what editor macros are for. > > What about replacing "->" with "/" ? Your idea aside, I think the substitution was more to gain the '.' than to replace the '->'. -- Bryan C. Warnock [EMAIL PROTECTED]
properties, revisited
If I've got a set of matching properties, do I get to build hotels on my hashes? There are a number of properties "built into" Perl 6. Nearly all of these properties don't make sense across the board - eg, a scalar won't have a dimension, a hash won't prompt, etc. So given the two different sets that you must consider (variable versus value, and hash versus array versus scalar versus filehandle), are properties that are meaningless for some section usable by the user? (Realizing that there was talk about distinguishing between value and variable properties...) # scalar variable property doesn't allow $foo to be changed $foo is constant = 3; # But this doesn't make sense, as 3 is already constant. $foo = 3 is constant; # Error? Or simply user-defined? Example 2: $*ARGS is chomped; # Fine, but %hash is chomped; # Is this legal? An error? # (The chomp character is defined by the IRS attribute of a filehandle.) # Can I define something that says to chomp the values entered # into the hash? The keys? # What if the hash is tied to a filehandle? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: properties, revisited
Here's how I'm documenting it. Corrections requested. Properties are by Perl thingy. (scalar, array, hash, reference, blessed reference?, file handle, etc) That allows different things to be 'foo', for the appropriate definition of 'foo'. --- Second thought: Scribbling Servant from Savage writes: Damian, You mentioned in E2 that the chomped property relies on the insep property of the filehandle (formerly $/). Can I extrapolate that $. $, $\ $| will also be properties on filehandles? (How about $" for arrays?) Will they only be accessable as properties, or will there also be a proper member/method of some class (or metaclass)? The syntax (currently) is the same. Come to think of it, are properties really anything more than a nicer (IMHO), more Anglican replacement than traditional get_ and set_ methods? Properties interract with (potentially dynamic attributes), while member functions do the real work. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: properties, revisited
On Friday 03 August 2001 04:09 pm, Brent Dax wrote:
> # %foo is constant = (a=>1, b=>$foo);
> #
> # are only the keys contant; or both the keys and values.
>
> Keys and values, I imagine.
>
> # i.e. which of these is illegal
> #
> # %foo{c} = 1; # error
> # %foo{a} = 2; # probably error, but it would be nice
> # # to have a form of hash-constness that
> # # locks only the keys
> # $foo{b}->increment; # OK
>
> That "form of hash-constness that locks only the keys" is currently being
> discussed on p5p; it's being called clamp. So you could probably say
>
> %foo is clamped;
>
> and get that behavior.
Both arrays and hashes probably warrant something. I understood 'clamp' on
p5p in verb context, but would rather see something a little more
descriptive as an adjective.
I was originally thinking 'fixed', but that makes the distinction between
changable and non-changeable internal values nebious - which is constant and
which is fixed?
I then thought about 'resizable' That wouldn't allow the addition or
deletion of keys (or indices), but would allow the internal values to be
changed.
Today, I don't particularly care anymore.
In any case, properties will be pushed to the bottom of my stack for things
to document. There's a lot of Perl 6 contending for the bottom position, it
seems.
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: properties, revisited
On Thursday 02 August 2001 08:47 pm, Dan Sugalski wrote: > At 06:57 PM 8/2/2001 -0400, Bryan C. Warnock wrote: > >Here's how I'm documenting it. Corrections requested. > > > >Properties are by Perl thingy. (scalar, array, hash, reference, blessed > >reference?, file handle, etc) > > I think they're supposed to be both by perl thingie and by value. So: > I was generally classifying literals as scalars (even though I realize they're not scalars, they're literals - the specific properties overlapped). It seems the only consistent interpretation is that the differentiation between a variable property and a value property is what side of the assignent operator you're on. (Which is wrong, as I'll explore below. I'm leaving my misconceptions in place for whomever to examine, as a case study for further misconceptions.) >my $foo is const = 0 is true; my $bar is const = $foo is true; I'm assuming here that (assume $foo is mutable) that it's the value of $foo that is being tagged as true, and not $foo itself. (Not that it would make a lot of sense as a variable property.) But is that value tagged before or after the value itself has been retrieved? Is the value inside $foo above tagged as true or not? > the trueness of 0 is copied (since the value is copied, along with > properties on the value) while the constness of $foo is *not* copied, as > it's a variable property and those stick with the variables. Now that you've got me thinking about it, that brings up some interesting questions. $bar = $foo is my_prop = 0 is some_prop; ($bar = $foo is my_prop) = 0 is some_prop; $bar = ($foo is my_prop) = 0 is some_prop; Who's what when this is all done? How about void or boolean contexts? Damian uses this a lot in E2. $foo is chomped; $foo prompts; bar while ($foo is greedy); Hmmm. Actually, what makes *more* sense than that is the property itself. I think a property will need to tell Perl (or maybe handle it itself) whether it is a value property or a variable property. $bar is constant = $foo is true; # constant is a variable property, true is a value property. Therefore, # $bar is constant, and the constant isn't clonable. $bar is also true, and # that *is* clonable. But wait, what it we want to make $foo true? Or, actually, the value in $foo true? $foo is true; $foo = $foo is true? (And could that be shortened to '$foo is= true;'?) $foo is now true;? (Allow 'now' to refer to the thing holding the current value?) $bar is constant = $foo is now true; (And speaking of trueness, how do you turn it off if you want? You can't say '$bar is false', cause then the value is always false.) $foo is true = $bar is constant; # The value in $foo (gotten from $bar) is true. $bar is made constant. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: properties, revisited
On Thursday 02 August 2001 10:38 pm, Edward Peschko wrote: > Statement: $bar isnt my_prop; > > This makes $bar keep all of its properties, removing my_prop; No. This gives $bar the negation of my_prop, whatever it may be. It may be its removal, it may be something else. > Anyways, just a clarification. Get rid of the distinction between 'value' > or 'variable' properties, and you have no clumsy syntax or confusion. No, you simply have a different clumsy syntax and different confusion. And you lose the distinction between properties, which, I agree, wouldn't be bad, except that there is a distinction between variables and the values they contain. For "out of band" data, properties sure have a strong affect on things. -- Bryan C. Warnock [EMAIL PROTECTED]
