Re: rethinking printf
On Wed, 6 Mar 2002 17:57:07 -0500, Uri Guttman wrote:
how often will you need to interpolate a hash?
A whole hash: quite rarely. A hash item: a LOT. Don't forget that
$foo{BAR} will now become %foo{BAR}
--
Bart.
Re: 123_456
On Fri, 25 Jan 2002 17:34:12 +, Simon Cozens wrote: Should we be allowed to use _ to group numbers, now that _ is concat? If not _, then what? (if anything?) I don't really understand your question. Currently, . is used for concat and that doesn't inhibit using it in a number, does it? Or what would you suppose that 3.14 means? Quite the countrary: (100 . 000) as a number is indeed 10, as is 100_000. So there's *less* of a conflict than today, in perl5. -- Bart.
Re: Apoc4: The loop keyword
On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: What we're cleaning up is the ickiness of having things declared outside the braces be lexical to the braces. *That's* hard to explain to beginners. But it's handy. And that was, until now, what mattered with Perl. -- Bart.
Re: Apoc 4?
On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote: http://www.perl.com/pub/a/2002/01/15/apo4.html David Whipp wrote: Michael G Schwern wrote: Reading this in Apoc 4 ... I looked on http://dev.perl.org/perl6/apocalypse/: no sign of Apoc4. Where do I find this latest installment? I thought I had just missed it... but there's no trace of it in the archives of [EMAIL PROTECTED]. Or any other perl6 list. Don't tell me that is normal. -- Bart.
Re: [PATCH] The Code Police [1/
On Sun, 30 Dec 2001 16:11:35 -0800 (PST), Boris Tschirschwitz wrote: Yeah, int *num; is customary in C, but for some reason C++ people like to write int* num; I am sure I saw some rationale for that in gcc's C++ part, but I can't find it anymore. Apparently C programmers do not fall for that. It declares a pointer, not an integer? FWIW, it's one of the reasons I really really don't like C at all. The other main reason is the mess you likely get when trying to write cross-platform code. Just watch these perl6 mailing lists for a while, and you'll see that it really is a major problem. -- Bart.
Re: Apropos of nothing...
On Thu, 13 Dec 2001 12:17:44 -0500, Mark J. Reed wrote: @i = (0); @ary[@i] = foo(); How could one get that behavior without the intermediate array? Parens, likely. (@ary[0]) = foo(); -- Bart.
Re: Moving string - number conversions to string libs
On Thu, 06 Dec 2001 00:16:34 GMT, Tom Hughes wrote: So far I have added as is_digit() call to the character type layer to replace the existing isdigit() calls. There seems to be an overlap with the /\d/ character class in regexes. Can't you use the same test? Can't you use the definition of that character class, whatever form it may be in? -- Bart.
Re: Parrot FAQ
On Wed, 05 Dec 2001 13:32:32 -0500, Dan Sugalski wrote: Right, but FORTH's not an interpreted language, generally speaking. The old FORTH's in the 80's worked pretty much like the p-copde interpreter. Nowadays, FORTH compilers are really optimizing compilers. There are excellent commercial offerings, like VFX from MPE (MPE's Stephen Pelc showed some examples in comp.lang.forth of what machine code got generated from some FORTH code, and it was really cool -- but I can't find it back with groups.google.com, as Stephen Pelc advertises for VFX in every single post. I did manage to find something, see link below), and some less ambitious free FORTHS, like iFORTH (if I'm not mistaking) and BigFORTH. The latter has a really simple optimizer consisting of 3 screens (1 screen = 1k) of source code. http://groups.google.com/groups?selm=3C0BAB3E.BD54B0E2%40gmx.de http://groups.google.com/groups?selm=MPLT160213F08E%40mpeltd.demon.co.uk -- Bart.
Re: Parrot FAQ
On Tue, 04 Dec 2001 15:57:56 -0500, Dan Sugalski wrote: Q: Don't you know that stack machines are the way to go in software? A: No, in fact, I don't. Q: But look at all the successful stack-based VMs! A: Like what? There's just the JVM. Q: What about all the others? A: *What* others? That's it, unless you count perl, python, or ruby. I thought Pascal's (ancient) p-code was a stack VM... Yup, some web pages that I can find in a hurry, confirm that. http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?P-code -- Bart.
Re: Benchmarking the proposed RE engine
On Sun, 25 Nov 2001 19:34:15 -0800, Brent Dax wrote: Perl 5's REs will always appear faster because Perl 5 has an intelligent, optimizing regex compiler. For example, take the following simple regex: /a+bc+/ pregcomp will optimize that by searching for a 'b' and working outwards both ways from there. (Actually, it might search for 'abc' and work from there; I'm not really sure.) Without considering pregcomp's optimizations, that RE is pretty easy to write in Parrot: RE_0: #/a+bc+/ rx_minlength 3 branch $start $advance: rx_advance $fail $start: rx_literal P0, a, $advance $a_loop: rx_literal P0, a, $b rx_pushindex P0 branch $a_loop $a_back: rx_popindex P0, $advance $b: rx_literal P0, bc, $a_back $c_loop: rx_literal P0, c, $succeed branch $c_loop $succeed: rx_succeed P0 $fail: rx_fail P0 Before we go down that road for good, may I draw your attention to the principle of a regex matcher that appeared in an article in DDJ a few years ago? The name was Grouse Grep, it has a website (http://www.grouse.com.au/ggrep/), but I think (I'm not absolutely sure) that the latest version has stepped away from the principle that made the original interesting. That principle was, in a nutshell: implement each character class as a jump table. I guess that is unfeasable for Unicode, but for 8 bit characters it's easy to do. What you need is a table of 256 entries for each state, and using the next character in the input stream, you simply look up the address of the next state in the lookup table. Yes, that means that you *always* use character classes, even if just to match one literal character. The original used i386 machine code to do it, (I think it was a combination of LODSB to fetch the byte, and XLAT to look up the lowest byte of the address in the jump table), but I would think that jumping through a lookup table should be fairly easy to implement on top of Parrot VM instructions. The DDJ article appeared in november 1997, but it looks like it's not online. (The table of contents for that issue is at http://www.ddj.com/articles/1997/9711/) (Grouse Grep 2 appears to be released under the GNU license, but I wouldn't *use* the code, only re-implement the idea.) -- Bart.
Re: PMC Classes Preprocessor
On Sun, 25 Nov 2001 13:14:22 +, Simon Cozens wrote:
On Sun, Nov 25, 2001 at 02:32:34AM -0500, Angel Faus wrote:
use Text::Balanced 'extract_bracketed';
Urgh. We need to work around this.
Can somebody fill me in exactly how this is supposed to behave?
I think that this may come close:
$_ = { a { b } c { d } } { e { f } g } ;
print Extracted: '. extract_balanced($_) . '\n;
print Remains: '$_'\n;
sub extract_balanced {
my $balance = 0;
for(shift) {
s/^\s+//;
/^\{/ or die bad block open;
while(/(\{)|(\})/g) {
if($1) {
$balance++;
} else { # $2
--$balance or return substr($_, 0, pos, );
}
}
die Badly balanced if $balance;
}
}
This prints:
Extracted: '{ a { b } c { d } }'
Remains: ' { e { f } g } '
(p.s. for various reasons I am not capable of submitting an actual
patch)
--
Bart.
Re: sizeof(INTVAL), sizeof(void*), sizeof(opcode_t)
On Wed, 21 Nov 2001 13:46:09 -0500, Dan Sugalski wrote: Nah, using an I register as a host-machine-address for jumps doesn't argue for sizeof(INTVAL) = sizeof(void *). Instead, it argues that the design that uses an int as an absolute address is wrong. I'm going to rewrite the docs and ops to use a S register instead. Now all I need to do is figure out something to make S stand for that encompasses both uses. (Buffer pointer and generic pointer) That sounds equally bad. This opens the door into jumping into user data as if it was code. Plus, will your code be garbage collected too? -- Bart.
Re: Perl 6 - Cheerleaders?
On Thu, 25 Oct 2001 16:53:46 -0500, Garrett Goebel wrote: Piers Cawley has written a nice article entitled: Perl 6 : Not Just For Damians. http://www.perl.com/pub/a/2001/10/23/damians.html I just hope that you don't really have to insert that many blank lines in your code just to make it compile. -- Bart.
Re: Revamping the build system
On Tue, 23 Oct 2001 08:39:29 -0400, John Siracusa wrote: As one of the few rabid Mac users on this list, let me just say that I personally have no problem with classic Mac OS support being totally dropped from Parrot if it'll get stuff out the door sooner :) Classic Mac OS is (somewhat sadly) a dead OS at this point. By the time Parrot is done, Apple will probably be shipping hardware that won't even *boot* classic Mac OS outside of a virtual machine in OS X. I disagree. OS X is but slowly catching on. You may drop 68k support if you want, but please don't drop MacOS 8.x/9.x for PPC. Those Macs aren't dead yet, and most of them will never be upgraded to OS X. But I am not happy of having to use a proprietary mechanism for building things. -- Bart.
Re: Math functions? (Particularly transcendental ones)
On Mon, 10 Sep 2001 18:48:01 -0400, Dan Sugalski wrote: At 12:35 AM 9/11/2001 +0200, Bart Lateur wrote: On Mon, 10 Sep 2001 17:13:44 -0400, Dan Sugalski wrote: Who the heck is going to override arctangent? (No, don't tell me, I don't want to know) Perhaps you do. Think BigFloat. Or Complex. I'm not too worried about bigfloats, since the precision loss you get converting the argument to a float isn't a big deal. (All the transcendentals are only good to four or six places anyway, so...) Perhaps that might just be the reason to overload them? Somebody might want higher precision transcendentals? It won't be fast... -- Bart.
Re: Math functions? (Particularly transcendental ones)
On Sat, 08 Sep 2001 13:02:04 -0400, Dan Sugalski wrote: Uri mentioned exp(x) = e^x, but I think if you are going to include log2, log10, log, etc, you should also include ln. Added. Er... aren't ln and log synonyms? -- Bart.
Re: Should MY:: be a real symbol table?
On Mon, 03 Sep 2001 19:29:09 -0400, Ken Fox wrote:
*How* are they fundamentally different?
Perl's local variables are dynamically scoped. This means that
they are *globally visible* -- you never know where the actual
variable you're using came from. If you set a local variable,
all the subroutines you call see *your* definition.
Perl's my variables are lexically scoped. This means that they
are *not* globally visible. Lexicals can only be seen in the scope
they are introduced and they do not get used by subroutines you
call. This is safer and a bit easier to use because you can tell
what code does just by reading it.
But in this case the pad is actually a full symbol table. The
concept is the same, the data structure is different.
The concept isn't the same. local variables are globals.
This is nonsense.
Firs of all, currently, you can localize an element from a hash or an
array, even if the variable is lexically scoped. This works:
use Data::Dumper;
my %hash = ( foo = 42, bar = '007' );
{
local $hash{foo} = 123;
print Inner: , Dumper \%hash;
}
print Outer: , Dumper \%hash;
--
Inner: $VAR1 = {
'foo' = 123,
'bar' = '007'
};
Outer: $VAR1 = {
'foo' = 42,
'bar' = '007'
};
So local and global are not one and the same concept.
Unfortunately, this doesn't work with plain lexical scalars. I wonder
why. Really.
How are globals conceptually different than, say, globally scoped
lexicals? Your description of global variables might just as well apply
to file scoped lexicals. Currently, that is the largest possible scope,
but why stop there?
Typeglobs are on the verge of extinction. Perhaps the current concept of
symbol tables may well follow the same route? A symbol table will be
different in perl6, anyway. If the implementation of lexicals is
consistently faster than that of globals, perhaps globals ought to be
implemented in the same way as lexicals?
From the top of my head, I can already think of one reason against:
dynamic creating of new global variables, for example while loading new
source code. It's a situation you just can't have with lexicals. For
globals, it can, and will, happen, and it would require extending the
global pad or something like that.
--
Bart.
Re: Should MY:: be a real symbol table?
On Mon, 03 Sep 2001 19:30:33 -0400, Dan Sugalski wrote: The less real question, Should pads be hashes or arrays, can be answered by whichever is ultimately cheaper. My bet is we'll probably keep the array structure with embedded names, and do a linear search for those rare times you're actually looking by name. Perhaps a lookup hash for the names, containing the offsets? -- Bart.
Re: ! and !
On 01 Sep 2001 14:40:40 -0700, Russ Allbery wrote: Sterin, Ilya [EMAIL PROTECTED] writes: From: Russ Allbery [mailto:[EMAIL PROTECTED]] How is ! different from =? ... It's the same number of characters. How can it be more convenient? Why is it = and not =? Why = and not =? Simply trying to remember the order of characters might be (a bit of) a pain. That problem doesn't exist with ! and !. -- Bart.
Re: Come and get me, Schwern
On Wed, 29 Aug 2001 16:26:59 -0500, David L. Nicol wrote: Bill J. Programmer publishes a class foo that is guaranteed to correctly blarg the frobniz, someone subclasses it and breaks the blarg function, that simply will not do! With a final it is no longer possible for the new class to identify itself as a foo. It's not a foo. It's instance of a *subclass* of foo. If it can't be different than foo, then you might just as well toss out the idea of subclassing altogether. Look at the lame duck example on this page: http://www.cs.mdx.ac.uk/harold/srf/javaspae.html. So you say a duck has two legs. That's fine as a default. But a lame duck, with one leg missing, only has one leg. So if you make the number of legs (or feet) of a duck final, then lame ducks can't be ducks. Or they can be ducks, but then they can't have but one leg. -- Bart.
Re: Something to hash out
On Sat, 25 Aug 2001 18:58:50 +0100, Simon Cozens wrote: I was using .pas and .pac. Gotta think about 8.3ness, unfortunately. The 8 might not be that relevant nowadays, but the 3 still matters. On Win32, file extensions get cut off after 3 characters. So a .html file is actually the same as a .htm file, I think. -- Bart.
Re: Draft assembly PDD
On Mon, 06 Aug 2001 21:55:07 -0400, Dan Sugalski wrote: But I do not agree that calculated jumps should be done in such a hard way. Nothing hard about it, really. I was referring to Hong Zhang's proposal, not yours. -- Bart.
Re: new syntax idea: eval ...o;
On Tue, 7 Aug 2001 09:27:43 -0400, John Porter wrote:
David L. Nicol wrote:
eval ${code}o;
Another brilliant idea from David Nicol!
Not really.
What I would like is an option to just *compile* a piece of perl code,
without executing it. This kinda works:
$coderef = eval sub { $code };
and currently (5.6.0) even if $code contains sub definitions; but it's
still just a hack.
--
Bart.
Re: Draft assembly PDD
On Mon, 6 Aug 2001 15:41:59 -0700 , Hong Zhang wrote: Branches should work from both constants and registers. Even so, the branch #num should have better performance, and it is part of any machine language. Since we already have jump instruction, do we really need the branch %r, which can be simulated by add %r, %pc, #num; jump %r. In a way, I feel like agreeing. Isn't branch #num the normal case? Should you waste time on the normal case because you want to be able to do exceptional stuff too? And don't calculated jumps kill caching efficiency? (Or is this old CPU wisdom?) But I do not agree that calculated jumps should be done in such a hard way. -- Bart.
Re: if then else otherwise ...
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. -- Bart.
Re: if then else otherwise ...
On Sun, 29 Jul 2001 14:22:23 +0300, raptor wrote: But at least the second shortcut is worth it, i think : cond ? then : else : otherwise This has a vague smell of Fortran. -- Bart.
Re: as long as we are discussing 'nice to have's...
On Sat, 21 Jul 2001 14:47:43 -0700 (PDT), Dave Storrs wrote: I discovered today that I had forgotten to put 'use strict' at the top of one of my modules...it was in the script that _used_ the module, but not in the module itself. Putting it in instantly caught several annoying bugs that I'd been trying to track down. It would be nice if there was... No. Your script should not be responsible for debugging modules. Modules are supposed to be debugged already, and are the responsibility of the module author, not the script writer. -- Bart.
Re: The internal string API
On Tue, 19 Jun 2001 14:51:43 -0500, Jarkko Hietaniemi wrote: But a locale is a collection of user preferences. How I want my dates to be formatted, how I want my strings to be sorted. That's not right. If I do a text conversion from Windows to Mac, I would want to source to use the CP-1522 locale, and the output the MAc-Roman locale. If I have a file in French, and a file in Chinese, I want one to be treated as French, and the other as Chinese. If this can't be done, I don't need locale's. I'll make my own kludges thank you very much. -- Bart.
Re: Multiple classifications of an object
On Wed, 27 Jun 2001 13:48:38 -0400, Dan Sugalski wrote: And the current @ISA stuff is MI, albeit on a per-class basis rather than on a per-object one. Anyway, as Damian mentioned, setting the .ISA property is a perfectly reasonable sort of thing to do if the language supports this. Just one question. If an object would have both per-object inheritance (.ISA), and per class inheritance (@ISA), which one would have precedence? If there's a conflict, a method exists both for a superclass and for an object superclass (i.e. through .ISA), which list would be checked first? Which method would be picked, and executed? FWIW, I think I'd vote for .ISA, as it is more individually tied to this particular object. The other one is generic. -- Bart.
Re: The internal string API
On Tue, 19 Jun 2001 11:53:28 -0700, Hong Zhang wrote: * Do a substr operation by character and glyph The byte based is more useful. I have utf-8, and I want to substr it to another utf-8. It is painful to convert it or linear search for charaacter position. I tend to agree. I currently use substr(), length() and read()/sysread(), based on a byte count. It's a mindset. Even if my encoding is in (16 bit) Unicode or UTF8, I still prefer to use bytes as my count base. Personally, I would prefer if it stayed this way, i.e. that the raw, non-OO keywords for the above kept counting in bytes. Why? Just imagine processing a binary file like a JPEG file, with embedded comments in (16-bit) Unicode. You wouldn't want Perl preventing you from treating this comment as Unicode, or having to process this entire binary file as Unicode, would you? I'd hate that. I want to remain in control. I would not mind if OO versions of these words were smarter, and did their count in characters for whatever character mode they're set to. For example, if $string is a UTF8 object, then $string-length may return a length in (UTF8) characters. -- Bart.
Re: More character matching bits
On Fri, 15 Jun 2001 06:52:32 -0400, Bryan C. Warnock wrote: On a side note (and this *will* sound stupid, but there is a reason I'm asking). Why is there no logical opposite to '.'; that is, a character which never matches another character? (Besides, of course, that it's utterly useless from a classic regex perspective.) You mean, like (?!) ? Actually that's a lookahead that always fails. For single byte character sets, there's also [^\000-\377] -- Bart.
Re: More character matching bits
On Wed, 13 Jun 2001 13:39:16 -0400, Dan Sugalski wrote: Something that should be part of the core? I'll leave that for you to decide. Most definitely NOT. Most definitely sort of. There is no reason to put fucntionality for free matching of Japanese characters into the basic perl executable. No, you're right. But the core must take into account the capabilities that need to be available for comparison and matching of the languages perl's going to make at least some effort to support. If you're saying that the perl core shsould include hooks into the regex engine for custom character classes, I agree. But nothing more. Currently, Perl5 provides a hook for use locale;, but I wish there was something more general than this, more customizable. For example, I sometimes have user defined character encodings, that don't follow any standard. I wish there was a simple, perl-only, way to cope with them. Also, for example, I would like be able to match á with /[a]/, but without changing the sort order. locale is a bit too much all or nothing for me. -- Bart.
Re: should vtables be vtables?
On Wed, 13 Jun 2001 12:00:21 +0100 (BST), Dave Mitchell wrote:
I was thinking back to the earlier discusions on opcode dispatch,
and the fact that some people thought that a big switch was as good as,
or possibly faster than a dispatch table. Which led me to think...
I would think that a switch could be optimized by the compiler by
turning it into a jump table. That way, it's not surprising that it can
be as fast. Un der the surface, it is the same thing!
should we abandon vtables (ie arrays of fn pointers indexed by op),
and just have a single hander function per type which has the op as an arg?
You mean, like Windows' window function? Shudder.
I wouldn't do that. For one thing, a vtable can grow dynamically,
functions can be added at runtime. It doesn't matter, the machine code
to execute remains the same for built-in, or for freshly added
functions.
In a statically compiled switch, it is impossible to add a new function,
i.e. a new switch branch.
Furthermore, unoptimized switches are definitely slower than vtables.
Internally, a switch is turned into something like:
if($fn == FN1) {
...
} elsif($fn == FN2) {
...
} elsif($fn == FN3) {
...
} elsif($fn == FN4) {
...
} elsif ...
}
The further down the chain, the slower the dispatching. Do you really
want that?
--
Bart.
Re: More character matching bits
On Wed, 13 Jun 2001 01:22:32 +0100, Simon Cozens wrote: Something that should be part of the core? I'll leave that for you to decide. Most definitely NOT. There is no reason to put fucntionality for free matching of Japanese characters into the basic perl executable. There were already voices here, on how to strip Unicode support completely from the perl core, because these people don't feel like they need it. so this is most definitely going to far. If you want to free matching on Japanese text, stuff it in a module. If you want the same kind of support for Korean, stuff it in another module. Very few people will need both at the same time. Perhaps it can even be put into locale...? But, as a summary: Unicode support in the perl core should be minimal, so nobody feels the need to strip anything. -- Bart.
Re: Should the op dispatch loop decode?
On Tue, 12 Jun 2001 18:12:35 -0400, Dan Sugalski wrote: 'Kay, here's a question to ponder. Should the op dispatch loop handle argument decoding, or should that be left to the opcode functions? Are you talking about lazy vs. normal evaluation? Lisp knows basically two modes, normal evaluation, where parameters are interpreted before the function is called, and lazy evaluation, where each parameter is only interpreted as it is needed. The latter is useful in Perl for shortcircuiting operators like || or and but also for ?: I'd say that for the general case, you need these two modi. How you implement them, is for you to choose. -- Bart.
Re: Social Reform
On Tue, 12 Jun 2001 08:54:13 +0100, Simon Cozens wrote: On Mon, Jun 11, 2001 at 05:19:26PM -0700, Daniel S. Wilkerson wrote: I would say Simon was the one ignoring an issue and attacking a person, not Vijay. You are wrong. Go back through the archives. Vijay has posted four messages: two of which are critical of Perl, two of which are pretty heated personal attacks on me. None of those four does anything useful for Perl 6. Well, I *have* been following the discussion. And to me, it looks indeed like you, Simon, were indeed attacking ME on non-technical grounds. Vijay just jumped in for him, like a lioness trying to protect her kittens. -- Bart.
Re: hash and array variables vs. references
On Fri, 8 Jun 2001 14:05:44 -0400, Mark J. Reed wrote:
My question/suggestion: why not get rid of @arrays and %hashes as
separate variable types? Have all variables be scalar - with,
of course, the ability to hold a reference to an anonymous array
or hash. Keep the funny characters around, but only as dereference
operators - and let @foo be equivalent to @$foo and %bar to %$bar.
That would bring back the relationship between @foo/$foo[$i]
and %bar/$bar{$key} and would also let the Perl5 slice notation
stay intact.
This looks like the idea of Highlander variables to me -- so called
after the movie Highlander: There Can Be Only One. That will be RFC 9.
http://dev.perl.org/rfc/9.pod
--
Bart.
Re: PDD 2nd go: Conventions and Guidelines for Perl Source Code
On Tue, 29 May 2001 18:25:45 +0100 (BST), Dave Mitchell wrote: diffs: -KR style for indenting control constructs +KR style for indenting control constructs: ie the closing C} should +line up with the opening Cif etc. On Wed, 30 May 2001 10:37:06 -0400, Dan Sugalski wrote: I realize that no matter what style we choose, there will be a good crop of people who won't be thrilled with it. (For the record, we can count me as one, if that makes anyone feel any better :) That's inevitable. If you have a diff/patching suite that falls over whitespace, you have a problem with diff, not with style. One can always to a pretty-print cleanup of the code, before doing the diff, if all else fails. IMO this is not worth bickering over. -- Bart.
Re: Should we care much about this Unicode-ish criticism?
On 05 Jun 2001 11:07:11 -0700, Russ Allbery wrote: Particularly since part of his contention is that 16 bits isn't enough, and I think all the widely used national character sets are no more than 16 bits, aren't they? It's not really important. UTF-8 is NOT limited to 16 bits (3 bytes). With 4 bytes, UTF-8 can represent 20 bit charatcers, i.e. 6 times more than the desired number of 17. See http://czyborra.com/utf/#UTF-8 for how it this is done. And the major flaw that I see in acceptance of Unicode, is that the Unicode text files are not Ascii compatible. UTF-8 file are. That makes for a very nice upgrade path. -- Bart.
Re: slices
On Thu, 24 May 2001 22:19:12 -0400, James Mastros wrote: But what about: @foo[(1,2,3)]? Are those parens a list-maker, or are they a scalar expression using the comma operator. Both. But in this case, I'd say: it depends on the context the slice is called in. @bar = @foo[(1,2,3)]; is the same as @bar = (@foo[1], @foo[2], @foo[3]); or: just an ordinary slice. OTOH, $bar = @foo[(1, 2, 3)]; is the same as $bar = (@foo[1], @foo[2], @foo[3]); or, the comma operator acting on the individual array items. In the latter case, only the last array item will survive. At least, that's what I think that should happen. -- Bart.
Re: Separate as keyword? (Re: 'is' and action at a distance)
On Fri, 18 May 2001 23:26:53 +0200, Trond Michelsen wrote: While I understand how 0 but true is a cute hack that is destined to be replaced by a truth property, I fail to realize how it's useful to have a value that's true no matter what value you assign to it later. I thought the truth property was attached to the value, not to the variable. So if you assign a new value to that variable, the truth property is overwritten, too. Actually, replace variable with lvalue. It could be, say, a hash element. -- Bart.
Re: Damian Conway's Exegesis 2
On Wed, 16 May 2001 13:49:42 +0200, Carl Johan Berglund wrote:
sub show {print 6}
print Perl ${show()}\n;
(That prints 6Perl, not Perl 6.)
If you want to call the subroutine in the middle of the string, you
should make it _return_ something, not print it.
This person obviously expects a pipe effect, i.e. capturing of the
printed output.
Should Perl6 provide one? Is print() really easier to grasp, than
'return $buffer', with possibly lots of '$buffer.=$append' in the sub?
Actually, yes, the latter is annoying.
--
Bart.
Re: Apoc2 - STDIN concerns
On Thu, 10 May 2001 17:15:09 +0100, Simon Cozens wrote: What you could do, is treat an iterator as something similar to reading a line from a file. Tied filehandles allow something like it in Perl5. You know, if what you say is true, I'd expect to find a module on CPAN which turns the exotic 'each' function into the friendly tied filehandle model. But I don't see one. I think people are less confused by all this than you imagine. :) Perhaps it's because the people who are capable of writing such a module, are the ones who don't need it. But, not everyone is a conway. There must be some reason why a language like Sather isn't more popular. I think that iters are part of the problem. -- Bart.
Re: Apoc2 - STDIN concerns
On Mon, 14 May 2001 12:39:11 +0100, Simon Cozens wrote: I think the more immediate problem with Sather is that it's totally obscure. I'd never heard of it. I'd never read any articles about it. It has no publicity. If people haven't heard of it, it'll remain unpopular. http://www.ddj.com/articles/1994/9415/9415toc.htm The same place I first heard about Perl. Iters are most definitely the reason why *I* didn't pick it up. -- Bart.
Re: what I meant about hungarian notation
On Mon, 14 May 2001 20:38:31 +0100, Graham Barr wrote:
You forgot
$bar[$foo]; # $bar is an array reference
$bar{$foo}; # $bar is a hash reference
As to what the combined
$bar[$foo]
would mean: that depends on what $bar contains.
(Aw! That hurt!)
--
Bart.
Re: Perl, the new generation
On Fri, 11 May 2001 08:20:53 -0400, John Porter wrote: Let's not confuse Perl 6, the Language, with Perl 6, the Implementation, which includes compatibility apparatus that knows about Perl 5. Maybe we need more difference in the names than exactly one bit. Then maybe it's a good thing that the difference is two bits. duck -- Bart.
Re: Apoc2 - STDIN concerns
On Fri, 4 May 2001 18:20:52 -0700 (PDT), Larry Wall wrote: : love. I'd expect $FOO.readln (or something less Pascalish) to do an : explicit readline to a variable other than $_ It would be $FOO.next, but yes, that's the basic idea. It's possible that iterator variables should be more syntactically distinquished than that. One could, I suppose, make up something about $FOO or $FOO meaning the same thing thing as $FOO.next, for people who are homesick for the angles, but I haven't thought that out, and don't even dare to mention it here for fear someone will take it as a promise. Er, oops... Just my thoughts: this is sick. I am having great difficulties in trying to wrap my mind around iterators. I expect that I'm far from alone at that. People are *very much* familiar with reading a line from a file. People may steer clear from a language because it deeply relies on exotic stuff like iterators. So trying to turn read a line from a file into a special case for an iterator, is the wrong way around. What you could do, is treat an iterator as something similar to reading a line from a file. Tied filehandles allow something like it in Perl5. Doing the reverse is, er, insane. -- Bart.
Re: what I meant about hungarian notation
On Tue, 08 May 2001 20:21:10 -0500, David L. Nicol wrote: What if, instead of cramming everything into scalar to the point where it loses its value as a data type that magically converts between numeric and string, as needed, we undo the Great Perl5 Dilution and undecorate references. Undecorated if for function calls and methods. And buolt-ins, of course. So what I am suggesting is, Scalar as catch-all for unclassifiables that are neither strings nor numbers may have been a historic stopgap measure in perl 5 which was seen to be unworkable given the profusion of object types which became available in perl 6. An object of type abstracted reference to a chair is _NOT_ an object of type numeric or string that magicly switches between as needed So what you're really saying is that references aren't really scalars, but their own type. Thus they need their own prefix. But we've sort of run out of possible prefixes. -- Bart.
Re: what I meant about hungarian notation
I really need to spell-check better. Undecorated if for function calls and methods. And buolt-ins, of course. Undecorated is for function calls and methods. And built-ins, of course. -- Bart.
Re: what I meant about hungarian notation
On Wed, 9 May 2001 11:06:45 -0400, Bryan C. Warnock wrote: 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) Which reminds me... One of the fundamental functions in the Windows API is SendMessage. Here, one can give two parameters. They're call wParam and lParam. Yes, originally, wParam was a word (16 bit), and lParam was a long (32 bit). But under the Win32 API, every kind of integer was turned into a long, but the names wParam and lParam still stuck, despite the fact that both are now 32 bit integers. -- Bart.
Re: what I meant about hungarian notation
On Wed, 9 May 2001 09:47:56 -0400, John Porter wrote: Undecorated if for function calls and methods. And buolt-ins, of course. No, that's the situation already. David is proposing a change. So what you're really saying is that references aren't really scalars, but their own type. Thus they need their own prefix. No, that does not follow. What he is proposing is that Perl6 would have a kind of variable that doesn't have a prefix. That isn't perlish IMO. We might just as well drop all prefixes. At least, that'd be consistent. -- Bart.
Re: Apoc2 - STDIN concerns ::::: new mascot?
On Wed, 9 May 2001 10:24:26 -0400, David Grove wrote: I remember someone (whether at O'Reilly or not I don't remember) saying that, even if it looks like a horse but has a hump, it's not allowed. Or was that an alpaca with a llama... The RFC pleads for a community spirit from ORA. Barring that, it seeks a new symbol for the community entirely. Several perl ports, and at least one book, use a shiny ball as a symbol. http://www.effectiveperl.com Scroll down to the heading Book Nickname (?). It took me a bit of thinking before I realized what this shiny ball represents. Odd. -- Bart.
Re: Apoc2 - STDIN concerns
On Sat, 5 May 2001 15:22:40 -0700, Nathan Wiger wrote: I suggest that we simply create another q-op to do the qw-ish things you're proposing. Perhaps qi() for interpolate or something else. qqw -- Bart.
Re: Apo2: \Q ambiguity
On Fri, 04 May 2001 15:05:12 -0400, Dan Sugalski wrote: Have you considered allowing Unicode characters as alternatives to some of the less pleasant looking bits? $foo1 (where and are the double angle characters) as an alternative to $foo\Q[1] if the user's got the characters handy? Until now, all characters with a special meaning for the syntax of the language, are in the ASCII range. I see no reason to change that. This is the case for most programming languages, with as a notable exception APL. -- Bart.
Re: apo 2
On Thu, 03 May 2001 22:14:47 -0500, David L. Nicol wrote: I am going to miss doublequoting being the default quoting for here strings. I find that to be a very nice optimization and would like to know more about the reasoning behind taking it away. I was already panicking when I saw this message. Of course, I hadn't seen Apo 2 itself, and I was really reliefed when I did. For the record: I had assumed that double quotish interpretation for the here docs was going to disappear. Not so. It's just that in $heredoc = END; foofoo foo foo END the double quotes around the end marker, END, will have to be included. They may no longer be dropped. I worry that official standard p6 will be more difficult to use than official standard p5. Heh? I *always* put quotes around them. But I hardly ever restrict myself to word characters in the end delimiter, anyway. I fail to see the problem. -- Bart.
Re: apo 2
On Fri, 4 May 2001 10:49:48 -0500 , Garrett Goebel wrote: And btw . . . Wouldn't $thing has property 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. Maybe it is just my interpretation of Damian's OO-Perl book... but: is = typing, inheritance, etc. has = composition, aggregation, etc. NOD Thinking as in VB again... I associate a property with has, and a default property with is. Something like: $label is Click here; $label has caption = Click here; Jeezes, this is weird stuff. -- Bart.
Re: Please make last work in grep
On Wed, 2 May 2001 11:41:32 -0500, Jarkko Hietaniemi wrote:
but I suspect in this case want('LIST') would
return that magical 0 but true or something similar.
Hopefully the something similar, I hope in Perl 6 we will able to
bury the 0 but true workaround to the backyard on a moonless night :-)
Especially since you don't need it. 0E0 and 0., to name just two,
work just as well. ;-)
--
Bart.
Re: Please make last work in grep
On Wed, 2 May 2001 17:05:31 +0100, Graham Barr wrote: wantarray-ness is already passed along the call stack today. Thats the whole point of it. So what is the difference in passing a number instead of a boolean ? Because you might have a wantarray situation that expects no values? () = whateveryouwant(); You can always expect one more than is on the LHS. How is this currently handled with split()? -- Bart.
Re: Curious: - vs .
On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote: $bar = [$obj method() ]; # method call $bar = method $obj() would be more consistent with perl's current $object = new Class() syntax. -- Bart.
Re: Curious: - vs .
On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: the idea of a dereference operator dumbfounds lots of folks. What's an object got to do with a reference, much less a pointer? A p5 object is very confusing to others for this reason, and so is the syntax. So you want a method invocation syntax that doesn't remind people of references. OK. But why does it have to be the dot? It is already taken. Sorry. Use an operator that doesn't exist yet in Perl. For example, old style VB used ! to connect objects and their properties: label1!caption = Hi! is the same as label1.caption = Hi! So why not $object!method(foo, bar); -- Bart.
Re: a modest proposal Re: s/./~/g
On Thu, 26 Apr 2001 10:15:14 +0200, Bart Lateur wrote: For example, in -3.4 and in 2-3.4 the - sign is a *different* kind of operator. No conflict. Well alright, in the first line, the - might be part of the number. Replace 3.4 with a variable and it does hold: -$x $y-$x Different kinds of operators. -- Bart.
Re: a modest proposal Re: s/./~/g
On Wed, 25 Apr 2001 18:19:40 GMT, Fred Heutte wrote: Yes, I know ~ is the bitwise negation operator. Have you EVER used it? Yes. A lot. But there is no conflict. ~ is currently just an unary operator, while your use would be as a binary operator (are those the correct terms?). For example, in -3.4 and in 2-3.4 the - sign is a *different* kind of operator. No conflict. -- Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
On Wed, 25 Apr 2001 06:09:56 -0700 (PDT), Larry Wall wrote:
Bart Lateur writes:
: Er... hip hip hurray?!?!
:
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs.
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?
$foo{THERE} always means the hashref in $foo. %foo{THERE} always means
the hashref in %foo. %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref. foo by itself in
a scalar context means a coderef. It's gonna be pretty consistent.
Yeah. But no cheers then. The problem still remains: you can access a
hash in the normal way in plain code, but inside a sub, you can mainly
only access a passed hash through a reference.
It's annoying to basically having two ways of doing something, and one
of them can't be used half of the time.
Even though @foo and %foo may be two different structures, a scalar $foo
can only reference one of them at a time.
Are you going to provide a simpler aliasing mechanism to turn a hash
reference, for example as passed to a sub as an argument, back into the
full-blown hash? Simpler (and safer) than the much frowned upon
assignment to a tyeglob, that is.
--
Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, 24 Apr 2001 21:06:56 -0700 (PDT), Larry Wall wrote:
: Ok, so what does:
:
: my %hash = ( 1 = 3);
: my $hash = { 1 = 4};
:
: print $hash{1};
:
: print?
4. You must say %hash{1} if you want the other.
Ok. So how about hash slices? Is $hash{$a, $b}, the faked
multidimensional hash, going to go? Otherwise %hash{$a, $b} is going to
be ambiguous.
--
Bart.
Re: Tying Overloading
On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote: If the idea is supporting arbitrary add-on operators, which I believe will be done seldom, for only some specific classes, wouldn't it be better to have a ``catch all'' entry for operators different than the built-in ones? Of course, add-on operators would not have the same ``performance'' of built-in ones I think I second that. I would think of a fixed table for the built-in ones, and a linked list for the add-ons. It's not necessary that a new node is added for each and every method; instead, a structure similar to those used in TIFF files could be used, where each linked in node contains a table with several items, and a new node is only added when that table is full. -- Bart.
Re: Sane + string concat proposal
On Wed, 25 Apr 2001 08:25:40 -0400, Stephen P. Potter wrote: | I'm really beginning to like | | $string3 = $string1 _ $string2; | | The underscore indeed connects the two strings. This still breaks because _ is a valid word character. So are cmp, and, lt, and the proposed cat and cc. Having operators consisting of word characters doesn't really seem to be any problem, except that you may not attach them at the end of a variable's name. -- Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
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!
--
Bart.
Re: Tying Overloading
On Tue, 24 Apr 2001 10:49:18 +0100, Simon Cozens wrote: While that's true, concatenation is quite a common operation that I'd be really uncomfortable with it necessitating 4 keystrokes ( cat) instead of one. Er, ~ is an extremely annoying character to type at many keyboards. It may depend on your keyboard localization. On my Belgian keyboard, I have to press Alt-Gr (the second Alt) and keep it down, then the ~ button, release Alt-Gr, then a space. I don't find this handy, because it's far too easy to mess up. Just the word cat (or cc) is a lot less work, simply because it requires no special keypresses. -- Bart.
Re: Tying Overloading
On Tue, 24 Apr 2001 14:37:02 +0100, Simon Cozens wrote: Let's put it a different way - if we can find a short operator which is readily accessible on most people's keyboards, then that would score over a longer operator which is readily accessible on most people's keyboards. Maybe ~ isn't that operator. Maybe is, or ^ or #, or whatever. '~' is not good because it's very hard to reach. But ^ is a deadkey too, so this one also needs pressing a space. If you want something that's easy to type and that won't conflict with current Perl, try !. Too bad _ is a word character. -- Bart.
Re: Sane + string concat proposal
On Wed, 25 Apr 2001 00:37:53 +0100, Simon Cozens wrote: $string3 = $string1 . $string2; $string3 = $string1 + $string2; That's now *five* characters required to perform a very common operation. Rather than one. I'm really beginning to like $string3 = $string1 _ $string2; The underscore indeed connects the two strings. But: as somebody else wrote: why on earth do we need to reserve the dot for OO? Why do we have to be compatible with everybody else in the world? Because we're not, anyway. Recently, there was a question about polymorphism in Perl. This person did not understand that it is possible that you can use the same method for two different classes, without them having a common superclass. It's perfectly possible in Perl (because method resolving actually is a form of symbolic dereferencing... heheh...), but most definitely not in most other OO languages. So, perl is different anyway. What does one tiny extra superficial difference of notation FGS make any difference. I think backward compatibility with Perl5 is far more important, than having the *appearance* of doing the same as other OO languages. -- Bart.
Re: So, we need a code name...
On Tue, 24 Apr 2001 19:17:08 -0500, Jarkko Hietaniemi wrote: Wasn't Perl also taken, so why care...? I vaguely remember reading about another language called PERL... It was Pearl, AFAIK. That's why the a got missing. So I've been told... (Practical Extracting And Reporting Language... yup, there is an a there.) -- Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:
Using + for concat: no!
My vote is to use . and require space before and after.
$this.$is.$ugly.$anyway ;)
My vote is to ditch the concat operator altogether. Hey, we have
interpolation!
$this$is$just$as$ugly$but$it$works
Which reminds me... one problem I have with it is that it's too hard to
separate a variable name from the rest of the string, if it also
consists of word characters:
my $bar = BAR;
print foo${bar}baz; - fooBARbaz
Since $bar is a lexical variable, this syntax doesn't make much sense
anyway: it reeks of symbolic references and those don't work for
lexicals.
I think I'd like something incorporating a backslash would be nicer:
print foo$bar\Ebaz;
It works, but it may have unwanted side effects -- in case the \E
actually serves a purpose.
But, you may completely forget about it. I just had to say this one day.
--
Bart.
Re: Tying Overloading
On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr wrote: Or we change the concatenation operator. I am thinking that maybe it should be a 2 character operator with at least one of then being + as + is common in many other languages for doing concatenation. Or, in analogy to cmp, gt etc: $a = $b plus $c; or $a = $b cat $c; -- Bart.
Re: PDD 4 internal data types, version 1.1
On Thu, 29 Mar 2001 19:24:21 +0200 (CEST), Tels wrote: And then, if we have BigFloat, we need a way to specify rounding and precision. Otherwise 1/3 eats up all memory or provides limits ;o) Er... may I suggest ratio's as a data format? It won't work for sqrt(2) or PI, but it can easily store 1/3 as two (long) integers. You can postpone doing integer divisions until you need a result, at which time you can reorder calculations between * and /, so (2/3)*9 will return exactly 6. -- Bart.
Re: Schwartzian transforms
On Wed, 28 Mar 2001 11:11:20 -0500, Dan Sugalski wrote: "Can perl automatically optimize away function and tie calls inside a sort function, and under what circumstances?" 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. This whole discussion borders on the edge of the ridiculous. Any sort algorithm ALWAYS assumes that comparisons are constant, i.e. return consequent results on subsequent calls. They always infer sorting information out of what they got yet. That's why they hardly ever need to compare every item with every other item. The fewser comparisons, the better the algorithm. As MJD very recently wrote: An optimal sort function will not call the comparator if it already knows what the result should be! So true. That implies that side effects and otherwise unmemoizability of sort functions may *always* safely be ignored. If not, the programmer has a personal problem, i.e. a bad starting point. Otherwise, the results of sort would largely depend upon which sort algorithm was used internally! -- Bart.
Re: Schwartzian Transform
On Wed, 21 Mar 2001 15:40:20 -0500, John Porter wrote: Uri Guttman wrote: JP y/L/A/; tell that to perllol :) I do, through clenched teeth, every time I see it. IMHO, it is: HoA HoH LoA LoH -- Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Wed, 21 Feb 2001 17:32:50 -0500 (EST), Sam Tregar wrote: On Wed, 21 Feb 2001, Bart Lateur wrote: Actually, it's pretty common. Only, most languages are not as forgiving as perl, and what is merely a warning in Perl, is a fatal error in those languages. Examples? I know you're not talking about C or C++. Visual Basic, for one, or any other BASIC in history. It looks like a compiled vs. interpreted thing. C doesn't do any runtime error checking, because of speed reasons. There's no array bounds checking. You can use a null pointer when copying a string, which results in an untrappable program error ;-). Virtually all interpeted languages, where safety reigns over speed, do all of those. Anything out of the ordinary is a fatal error. AppleScript is an extreme example. There, if you're trying to get a list all picture boxes of a certain type on a page, it works properly if there is one or more. But if there is isn't one, you don't just get the empty list. No: it's a fatal (but trappable) error. That kind of anal behaviour in a language is extremely annoying. -- Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Wed, 21 Feb 2001 16:01:39 -0500, [EMAIL PROTECTED] wrote: Has anyone actually used a language which has run-time warnings on by default? Or even know of one? Actually, it's pretty common. Only, most languages are not as forgiving as perl, and what is merely a warning in Perl, is a fatal error in those languages. Trying to read the value of an uninitialized variable, for example, that's commonly a fatal error. Failing to chdir, is another example. So even with warnings on by default, Perl is still pretty mild. -- Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tue, 20 Feb 2001 16:31:35 -0500, Bryan C. Warnock wrote:
Scalar value @foo[$bar] better written as $foo[$bar], for one.
I agree on this one (hash slices too), if this expression is in list
context. There is no error in
@r = map { blah } @foo{$bar};
--
Bart.
Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test
On Mon, 19 Feb 2001 15:47:12 +0100, Johan Vromans wrote: As an active non-smoker, I'd appreciate a different name. You guys (=plural) are nuts. So much bickering over such a tiny irrelevant detail. But anyway, if you want a clear and explicit name, why not "smoketesters". Nothing to do with tobacco. Electronics, yes. Or, if you're unlucky, former electronics. -- Bart.
Re: The binding of my (Re: Closures and default lexical-scope
On 17 Feb 2001 20:53:51 -0800, Russ Allbery wrote: Could people please take the advocacy traffic elsewhere where it isn't noise? Advocacy is noise everywhere. That doesn't mean that davocates for either side don't have anything interesting to say. For starters, it's usually dissatisfaction with certain aspects of some languages that causes the birth of yet another new language, such as PHP (which is more a different programming platform than really a different, full blown language) and Ruby. When designing a new generation of a language, it can be interesting to look what those alternative language designers have done. They just might have done some interesting things. No language is an island. -- Bart.
Re: Warnings, strict, and CPAN
On Fri, 16 Feb 2001 21:03:54 -0800, Edward Peschko wrote: It is one hell of a burden to find a missing 'use strict' or 'use warnings'. 'Well, type them then' you say. Right, and always type ';' at each line, or 1; at the end of each file. Its as unavoidable as a *syntax error*, which is the point. syntax errors should be easy to fix, not hour-long treks through code. It seems to me that *that* is your main problem. Not the fact that strict and warnings aren't put in by the perl interpreter itself, but that perl code is so difficult to debug. Something as simple as requiring variable declarations or initializing variables ought not take hours of debugging, assuming that for the rest, the source works reasonably OK. So, A) a code profiler that can verify use of variables and stick a limited scope onto every variable, plus optionaly initializing variables to '' or 0, that might be handy at times. B) perl's error messages could be somewhat more helpful. If you have a here doc with 30 lines of interpolated pure text, it's extremely annoying that perl will only point you to this data block (actually to the line containign the ""), and just say "use of uninitialized value" without saying *which* variable it is talking about. But, this has been brought of on the perl6 lists a few times already. All this could help strictifying and warn-proofing otherwise properly working modules, in say, oh, five minutes. -- Bart.
Re: End-of-scope actions: do/eval duality.
On Thu, 15 Feb 2001 10:04:51 -0300, Branden wrote:
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }' to
have the behaviour of not dying and setting $@ ?
The reason for its existence is simple: history. "do FILE" dates from
before "eval BLOCK". The only way it could have been like you say,
would, at the time, have been:
eval "do \'$file\'";
which is simply horrible (and possibly buggy, if $file contains an
apostrophe or a couple of backlashes).
--
Bart.
Re: End-of-scope actions: do/eval duality.
On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote: In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is set to the result of an eval or do. How does this impact exception handling tests on $@ to determine if an exception was thrown, if $@ can be set by a do ? OR is that an error in the pocket guide? No, it's a misunderstanding between you and Tony. The "do" your reference is talking about, is of the form do FILE where file is a string containing a filename, while Tony is talking about the do BLOCK form. do FILE behaves just like eval() (except it reads its data from a source file), while do BLOCK doesn't. Neither. -- Bart.
Re: assign to magic name-of-function variable instead of return
On Tue, 6 Feb 2001 04:36:36 +1100 (EST), Damian Conway wrote:
RFC 271 handles this. Your example would be:
sub readit {
open F, " $f" ...
scalar(F)
}
post readit {
close F;
}
The connection between these two things is not strikingly obvious. I'd
like it better, if you put the post thing inside the sub readit's
contents. It can even be anonymous.
sub readit {
open F, " $f" ...
scalar(F)
POST {
close F;
}
}
The place where it would be put, would be irrelevant.
sub readit {
POST {
close F;
}
open F, " $f" ...
scalar(F)
}
--
Bart.
Re: vtables: Assignment vs. Aliasing
[CC'ed to language, because I think it's there that it belongs]
On Mon, 5 Feb 2001 15:35:18 -0200, Branden wrote:
There are two possible things that could happen when you say:
$a = $b;
@a = @b; # or
%a = %b;
These two things are assignment and aliasing.
No way. Although I think aliasing is a great tool, but assignment is by
value. Always. (Well, except for referenced things...)
In perl5 terms:
*a = \$b;
*a = \@b; # or
*a = \%b;
However, typeglobs are said to disappear from Perl6,
I think Larry wants to drop typeglobs themselves, i.e. keeping different
kinds of variables of the same name in one record, but not the
possibilities they offer. Aliasing is likely the most interesting
feature of them all.
...
My preference:
* Alias when assigning to a reference:
\$a = \$b;
\@a = \@b;
\%a = \%b;
I think this is a nice symmetrical syntax.
* Make aliasing the default for = and provide another way of assigning (NO
WAY!!!)
Indeed, no way.
Look, if you'd do the latter, you would not only make Perl effectively a
different language, but you'd also be missing out on one of the great
benefits of aliasing. For example, you pass a reference of a hash to a
sub, so the original hash can be accessed and modified. With the latter
syntax, you can't even do that through an alias. In the former syntax:
foo(\%bar);
sub foo {
my \%hash = shift; # alias through reference
print $hash{FOO};
}
You can now access the passed hash as a hash, and not through the
slightly awkward syntax of accessing it through a reference:
sub foo2 {
my $hash = shift;
print $hash-{FOO};
}
(You don't think it's that awkward? Try getting a hash slice through a
hash reference. Ugh.)
--
Bart.
Re: assign to magic name-of-function variable instead of return
On Sun, 4 Feb 2001 15:43:29 -0500, James Mastros wrote:
The $__ option seems a lot better to me, because there's no syntatical
reason against self-reference. ($^R for return might be a better name --
unless we've already used that for somthing else. Nope.)
What do you mean, "nope"? It *is* in use. The (?{...})
embed-perl-code-in-a-regex feature sets it. With a return value. Hah.
BTW I think the whole idea is bad. I like "return FOO". Neat and simple.
At least it's independent of the sub's name. I wish this could be
extended to doing recursive calls without having to say the subs own
name, again.
--
Bart.
Re: Really auto autoloaded modules
On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote:
use autoload { Bar = 'http://www.cpan.org/modules/Bar' },
{ Baz = 'ftp://my.local.domain/perl-modules/Baz', VERSION =
2 };
Very good idea indeed!!! Append the wishlist to add this module to perl6's
standard library!!!
Very *bad* idea. It sounds nice, but using a remote module without any sort
of control is just begging for trouble.
I agree. Plus, it strikes me as asking for trouble. It sounds make-ish.
So every time you run a script, it could actually *upgrade* your module
behind your back, without you checking it!
But, this discussion gives me yet another idea. Think of a module,
somewhat like the B::* modules. This one could check your script, and
prevent perl from running it, but instead try to install any modules
that you're missing. The installation itself of the modules could be
handled by (an extension of) CPAN.pm. Of course, it shouldn't upgrade,
i.e. replace, any previously installed modules without your explicit
consent.
--
Bart.
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, 31 Jan 2001 08:53:13 -0600, Jarkko Hietaniemi wrote: So nice of you to volunteer for being our help desk person man for explaining to people why their time() just got broken :-) I'd use the same function name for both the integer version of time(), and the hires version. All you need is an optional parameter, whicch, if true, makes time() return a float. $a = time();#same as now $b = time(undef) # idem $c = time(1)# hires -- Bart.
Re: safe signals + sub-second alarms [was: sleep(0.5) should DWIM]
On Wed, 31 Jan 2001 11:36:32 -0500, Ken Fox wrote: You want perl to block a thread and then busy wait until it's time for the thread to wake up? What if we take the ordinary sleep() for the largest part of the sleeping time (no busy wait), and the 4 argument select for the remainder, i.e. subsecond? What if we add a new function, say, "nap" (very short sleep), for subsecond sleeping times? -- Bart.
Re: RFC195: Do not remove 'chop' PLEASE!
On Mon, 29 Jan 2001 11:47:47 -0500, Uri Guttman wrote: well, according to this perl5.6.0 -le '%h = qw( a b c d ); $_ .= 1 for %h ; print values %h ; chop %h ; print values %h' b1d1 bd it doesn't appear to be a chop specific thing. unraveling a hash always seems to use aliases for the values. chop just takes a list like it always has. If you're talking about values(%h) returning aliases to the values in the hash: well, that's a pretty recent thing. It wasn't like that in pre 5.6.0 (or near) days. I remember complaining about this not being the case in comp.lang.perl.misc, just one year ago (Deja finds a message dated 01/16/2000, subject line "values() does not return LValues"). -- Bart.
Re: JWZ on s/Java/Perl/
On Sat, 27 Jan 2001 18:16:52 -0500, Michael G Schwern wrote: o The architecture-interrogation primitives are inadequate; there is no robust way to ask ``am I running on Windows'' or ``am I running on Unix.'' **We have $^O, but it requires parsing every time** Uhm, I'm sorry, but that's not good enough. You cannot distinguish between Windows 95/98/ME on one side, and NT/2k on the other, using $^O alone. After all, $^O is just a constant burnt into the executable when perl was compiled. You can run the same perl.exe on all platforms, and indeed, most people do. Yet win9* and NT are different enough in behaviour (e.g. flock) to warrant a test on platform. Er... which is: no go. -- Bart.
Re: RFC195: Do not remove 'chop' PLEASE!
On Sat, 27 Jan 2001 15:42:43 -0700, root wrote:
I read RFC195 suggesting to drop 'chop' and go with 'chomp'.
What does 'chop' have anything to do with 'chomp'?
I'm totally oppose to that. Consider:
my $s;
map { /\S/ $s .= "$_ " } split(/\s+/,@_);
chop($s);
return $s;
Excuse me, but you're using chop() for a task it wasn't invented for.
Think about joining your strings with more than one character.
my $s;
map { /\S/ $s .= "$_ - " } split(/\s+/,@_);
chop($s);
return $s;
That doesn't quite cut it, does it?
Here's how you should have written your code:
return join ' ', grep { /\S/ } split(/\s+/,@_);
I, too, once used chop() to get the last character of a string, in my
case to calculate a barcode check digit.
while(my $digit = chop($barcode)) {
...
}
The while loop should have continued until $barcode was empty, all
digitis consumed. Well, the fact that "0" is false really spoilt it for
me.
And in case you're wondering why I wanted to process a barcode from the
back: because the total number of dogots isn't always the same, and the
last digit is the only one you're always sure of on how it ought to be
processed. For the following digits, you always have to toggle the
behaviour of the processing.
The full story is: chop() is not a generic operator, but one
specifically intended for one dedicated task: dropping the newline from
a string read from a file. If you use it for anything else, it probably
sooner or later will bite you. And it's not particularily good at what
it *was* designed for, e.g. with a file not ending in a newline.
--
Bart.
Re: perl IS an event loop (was Re: Speaking of signals...)
On Sat, 6 Jan 2001 00:45:11 +, Simon Cozens wrote:
No, it's exactly what Perl 5 does.
This is the Perl interpreter:
while ((PL_op = CALL_FPTR(PL_op-op_ppaddr)(aTHX))) {
PERL_ASYNC_CHECK();
}
The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
do anything. :)
I don't get it. Does this *have* to give a 3-5% performance hit? Even if
you do it this way (syntax is a Perlish extension to C):
while ((PL_op = CALL_FPTR(PL_op-op_ppaddr)(aTHX))) {
async_waiting or next;
PERL_ASYNC_PROCESS();
}
BTW I agree with Nicolas Clark's remark (but I don't subscribe to p5p,
so I won't post there either):
Hmm. No-one produced a patch with 2 loops, 1 for normal use, and 1 when
%SIG has handlers other than default or ignore assigned to it.
Would that be an acceptable perl5 compromise?
Since this "event loop" is so tiny, this doesn't even look like much of
a compromise.
Apropos safe signals, isn't it possible to let perl6 handle avoiding
zombie processes internally? What use does having to do wait() yourself,
have anyway?
--
Bart.
Re: Now, to try again...
On Sun, 17 Dec 2000 14:11:50 -0700 (MST), Nathan Torkington wrote: I think the problems with this that were raised in the past are: * parsing partial source * does this mean that the parser has to reparse the whole sourcefile every time you type a character? Hold it. I don't think that is very practical, and for more than one reason. For the editor I'm currently using, the Perl syntax coloring is a bit simple minded, in that it does its syntax highlighting on a line by line basis. Yes that does imply that multiline statements and strings won't be colored properly, but otherwise, it behacves nicely. Why? because, when I'm working on source, it is very unreasonable to expect that the source will be a valid Perl program after every single keystroke. So no, while editing, it is *impossible* to do proper syntax highlighting for the whole script at all times. More specifically, I can't be 100% sure that the lines *above* the one I'm currently editing, are indeed valid Perl. And I don't care, not at this moment. I definitely do not want these lines above to screw with the syntax highlighting of the line that I'm currently editing. So what do I envision? I think we need some sentinels, marker points in the source, saying: "OK, do not reparse anything above this marker". What kind of marker? Block ends, or semi-colons, those seem like reasonable candidates. We should also know where to stop. Do we indeed want, as soon as we type one quote, have everything on the right of and below it, to change color into "quoted string" mode, up until the next quote? Is this a tool, or a light show? If we limit the range of what the syntax highlighter affects at any time, we'll save on processing time too. For example, we can re-highlight the lines below the one we just edited, as soon as the cursor leaves the line. But, the gist of this post is: we don't want to loose the usefulness of the syntax highlighter, as soon as there is one syntax error in the script, because this will be the normal situation while editing source. Parsers are generally very bad at parsing erroneous code. -- Bart.
Re: SvPV*
On Fri, 24 Nov 2000 08:54:43 +0100, Roland Giersig wrote: Maybe the title should be : "Perl should use XML as its basic data type instead of linear strings" Horrible. I kinda liked your original proposal. But you should NOT focus on XML. That leaves out too many other possible data sources: RTF, for example, or TeX. What is typical, is that it is marked up text, in the form of a tree, i.e. properly nested. The internal structure might as well be easily representable as XML. I do think that the term "non-linear text" is absolutely unclear. -- Bart.
Re: To get things started...
On Tue, 21 Nov 2000 17:24:49 +, Simon Cozens wrote: I really *would* recommend Aho, Sethi, Ullman, "Compilers: Principles, Techniques and Tools". AKA "The Dragon Book". You're not the only one to mention this book on this list. IMO, this book is really thick to crawl through, and in the end, it's all just theory, you still won't be able to build a compiler, or an optimizer in case you already have a compiler. Heh. In short: are there any more *practical* "how do I build my own compiler" books, that people can wholeheartedly recommend? -- Bart.
Re: To get things started...
On Wed, 22 Nov 2000 14:15:57 -0500, Dan Sugalski wrote: We bootstrap on perl5 to get a bytecode stream, and then that bytecode stream had better stay supported. Yup. It's one way to ensure backwards compatibility... :) I assume a byte is still 8 bits? So you have a max of 256 different (1 byte) opcodes? What if Perl6 has more than 256 instructions (as it probably will)? Will somebody choose the important ones, which get a one-byte opcode, and the rest get an escape byte + one (or more) opcode bytes, à la Z80 machine code? But what if you choose wrong, forgat a really important one, and this instruction gets a multibyte representation? We're stuck with it forever...? I have had some thoughts on "dynamic opcodes", where the meaning of opcode bytes needn't be fixed, but can be dynamically assigned, depending on how often they occur (for example). A bit like how a Huffman compressor may choose shorter representations for the most occurring byte patterns. Just some wild thinking. -- Bart.
Re: Critique available
On Thu, 2 Nov 2000 16:10:12 +, Simon Cozens wrote: On Thu, Nov 02, 2000 at 10:11:56AM -0500, Mark-Jason Dominus wrote: My critique of the Perl 6 RFC process and following discussion is now available at http://www.perl.com/pub/2000/11/perl6rfc.html Agree 100% to every point. Coming from someone whoe probably wrote more RFC's than anyone else (I count 33), I find that pretty ironic. But no, I don't think the RFC process is a failure. I sure hope that the collection of accepted RFC's is the blueprint for Perl6. Because, for one thing, I really despise the idea of placeholders as a "data type" (They're not. It's like saying a witch is not a woman. They're just scalars, but which "enchant" the expression they're in.) Curried functions have their uses, but not in this syntax. Far too much ambiguity. I sure hope Larry shoots this idea down. And there are plenty of other idea's that haven't even been RFC'ed, mainly because of lack of time. Writing an RFC for a relatively simple idea took me *hours*. Unofficial discussion is sooo much simpler. -- Bart.
Re: code name for perl 6
On 19 Oct 2000 22:01:23 -, [EMAIL PROTECTED] wrote:
the code name "omega" would be a fitting handle...after all, this will be
the last perl of all...i am obviously assuming perl 6 will not be still born.
Hey, why not something in the line of "2PI" ("P2PI"?). After all, 2 * PI
is what the version number should asymptotically head for, according to
that RFC that Larry Wall mentioned in his talk.
--
Bart.
