goof - RFC 328 (v1) Single quotes don't interpolate \' and \\
I goofed. (EWRONGLIST) I realise now that I should have said that RFC 328 (and 327) should have been on this list, not perl-language-data I had what I thought was a good look at previous RFCs but managed to miss RFC226 (Selective interpolation in single quotish context.) What I wanted comments about (I'm not sure if I favour it and so far 2 people have said they don't) is whether to be very strict on q// == '' == *NO* interpolation [Nathan Wiger, http://www.mail-archive.com/perl6-language@perl.org/msg04005.html ] and hence "cure" Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? [Steve Fink, http://www.mail-archive.com/perl6-language@perl.org/msg04008.html ] by removing all \ escapes from '' and q(), to make perl's use of '' just like /bin/sh, and identical to how perl treats <<'HERE' I've asked the librarian what I should do, but as there's little time left to demolish this idea, I've sent this mail here now. Nicholas Clark
Re: Why shouldn't sleep(0.5) DWIM?
Stephen P . Potter <[EMAIL PROTECTED]> writes: >Lightning flashed, thunder crashed and Jarkko Hietaniemi <[EMAIL PROTECTED]> whispered >: >| I guess it's part of the can of sub-second worms: if we do sleep(), >| people will ask why don't we do time() and alarm(), too. sleep() and >| alarm() we could get away with more easily, but changing time() to do >| subsecond granularity would be A Bad Thing for backward compatibility. > >Why do we have to worry about changing time()? There's a real parallel >between sleep() and alarm(), so we would want to do both if we did either, >but time() really has no relation to them. > >Or, should we just implement usleep() and (for lack of a better name) snooze() is a better name ;-) -- Nick Ing-Simmons
Re: Larry's Apocalypse 1
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> But the structure you speak of exists only on the server. A URL as
>> accessor reference doesn't really need to know anything about the opening
>> of that path other than the fact that it is a URL. This renders it pretty
>> useless as a structure to be interpreted *as* a structure as far as the
>
>if (open(BLAH, ">mailto:[EMAIL PROTECTED]")) { ...
You mean something like:
if (open(BLAH,">:URL","mailto:[EMAIL PROTECTED]")) { ...
Now PerlIO/URL.pm has to know the semantics of /^mailto:/.
If it does it can do DNS lookup for MX record for north.pole and
presumably fail and return undef.
Oops sorry that is perl5 ;-)
--
Nick Ing-Simmons
Re: Larry's Apocalypse 1
Adam Turoff <[EMAIL PROTECTED]> writes: >On Fri, Apr 06, 2001 at 03:31:56PM -0400, John Porter wrote: >> Jarkko Hietaniemi wrote: >> > So URLs are not >> > literals, they have structure, and only thinking of them as filenames >> > may be too simplistic. >> >> Yeah. But Rebol manages to deal with them. > >I doubt it. telephone:? fax:? lpp:? callto:? uuid:? > >If Rebol can handle all of those URL schemes, why bother with Perl >in the first place? > >> I don't know if this is something we want to follow Rebol's >> lead on, but it's something to look at. > >Sounds like if there's a 'use url;' clause in use, then the standard >three (mailto:, http:, ftp:) might be available, whereas other >URL schemes would need different declarations (use url::dns;). Why not have URL.pm look for the appropriate module PerlIO::URL::fax say - as I recall that is what LWP does in the mundane perl5.003 world. > >Z. -- Nick Ing-Simmons
Re: Larry's Apocalypse 1
Dan Brian <[EMAIL PROTECTED]> writes:
>> if (open(BLAH,">:URL","mailto:[EMAIL PROTECTED]")) { ...
>>
>> Now PerlIO/URL.pm has to know the semantics of /^mailto:/.
>> If it does it can do DNS lookup for MX record for north.pole and
>> presumably fail and return undef.
>>
>> Oops sorry that is perl5 ;-)
>
>Which part? "Presumably", "fail", "undef" ? ;-)
Well no one has written PerlIO::URL yet so all you get is:
nick@dromedary 507$ cd /home/perl5/perlio
nick@dromedary 508$ ./perl -Ilib -e
'open(BLAH,">:URL","mailto:[EMAIL PROTECTED]") || die $!'
Can't locate PerlIO/URL.pm in @INC (@INC contains: lib
/usr/local/perl/lib/5.7.0/i686-linux-multi /usr/local/perl/lib/5.7.0
/usr/local/perl/lib/site_perl/5.7.0/i686-linux-multi
/usr/local/perl/lib/site_perl/5.7.0
/usr/local/perl/lib/site_perl/5.6.1/i686-linux-multi
/usr/local/perl/lib/site_perl/5.6.1 /usr/local/perl/lib/site_perl .) at (eval 1) line
3.
perlio: unknown layer "URL".
Of course they might want to write it in perl so that would be:
nick@dromedary 509$ ./perl -Ilib -e
'open(BLAH,">:Via(URL)","mailto:[EMAIL PROTECTED]") || die $!'
Cannot find package 'URL'.
Attempt to free unreferenced scalar.
Died.
Which shows a buglet ...
and now I have mailto:santa.claus.pole which shows that I meant
"mailto:santa.claus\@north.pole" anyway ...
--
Nick Ing-Simmons
Re: Strings vs Numbers (Re: Tying & Overloading)
Bart Lateur <[EMAIL PROTECTED]> writes:
>On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:
>
>>How do you concatenate together a list of variables that's longer than one
>>line without using super-long lines? Going to the shell syntax of:
>>
>>PATH=/some/long:/bunch/of:/stuff
>>PATH="${PATH}:/more/stuff"
>>
>>would really be a shame.
>
>A backslash at the end of a line?
>
>Kidding!
Obviously you meant a '+' in column 6 of the continuation line ;-)
--
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/
Re: Tying & Overloading
James Mastros <[EMAIL PROTECTED]> writes: >From: "Larry Wall" <[EMAIL PROTECTED]> >Sent: Monday, April 23, 2001 1:10 PM >Subject: Re: Tying & Overloading >> Helgason writes: >> : I _really_ think dot-syntax would make perl prettier as well as make it >> : more acceptable to the world of javacsharpbasic droids. Which is some >> : kind of goal, no? >> Consider it a given that we'll be using . for dereferencing. (Possibly >> with -> as a synonym, just for Dan. :-) >> >> Larry > >I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY >PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? One reason I have heard is that COM (Common Object Model) documents incantations to call up external objects in VBish thing.whatnot.attrib style. Not having to s/\./->/ make it easier on newbies. -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
Re: So, we need a code name...
Larry Wall <[EMAIL PROTECTED]> writes: >Then Perl language variants could go the other way and be: > >Pern Nano Perl Network perl - then we can say "here be dragons - but friendly ones..." -- Nick Ing-Simmons
Re: apo 2
Michael G Schwern <[EMAIL PROTECTED]> writes: >On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote: >> And btw . . . Wouldn't >> >> $thing has property As in "door has redness" - ugh vs "door is red". Property should be an adjective, not a noun. >> >> make more sense than >> >> $thing is property > >"$foo has true" doesn't flow as well as "$foo is true". Dunno quite >what the other expected uses are. -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
Re: Apo2: \Q ambiguity
Larry Wall <[EMAIL PROTECTED]> writes: >Dan Sugalski writes: >: Have you considered allowing Unicode characters as alternatives to some of >: the less pleasant looking bits? $foo<<1>> (where << and >> are the double >: angle characters) as an alternative to $foo\Q[1] if the user's got the >: characters handy? > >Actually, my first thought a year or three ago was to replace qw() >with «», but we just aren't there with the Unicode editors yet. >My keyboard seems to be missing a few of the characters, too. :-) MultiKey < < is what it takes «here». But I don't see why AltGr < should not work (SuSE Linux's keymap is so un-mnemonic compared to Sun's compose key scheme). -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
Re: Typeglobs, filehandles, asterisks
Buddha Buck <[EMAIL PROTECTED]> writes:
>I haven't looked at the internals for local, but isn't:
>
>{
> local $foo;
>
> ...
>}
>
>effectively syntactic sugar for:
>
>{
> my $unnamed_foo = $foo; # $unnamed_foo not accessible
>
> ...
>
> $foo = $unnamed_foo;
>}
>
>Is there something in the behavior of local I'm missing?
There certainly is - that functions _called_ in the scope of the
local see the $unnamed_foo as the value of $foo too.
While hard to get ones brain round at first is is amazingly useful
on occasion.
--
Nick Ing-Simmons
Re: formats and localtime
Chaim Frenkel <[EMAIL PROTECTED]> writes: >>>>>> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: > >LW> But yelling that formats are essential to the core reminds me of my >LW> kids, who sometimes act as if they're being excoriated when we're >LW> merely trying to get them out of their dirty clothes and into some >LW> clean clothes. As humans we identify too closely with our clothes. > >What do you mean by core? Core users or core perl engine? I assume 'core perl engine' i.e. /usr/bin/perl or perl.exe they will of course be provided in perl6.tar.gz We need a quick glossary: perl core: perl.exe + perl.dll or .../bin/perl + libperl.so perl distribution anything from perl6.tar.gz Optional module things in CPAN -- Nick Ing-Simmons
RE: Typeglobs, filehandles, asterisks
Garrett Goebel <[EMAIL PROTECTED]> writes: >Personally, I like to be able to directly access the symbol table. I think that will be essential. And not just the perl5 symbol table but lexicals and the "which file" and other "methods" that B:: provide. >It is >nice when generating classes from a template. I hope typeglobs go in the >washing machine instead of the bathtub. But, I don't mind it they are hard >to recognize when they come back. What _should_ symbol table access look like to the perl programmer? -- Nick Ing-Simmons <[EMAIL PROTECTED]> Via, but not speaking for: Texas Instruments Ltd.
Re: date interface (was Re: perl6 requirements, on bootstrap)
Simon Cozens <[EMAIL PROTECTED]> writes: >On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote: >> I like perl's smart built-in IO just fine, thanks. :) Don't mind making it >> better, but I do mind making it optional. > >If we're going to do line disciplines, we need a built-in stdio replacement. >Full ground-up rewrite, like sfio but Perlish. I think that is almost a given - we have been on verge of doing it for perl5 for years. -- Nick Ing-Simmons
Re: multiline comments
Buddha Buck <[EMAIL PROTECTED]> writes:
>
>The one concern I would raise about this is that a common use of multi-line
>comments is to dyke out code.
What is wrong with
if (0) {
}
(and of course teaching op builder not to build them in this case).
--
Nick Ing-Simmons
Re: perl6 requirements
Chaim Frenkel <[EMAIL PROTECTED]> writes: >>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > >DS> At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote: >>> We may need that all variables are by default lexical. >>> >>> Without the explicit declaration of cross-thread visible variables, doing >>> threading may well be difficult (on one's fingers) > >DS> The two things are orthogonal. Threading doesn't place any sort of >DS> requirements on lexical or package variable visibility. We could do a deep >DS> clone ala 5.6.0's ITHREADS, or a partial clone, or start new threads with >DS> empty package stashes. Or any (or all) combinations of the above. > > >Please explain what the utility of having unshared variables? Thread local storage - is often what you want most of. >I might >as well just fork(). That assumes you can fork() ... > > -- Nick Ing-Simmons
Re: RFC: Rename local() operator
Bart Lateur <[EMAIL PROTECTED]> writes: >>> C >> >>If I had my druthers, save() would be it. > >I'm against it. Why? Because it suggests that all it does is save the >value for later retrieval. It does not: the value is cleared as well. It >masks the previous global value, as if it didn't exist before. > > save $/ = "\n"; > >That doesn't quite say it, does it? What about C ? I think C or C has merit - "while I am out contact ...". But I still think C is the essence of what it does. > >In PostScript, for example, there's a gsave and grestore, the "g" >standing for graphics state. It allows you to save the current state of >the graphics output device, on a stack, but it doesn't modify it. Neither does local - it is the = "\n" that does the modifying. >You >can continue from there. It's a different concept. But PostScript also has Save/Restore which is a very similar concept to perl5's local ;-) > >The name "local" is wrong, because it suggests a private value scoped in >space. It is private value scoped in "time" >It is not, that's lexical values. It is scoped in time. I think >it's name should refelect that. "temporary"? > > temporary $/ = "\n"; > >It's a mouthful. But it's going where I'd want it to go. -- Nick Ing-Simmons
Re: perl 6 requirements
Alan Burlison <[EMAIL PROTECTED]> writes:
>"Randal L. Schwartz" wrote:
>
>> Graham> sub def { my @a = (9,8,7); return @a; }
>>
>> That's not returning the array. That's returning a copy of the contents
>> of @a in a list context, and the number of elements of @a in a scalar
>> context, using the "@a" operator. You still haven't "returned the array".
>
>So then in fact it is impossible to return an array - yes? You can
>either return a single scalar or a list. The closest you can come to
>returning an array as an entity is to return a reference to it - \@a.
>
>Have I got that straight?
At the perl level yes. The core C can push an AV * on the stack
but perl does not know what it means. (Tk did this for a while
internally before I decided to comply with the perl semantics.)
--
Nick Ing-Simmons
Re: RFC: Filehandle type-defining punctuation
Nathan Wiger <[EMAIL PROTECTED]> writes: >> Um, what stops open returning undef on failure (and setting $!), so I could do >> >> $fh = open $filename or die "open $filename failed: $!\n"; > >Exactly. You don't lose anything because open() will still return "true" >(a handle) or "false" (undef). You loose one little thing - you have a new scalar (the handle) with open $fh,$filename one can re-use an existing thing to which someone else may have a reference. (Not that that is useful very often.) -- Nick Ing-Simmons
Re: RFC: lexical variables made default
John Porter <[EMAIL PROTECTED]> writes: >[EMAIL PROTECTED] wrote: >> Perl's similarity to English is one of the things that makes it Fun. > >OTOH, being fun (which I admit it is) is one of the reasons many >people don't want to think Perl is a serious language. English had the same problem for 100s of years - all the serious stuff was done in latin (or even french). -- Nick Ing-Simmons
Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 10:55 AM 8/2/00 +0200, Gisle Aas wrote: >>All functions that return time values (seconds since epoch) should use >>floating point numbers to return as much precision as the platform >>supports. All functions that take time values as arguments should >>work for fractional seconds if the platform supports it. > >Floats have resolution issues that exacerbate sub-second resolution issues. As an engineer I would really like to know when you are going to run out of precision in double - that is forty something bits of mantissa. That is more precision than you have in the real world. -- Nick Ing-Simmons
Re: Recording what we decided *not* to do, and why
Michael Mathews <[EMAIL PROTECTED]> writes: >Jonathan Scott Duff said >> Status: tabled # shelved, put away for now Please avoid 'tabled' - it means near the opposite in the UK. To table something is to put it "on the table" i.e. open for discussion. -- Nick Ing-Simmons
Re: RFC 15 (v1) Stronger typing through tie.
John Porter <[EMAIL PROTECTED]> writes: >Michael Fowler <[EMAIL PROTECTED]>: >> >> use typing; # place your fingers on the home row.. >> >> my integer $quux = 4; > >I believe that would have to be > > integer my $quux = 4; > >at least in perl5... Well Larry has been using my Dog $spot; for a while. But I just realized if $ is one of something, @ sereral etc. then do we need a magic char to designate 'type' (class or whatever). I suppose: my ¢Dog $spot; # That is "cent" i.e. c with line. might do ;-) -- Nick Ing-Simmons
Re: RFC: lexical variables made default (revised)
Nathan Wiger <[EMAIL PROTECTED]> writes:
>> I have retained the title of "Lexical variables made default,"
>> because I still feel that that is the primary purpose of this change
>
>First off, I think this is a great idea in principle. However, I don't
>think it goes nearly far enough in the implementation. I'd like to
>propose something radical.
>
>Consider code like this, which is not uncommon:
>
> use strict;
> my $var1 = 'some val';
> my $var2 = 'some other val';
>
> sub mysub {
> my($arg1, $arg2) = @_;
> (my $result = $arg1) =~ s/some/every/g;
> return ($result, $arg2);
> }
>
> my @stuff = mysub($var1, $var2);
>
>You get the idea. Dang there's a lot of my()'s in there! The only thing
>I see this RFC changing is the need for the "use strict" statement.
>However, the code is still littered with what I would argue are
>"useless" my()'s that serve as workarounds for a fundamental flaw in the
>langauge: all variables are global by default.
Go look at some Tcl/Tk code for what happens if you make everything
innermost lexical by default.
You get liberal sprinkling of
upvar 2 foo
global fred harry
etc.
The problem is you quite often whant variables to cross {} boundaries,
if any mention of thing on left declares it in current scope you
end up with "upvar" and "global" to say "no I don't mean that".
--
Nick Ing-Simmons
Re: Language RFC Summary 4th August 2000
Damian Conway <[EMAIL PROTECTED]> writes: > > It definitely is, since formats do things that can't be done in modules. > >Such as??? Quite. Even in perl5 an XS module can do _anything at all_. -- Nick Ing-Simmons
Re: RFC 27 (v1) Coroutines for Perl
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 01:17 PM 8/4/00 +0500, Tom Scola wrote: >> >[I think this belongs on the language list, FWIW, Cc'd there] >> > >> >I like this, but I'd like to see this, inter-thread queues, and events >>all >> >use the same communication method. Overload filehandles to pass events >> >> >around instead, so: >> >>I'm proposing that events and threads be dropped in lieu of coroutines. > >Not gonna happen. Tk and signals, at the very least, will see to that. As far as I am aware any multi-processing problem can be reduced to message passing and these "co routines as IO" are just one stab at that. For example occurance of a signal could just "print" down the handler "pipe", Likewise mouse click could just "print" down the Tk-ish pipe. It is the "return path" that bothers me - and of course the thread behind the co routine still has locking issues if it updates "global" state. -- Nick Ing-Simmons
Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: >> >>As an engineer I would really like to know when you are going to >>run out of precision in double - that is forty something bits of mantissa. >>That is more precision than you have in the real world. > >It's not precision, it's resolution. What do you do if your timers return >values in 1/10ths of a second? What is the problem with that? -- Nick Ing-Simmons
Overloading && ||
Damian Conway <[EMAIL PROTECTED]> writes: >Operator overloading is scheduled to be revamped. While I remember - it would be good if overload mechansim could be extended to cover && and || as well as & and | with the class deciding if short-circuit happens. -- Nick Ing-Simmons
Re: Ramblings on "base class" for SV etc.
Dan Sugalski <[EMAIL PROTECTED]> writes: > >Well, compactness for one. With a scalar on one side it's less odd (it was >a bad example). When funkier, though: > > @foo = @bar * @baz; > >the expansion becomes less obvious It is "obviously" a cross-product ;-) With perl's $s and @s we can actually make sensible choice between mathamaticians · (dot) and X (cross) produducts from context. Whether that is a good idea is another matter. >and quite a bit larger, especially if >the arrays are multidimensional. > > Dan > >--"it's like this"--- >Dan Sugalski even samurai >[EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk -- Nick Ing-Simmons
Re: Overloading && ||
Peter Scott <[EMAIL PROTECTED]> writes:
>At 06:23 PM 8/9/00 +0000, Nick Ing-Simmons wrote:
>>Damian Conway <[EMAIL PROTECTED]> writes:
>> >Operator overloading is scheduled to be revamped.
>>
>>While I remember - it would be good if overload mechansim
>>could be extended to cover && and ||
>
>Yes.
>
>>as well as & and |
>>with the class deciding if short-circuit happens.
>
>No. I don't want to see && or || and not know whether it short-circuits
>without looking in the class interface. My brain is conditioned through
>years of C and Perl to expect that they always short-circuit. This is too
>venerable a semantic to change. Please.
The reason I want the class to decide is not to change the semantic meaning
but the implementation - i.e. _when_ it short circuits.
I have an application which overloads all the ops and builds a little parse
tree of objects. When you "look" at the tree it returns the value.
my $a = new Thing;
my $b = new Thing;
my $cond = $a && $b; # an object
sub foo
{
if ($cond)
{
}
}
$a->bind($a_value);
$b->bind($b_value);
foo();
If things worked as I wanted then when foo is called and "looks" at $cond
then overloaded "boolean" operator of $cond would walk the tree and see
if $a should be considered "true" with its current binding if not
it would short-circuit tree traversal, if it was it would go look at $b's
trueness.
Currently it is completely hosed by && and || as perl will not give me
access to the short-circuited operand so I cannot put it in my tree so
when it evaluates I get the wrong answers.
(To make app. work I use & and | and make _those_ short circuit - but
my users and I keep forgetting ...)
I don't think giving overload control over short-circuit is any more
surprising than allowing overloaded '+' to subtract.
--
Nick Ing-Simmons
Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 06:16 PM 8/9/00 +0000, Nick Ing-Simmons wrote: >>Dan Sugalski <[EMAIL PROTECTED]> writes: >> >> >> >>As an engineer I would really like to know when you are going to >> >>run out of precision in double - that is forty something bits of mantissa. >> >>That is more precision than you have in the real world. >> > >> >It's not precision, it's resolution. What do you do if your timers return >> >values in 1/10ths of a second? >> >>What is the problem with that? > >You can't accurately represent a tenth of a second with floating point >numbers. You could if you made 1/10th second the "unit" of the float internally. >If we're going to handle them, we might as well be exact. Why - the 1/10 of second is not exact anyway (unless you happen to have an atomic clock in an appropriate physical enviroment attached to your machine). A double's mantissa is better than your typical oscillator. -- Nick Ing-Simmons
Re: Overloading && ||
Dan Sugalski <[EMAIL PROTECTED]> writes:
>>I have often wondered whether a language could allow user-defined
>>operators. The fact that none have done it should be a clue :-)
>
>What, like C++? ("I don't believe in it?" "What, C++? Just a conspiracy of
>computer programmers?")
You cannot as far as I aware define new operators in C++ - just redefine the
ones you have. I cannot decide that '>|<' is now an operator.
>
>>I guess it's getting too incestuous with the lexer.
That is the root of the problem.
--
Nick Ing-Simmons
Re: RFC: Higher resolution time values
Dan Sugalski <[EMAIL PROTECTED]> writes: >>Why - the 1/10 of second is not exact anyway (unless you happen to >>have an atomic clock in an appropriate physical enviroment attached to >>your machine). A double's mantissa is better than your typical oscillator. > >While it may not be correct, at least it's exact. The importance of the distinction escapes me - where the errors come from does not matter in the real world. >If we go with an inexact >representation, we run the risk of accumulating errors and eventually >ending up with a number that's both inexact and incorrect. But computer time is always inexact and incorrect - thats why we need NTP. -- Nick Ing-Simmons
Re: type-checking [Was: What is Perl?]
Alan Burlison <[EMAIL PROTECTED]> writes:
>
>No, I disagree. Perl gains a lot of its expressive power from being lax
>about typing. I suspect it will also impose an unacceptable overhed for
>the vast majority who don't want it - at the very least every variable
>access will have to check an 'are you typed' flag.
Cross posted to internals ('cos it is...)
We should consider using "vtables" to avoid the cost of the conditional
branches (and running out of flag bits).
Thus this function would call variables "type check" "method" -
which for normal case would be pointer to blue-white-hot "NoOp" function
which is near always in-cache, for a typed var it could be a slow
as you wanted...
--
Nick Ing-Simmons
Re: Language RFC Summary 4th August 2000
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 11:40 AM 8/5/00 +0000, Nick Ing-Simmons wrote: >>Damian Conway <[EMAIL PROTECTED]> writes: >> > > It definitely is, since formats do things that can't be done in >> modules. >> > >> >Such as??? >> >>Quite. >> >>Even in perl5 an XS module can do _anything at all_. > >It can't access data the lexer's already tossed out. A source filter can, but not elegantly. >That's where the >current format format (so to speak) runs you into trouble. > > Dan > >--"it's like this"--- >Dan Sugalski even samurai >[EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk -- Nick Ing-Simmons
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: >On Fri, Aug 11, 2000 at 02:09:43AM +0200, Bart Lateur wrote: >> On Thu, 10 Aug 2000 14:39:39 -0500, Jarkko Hietaniemi wrote: > >Did not. > >> > people in Newfoundland are going to expect to be >> >> able to pass in -0230 and have that work, and that's interestingly hard. >> >> What's so hard? Subtracting 2 hours and 30 minutes from the official >> referential time (GMT)? Or the Daylight Savings Time rules? > >Without any further thought I'll just shoot and say the DST rules because >they are legislation and fickle, not logic/astronomy and stable. One of the most amusing of which is that at the UNIX epoch (Jan 1, 1970) Greenwich (i.e. London) of GMT was not on GMT but BST which that year (or so) stood for "British Standard Time" not "British Summer Time". -- Nick Ing-Simmons
Re: RFC 84 (v1) Replace => (stringifying comma) with =>
Peter Scott <[EMAIL PROTECTED]> writes:
>At 07:29 PM 8/10/00 -0700, Glenn Linderman wrote:
>>Thanks for the clarification in your intentions, but isn't _any_ bareword is
>>converted to a string, unless it is in some particular context where a
>>bareword is
>>meaningful (such as filehandle)? So that seems to be nothing unique to
>>=>. You
>>could just as well say
>>
>> bareword, $whatever
>>
>>and get the same effect in perl5!
>
>Have you used strict lately? :-)
It also matters in this case:
sub bareword { }
foo(bareword,4);
vs
foo(bareword => 4);
--
Nick Ing-Simmons
Re: vector and matrix calculations in core? (was: Re: Ramblings on "base class" for SV etc.)
Bart Lateur <[EMAIL PROTECTED]> writes: >On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote: > >>> > @foo = @bar * @baz; > >>Given that the default action of the multiply routine for an array in >>non-scalar context would be to die, allowing user-overrides of the >>functions would probably be a good idea... :) > >[Is this still -internals? Or should we stop CC'ing?] > >One problem: overloading requires objects, or at least one. Objects are >(currently) scalars. You can't make an array into an object. We are thinking of adding "objects" in the implementation of perl. i.e. perl's primitive "things" (scalars, arrays, hashes) will have 'vtables' (table of functions that do the work). So in that sense an array as in @foo can be an "object" at some level of meaning while not being an "object" at the perl level. -- Nick Ing-Simmons
Re: RFC 83 (v1) Make constants look like variables
Ed Mills <[EMAIL PROTECTED]> writes: > >I've noted a few messages here with statements like "it looks like C++" and >"I hated that in Pascal" and so on. If we restricted ourselves to constructs >not found in other languages, there would be no Perl as we know it today. >Larry freely admits he borrowed constructs and techniques from many >languages. > >There are many logical reasons for and against the RFC's here, but saying >"it looks like c so it doesn't make it for me" is a weak argument at best. I don't think anyone made that argument - they have all been "I hate that in ..." type comments. I did not work for X, so probably won't for for us - _is_ a valid argument. We borrow what works not what doesn't! > -- Nick Ing-Simmons
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
Jonathan Scott Duff <[EMAIL PROTECTED]> writes: >On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote: >> =head1 TITLE >> >> Maintain internal time in Modified Julian (not epoch) There has to be _an_ epoch - even Caesar started somewhere... > >How would this be stored? As a floating point number? What about >sub-second accuracy? To get seconds you'd need about 5.15 decimal >places (let's just call that 6) IEEE 'float' (the short one) has about 6 places (24 bit mantissa). double has many more. But even I don't think using years as the "unit" is right thing to do. Seconds is my favourite... -- Nick Ing-Simmons
Re: RFC 83 (v1) Make constants look like variables
John Porter <[EMAIL PROTECTED]> writes: >Nick Ing-Simmons wrote: >> Ed Mills <[EMAIL PROTECTED]> writes: >> > >> >There are many logical reasons for and against the RFC's here, but saying >> >"it looks like c so it doesn't make it for me" is a weak argument at best. >> >> I don't think anyone made that argument - they have all been >> "I hate that in ..." type comments. > >You forget... There have been numerous cases of people saying things like >"that's what Python [or Java] calls those functions, so we should call >them something else." You may be right - though as I recall those were "that's what X calls those functions, ours don't work the same so we should call them something else" My point was if experienced folk don't like something somewhere else we should think twice before borrowing it. The _names_ don't matter much at this stage - Larry can change them but if "making things const like C++" is a bad idea then it is a bad idea - A midden by any other name would smell as foul. -- Nick Ing-Simmons
Re: RFC 90 (v1) Builtins: zip() and unzip()
David L . Nicol <[EMAIL PROTECTED]> writes: >These things sound like perfectly reasonable CPAN modules. >What's the block prevenenting their implementation w/in the >perl5 framework? No one has done it? -- Nick Ing-Simmons
Re: RFC 127 (v1) Sane resolution to large function returns
Dan Sugalski <[EMAIL PROTECTED]> writes: >At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: >>But >> >>($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) >> >>Actually, looking at it like that makes it an ugly situation. The 'new' >>expectation would be to have it become >> # $foo=1 $baz=2 @bar=(4) > >Wouldn't that be $baz = 3, since the middle list would be taken in scalar >context? Which has sanely become the length of the list rather than last element. -- Nick Ing-Simmons
Re: "Counting the birds" :")
Raptor <[EMAIL PROTECTED]> writes: >What is interesting to me : > >1. "push" is used more than any of the other array ops, even than "shift" >2. "use" is very good candidate for speedup >3. We still use very much "goto" :") >4. "each" is used more than "values" and "keys" >5. Things like "hex,chr,oct,atan2" are used very rarely >6. "pack" and "unpack" are also used very rarely, "study" - >the same number of times. > >We can make similar thing for the whole CPAN. >What will this give to us : >1. It will help us to decide which of the operators are mostly used > (CPAN is suitable for this) so then we can take care > to speed up only mostly used ops in the new Perl6 (or Perl5) > (current script doesn't care about the "weight" of the ops i.e. >it doesn't count how many times any op will be used in REAL LIFE f.e >some op may execute 10 times during the life of the module but other can >be >executed only once. They are both counted as "ONE time" execution) This is the snag with this - it may noy be 1 : 10 but as in profile example I sent at weekend 1 : 5,833,600 Thus although 'use' occurs a lot as (by definition!) it is only executed once it is less important than it looks. -- Nick Ing-Simmons <[EMAIL PROTECTED]> Via, but not speaking for: Texas Instruments Ltd.
Re: Schwartzian Transform
Simon Cozens <[EMAIL PROTECTED]> writes:
>On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
>> SC> it? That is, @s = sort { f($a) <=> f($b) } @t
>>
>> because that would require the PSI::ESP module which isn't working
>> yet. how would perl intuit exactly the relationship between the records
>> and the keys extraction and comparison? the ST defines that by the first
>> map and the comparison callback. just providing the comparison would
>> entail perl parsing an arbitrarily complex piece of code and then
>> autognerating the map that would produce an anon array that fits it. not
>> a simple task.
>
>No, it wouldn't, don't be silly. The ST can always be generalized to
>
>ST(data, func, compare) =
>map { $_->[0] } sort { compare($a->[1], $b->[1]) } map { [$_, f($_)] } data
>
>In fact, you can implement it in LISP just like that:
>
>(defun Schwartzian (list func compare)
> (mapcar
> (lambda (x) (car x))
> (sort
>(mapcar
> (lambda (x) (cons x (funcall func x)))
> list
> )
>(lambda (x y) (funcall compare (cdr x) (cdr y)))
>)
> )
> )
So can you write that in perl5 rather than LISP?
If not what does perl6 need so we can write it in perl6.
sub Schwartzian
{
...
}
>
>Do you see any ESP there? Do you see any parsing of arbitrary pieces of
>code? No, me neither.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
%_ - is it available for use?
We have been discussing how to pass data to Tk callbacks. In particular Entry widget validation routines. There are a number of items that they _might_ be interested in but a typical routine would only use a few. Currently it passes them all as positional parameters. One idea that occured to me/us is to have a "localized" hash for this purpose (which might be tied/magical). One choice of name for this is %_ - which fits neatly with @_ for positional args and $_ as current thing. Also *_ glob already exists to have its GvHV entry (ab-)used. What does p5p think of this use ? Basically @_ says "how" you been called $_ is "what" you are working on, and this idea gives %_ the meaning of "why". (Caller gives the "who" ;-) )
Re: %_ - is it available for use?
Damian Conway <[EMAIL PROTECTED]> writes: > > From a Perl 6 perspective, it seems likely that C<%_> will be the name >commonly used for the "slurpy hash" of a subroutine. Just as C<@_> will often >be the name used for the "slurpy array". See Exegesis 6 for more details. > >Indeed, when it comes to object constructors (all of which implicitly have a >slurpy hash), C<%_> might well be the automatically provided name for that >hash. See Exegesis 12 for more details. ;-) > >Hence, making C<%_> mean something different in core Perl 5 might possibly be >"forwards incompatible". This wouldn't have been a core Perl 5 thing but a (module) Tk thing. But if Perl 6 is giving it a meaning I will avoid it (unless a slurpy hash is what I meant - I haven't kept up the Perl6 jargon.)
RE: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
David Grove <[EMAIL PROTECTED]> writes: >> Well, I think we should take a step back and answer a few key questions: >> >> 1. Do we want to be able to use Perl 5 modules in a >>Perl 6 program (without conversion)? > >For a while, quite possibly, I'd say. > >When 5.6 came out, I was in module hell, trying to get 5.005 modules to >compile with 5.6. Most of the ones giving the most trouble were the most >popular/demanded. That's not something I'd like to see repeated. Perl5 modules which make use of XS will be more of a pain to support, and most of the perl5.6 fails were due to XS-ness tweaks (PERL_POLLUTE). -- Nick Ing-Simmons http://www.ni-s.u-net.com/
