Re: [RFC] Perl6 Operator List, Take 5
On 2002-10-30 at 12:47:17, Larry Wall wrote: (Anybody know of a version of pine that does UTF-8?) Yes - it's called mutt. ☺ Seriously, I do highly recommend switching from pine to mutt. It's not a completely painless transition, since mutt is more ELMlike than PINElike, but I know many who have made the switch and never looked back. And mutt does do UTF-8 just fine, including converting automagically between it and various other character sets (whichever ones your iconv library knows about). And I continue to see no French quotes whatsoever in your messages, while those from other people either come through fine or come through with Latin-1 French quotes marked as UTF-8. Very odd. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
email encoding of the french quote characters (ISO_8859_1 0xab and 0xbb)
On Wed, 30 Oct 2002 at 12:17 -0800, Michael Lazzaro [EMAIL PROTECTED]: On Wednesday, October 30, 2002, at 11:58 AM, Larry Wall wrote: I'd even be willing to give up ´foo bar bazª meaning qw(foo bar baz) for this. I can't see that right (MacOSX Jaguar) in the email; to me it looks like a forwardtick and an, um, underlined 'a' -- but in spite of that, I'm game. It's just so pretty (when it works!) On my Mac, it's spelled «op» -- can others see that correctly, or do we have a sorry disconnect in the fonts, here, for us Mac folks? This concerns me, so forgive this partial digression. When I tried to read Larry's message there were no characters around the foo bar bas (which arrived as Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT) I just saw I'd even be willing to give up foo bar baz meaning qw(foo bar baz) for this. in both pine and lookout, and my spool files. I was quite surprized when I saw Larry's message quoted with the characters in question in Austin's message (arrived as Content-Type: text/plain; charset=us-ascii) I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz) for this. How did they get transformed to the funny 0xb4 and 0xaa characters in Micheal's quote. (arrived as Content-Transfer-Encoding: quoted-printable_ ISO_8859_1 253 171 AB « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK 273 187 BB » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
RE: [RFC] Perl6 Operator List, Take 5
-Original Message- From: Austin Hastings [mailto:austin_hastings;yahoo.com] How do you write a in a Windows based environment? (Other than by copying them from Larry's emails or loading MSWord to do insert-symbol) You could use the Character Map accessory to put the character into the clipboard, or press the alt and hold the alt key while typing 0171 (or 0187) alt+0171 alt+0187
Re: [perl #18170] [PATCH] very complete lexical scope implementation
Jonathan Sillito (via RT) wrote: # New Ticket Created by Jonathan Sillito # Please include the string: [perl #18170] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18170 - changed: sub.c Comments? WRT your comment: should we use a List * here, I slightly vote for yes. In the long run we could use List as the basic store for registers and stacks as well. List would only need a small extension to manage arbitrary sized data. WRT names: wouldn't be a hash faster then the linear search? leo
Re: Vectorizing operators for Hashes
%a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. I'd agree with that. In fact probably anything over 4, and even 4 is seriously pushing it. I'll clarify that I am talking here about using adverbs. From A3 (about the colon): Hence, this operator modifies a preceding operator adverbially. ... It can be used to supply a ``step'' to a range operator, for instance. I would expect the length of these adverbs to fall in a range somewhat the same as properties. So a word like 'union' is reasonable, and even 'intersection' too. Ignoring hyperoperators, one might use an adverb thus: $a / $b : dbz_Inf to have a divide by zero be treated as Infinity. I can see scope for a bunch of adverbs that control how a particular hyperoperation works. Thus, perhaps: a ^[/] b : short to stop iteration when the shortest of two arrays is used up. But this assumes that the adverb applies to the ^[] hyperop, not the / op. Perhaps this is resolved thus: a ^[/ : dbz_Inf] b : short But I also suspect it would be good to be able to associate distinct adverbs with the lhs and rhs of a binary operation. So I thought perhaps one could go down the path of a ^ :step(2) [/ : dbz_Inf] :step(3) b : short Hmm. Perhaps hyperop adverbs are preceded with a ^ and one gets instead: a ^[/] b : dbz_Inf, ^short, ^step(2,3) -- ralph
Re: Vectorizing operators for Hashes
On 31 Oct 2002 at 0:40, John Williams wrote: On Wed, 30 Oct 2002, Me wrote: %a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. I don't think there should be any upper limit for operator-lengths. e.g. When teaching perl to my little brothers (still at primary school) I might want to use alphabetical userdefined operators: print 1 + 5 - 4 / 2 print one plus five minus four divided_by two (and same in finnish) näytä yksi plus viisi miinus neljä jaettuna kaksi At least it wouldn't harm anyone to allow this. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
* Dyck, David ([EMAIL PROTECTED]) [31 Oct 2002 19:21]: [...] You could use the Character Map accessory to put the character into the clipboard, or press the alt and hold the alt key while typing 0171 (or 0187) alt+0171 alt+0187 To be honest, as easy as it is to type ^a^v or ^k,[1] it's still typing an awful lot just to get a character. Surely the Perl operator Huffman encoding should take into account the length of time it takes to type the darn thing. Personally, I'm against non US-ascii chars being part of the core language. It's fine if people want their Unicode identifiers, or import modules to change operators, but I'd like to think I can at least read and write my own code in non-Latin-1 environments. [1] screen and vim respectively, although I could always make vim treat as an abbreviation for the guillemet, although that would interfere with heredocs), cheers, -- Iain, who carefully didn't use any « or » chars until just then. Oops.
Re: Vectorizing operators for Hashes
Uri Guttman writes:
%hash1.values [+]= %hash2{%hash1.keys} ;
but here is exactly example analogous to
my Dog $x = new Dog .
which was discusse dand turned to
my Dog $x .= new ;
It's (almost) clear what you want when you write
%hash1 [+]= %hash2 ;
so why to screen the meaning with several ( almost ) unnecessary
words .
And besides, If that will be usefull there will be somebody who will
make those shortcuts.
aracdi .
Perl6 Operator List (REMAINING ISSUES)
Michael Lazzaro writes: OK, by my count -- after editing to reflect Larry's notes -- only a few issues remain before the ops list can be completed. 1) Need a definitive syntax for hypers, ^[op] and «op» have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. 2) Possible inclusion of unary prefix ^, meaning complement. (Assuming doesn't conflict with (1)) 3) Possible inclusion of like/unlike or similar as synonyms for ~~ !~. Which we don't have to decide now. All other op issues, by my count, revolve around the meanings of specific hyperop constructs. There is one, overriding question with the hyperops, which is the precise relation between an op, an assignment op, and their (three!) hyperop equivs: A op B A op= B A ^[op] B A ^[op=] B A ^[op]= B If we can formalize the precise relationship between the three hypers in the presence of scalar and list (and hash?) values for A and B, I believe we can answer nearly all the hyperop questions definitively. For example: a ^[op] b # array v array $a ^[op] b # scalar v array a ^[op] $b # array v scalar $a ^[op] $b # scalar v scalar a ^[op=] b # array v array $a ^[op=] b # scalar v array a ^[op=] $b # array v scalar $a ^[op=] $b # scalar v scalar a ^[op]= b # array v array $a ^[op]= b # scalar v array a ^[op]= $b # array v scalar $a ^[op]= $b # scalar v scalar and also this : %a ^[op]= b # hash v array %a ^[op]= $b # hash v scalar %a ^[op]= %b # hash v hash a ^[op]= %b # array v hash $a ^[op]= %b # scalar v hash Some of these are nonsensical, some of them aren't. So which are which, and can someone demonstrate that the rule holds true for ALL hyperoperators, as opposed to just MOST? ;-) MikeL arcadi
Re: Vectorizing operators for Hashes
Me writes: %a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. I agree. But I think that we can get away here with just hash properties , just like hash behaviour in regexps is controlled by properties . e.g. union: (%a,%b) ^is no_strict_keys ; (%a %b) ^is default_value ( 0 ) ; %a ^[+] %b intersection : (%a,%b) ^is strict_keys ; %a ^[+] %b this maybe longer but clear : one line - one concept . but I am not shure ... arcadi .
Re: [RFC] Perl6 HyperOperator List
Yesterday Aaron Crane wrote: Jonathan Scott Duff writes: a `+ b In my experience, many people actually don't get the backtick character at all. Yes. I think that might be a good reason _for_ using backtick in vector operators: * Backticks aren't used in any other operators, so they would not be mistaken for xor nor arrays. Backticks also look a little odd, so even if it isn't intuitive as to what is going on, somebody seeing a vector op for the first time should at least spot that _something_ different is happening. * People starting out in Perl wouldn't want to use vector ops straight away (there are enough other things to be learning). So a character that involves 'advanced' typing is used for an 'advanced' feature. A pair of backticks could be used if the vector-equals distinction is required: a `+`= b; a `+=` b; I always hate teaching people what backticks do -- not because the concept is difficult, but because the syntax is so alien to so many people. So I teach qx// for Perl, and $() for Unix shell, and I throw in backticks as an extra 'you might also see this' affair. I don't think backticks for vector conflicts with backticks for invoking a shell (cos the latter is a term not an op), I'd be in favour of removing the current backtick behaviour anyway: * It looks like quoting, and it isn't really. It's more like a function call. * Many people use backticks when Csystem() is desired. The fact that these two similar features look so different from each other us confusing. Also, if backticks were to be used for vector ops then removing the existing use would mean that backticks are _only_ for vector ops. No 'small exceptions' -- the very simple rule that backticks are always vector ops. Anyway, that was a bit of a rant, but what I mean is: I'd actually be in favour of avoiding backtick entirely in operators. I can see where you're coming from there. They are an awkward glyph. But Larry's short enough of characters as it is: I don't think we can afford to throw one away entirely, however unpleasant it is. Smylers
Packfile / strings / flags
The packfile contains for string constants the STRING internal field flags. This is used for various *internal* purposes, e.g. defining that a string is external or COWed. So a badly (i.e. non NULL) set flags field could seriously damage parrots operation WRT strings. IMHO, this field doesn't belong into the PBC. In the meantime, I would clear flags near packfile.c:930. leo
Re: [RFC] Perl6 HyperOperator List
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: Yesterday Aaron Crane wrote: Jonathan Scott Duff writes: @a `+ @b In my experience, many people actually don't get the backtick character at all. Yes. I think that might be a good reason _for_ using backtick in vector operators: A pair of backticks could be used if the vector-equals distinction is required: @a `+`= @b; @a `+=` @b; Thats ugly, IMO. Now this is going to sound wild (probably) and I have not thought too much about it and there are probably others who can see the pitfalls quicker then me. But could () be available for hyper operators ? I will sit back now and watch the firewaorks, as I wont be in the UK on Nov 5 :-) Graham.
RE: [RFC] Perl6 Operator List, Take 5
--- Dyck, David [EMAIL PROTECTED] wrote: -Original Message- From: Austin Hastings [mailto:austin_hastings;yahoo.com] How do you write a in a Windows based environment? (Other than by copying them from Larry's emails or loading MSWord to do insert-symbol) You could use the Character Map accessory to put the character into the clipboard, or press the alt and hold the alt key while typing 0171 (or 0187) alt+0171 alt+0187 Well, that certainly flows fluidly from the fingertips... ^[op], you say? Or I could finally figure out how to program the function keys on my keyboard, I guess... APL, here we come... =Austin __ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute
Re: [RFC] Perl6 HyperOperator List
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
? ?| ?^ - [maybe] C-like bool
operations
?= ?|= ?^= - (result is always just 1 or
0)
[?][?|][?^] - (hyperversions)
[?]= [?|]= [?^]=
[?=] [?|=] [?^=]
Two possible differences between double-[|] and single-[|]:
1- Force (unlazy) evaluation of all operands.
2- Force conversion to 1 or 0. (Are true and false going to be
built-in literals, a la java?)
Which (or both) of these are supposed to come from the single-op
versions of these?
Superpositions don't lazily evaluate their operands (unless those
operands are themselves superpositions).
Sorry, let me be more explicit: Forget the flexops for now. What's a
C-like boolean single-letter do?
- [maybe] C-like bool operations
- (result is always just 1 or 0)
In the C that I learned, the ^| ops were bitwise.
Likewise, the || ops were lazy booleans.
So what's a single-letter boolean act like? Is it lazy? Does it retain
its bitwise-ness but (since boolean) force evaluation for 1 or 0 first?
I just don't understand what the implied behavior is, since the
reference is outside my experience.
$a = 1 | 5;
$a = 10;
What's $a?
1 | 5 10
Yes (by precedence)
Umm, is this wrong? As I understand it, that's the same as 1 | (510)
because of precedence, no?
(1|5) 10
Yes (explcitly).
(With apologies to the folks at Sesame Street):
One of these answers isn't like the other ...
One of these answers just doesn't belong ...
On the other hand, some of the examples seem counterintuitive. That
is,
considering Damian's:
$seen = $start | $finish;
for ... - $line {
print $line\n unless $line == $seen;
$seen |= $line;
}
I can understand the notion of unless $line is a-or-b-or-c-or...
but
I keep THINKING in terms of I've seen a-and-b-and-c-and...
That's understandable. So you write:
$seen = $start $finish;
for ... - $line {
print $line\n if $line != $seen;
$seen = $line;
}
Yeah, that's better. Thanks.
So when would multiple flexops be combined? Anyone have any real
world
examples, even simple ones?
Sure (for sufficiently complex values of simple ;-)
Here's how to find the love of your life:
$requirements = tall dark handsome
| old rich
| Australian;
for - $candidate {
my $traits = any( split /ws/, $candidate );
print True love: $candidate\n
if $requirements eq $traits;
}
Of course, not everyone can hope to be lucky enough to meet an
Australian, but you get the idea. ;-)
Well, thank God for small favors.
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
I mean, assuming that the split returns only adjectives, you've got
something like:
short busty dark nymphomaniac father owns a chain of
liquor stores
in the requirements
and you've got
a | b | ... | z
in the traits
How do THOSE work together?
(In other words: Can you write Apoc.Flexible now, please?)
=Austin
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: worth adding collections to the core language?
--- Damian Conway [EMAIL PROTECTED] wrote: Larry wrote: Possibly we might even extend the notion of hash to any junk. %hash = 1 | 2 | 3; So you're suggestion that a normal hash is a junction of pairs??? Damian Conway admits: Everything in Perl6 is 'Junk' Who can't see *this* coming on slashdot? :-) =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: operator:alt-0171 and operator:alt-0187
--- Iain 'Spoon' Truskett [EMAIL PROTECTED] wrote: * Dyck, David ([EMAIL PROTECTED]) [31 Oct 2002 19:21]: [...] You could use the Character Map accessory to put the character into the clipboard, or press the alt and hold the alt key while typing 0171 (or 0187) alt+0171 alt+0187 To be honest, as easy as it is to type ^a^v or ^k,[1] it's still typing an awful lot just to get a character. Surely the Perl operator Huffman encoding should take into account the length of time it takes to type the darn thing. Somewhere, deep in the bowels of some Digital Equipment .. err .. Compaq .. err .. HP building, there's a guy getting major wood because ALL THAT WORK that he chipped in so many years ago on the 'X' keyboard input routines is about to be justified. FINALLY, someone in the US is going to actually use the [compose] key. Woo-hoo! (Except for the PCLinux guys, who didn't get a Compose key. But maybe they can liquid-paper over the Windows key and write in Compose and «voila»!) [Note smooth, casual insertion of guillemets into daily conversation ...] How much of the length of time it takes to type the darn thing is because right now we don't use those symbols? Most PC keyboards make the tilde (~) character a PITA by putting it out at top-left or top-right (or, worse, just below backspace). The reason -- most people aren't writing perl or awk code, and so aren't using that symbol. This is, IMO, one of those cases where if we suck it up and adopt the operator, and if the operator's as useful as it seems, then it will take about two weeks before this problem is history. Everyone will know how to generate the symbol, with the same encoding, on however many keyboards. And Tim O'Reilly will be happy because for once newbies will actually READ the preface chapter of the perl books, in which conventions and fonts and such are explained -- that's where the first of the masonic secrets (Perlish rite) will be illuminated. =Austin PS: MSIE doesn't like alt-. I'm still doing copy and paste. But I have CONFIDENCE... __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: [RFC] Perl6 Hyperoperator backtick
--- [EMAIL PROTECTED] wrote: Yesterday Aaron Crane wrote: Jonathan Scott Duff writes: @a `+ @b In my experience, many people actually don't get the backtick character at all. Yes. I think that might be a good reason _for_ using backtick in vector operators: * Backticks aren't used in any other operators, so they would not be mistaken for xor nor arrays. Backticks also look a little odd, so even if it isn't intuitive as to what is going on, somebody seeing a vector op for the first time should at least spot that _something_ different is happening. * People starting out in Perl wouldn't want to use vector ops straight away (there are enough other things to be learning). So a character that involves 'advanced' typing is used for an 'advanced' feature. This almost makes more sense than the ^[] stuff. But see below. A pair of backticks could be used if the vector-equals distinction is required: @a `+`= @b; @a `+=` @b; Now it does make more sense. Use them as quotes, please, since that's the understood usage (and becase syntax highlighters know how to do this). I don't even mind if they keep the dual use of run-gather and vectorize. (They probably can't, since prefix ops would look like run-gathers.) @a = @b `+` @c; let @a be the result of running PLUS with inputs @b and @c Yeah! =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Vectorizing operators for Hashes
--- [EMAIL PROTECTED] wrote: I agree. But I think that we can get away here with just hash properties , just like hash behaviour in regexps is controlled by properties . e.g. union: (%a,%b) ^is no_strict_keys ; (%a %b) ^is default_value ( 0 ) ; %a ^[+] %b intersection : (%a,%b) ^is strict_keys ; %a ^[+] %b this maybe longer but clear : one line - one concept . Arcadi, How would this work for hashes with differing properties? E.g., %a = (apple = 1, abacus = 2); %b = (banana = 3, abacus = 2); %a ^is strict_keys; %b ^is no_strict_keys; %c = %a ^[+] %b; What would happen? %a rules?: %c == (abacus = 4) %b rules?: %c == (apple = 1, abacus = 4, banana = 3) strict_keys filters result?: %c == (apple = 1, abacus = 4) =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:52 PM, Michael Lazzaro wrote: Applications/Utilities/Key Caps (Again, OSX) which shows you where they all are. The «» quotes, for example, are option-\ and shift-option-\ Oh, well, I guess those aren't *too* far out of the way... David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: [perl #18170] [PATCH] very complete lexical scope implementation
-Original Message- From: Leopold Toetsch [mailto:lt;toetsch.at] WRT your comment: should we use a List * here, I slightly vote for yes. In the long run we could use List as the basic store for registers and stacks as well. List would only need a small extension to manage arbitrary sized data. Ok, if the code goes in I can easily change this ... WRT names: wouldn't be a hash faster then the linear search? My thinking is that compilers will most often generate code that accesses lexicals using position and the current structure provides constant time by position access to the lexicals. While by name access is linear time. As you say, this could be improved using a hash, but at some cost in space (maybe?). In any case, the implementation details of the struct Parrot_Lexicals are (currently) only touched in sub.c, so it should be easy to change the approach. Thanks for the comments, anything else? -- Jonathan Sillito
[PATCH] Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
On Tue, 29 Oct 2002, Andy Dougherty wrote:
On Tue, 29 Oct 2002, Andy Dougherty wrote:
Here's my proposal for stage one: This patch is intended to define
explicitly what the different compiler and linker commands and flags
are, what they are supposed to mean, and how they are to be used.
I've gotten a little feedback. Here's my proposed patch. I added yet
more documentation and cleaned up config/gen/makefiles/root.in to use the
variables consistently. Also, with the new link_out variable, the stack
direction test should work again with MS Visual C. It might even work
with VMS, though lots of other things still won't. I had to make some
guesses for all those systems.
I did not fix up Makefiles in different sub-directories or any other build
commands that are part of the test suite. Nor did I generalize the
stackdir.pl stuff to a generic Configure function. One thing at a time.
diff -r -u parrot-orig/config/auto/stackdir.pl parrot-andy/config/auto/stackdir.pl
--- parrot-orig/config/auto/stackdir.pl Mon Oct 21 09:44:36 2002
+++ parrot-andy/config/auto/stackdir.pl Thu Oct 31 11:57:03 2002
@@ -18,19 +18,33 @@
genfile('config/auto/stackdir/test1_c.in', 'test1.c');
genfile('config/auto/stackdir/test2_c.in', 'test2.c');
-my($cc, $ccflags, $ldout, $o, $link, $linkflags,
- $cc_exe_out, $exe, $libs) =
- Configure::Data-get( qw(cc ccflags ld_out o link linkflags
- cc_exe_out exe libs) );
+my($cc, $ccflags, $cc_c, $cc_inc, $o, $link, $linkflags,
+ $link_out, $exe, $libs) =
+ Configure::Data-get( qw(cc ccflags cc_c cc_inc o link linkflags
+ link_out exe libs) );
-system($cc $ccflags -I./include -c test0.c test0.cco $redir_err) and
-die C compiler failed (see test0.cco);
-system($cc $ccflags -I./include -c test1.c test1.cco $redir_err) and
-die C compiler failed (see test1.cco);
-system($cc $ccflags -I./include -c test2.c test2.cco $redir_err) and
-die C compiler failed (see test2.cco);
-system($link $linkflags ${cc_exe_out}test$exe test0$o test1$o test2$o $libs
test.ldo $redir_err) and
- die Linker failed (see test.ldo);
+# XXX VMS syntax is only a guess!
+# (The main issue is what to do about redirecting errors.)
+if ($^O =~ /VMS/) {
+ system($cc $ccflags $cc_inc $cc_c test0.c) and
+ die C compiler failed for test0.c.;
+ system($cc $ccflags $cc_inc $cc_c test1.c) and
+ die C compiler failed for test1.c.;
+ system($cc $ccflags $cc_inc $cc_c test2.c) and
+ die C compiler failed for test2.c.;
+ system($link $linkflags ${link_out}test$exe test0$o,test1$o,test2$o $libs)
+and
+ die Linker failed for stack direction test.;
+}
+else {
+ system($cc $ccflags $cc_inc $cc_c test0.c test0.cco $redir_err) and
+ die C compiler failed (see test0.cco);
+ system($cc $ccflags $cc_inc $cc_c test1.c test1.cco $redir_err) and
+ die C compiler failed (see test1.cco);
+ system($cc $ccflags $cc_inc $cc_c test2.c test2.cco $redir_err) and
+ die C compiler failed (see test2.cco);
+ system($link $linkflags ${link_out}test$exe test0$o test1$o test2$o $libs
+test.ldo $redir_err) and
+ die Linker failed (see test.ldo);
+}
my %results=eval cc_run();
cc_clean();
diff -r -u parrot-orig/config/gen/makefiles/root.in
parrot-andy/config/gen/makefiles/root.in
--- parrot-orig/config/gen/makefiles/root.inMon Oct 28 12:25:36 2002
+++ parrot-andy/config/gen/makefiles/root.inThu Oct 31 10:00:21 2002
@@ -7,8 +7,9 @@
RANLIB = ${ranlib}
LINK = ${link}
LD = ${ld}
+# link_out and ld_out might have trailing spaces, so they are handled
+# by the input file, config/gen/makefiles/root.in.
LD_SHARED = ${ld_shared}
-LD_OUT = ${ld_out}
LD_SHARED_FLAGS=${ld_shared_flags}
INC=include/parrot
@@ -168,7 +169,7 @@
mops : examples/assembly/mops${exe} examples/mops/mops${exe}
$(TEST_PROG) : test_main$(O) $(GEN_HEADERS) $(O_DIRS) $(O_FILES)
lib/Parrot/OpLib/core.pm
- $(LINK) ${ld_out}$(TEST_PROG) $(LINKFLAGS) $(O_FILES) test_main$(O) $(C_LIBS)
+ $(LINK) ${link_out}$(TEST_PROG) $(LINKFLAGS) $(O_FILES) test_main$(O) $(C_LIBS)
lib_deps_object : $(O_DIRS) $(O_FILES)
$(PERL) tools/dev/lib_deps.pl object $(O_FILES)
@@ -201,17 +202,17 @@
$(RANLIB) $@
blib/lib/libparrot$(SO) : blib/lib $(O_DIRS) $(O_FILES)
- $(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS)
$(LD_OUT)blib/lib/libparrot$(SO) $(O_FILES) $(C_LIBS)
+ $(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS)
+${ld_out}blib/lib/libparrot$(SO) $(O_FILES) $(C_LIBS)
$(TEST_PROG_SO) : test_main$(O) blib/lib/libparrot$(SO) lib/Parrot/OpLib/core.pm
- $(LINK) $(LINKFLAGS) $(LD_OUT)$(TEST_PROG) test_main$(O)
blib/lib/libparrot$(A) $(C_LIBS)
+ $(LINK) $(LINKFLAGS) ${link_out}$(TEST_PROG) test_main$(O)
+blib/lib/libparrot$(A) $(C_LIBS)
#
Re: Perl6 Operator (REMAINING ISSUES)
On 2002-10-31 at 12:45:23, David Wheeler wrote: Plus, it turns out not to be at all hard to type on Mac OS X. ;-) Well, the angle quotes happen to fall within Latin-1, and so they're easier to get to. On Windows you can either set up special key mappings or just type ALT+171 for « and ALT+187 for », which gets wearisome after a while although you can get your fingers taught pretty quickly. Vim and emacs and XIM all take care of the UNIX case. Once you wander away from Latin-1 into the more general world of Unicode, you start running into trouble on the input side. On Windows you pretty much have to use the Character map accessory. Emacs and vim still work on UNIX, but I don't know of a XIM implementation for general Unicode. (Although if you log into your Unix machine using Kermit-95, it has a keystroke sequence for arbitrary Unicode input). Presumably, though, if Perl did have Unicode operators, it would also have an ASCII alternative, even if only something like \u00ab and \u00bb. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: UTF-8 operator possibilities
On Thursday, October 31, 2002, at 12:18 PM, Chip Salzenberg wrote: According to Michael Lazzaro: ?? ?? ?? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? Am I the only person who discovered Korean spam on p6-lang? Rats. I was trying to write mostly Greek spam. ;-) MikeL
Re: Vectorizing operators for Hashes
union: intersection : How would this work for hashes with differing properties? %a ^is strict_keys; %b ^is no_strict_keys; What would happen? That's one reason why I suggested control of this sort of thing should be a property of the operation, not of the operands. -- ralph
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 2002-10-31 at 04:02, Iain 'Spoon' Truskett wrote: * Dyck, David ([EMAIL PROTECTED]) [31 Oct 2002 19:21]: [...] You could use the Character Map accessory to put the character into the clipboard, or press the alt and hold the alt key while typing 0171 (or 0187) alt+0171 alt+0187 To be honest, as easy as it is to type ^a^v or ^k,[1] it's still typing an awful lot just to get a character. Surely the Perl operator Huffman encoding should take into account the length of time it takes to type the darn thing. Personally, I'm against non US-ascii chars being part of the core language. It's fine if people want their Unicode identifiers, or import modules to change operators, but I'd like to think I can at least read and write my own code in non-Latin-1 environments. I agree considering, this isn't APL and the problems people have had mailing examples (let alone creating them!). I've got to admit all of these operators are scaring me. Seems alot like Brooks' second-system effect. Brian Wheeler [EMAIL PROTECTED]
Re: worth adding collections to the core language?
On Thu, 31 Oct 2002, Austin Hastings wrote: : Damian Conway admits: Everything in Perl6 is 'Junk' : : Who can't see *this* coming on slashdot? :-) Cool. Perl 6 junk gives new meaning to Pathologically Eclectic Rubbish. Larry
Re: [RFC] Perl6 Operator List, Take 5
On 31 Oct 2002, brian wheeler wrote: : I agree considering, this isn't APL and the problems people have had : mailing examples (let alone creating them!). Nevertheless, it has already been decreed that Perl 6 programs are written in Unicode. That's not gonna change... : I've got to admit all of these operators are scaring me. Seems alot : like Brooks' second-system effect. But that's our slogan: Perl 6 is second-system effect done right. :-) Larry
Re: Vectorizing operators for Hashes
On Thu, 31 Oct 2002, Me wrote: : That's one reason why I suggested control of this sort : of thing should be a property of the operation, not of : the operands. I think that by and large, the operator knows whether it wants to do union or intersection. When you're doing «+», it's obviously union that you want, with undef defaulting to 0. And «//» would want intersection. Larry
Re: [RFC] Perl6 HyperOperator List
On Thu, 31 Oct 2002, Graham Barr wrote: : On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: : A pair of backticks could be used if the vector-equals distinction is : required: : :@a `+`= @b; :@a `+=` @b; : : Thats ugly, IMO. : : Now this is going to sound wild (probably) and I have not thought too much : about it and there are probably others who can see the pitfalls quicker : then me. But could () be available for hyper operators ? It would work for binary ops, but unfortunately, nothing that looks like a term can work for unary ops. (Also parens are already used as a postfix operator that means call the preceding function ref.) Larry
UTF-8 and Unicode FAQ, demos
Here is an extensive FAQ for Unicode and UTF-8: http://www.cl.cam.ac.uk/~mgk25/unicode.html and here is a test file that will show you how many of the most common glyphs (WGL4, via Microsoft) you are capable of displaying in your current setup: http://www.cl.cam.ac.uk/~mgk25/ucs/wgl4.txt A reduced list of interesting characters is as follows. Note that I may not be sending them all correctly, as not all of them are available on OSX. And that not all interesting characters are a part of the WGL4 set. 00AB # « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK 00BB # » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK 00AC # ¬ NOT SIGN 2202 # ∂ PARTIAL DIFFERENTIAL 2206 # ∆ INCREMENT 220F # ∏ N-ARY PRODUCT 2211 # ∑ N-ARY SUMMATION 2219 # ÅE BULLET OPERATOR 221A # √ SQUARE ROOT 221E # ∞ INFINITY 221F # àA RIGHT ANGLE 2229 # Åø INTERSECTION 222B # ∫ INTEGRAL 2248 # ≈ ALMOST EQUAL TO 2260 # ≠ NOT EQUAL TO 2261 # Åfl IDENTICAL TO 2264 # ≤ LESS-THAN OR EQUAL TO 2265 # ≥ GREATER-THAN OR EQUAL TO 00D7 # Å~ MULTIPLICATION SIGN 00F7 # ÷ DIVISION SIGN 00B0 # ° DEGREE SIGN 00B1 # ± PLUS-MINUS SIGN 00B5 # µ MICRO SIGN 00B6 # ¶ PILCROW SIGN 2020 # † DAGGER 2021 # ‡ DOUBLE DAGGER 2022 # • BULLET 2026 # … HORIZONTAL ELLIPSIS 2030 # ‰ PER MILLE SIGN 00A1 # ¡ INVERTED EXCLAMATION MARK 00A2 # ¢ CENT SIGN 00A3 # £ POUND SIGN 00A4 # °Ë CURRENCY SIGN 00A5 # ¥ YEN SIGN 00A6 # ∫ BROKEN BAR 00A7 # § SECTION SIGN 00A8 # ¨ DIAERESIS 00A9 # © COPYRIGHT SIGN 00AA # ª FEMININE ORDINAL INDICATOR 00AD # ú SOFT HYPHEN 00AE # ® REGISTERED SIGN 00AF # ¯ MACRON 00B2 # ©˜ SUPERSCRIPT TWO 00B3 # ©¯ SUPERSCRIPT THREE 00B7 # · MIDDLE DOT 00B8 # ¸ CEDILLA 00BA # º MASCULINE ORDINAL INDICATOR 00BF # ¿ INVERTED QUESTION MARK 203C # ßÑ DOUBLE EXCLAMATION MARK 02C7 # ˇ CARON 02D8 # ˘ BREVE 02D9 # ˙ DOT ABOVE 02DA # ˚ RING ABOVE 2122 # ™ TRADE MARK SIGN 2126 # Ω OHM SIGN 2190 # Å© LEFTWARDS ARROW 2191 # Å™ UPWARDS ARROW 2192 # Å® RIGHTWARDS ARROW 2193 # Å´ DOWNWARDS ARROW 2194 # °Í LEFT RIGHT ARROW 2195 # ¢’ UP DOWN ARROW 0391 # Éü GREEK CAPITAL LETTER ALPHA 0392 # Ɇ GREEK CAPITAL LETTER BETA 0393 # É° GREEK CAPITAL LETTER GAMMA 0394 # É¢ GREEK CAPITAL LETTER DELTA 0395 # É£ GREEK CAPITAL LETTER EPSILON 0396 # ɧ GREEK CAPITAL LETTER ZETA 0397 # É• GREEK CAPITAL LETTER ETA 0398 # ɶ GREEK CAPITAL LETTER THETA 0399 # Éß GREEK CAPITAL LETTER IOTA 039A # É® GREEK CAPITAL LETTER KAPPA 039B # É© GREEK CAPITAL LETTER LAMDA 039C # É™ GREEK CAPITAL LETTER MU 039D # É´ GREEK CAPITAL LETTER NU 039E # ɨ GREEK CAPITAL LETTER XI 039F # É≠ GREEK CAPITAL LETTER OMICRON 03A0 # ÉÆ GREEK CAPITAL LETTER PI 03A1 # ÉØ GREEK CAPITAL LETTER RHO 03A3 # É∞ GREEK CAPITAL LETTER SIGMA 03A4 # ɱ GREEK CAPITAL LETTER TAU 03A5 # É≤ GREEK CAPITAL LETTER UPSILON 03A6 # É≥ GREEK CAPITAL LETTER PHI 03A7 # É¥ GREEK CAPITAL LETTER CHI 03A8 # ɵ GREEK CAPITAL LETTER PSI 03A9 # Ω GREEK CAPITAL LETTER OMEGA 03B1 # Éø GREEK SMALL LETTER ALPHA 03B2 # É¿ GREEK SMALL LETTER BETA 03B3 # É¡ GREEK SMALL LETTER GAMMA 03B4 # ɬ GREEK SMALL LETTER DELTA 03B5 # É√ GREEK SMALL LETTER EPSILON 03B6 # Ƀ GREEK SMALL LETTER ZETA 03B7 # É≈ GREEK SMALL LETTER ETA 03B8 # É∆ GREEK SMALL LETTER THETA 03B9 # É« GREEK SMALL LETTER IOTA 03BA # É» GREEK SMALL LETTER KAPPA 03BB # É… GREEK SMALL LETTER LAMDA 03BC # É GREEK SMALL LETTER MU 03BD # ÉÀ GREEK SMALL LETTER NU 03BE # Éà GREEK SMALL LETTER XI 03BF # ÉÕ GREEK SMALL LETTER OMICRON 03C0 # π GREEK SMALL LETTER PI 03C1 # Éœ GREEK SMALL LETTER RHO 03C2 # V GREEK SMALL LETTER FINAL SIGMA 03C3 # É– GREEK SMALL LETTER SIGMA 03C4 # É— GREEK SMALL LETTER TAU 03C5 # É“ GREEK SMALL LETTER UPSILON 03C6 # É” GREEK SMALL LETTER PHI 03C7 # É‘ GREEK SMALL LETTER CHI 03C8 # É’ GREEK SMALL LETTER PSI 03C9 # É÷ GREEK SMALL LETTER OMEGA MikeL
Re: Perl6 Operator List (REMAINING ISSUES)
On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote: : %a ^[op]= @b # hash v array : @a ^[op]= %b # array v hash What would those mean? Are you thinking only of hashes with numeric keys? Larry
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 31 Oct 2002, Iain 'Spoon' Truskett wrote: : To be honest, as easy as it is to type ^a^v or ^k,[1] it's still Thanks, I didn't know it was that «easy» in vim. :-) : typing an awful lot just to get a character. Surely the Perl operator : Huffman encoding should take into account the length of time it takes to : type the darn thing. Sure, but that's only one half of Huffman. You also have to consider the frequency of use. (And as a second order effect, whether you want to discourage frequent use. :-) I personally think vector ops are pretty special, and should remain so. I have enough familiarity with (read: contempt for) APL that I don't want multi-dimensional operators to be the default, regardless of how they're spelled. Special ops should look special. : Personally, I'm against non US-ascii chars being part of the core : language. It's fine if people want their Unicode identifiers, or import : modules to change operators, but I'd like to think I can at least read : and write my own code in non-Latin-1 environments. Perl 6 is written in Unicode. This will cause more pain in the short term, but I'm trying to optimize for twenty years from now. (Yes, this message is in Latin-1, but that can be considered an encoding of the first 256 codepoints of Unicode.) Larry
Re: Vectorizing operators for Hashes
On Thu, 31 Oct 2002, Markus Laire wrote: : I don't think there should be any upper limit for operator-lengths. There will never be any official limits. Perl is not about arbitrary limits. But I will tell you that I only added = to Perl 5 because I knew there would never be a == operator. We'll have to relax that a bit for Perl 6, but we're still trying vaguely to avoid the Icon trap. Only compositions of operators will be allowed to get longer than 3 chars. And we try to keep the basic operators at 2 or less. The really great thing about the French quotes is that they visually keep the user aware of the composition. «+=» is obviously a variety of +=, whereas ^+= is not obvious, though shorter. (Square brackets are even better at that, but have other problems.) Larry
Re: Vectorizing operators for Hashes
Austin Hastings writes: --- [EMAIL PROTECTED] wrote: I agree. But I think that we can get away here with just hash properties , just like hash behaviour in regexps is controlled by properties . e.g. union: (%a,%b) ^is no_strict_keys ; (%a %b) ^is default_value ( 0 ) ; %a ^[+] %b intersection : (%a,%b) ^is strict_keys ; %a ^[+] %b this maybe longer but clear : one line - one concept . Arcadi, How would this work for hashes with differing properties? E.g., %a = (apple = 1, abacus = 2); %b = (banana = 3, abacus = 2); %a ^is strict_keys; %b ^is no_strict_keys; %c = %a ^[+] %b; What would happen? in the result hash there will be only keys of %a, because %b *can admit unknown keys*, but %a - cannot %a rules?: %c == (abacus = 4) %b rules?: %c == (apple = 1, abacus = 4, banana = 3) strict_keys filters result?: %c == (apple = 1, abacus = 4) =Austin arcadi
Re: Vectorizing operators for Hashes
Austin Hastings writes: but I am not shure ... sure thanks . sorry that I write so badly . I'll try to be better . (Unless you do this on purpose :-) Cheers, =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Vectorizing operators for Hashes
Me writes: union: intersection : How would this work for hashes with differing properties? %a ^is strict_keys; %b ^is no_strict_keys; What would happen? in the resulting hash only ( and all ) keys of %a will be present. because %b *admits* unknown keys but %a does not. although I admit that property names can be much better . That's one reason why I suggested control of this sort of thing should be a property of the operation, not of the operands. -- ralph arcadi .
Re: Vectorizing operators for Hashes
Larry Wall writes: On Thu, 31 Oct 2002, Me wrote: : That's one reason why I suggested control of this sort : of thing should be a property of the operation, not of : the operands. I think that by and large, the operator knows whether it wants to do union or intersection. When you're doing «+», it's obviously union that you want, with undef defaulting to 0. And «//» would want intersection. Larry so is really going to the direction that many official operators will be wysiwig Unicode staff like «+» , and then for some slice of the comunity there will be ( TeX - like ?? ) ascii shortcuts , because we need them ( what was the length of the tread to figure out how to write and read them ) . So perl take placeholders from Mathematica , vector operations from Matlab , and greek and all other funny characters from TeX : use TeX; \gamma = \alpha \hyper[\sum] \beta ; arcadi .
Re: Perl6 Operator List (REMAINING ISSUES)
Larry Wall writes:
On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:
: %a ^[op]= @b # hash v array
: @a ^[op]= %b # array v hash
What would those mean? Are you thinking only of hashes with numeric keys?
Larry
no but hash can have property that tells how to turn its keys to
integer indexes if it fins itself in the ^[op] situation .
just like %hash can have a property that tells it how to behave in
regexp /%hash/ . And then just like here there may be some default
value for that property . I dont know what it should be . is it sane ?
%hash is if_in_vectorized_op_map_keys_to_integers_as { some function
returning integer }
arcadi .
Re: [RFC] Perl6 HyperOperator List
Thats ugly, IMO. Now this is going to sound wild (probably) and I have not thought too much about it and there are probably others who can see the pitfalls quicker then me. But could () be available for hyper operators ? I will sit back now and watch the firewaorks, as I wont be in the UK on Nov 5 :-) Graham. yes if you demand a prefix a ^(+=) b where ^ can be replaced (almost ) everything . arcadi .
Perl6 Operator List (REMAINING ISSUES)
Michael Lazzaro writes: OK, by my count -- after editing to reflect Larry's notes -- only a few issues remain before the ops list can be completed. 1) Need a definitive syntax for hypers, ^[op] and «op» have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. 2) Possible inclusion of unary prefix ^, meaning complement. (Assuming doesn't conflict with (1)) 3) Possible inclusion of like/unlike or similar as synonyms for ~~ !~. Which we don't have to decide now. All other op issues, by my count, revolve around the meanings of specific hyperop constructs. There is one, overriding question with the hyperops, which is the precise relation between an op, an assignment op, and their (three!) hyperop equivs: A op B A op= B A ^[op] B A ^[op=] B A ^[op]= B If we can formalize the precise relationship between the three hypers in the presence of scalar and list (and hash?) values for A and B, I believe we can answer nearly all the hyperop questions definitively. as I understand , every such construct will be macro preprocessed parser and in real program ( that is in parrot ) there will be no vector operations in perl sence , only as optimizations . so I think that if we are talking about oprator list , we just can state ( and we did ) that such operators are present in language . their prcize functionality may be defined or changed by pragma or module. what I want to say is that we definitely have ^[op] staff so somebody in or out of sanity will ask ( or make a mistake ) what is %a ^[op] %b and the answer already is a question of ( Apo 29 ? ). the language have beasts $x, y, %z and they can talh through op , ^[op] , ... so they will , or at least try . although by the laws of jungle something can be made a taboo . But thats life... arcadi .
Re: UTF-8 and Unicode FAQ, demos
And if you really want to drool at all the neat glyphs that the wonderful, magical world of math has given us, check out: http://www.unicode.org/charts/PDF/U2A00.pdf now *theres* some brackets! MikeL
Re: Vectorizing operators for Hashes
On Thu, 31 Oct 2002, Me wrote: : That's one reason why I suggested control of this sort : of thing should be a property of the operation, not of : the operands. I think that by and large, the operator knows whether it wants to do union or intersection. When you're doing +, it's obviously union that you want, with undef defaulting to 0. And // would want intersection. Ok. So I accidentally got something right! ; (control of this sort of thing should be a property of the operation, not of the operands.) There are clearly some operations where adverbs make sense. Presumably one of the classes of op for which adverbs might make sense is hyperop. Assuming so, did my suggestion of ^adverb make sense to you as a way to distinguish op and hyperop adverbs? -- ralph
Re: Vectorizing operators for Hashes
Me writes: union: intersection : %a ^is strict_keys; %b ^is no_strict_keys; in the resulting hash only ( and all ) keys of %a will be present. because %b *admits* unknown keys but %a does not. Yes, but the general case is that one wants to be able to control nuances of (hyper)operations, and Larry introduced adverbs for precisely that reason. Just because one can get away with controlling this particular issue via noun adjectives (variable properties) does not mean one should. (Although, conversely, just because adverbs seem more more appropriate in this case doesn't mean one shouldn't for some reason use properties as you suggest.) there is one mor epossibility : temp sub infix:^[op] is force_hash_to_intersect ; ( I'm compleatly not sure about that sintax ) sinse vectorization of any op is orthogonal concept to details of that particular op , maybe we can controll behavior of that vectorization by ( ...? ) properties . we need it not only for hashes ; maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of length 3 ; arcadi
RE: [RFC] Perl6 Operator List, Take 5
Larry Wall:
# Perl 6 is written in Unicode.
Great. That's a wonderful policy. But it *shouldn't influence routine
coding in any way*. I have no problem with user-defined Unicode
operators. I have a *huge* problem with built-in Unicode operators, and
a gargantuan problem with built-in Unicode operators that are generally
useful.
I can honestly say at this point that I'd rather give up $iterator
than lose hyperops. And I consider relegating them to the
digraphs losing them, because I'm never going to be able to remember how
to type them, and neither will anybody else.
Let's look at this logically. Here's all the punctuation (non-\w)
characters on my keyboard and what they do in Perl 6:
TERMOPERATORDOUBLE
OPERATOR
` backticks nonenone
' string constantsnone** none
string constantsnonenone
# comment comment comment
$ scalar sigilnonenone
@ array sigil nonenone
% hash sigil modulo none
sub sigil junction and** logical and
! logical not none (?)none
^ complement junction xor** logical xor**
| nonejunction or** logical or
/ regex divide defined or (in
5.9)
* list flatten* multiplyexponent
- numify and negate subtraction
postdecrement
+ numify**addition
postincrement
~ stringify* concat**smart
match
= noneassignment
comparison
\ get reference nonenone
.. method call** method call** range constructor
? force to bool* none** trinary operator
, nonelist composer list composer
; nonestatement end statement end
(in parentheses)super-comma none
: nonesuper-comma package
separator, trinary operator
( ) expression grouping sub parameters yuck
{ } hash composing hash subscripts yuck
block composing block composing yuck
[ ] array composing array subscriptsyuck
iterator syntax comparison ops shift-left, shift-right
UNUSED: 5 8 9
Items marked with a * are new, ** are changed. There are twenty-two
'none's on that list, but none of them line up. (Isn't Perl great?!?)
';;' is available (it doesn't mean anything in either term or operator
context), but it's really ugly. The other possibilities I see there
have the same problem.
There are potentially some meaningless sequences, especially with
sigils, but those'll look quite cluttered. Actually, one of the few
good meaningless ones is ^[op] (with the square brackets). In term
context it would normally mean bitwise complement this array, and in
operator context it would mean add this array to an xor junction. If
we lose xor junctions (which I'm not necessarily advocating, mind you),
this sequence is pretty much open.
Damn. Larry, I don't envy you your job. :^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: UTF-8 and Unicode FAQ, demos
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Thu, 31 Oct 2002 10:11:00 -0800 From: Michael Lazzaro [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ And if you really want to drool at all the neat glyphs that the wonderful, magical world of math has given us, check out: http://www.unicode.org/charts/PDF/U2A00.pdf now *theres* some brackets! Ooh! Let's use 2AF7 and 2AF8 for qw! MikeL
Re: Perl6 Operator (REMAINING ISSUES)
Michael Lazarro wrote: 1) Need a definite syntax for hypers ^[op] and op have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. hm. What was wrong with just '^' again? Reading the threads, it seems to have gotten lost in the shuffle. Ed
Re: Vectorizing operators for Hashes
temp sub infix:^[op] is force_hash_to_intersect ; Right. A property used as you suggest is effectively an adverb applied at op definition rather than use. maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of length 3 ; Right. It's quite plausible that one would want to be able to control this at op use, rather than definition. -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Thu, 31 Oct 2002 11:13:28 -0800 From: Ed Peschko [EMAIL PROTECTED] Content-Disposition: inline X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ Michael Lazarro wrote: 1) Need a definite syntax for hypers ^[op] and op have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. hm. What was wrong with just '^' again? Reading the threads, it seems to have gotten lost in the shuffle. Xor needs it. I'd place hypers in front of xor on my importance list, but that's just me. Ed
Re: Perl6 Operator (REMAINING ISSUES)
1) Need a definite syntax for hypers ^[op] and op have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. hm. What was wrong with just '^' again? Right. I didn't have a problem with ^ in the first place. But... A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). Personally, I liked the use of single backtick someone suggested. I suspect that this is because it seemed to be just as good as square brackets at getting out of the way visually (vastly better than ^); was enough to catch my attention to suggest something special was going on; was just one, unshifted, character (or two, if used for a `op`= variant); and seemed to be the least disruptive (it left ^ for other duties and just meant one needed to eliminate `` for a syscall; hmm, maybe that's not acceptable...) -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
On Thu, Oct 31, 2002 at 01:36:20PM -0600, Me wrote: 1) Need a definite syntax for hypers ^[op] and op have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. hm. What was wrong with just '^' again? Right. I didn't have a problem with ^ in the first place. But... A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). I know it clutters up things a bit, that's my very argument; that ^[ ] clutters up things even *more*. especially, with use of arrays: array[1,2,3] ^[+=] array[4,5,6]; bleah. array[1,2,3] ^+= array[4,5,6]; Not much of a improvement, but its palpable. There's some comfort knowing that '^' is being used as a sigil for an operator, and that all you need is one keystroke in order to use it. I guess it depends on how much hyperoperators are meant to be used. The more they are, the shorter the operator should be. Oh by the way. IMO 'vector' operators should be the proper term. Looking at the above sentence, the term 'hyperoperator' should be quietly euthanized. (or quickly shot.) Ed
UTF-8 operator possibilities
Here is more to think about. No freaking out, this is just for
mulling...
If we, for the moment, assume the use of «op» for hypers, that
obviously raises the _possibility_ of using some other Unicode/UTF-8
characters for other very special tasks. I'm not actually advocating
most of these (no APL, please) but note that some chars might have
distinct possibilities, especially with superpositions:
-- a wide variety of unary and binary ops, some obscure, some obvious:
± × ÷ ≤ ≥ ≠ ≅ ≈ ≡
∩ ∪ ⊂ ⊃ ⊆ ⊇ ∈ ⊄ ∉
⇒ ⇔
∧ ∨ ∴ ∀ ∃ ∠ ⊥ ∝ √ ∫ ∇ ∅ ⊕ ⊗ ∍
† ‡ ˇ ∑ ∏ ∆ Ω ¡ ¿ ¬ ∂ • º ©
(including things like:)
∑array - summation
∏array - product
±$x - { any(+$^x,-$^x) }
$v ∈ array; # element of
-- possible alternate separators in place of ';', where ';'
would result in doing a very, very wrong thing:
for (x • y) - ($x • $y) { ... } - (bullet)
for (x ∫ y) - ($x ∫ $y) { ... }
for (x ‡ y) - ($x ‡ $y) { ... }
for (x † y) - ($x † $y) { ... }
for (x ⊥ y) - ($x ⊥ $y) { ... }
-- a global var like epsilon or mu that sets a +-bound
for like comparisions between floating point nums,
to locally allow comparisions with a settable degree
of accuracy:
{
temp µ = 0.5;
( 10/3 == (1/3) * 10 ); # FALSE, floating point issues
( 10/3 ~~ (1/3) * 10 ); # TRUE, is within µ
}
(OK, we could name that $EPSILON, or anything else in ASCII.
but you gotta admit it looks really slick. If you can see it.)
;-)
-- *plenty* more wierd bracketing and quotelikes, if you dare:
«thing»
‡thing‡
†thing†
∫thing∫
§thing§
¶thing¶
≤thing≥
-- and, of course, terms (e.g. duh synonyms)
∞ - Inf
π - Pi
ø - null set
Just something to think about -- No reason to go all APLish, but if we
find we need another few chars for some obscure but incredibly useful
operations, there _are_ possibilities. Depends primarily on which
characters are most widely recognized on the various platforms, and how
confident we are or aren't that we should say deal with it to people
with non-Unicode-capable editors.
And note that using special chars for special things may increase
readability significantly, since we don't have to worry as much about
similar-looking punctuational strings doing completely different
things, which is already a bit of a problem.
Oh, and here's another tip for you OSX types:
From within Mail, choose Format - Font - Show Fonts.
From the Extras menu, choose Show Characters
you are presented with the grouped listings for every character
that exists on your computer, along with Unicode identifiers. Double
click them to insert them into your email. :-) (Note that you can
also use it in BBEdit.)
MikeL
Re: Perl6 Operator (REMAINING ISSUES)
A ^ prefix visually interferes a lot more I know it clutters up things a bit, that's my very argument; that ^[ ] clutters up things even *more*. especially, with use of arrays: array[1,2,3] ^[+=] array[4,5,6]; bleah. array[1,2,3] ^+= array[4,5,6]; Not much of a improvement, but its palpable. Maybe. I slightly prefer the first line right now. But it's close, and I think I've gotten too used to both notations to know what I'd think if I saw one or other for the first time, and I don't know what I'd think after a month of use of one or other. As I said, it's close. This will defintely be my last email on the topic... There's a couple other reasons to go for ^[op]. One is that [] is more obviously indicative to a newbie that there is some array aspect to how the op applies than ^ (or backtick) would be. Another is that bracketing works better to indicate the difference between the two ...= variants that might be useful: a ^[+=] b a ^[+]= b # vectorize the +, not the = a ^+= b a ^+^= b # vectorize the +, not the = ?!? '^' is being used as a sigil for an operator, and that all you need is one keystroke in order to use it. On my keyboard it's two (shift and the 6 key). Oh by the way. IMO 'vector' operators should be the proper term. Oops. Yes. -- ralph
Re: plaintive whine about 'for' syntax
Larry Wall writes:
I think decent formatting would make it clearer:
fora; b
- $x is rw; y {
$x = $y[5];
}
But this isn't very scalable:
fora; b;
c; d;
e
- $a_variable1 is rw, $a_variable2 is rw; $b_variable is rw;
$c_variable is rw; $d_variable is rw;
$e_variable1 is rw, $e_variable2 is rw
{
}
wheras:
for a - $a_variable1 is rw, $a_variable2 is rw;
b - $b_variable is rw;
c - $c_variable is rw;
d - $d_variable is rw;
e - $e_variable1 is rw, $e_variable2 is rw;
{
}
is much, *much* clearer. IMO the current 'for' syntax suffers from action at a
distance, even if that distance is within the same line. Related things aren't
paired up nearly close enough to each other.
And I'd curse it if I was writing 'for' expressions as complicated as the
second one. Which I WILL do, especially when writing code generators.
Ed
Re: UTF-8 operator possibilities
According to Michael Lazzaro: ?? ?? ?? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? Am I the only person who discovered Korean spam on p6-lang? -- Chip Salzenberg - a.k.a. -[EMAIL PROTECTED] It furthers one to have somewhere to go.
Re: Perl6 Operator (REMAINING ISSUES)
On Thursday, October 31, 2002, at 11:36 AM, Me wrote: A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). If we're talking about operators being hypered, then I think that «op» makes a lot of sense. It reminds me of Perl 5's spaceship operator, =, and I think of a spaceship taking the operator and jumping into hyperspace. What could be a better analogy than that, quantumly speaking? Plus, it turns out not to be at all hard to type on Mac OS X. ;-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: plaintive whine about 'for' syntax
Ed Peschko wrote:
Larry Wall writes:
I think decent formatting would make it clearer:
fora; b
- $x is rw; y {
$x = $y[5];
}
But this isn't very scalable:
Sure it is. You just have to think more two-dimensionally...
for a; b; c; d; e
- $a_variable1 is rw, $a_variable2 is rw;
$b_variable is rw;
$c_variable is rw;
$d_variable is rw;
$e_variable1 is rw, $e_variable2 is rw
{
}
:-)
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
Damian
Re: [RFC] Perl6 HyperOperator List
Austin Hastings wrote: In the C that I learned, the ^| ops were bitwise. Likewise, the || ops were lazy booleans. So what's a single-letter boolean act like? Is it lazy? Does it retain its bitwise-ness but (since boolean) force evaluation for 1 or 0 first? I just don't understand what the implied behavior is, since the reference is outside my experience. Since they're producing a boolean result, both C? and C?| could be implemented lazily. However, I suspect they mightn't be, just to keep them consistent (in their evaluation of operands) with the other bitwise ops. What's $a? 1 | 5 10 Yes (by precedence) Umm, is this wrong? Yep. Sorry. (1|5) 10 Yes (explcitly). This one is still correct. traits = any ( ... ) requirements = .. .. if $requirements eq $traits Should that be traits = all()? No. Because later we say (effectively): print True love\n if all(desiderata) eq any(traits) In other words we want *all* the desired characteristics to be matched by *some* trait. If the comparison was Call(...) eq all(...), then you're asking for every characteristic to be the same as every trait, which obviously can't happen. This is just a case where the logic of English phraseology has several implicit assumptions that computational logic can't just fudge over. (In other words: Can you write Apoc.Flexible now, please?) Well, I'd *like* to, but since that would involve giving up my first vacation in two years, and consequently getting divorced...no. ;-) Damian
Re: Vectorizing operators for Hashes
--- Larry Wall [EMAIL PROTECTED] wrote: On Thu, 31 Oct 2002, Markus Laire wrote: The really great thing about the French quotes is that they visually keep the user aware of the composition. «+=» is obviously a variety of +=, whereas ^+= is not obvious, though shorter. (Square brackets are even better at that, but have other problems.) I'm still unconvinced that square brackets won't work. But compared to Larry giving up «foo bar baz», «sont petits pommes de terre» __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: plaintive whine about 'for' syntax
Damian Conway writes:
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
Damian
but why ? I am just curious about details.
is it complicated for immediate component of for loop ( mentioned by
Larry Wall ) to cut-and-paste to reconstruct the original stream list
and block signature.
1) for a - $x ; b - $y { ... }
===
2) for a ; b - $x ; $y { ... }
at the price of - not being consistently closure declarator
*everywhere* and having a bit different meaning inside for ( and only
for , because all other topicalizers dont know about streams -- am I
right ?) . Which it is already not exactly , since immediate component
of for loop preprocess the closure signature to match the streams .
and besides, it seems to me that both 1) and 2) can coexist since for
loop can controll what happens between for and {...} . but maybe I
am wrong.
I am just curious .
arcadi .
Re: UTF-8 and Unicode FAQ, demos
--- Luke Palmer [EMAIL PROTECTED] wrote: And if you really want to drool at all the neat glyphs that the wonderful, magical world of math has given us, check out: http://www.unicode.org/charts/PDF/U2A00.pdf now *theres* some brackets! Ooh! Let's use 2AF7 and 2AF8 for qw! Frankly, I don't know HOW we've lived for so long without larger than and smaller than operators. =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: [RFC] Perl6 HyperOperator List
Graham Barr wrote: On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: ... using backtick in vector operators ... A pair of backticks could be used if the vector-equals distinction is required: @a `+`= @b; @a `+=` @b; Thats ugly, IMO. Oh, I wasn't claiming that it's pretty. I think we're past being able to find something that's pretty. In general I find backticks fairly jarring on the eyes, but they have to be used for _something_ ... Smylers
Re: Perl6 Operator (REMAINING ISSUES)
Maybe. I slightly prefer the first line right now. But it's close, and I think I've gotten too used to both notations to know what I'd think if I saw one or other for the first time, and I don't know what I'd think after a month of use of one or other. As I said, it's close. This will defintely be my last email on the topic... likewise.. There's a couple other reasons to go for ^[op]. One is that [] is more obviously indicative to a newbie that there is some array aspect to how the op applies than ^ (or backtick) would be. I think that this advantage pales to the cost of having to type three characters every single time someone has to use a vector operation. Its just as easy for a newbie to say 'aha! ^ means array!'. Another is that bracketing works better to indicate the difference between the two ...= variants that might be useful: a ^[+=] b a ^[+]= b # vectorize the +, not the = a ^+= b a ^+^= b # vectorize the +, not the = ?!? Ok, I can sort of see this, but what the #%$ do both of these things mean? I can see a ^+= b meaining $a[0] += $b[0] $a[0] += $b[1] $a[0] += $b[2] $a[0] += $b[3]...etc but a ^[+]= b?? I swear, this whole vector operator thing would be a lot easier to understand if everything was vectored or not, ie: a = b ^+ c; was a syntax error or was optimised to: a ^= b ^+ c; In that case, ^[+]= doesn't really make sense. Ed
Re: Perl6 Operator (REMAINING ISSUES)
Me writes:
A ^ prefix visually interferes a lot more
I know it clutters up things a bit, that's my very argument; that
^[ ] clutters up things even *more*. especially, with use of arrays:
array[1,2,3] ^[+=] array[4,5,6];
bleah.
array[1,2,3] ^+= array[4,5,6];
Not much of a improvement, but its palpable.
Maybe. I slightly prefer the first line right now.
But it's close, and I think I've gotten too used to
both notations to know what I'd think if I saw one
or other for the first time, and I don't know what
I'd think after a month of use of one or other. As
I said, it's close. This will defintely be my last
email on the topic...
actually , ones we decide that ^ *is necessary for vectorization , we
can allow other brackets , optional brackets ( where unambiguous ) ,
and spaces inside the brackets :
a ^+= b
a ^[+]= b
a ^(+)= b
a ^( + )= b
a ^{ + }= b
a ^{+}= b
a ^[ + ]= b
all that can *coexist* !
There's a couple other reasons to go for ^[op].
One is that [] is more obviously indicative to a
newbie that there is some array aspect to how
the op applies than ^ (or backtick) would be.
Another is that bracketing works better to indicate
the difference between the two ...= variants that
might be useful:
a ^[+=] b
a ^[+]= b # vectorize the +, not the =
a ^+= b
a ^+^= b # vectorize the +, not the = ?!?
'^' is being used as a sigil for an operator, and that all
you need is one keystroke in order to use it.
On my keyboard it's two (shift and the 6 key).
Oh by the way. IMO 'vector' operators should be the
proper term.
Oops. Yes.
--
ralph
Re: [RFC] Perl6 HyperOperator List
--- Damian Conway [EMAIL PROTECTED] wrote: Austin Hastings wrote: traits = any ( ... ) requirements = .. .. if $requirements eq $traits Should that be traits = all()? No. Because later we say (effectively): print True love\n if all(@desiderata) eq any(@traits) In other words we want *all* the desired characteristics to be matched by *some* trait. If the comparison was Call(...) eq all(...), then you're asking for every characteristic to be the same as every trait, which obviously can't happen. This is just a case where the logic of English phraseology has several implicit assumptions that computational logic can't just fudge over. Does this imply some sort of depth matching is required for these expressions? In this case, there's T = tall dark handsome D = (tall dark handsome) | (Australian) | (rich old) So when I say: all(@desiderata) # I hated that ^[!]() poem does that implicitly search down until it finds a singleton (Australian) or a conjunction (old rich)? And likewise does saying any(@traits) do some sort of implicit (de) construction looking for a singleton or a disjunction? Obviously, yes. So you're saying that the all() can't work at the a|b|c level, because that would be conjunctive disjunction. (Doc, tell me straight: how long do I have?) So the evaluation alternates through the possibilities, looking for a chance to apply all. But on the other side, not all of the traits have to be matched. It won't be fatal if the traits are tall dark handsome socialist old rich fat Australian impotent so long as some subset (ANY?) of the traits completely match ALL the desired bits. So I can't use all(@traits) because that would OVERSPECIFY. But I don't feel right using any(@traits) because that feels like either saying traits[x] == all-these-things which is wrong, or traits was a list, like desiderata, which contains one of these which is wrong, too. It's right to say there is SOME trait in @traits that matches each @desiderata But of course, SOME is choose one, and that means any. (BTW: Will there be an alternate build of p6 that does NOT depend on the axiom of choice?) Damian, your reward for this whole flexible values mess is to spend the rest of your life being retained by large companies to explain this stuff to blockheads like me. Welcome to hell. =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: plaintive whine about 'for' syntax
[EMAIL PROTECTED] writes:
1) for @a - $x ; @b - $y { ... }
===
2) for @a ; @b - $x ; $y { ... }
You've got it! Semicolon naturally breaks things apart, not groups them
together!
--
Anything to do with HTML processing /usually/ involves a pact
with an evil supernatural being, I find.
-- Sean Burke
Primitive Boolean type?
While writing documentation: a trivial question on the boolean type, Cbit: my bit $light_switch; Q: Can bits/bools be undefined? Perl conventions would indicate yes. Does that mean that an array of bits: my bit bitfield; takes up, at minimum, two bits per, um, bit? Sorry if this question is as stupid as it looks. I'm just worried that maybe it isn't. MikeL
RE: [RFC] Perl6 Operator List, Take 5
--
On Thu, 31 Oct 2002 11:26:13
Brent Dax wrote:
I can honestly say at this point that I'd rather give up $iterator
than lose hyperops.
I was thinking the same thing not long ago. But now
that I think about it, is operator ever going to be
confused for $File_Handle? The vector operation cosy
up well to the concept of iteration anyway. Hell, if
were desperate (and I think we are) then why not just
double the brackets to [op] or [op]. Sure it's
ugly, but I prefer it to ^[op] any day of the week,
and it's not going to be ambiguous.
All that said, can anyone come up with a case to
confuse op with $File_Handle?
-Erik
And I consider relegating them to the
digraphs losing them, because I'm never going to be able to remember how
to type them, and neither will anybody else.
Let's look at this logically. Here's all the punctuation (non-\w)
characters on my keyboard and what they do in Perl 6:
TERMOPERATORDOUBLE
OPERATOR
` backticks nonenone
' string constantsnone** none
string constantsnonenone
# comment comment comment
$ scalar sigilnonenone
@ array sigil nonenone
% hash sigil modulo none
sub sigil junction and** logical and
! logical not none (?)none
^ complement junction xor** logical xor**
| nonejunction or** logical or
/ regex divide defined or (in
5.9)
* list flatten* multiplyexponent
- numify and negate subtraction
postdecrement
+ numify**addition
postincrement
~ stringify* concat**smart
match
= noneassignment
comparison
\ get reference nonenone
.. method call** method call** range constructor
? force to bool* none** trinary operator
, nonelist composer list composer
; nonestatement end statement end
(in parentheses) super-comma none
: nonesuper-comma package
separator, trinary operator
( )expression grouping sub parameters yuck
{ }hash composing hash subscripts yuck
block composing block composing yuck
[ ]array composing array subscriptsyuck
iterator syntax comparison ops shift-left, shift-right
UNUSED:5 8 9
Items marked with a * are new, ** are changed. There are twenty-two
'none's on that list, but none of them line up. (Isn't Perl great?!?)
';;' is available (it doesn't mean anything in either term or operator
context), but it's really ugly. The other possibilities I see there
have the same problem.
There are potentially some meaningless sequences, especially with
sigils, but those'll look quite cluttered. Actually, one of the few
good meaningless ones is ^[op] (with the square brackets). In term
context it would normally mean bitwise complement this array, and in
operator context it would mean add this array to an xor junction. If
we lose xor junctions (which I'm not necessarily advocating, mind you),
this sequence is pretty much open.
Damn. Larry, I don't envy you your job. :^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: [RFC] Perl6 HyperOperator List
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Thu, 31 Oct 2002 14:07:34 -0800 (PST) From: Austin Hastings [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ --- Damian Conway [EMAIL PROTECTED] wrote: Austin Hastings wrote: traits = any ( ... ) requirements = .. .. if $requirements eq $traits Should that be traits = all()? No. Because later we say (effectively): print True love\n if all(@desiderata) eq any(@traits) In other words we want *all* the desired characteristics to be matched by *some* trait. If the comparison was Call(...) eq all(...), then you're asking for every characteristic to be the same as every trait, which obviously can't happen. This is just a case where the logic of English phraseology has several implicit assumptions that computational logic can't just fudge over. Does this imply some sort of depth matching is required for these expressions? In this case, there's T = tall dark handsome D = (tall dark handsome) | (Australian) | (rich old) So when I say: all(@desiderata) # I hated that ^[!]() poem does that implicitly search down until it finds a singleton (Australian) or a conjunction (old rich)? And likewise does saying any(@traits) do some sort of implicit (de) construction looking for a singleton or a disjunction? Obviously, yes. So you're saying that the all() can't work at the a|b|c level, because that would be conjunctive disjunction. (Doc, tell me straight: how long do I have?) So the evaluation alternates through the possibilities, looking for a chance to apply all. I think you've got it mixed up: all() and any() don't work with junk, they _are_ junk. any($a) is just $a all($a) is just $a It doesn't do matching, not unless it collapses right there. So the only time it does matching is when it collapses, which has nothing to do with whether all() or any() are present. It has to do with whether a value is a junction. all(1, 2, 3) === 1 2 3 any(1 2 3) is still just 1 2 3 It matches: all(1, 2, 3) $x 1 2 3 $x because the junction is forced to collapse there. Understand? Luke But on the other side, not all of the traits have to be matched. It won't be fatal if the traits are tall dark handsome socialist old rich fat Australian impotent so long as some subset (ANY?) of the traits completely match ALL the desired bits. So I can't use all(@traits) because that would OVERSPECIFY. But I don't feel right using any(@traits) because that feels like either saying traits[x] == all-these-things which is wrong, or traits was a list, like desiderata, which contains one of these which is wrong, too. It's right to say there is SOME trait in @traits that matches each @desiderata But of course, SOME is choose one, and that means any. (BTW: Will there be an alternate build of p6 that does NOT depend on the axiom of choice?) Damian, your reward for this whole flexible values mess is to spend the rest of your life being retained by large companies to explain this stuff to blockheads like me. Welcome to hell. =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
RE: [RFC] Perl6 Operator List, Take 5
Erik Steven Harrison writes: All that said, can anyone come up with a case to confuse op with $File_Handle? it seems that parser cannot confuse them because op is operator and parser expect operator, while $File_Handle is a term . but human can confuse . I personally also like op sintax. arcadi .
RE: [RFC] Perl6 Operator List, Take 5
Erik Steven Harrison:
# All that said, can anyone come up with a case to
# confuse op with $File_Handle?
If you assume infinite lookahead, it's fine, but if not...
something ...
Is that a call to
sub something() returns(IO::Handle)
or a hypered
sub operator:something($operand:)
?
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: plaintive whine about 'for' syntax
* Ed Peschko ([EMAIL PROTECTED]) [01 Nov 2002 07:19]:
[...]
for @a - $a_variable1 is rw, $a_variable2 is rw;
@b - $b_variable is rw;
@c - $c_variable is rw;
@d - $d_variable is rw;
@e - $e_variable1 is rw, $e_variable2 is rw;
{
}
is much, *much* clearer. IMO the current 'for' syntax suffers from
action at a distance, even if that distance is within the same line.
Related things aren't paired up nearly close enough to each other.
Give this man a +1. I do prefer to have associated things placed
with each other. And, as Simon pointed out, ';' is used to break
things apart, thus the syntax above makes somewhat more sense.
The best part is that I can easily comment out, delete, add part of
the expression without worrying that I'm deleting the wrong thing.
It may not be often that I will use the construct for multiple
iterators, but I can foreseeably use at least 2, and with the
added ease I can imagine using more =)
cheers,
--
Iain.
Re: [RFC] Perl6 Operator List, Take 5
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Date: Thu, 31 Oct 2002 14:45:16 -0800 From: Erik Steven Harrison [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-Sent-Mail: off Reply-To: [EMAIL PROTECTED] X-Sender-Ip: 152.18.50.63 Organization: Angelfire (http://email.angelfire.mailcity.lycos.com:80) Content-Language: en X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/ -- On Thu, 31 Oct 2002 11:26:13 Brent Dax wrote: I can honestly say at this point that I'd rather give up $iterator than lose hyperops. I was thinking the same thing not long ago. But now that I think about it, is operator ever going to be confused for $File_Handle? The vector operation cosy up well to the concept of iteration anyway. Hell, if were desperate (and I think we are) then why not just double the brackets to [op] or [op]. Sure it's ugly, but I prefer it to ^[op] any day of the week, and it's not going to be ambiguous. All that said, can anyone come up with a case to confuse op with $File_Handle? sub postfix:bar returns handle; $y = undef bar; That has two syntactically valid interpretations. It wouldn't take even that much to confuse the parser, though. Luke
Re: Perl6 Operator (REMAINING ISSUES)
On 31 Oct 2002 at 15:59, Mark J. Reed wrote: Once you wander away from Latin-1 into the more general world of Unicode, you start running into trouble on the input side. On Windows you pretty much have to use the Character map accessory. Emacs and vim still work on UNIX, but I don't know of a XIM implementation for general Unicode. (Although if you log into your Unix machine using Kermit-95, it has a keystroke sequence for arbitrary Unicode input). Emacs and vim also works on Windows, not just UNIX. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: [RFC] Perl6 HyperOperator List
--- Luke Palmer [EMAIL PROTECTED] wrote: --- Damian Conway [EMAIL PROTECTED] wrote: Austin Hastings wrote: traits = any ( ... ) requirements = .. .. if $requirements eq $traits Should that be traits = all()? No. Because later we say (effectively): print True love\n if all(@desiderata) eq any(@traits) In other words we want *all* the desired characteristics to be matched by *some* trait. If the comparison was Call(...) eq all(...), then you're asking for every characteristic to be the same as every trait, which obviously can't happen. This is just a case where the logic of English phraseology has several implicit assumptions that computational logic can't just fudge over. Does this imply some sort of depth matching is required for these expressions? In this case, there's T = tall dark handsome D = (tall dark handsome) | (Australian) | (rich old) So when I say: all(@desiderata) # I hated that ^[!]() poem does that implicitly search down until it finds a singleton (Australian) or a conjunction (old rich)? And likewise does saying any(@traits) do some sort of implicit (de) construction looking for a singleton or a disjunction? Obviously, yes. So you're saying that the all() can't work at the a|b|c level, because that would be conjunctive disjunction. (Doc, tell me straight: how long do I have?) So the evaluation alternates through the possibilities, looking for a chance to apply all. I think you've got it mixed up: all() and any() don't work with junk, they _are_ junk. any($a) is just $a all($a) is just $a It doesn't do matching, not unless it collapses right there. So the only time it does matching is when it collapses, which has nothing to do with whether all() or any() are present. It has to do with whether a value is a junction. all(1, 2, 3) === 1 2 3 any(1 2 3) is still just 1 2 3 It matches: all(1, 2, 3) $x 1 2 3 $x because the junction is forced to collapse there. Understand? Maybe I just think differently. When I'm trying to actually DO the comparison, I'm forcing at least a partial collapse, no? I mean, maybe the traits are tall dark old handsome Australian so the three choices collapse to two, either of which would match. But regardless, when the actual == appears in the code, some determination needs to be made in order to figure out which way to go. So I'm trying to build rules in my brain for how these things are compatible-ized? And I'm trying to figure out when to specify which junction. =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Perl6 Operator List
Larry Wall writes:
sub postfix:! (num $x) { $x 2 ?? $x :: $x * ($x - 1) ! }
which could be fixed with the _:
sub postfix:! (num $x) { $x 2 ?? $x :: $x * ($x - 1) _! }
Weird, but it's all consistent with the distinction we're already
making on curlies, which gave a great increase in readability.
does it mean that *all* postfix operators have to be attached
without space to their operand or used with space eater modifyer
or
only those for which parser ( or we ) knows that they may be confused
with binary op or term ?
probably the same question for prefix operators .
aracdi
Re: [RFC] Perl6 HyperOperator List
Oops. About that op thing, I was wrong. Though there is a case that does it: sub bar(); sub postfix:bar($x) returns IO::Handle; $x = length bar; If it's possible to have a distinct sub and an operator with the same name. If not, I believe the distinction is precisely the same as that of named unary op with its argument optional. Except with infinite lookahead. Ummm, okay, it's not possible. Because of less than and friends, it's less possible than [op]. Luke
Question about for loop
for a - $x, $y { ... $x is topic ... }
for a ; b -
$x, $y ; $z { ... WHAT is topic ? ... }
what is topic in multi stream loop ?
arcadi
Re: [RFC] Perl6 HyperOperator List
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: ... using backtick in vector operators ... A pair of backticks could be used if the vector-equals distinction is required: @a `+`= @b; @a `+=` @b; Thats ugly, IMO. Oh, I wasn't claiming that it's pretty. I think we're past being able to find something that's pretty. In general I find backticks fairly jarring on the eyes, but they have to be used for _something_ ... I hear there's a vacancy for a qw(...) equivalent now . . . No, I'm not really suggesting this. But I am reminded by this whole endeavour of a certain text adventure. get underscore Taken. get bracket Taken. get guillemot Taken. get caret Taken. get backtick Oops! While you were reaching for the backtick, you drop the guillemot, and both tumble to the ground. (Whine: my Perl undergrad students are too young to remember or appreciate text adventures. At least some of you oldsters here will understand.) -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel? Ariel, her name is Ariel. - _The Little Mermaid_
RE: Perl6 Operator (REMAINING ISSUES)
Markus Laire:
# Emacs and vim also works on Windows, not just UNIX.
So does DOS 'edit'. That doesn't mean Windows users use it. Windows
users want tools that look and act like Windows tools--if they didn't,
they'd be using another OS. Neither GNU emacs nor xemacs fits the bill,
and I doubt vim does either.
I'm an aberration--I use Windows, but I have a Cygwin toolkit installed
and use it regularly. Still, I use VS.Net (with Visual Perl) for my
editing, not a Unix editor. When telnetting, I use emacs, so I
installed XEmacs, used it for a while, and decided I didn't like it for
my local work. It had some really cool features--I was *very*
pleasantly surprised at how nicely it meshed with CVS--but it just
didn't fit my Windows-shaped brain.
You can bet that if I, a Perl core hacker who keeps two copies of
cmd.exe open at all times with c:\cygwin\bin in his path, am not going
to use XEmacs, your average Joe who downloads ActiveState Perl 6 to test
his hit-counter script won't use emacs or vim either.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: [RFC] Perl6 HyperOperator List
get guillemot Taken. Extra credit for those of you who remembered that that's a bird, not a punctuation mark. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel? Ariel, her name is Ariel. - _The Little Mermaid_
Re: [RFC] Perl6 HyperOperator List
On Thursday, October 31, 2002, at 03:47 PM, Deborah Ariel Pickett wrote: (Whine: my Perl undergrad students are too young to remember or appreciate text adventures. At least some of you oldsters here will understand.) Hey! We're not old, we're just version 1.0! Can we have a grue operator? It would be invisible, and eat everything it operated on. Oh, wait... I think Damian already has that module. MikeL
Re: Perl6 Operator (REMAINING ISSUES)
actually , ones we decide that ^ *is necessary for vectorization , we
can allow other brackets , optional brackets ( where unambiguous ) ,
and spaces inside the brackets :
a ^+= b
a ^[+]= b
a ^(+)= b
a ^( + )= b
a ^{ + }= b
a ^{+}= b
a ^[ + ]= b
right, and what does this all mean? I have yet to see a good meaning for
array ^[+]= array2 ...
Perhaps, having just ^ as a vector op, and using ^[op] to disambiguate (or
as an equivalent) is the way to go.
Ed
Re: plaintive whine about 'for' syntax
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:
Damian Conway writes:
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
but why ? I am just curious about details.
Yeah, I'd like to hear those details too, because the alternate syntax:
1) for @a - $x ; @b - $y { ... }
sure looks a lot more attractive and sensible to me, and I agree with all
the arguments in favor of it so far. In particular:
* No look here, then look there connection between (possibly) widely
separated items.
* Simple to add or remove/comment-out individual stream/item(s) pairs
without having to count what are essentially positional parameters to make
sure you haven't mis-mapped anything in the process.
* More familiar use of the semicolon (IMO)
-John
Re: [RFC] Perl6 HyperOperator List
On Fri, Nov 01, 2002 at 07:54:01AM +1100, Damian Conway wrote:
Austin Hastings wrote:
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
No. Because later we say (effectively):
print True love\n
if all(desiderata) eq any(traits)
In other words we want *all* the desired characteristics to be matched
by *some* trait. If the comparison was Call(...) eq all(...), then
you're asking for every characteristic to be the same as every trait,
which obviously can't happen.
This is just a case where the logic of English phraseology has
several implicit assumptions that computational logic can't just
fudge over.
I don't understand this either, but my quibble is where did the all in
the all(desiderata) come from? Lets see if I've got this straight
a b is equivalent to all(a, b)
x | y is equivalent to any(x, y)
Yes?
so:
all(a, b) eq any(a, b, c)
should be true because all() of a and b are in the any() list. Yes?
If I'm right about that, I would expect
(a b) | (c d) eq any(a, e, g)
to be false because it should try ANY of the two junks (a b) or
(c d) the first fails because there is no b and the second fails
because there is no c and no d. I would also expect
(a b) | (c d) | g eq any(a, e, g)
to be true because any() of the terms (g in this case) on the left is
fully satisfied by terms on the right. In the original example the
desiderata is an | junk at the topmost level. I don't see why it
suddenly gets all() wrapped around it. Wouldn't that just be
all[ any all(), all(), all() ]
which is the same as
any all(), all(), all()
I'm not sure I'm explaining this very well, let me try with the example
that's giving me bother.
$requirements = tall dark handsome
| old rich
| Australian;
for - $candidate {
my $traits = any( split /ws/, $candidate );
print True love: $candidate\n
if $requirements eq $traits;
}
Lets say that $candidate = tall dark rich Australian, traits then
becomes any(tall, dark, rich, Australian). So, does
$requirements eq $traits? To me that expands to:
(
(
(tall eq tall) or \
(tall eq dark) or True because tall eq tall
(tall eq rich) or
(tall eq Australian)/
) AND (
(dark eq tall) or \
(dark eq dark) or True because dark eq dark
(dark eq rich) or
(dark eq Australian)/
) AND (
(handsome eq tall) or \
(handsome eq dark) or False no matches
(handsome eq rich) or
(handsome eq Australian)/
)
) ***OR*** (
(
(old eq tall)or \
(old eq dark)or False no matches
(old eq rich)or
(old eq Australian) /
) AND (
(rich eq tall) or \
(rich eq dark) or True because rich eq rich
(rich eq rich) or
(rich eq Australian)/
)
) ***OR*** (
(Australian eq tall) or \
(Australian eq dark) or True because Australian eq Australian
(Australian eq rich) or
(Australian eq Australian) /
)
Junk 1: tall dark handsome
Junk 2: old rich
Junk 3: Australian;
Junk 1 fails because the candidate is not handsome. Junk 2 fails because
the candidate is not old. Junk 3 succeeds because the candidate is
Australian.
This means that the candidate matches overall because junks 1, 2 and 3
are related by | which is any. I don't see how or why you would wrap an
all() around that. There is all()ness going on, but it's represented in
the above by the ands which are in turn grouped with any (the ors).
Why isn't this example
print True love\n
if any(desiderata) eq any(traits)
Does whether it's any() or all() not depend on what the top level
operator in the junction is? Am I missing something?
andrew
--
Gemini: (May 21 - June 21)
You will be the first one put up against the wall in next week's bloody
revolution in skin care.
Re: [RFC] Perl6 HyperOperator List
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 1 Nov 2002 03:08:37 +
From: Andrew Wilson [EMAIL PROTECTED]
Mail-Followup-To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Content-Disposition: inline
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
On Fri, Nov 01, 2002 at 07:54:01AM +1100, Damian Conway wrote:
Austin Hastings wrote:
traits = any ( ... )
requirements = .. ..
if $requirements eq $traits
Should that be traits = all()?
No. Because later we say (effectively):
print True love\n
if all(@desiderata) eq any(@traits)
In other words we want *all* the desired characteristics to be matched
by *some* trait. If the comparison was Call(...) eq all(...), then
you're asking for every characteristic to be the same as every trait,
which obviously can't happen.
This is just a case where the logic of English phraseology has
several implicit assumptions that computational logic can't just
fudge over.
I don't understand this either, but my quibble is where did the all in
the all(@desiderata) come from?
First, I'd like to say that your explanation was immaculate. You
understand junctions perfectly, from what I can tell.
I think Damian was ignoring the the top level any() in order to make
the explanation clearer (or forgot about it ;). Consider it as though
@desiderata contained the (all) states of only one of the (any) states
in his $requirements. I think that's what (effectively) meant.
Indeed, worry not. It was just a bit of an oversimplification.
Luke
Lets see if I've got this straight
a b is equivalent to all(a, b)
x | y is equivalent to any(x, y)
Yes?
so:
all(a, b) eq any(a, b, c)
should be true because all() of a and b are in the any() list. Yes?
If I'm right about that, I would expect
(a b) | (c d) eq any(a, e, g)
to be false because it should try ANY of the two junks (a b) or
(c d) the first fails because there is no b and the second fails
because there is no c and no d. I would also expect
(a b) | (c d) | g eq any(a, e, g)
to be true because any() of the terms (g in this case) on the left is
fully satisfied by terms on the right. In the original example the
@desiderata is an | junk at the topmost level. I don't see why it
suddenly gets all() wrapped around it. Wouldn't that just be
all[ any all(), all(), all() ]
which is the same as
any all(), all(), all()
I'm not sure I'm explaining this very well, let me try with the example
that's giving me bother.
$requirements = tall dark handsome
| old rich
| Australian;
for - $candidate {
my $traits = any( split /ws/, $candidate );
print True love: $candidate\n
if $requirements eq $traits;
}
Lets say that $candidate = tall dark rich Australian, traits then
becomes any(tall, dark, rich, Australian). So, does
$requirements eq $traits? To me that expands to:
(
(
(tall eq tall) or \
(tall eq dark) or True because tall eq tall
(tall eq rich) or
(tall eq Australian)/
) AND (
(dark eq tall) or \
(dark eq dark) or True because dark eq dark
(dark eq rich) or
(dark eq Australian)/
) AND (
(handsome eq tall) or \
(handsome eq dark) or False no matches
(handsome eq rich) or
(handsome eq Australian)/
)
) ***OR*** (
(
(old eq tall)or \
(old eq dark)or False no matches
(old eq rich)or
(old eq Australian) /
) AND (
(rich eq tall) or \
(rich eq dark) or True because rich eq rich
(rich eq rich) or
(rich eq Australian)/
)
) ***OR*** (
(Australian eq tall) or \
(Australian eq dark) or True because Australian eq Australian
(Australian eq rich) or
(Australian eq Australian) /
)
Junk 1: tall dark handsome
Junk 2: old rich
Junk 3: Australian;
Junk 1 fails because the candidate is not handsome. Junk 2 fails because
the candidate is not old. Junk 3 succeeds because the candidate is
Australian.
This means that the candidate matches overall because junks 1, 2 and 3
are related by | which is any. I don't see how or why you would wrap an
all() around that. There is all()ness going on, but it's represented in
the above by the ands which are in turn grouped with any (the ors).
Why isn't this example
print True love\n
if any(@desiderata) eq any(@traits)
Does whether it's any() or all() not depend on what the top level
operator in the junction is? Am I missing something?
andrew
--
Gemini: (May 21 - June 21)
You will be the first one put up against the wall in next week's bloody
revolution in skin care.
Re: Perl6 Operator List
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : does it mean that *all* postfix operators have to be attached : without space to their operand or used with space eater modifyer : : or : : only those for which parser ( or we ) knows that they may be confused : with binary op or term ? I think a postfix has to be attached always. If there is no postfix, then a binary operator doesn't need to have space before it. Otherwise it does. : probably the same question for prefix operators . You can always put a space after a prefix operator, since you can only get one of those when a term is expected. Larry
Re: Primitive Boolean type?
On Thu, 31 Oct 2002, David Wheeler wrote: : On Thursday, October 31, 2002, at 02:43 PM, Michael Lazzaro wrote: : : Q: Can bits/bools be undefined? : : Perl conventions would indicate yes. : : IIRC, native data types, which are all lowercase (e.g., int, bit, long, : etc.) cannot be undef. However, their class equivalents (e.g., Int, : Bit, Long, etc) can be undef. That is correct. It probably throws an exception if you try to assign an undefined value to a lowercase type. (Though an IEEE num might well set itself to NaN instead.) Larry
RE: [RFC] Perl6 Operator List, Take 5
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: : Erik Steven Harrison writes: : : : All that said, can anyone come up with a case to : confuse op with $File_Handle? : : : : it seems that parser cannot confuse them because op is operator and : parser expect operator, while $File_Handle is a term . All unary operators show up when a term is expected, not an operator. Larry
Re: Primitive Boolean type?
On Thu, 31 Oct 2002, Michael Lazzaro wrote: : While writing documentation: a trivial question on the boolean type, : Cbit: Please don't think of Cbit as a boolean type. There is no boolean type in Perl, only a boolean context. Or looking at it from the other direction, *every* type is a boolean type. : Does that mean that an array of bits: : : my bit bitfield; : : takes up, at minimum, two bits per, um, bit? Just one per. Larry
Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002, Larry Wall wrote: If no one saw them then it could well be a problem on my end. I'm trying to use a mailer (pine) that doesn't know about UTF-8 in a «+» b I'm using Pine 4.33 on FreeBSD 4.3, and I see these fine. --Dks
Re: [RFC] Perl6 HyperOperator List
On Fri, 1 Nov 2002, Damian Conway wrote: : Austin Hastings wrote: : : In the C that I learned, the ^| ops were bitwise. : : Likewise, the || ops were lazy booleans. : : So what's a single-letter boolean act like? Is it lazy? Does it retain : its bitwise-ness but (since boolean) force evaluation for 1 or 0 first? : I just don't understand what the implied behavior is, since the : reference is outside my experience. : : Since they're producing a boolean result, both C? and C?| could be : implemented lazily. However, I suspect they mightn't be, just to keep : them consistent (in their evaluation of operands) with the other bitwise : ops. What you're saying is correct, except that I don't think we should be confusing lazy with short-circuit. A lazy operator wouldn't evaluate *either* side until it jolly well had to. If you say () = 1..Inf; it shouldn't even try to produce a 1. I don't much care whether they short-circuit or not. I could argue it either way. I think it'd be okay if they short-circuit. Anybody who uses an operator like ? expecting it to force a side effect on the second expression is nuts. And there's something (though not much) to be said for having an exact equivalent for C's operator. Larry
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 31 Oct 2002, Dave Storrs wrote: : On Wed, 30 Oct 2002, Larry Wall wrote: : : If no one saw them then it could well be a problem on my end. : I'm trying to use a mailer (pine) that doesn't know about UTF-8 in : : a «+» b : : I'm using Pine 4.33 on FreeBSD 4.3, and I see these fine. I sent those as Latin-1, not UTF-8. Larry
Re: [RFC] Perl6 Operator List, Take 5
* Larry Wall ([EMAIL PROTECTED]) [31 Oct 2002 08:22]: [...] This is currently running in a window that does Latin-1 rather than UTF-8. Do these French quotes come through? @a «+» @b The window may say Latin-1, but the mail header said UTF-8. As it happens, I couldn't see them until I piped the message through less. That said, I've probably got a misconfiguration somewhere. I usually have trouble with top-bit set chars, and ms codepagisms. cheers, -- Iain.
Re: [RFC] Perl6 Operator List, Take 5
On Fri, 1 Nov 2002, Iain 'Spoon' Truskett wrote: : This is currently running in a window that does Latin-1 rather than : UTF-8. Do these French quotes come through? : : a «+» b : : The window may say Latin-1, but the mail header said UTF-8. : : As it happens, I couldn't see them until I piped the message through : less. That said, I've probably got a misconfiguration somewhere. : I usually have trouble with top-bit set chars, and ms codepagisms. I was misconfigured here. My pine was marking it as UTF-8 even though the window was Latin-1. So you ought to be able to see this: a «*» b. I'm definitely going to look into mutt though...gotta have Unicode email. Larry
Re: [RFC] Perl6 Operator List, Take 5
* Larry Wall ([EMAIL PROTECTED]) [01 Nov 2002 15:59]: [...] I was misconfigured here. My pine was marking it as UTF-8 even though the window was Latin-1. So you ought to be able to see this: @a «*» @b. That appeared perfectly. I'm definitely going to look into mutt though...gotta have Unicode email. So I'm told =) Me? I'd be happy if more mailers supported the Mail-Followup-To header. I'm not too concerned about unicode since my xterm doesn't support it anyway =) Obviously, I'll look into it one of these days. Soon after Perl 6 is released, I imagine. cheers, -- Iain.
Re: [RFC] Perl6 HyperOperator List
Larry wrote: I don't much care whether they short-circuit or not. I could argue it either way. I think it'd be okay if they short-circuit. Anybody who uses an operator like ? expecting it to force a side effect on the second expression is nuts. And there's something (though not much) to be said for having an exact equivalent for C's operator. Well, would you mind saying it then? Because there's certainly something to be said against having an exact equivalent for C's operator. Luke
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 2002-10-31 at 12:15, Larry Wall wrote:
On 31 Oct 2002, brian wheeler wrote:
: I agree considering, this isn't APL and the problems people have had
: mailing examples (let alone creating them!).
Nevertheless, it has already been decreed that Perl 6 programs are
written in Unicode. That's not gonna change...
Fair enough. However it seems the world isn't ready for unicode
operators. Ok, maybe its me that's not ready. Being a boring American
from the midwest I don't need no stinking French quotes! :) The fries
are good, though.
Anyway, I think that this is a good discussion (despite there being too
many threads to try to follow) and an important one. However,
considering I've spent the last 45 minutes trying to figure a quick way
to enter french quotes into my mailer and editor without them both being
very different and without resorting to cutting and pasting is showing
me that there are big problems with my environment (redhat 8, emacs,
evolution) and I suspect I'm not the only one. Displaying the glyphs
has been ok, for the most part, but its been hit and miss, depending on
other people's configuration. Some tables of operators have had lots of
holes.
It seems that to write effective perl using the new features requires me
to change not only how I think in the language, but also how I use my
computer. I think this might be too big of a leap for some. Unless
there's a compromise. Which brings up a question I hesitate to ask:
will there be the equivalent of trigraphs to cover the non-ascii
characters used? While ?? is a terrible substitute for {, it did get
the job done when people weren't able to press the '{' key. It gave
some visual clue as to what was going on, and was fairly easy to
remember. It doesn't bother me if someone wants to use Straße for an
array, but it gets bad if when instructing others I have to pull some
voodoo key sequence (especially one which is different for each platform
and/or program being used) in order to get the job done. Explaining
emacs' M-x was bad enough for some of the non-programmers in my
organization.
I'm going to go back to lurking now, because I do trust (most) of you.
Though Dan is pretty odd sometimes. :) I know that all of this will get
resolved in a (hopefully) sane fashion. I just wanted to voice my
concerns.
: I've got to admit all of these operators are scaring me. Seems alot
: like Brooks' second-system effect.
But that's our slogan:
Perl 6 is second-system effect done right.
:-)
But, doesn't *everyone* say that? :)
Brian
Larry
miniparrot, a first attempt.
I've banged together a first attempt at a miniparrot- that is, something that can be built on any ANSI C system without anything other than a compiler. Right now, as a proof of concept, it's building a source tree and a shell script which would build miniparrot under gcc. A real version would include platform-specific build scripts which are a tad smarter- but since all they have to do now is run a sequence of compile steps, they don't need to do much other than figure out what compiler to use and how to call it. Here's a log of how to use it. The way I would envision this working is that we would periodically run this and check the results into CVS, so that there was a miniparrot tree available alongside the real one. We could tinderbox it as well. Note: Until the stack direction issue is sorted out, this isn't really going to work across platforms. joshgalactic:~/devel/parrot-rw% make miniparrot-update tools/dev/rebuild_miniparrot.pl ** tools/dev/rebuild_miniparrot.pl: reconfiguring parrot for miniparrot build - perl Configure.pl --miniparrot Parrot Version 0.0.8 Configure 2.0 Copyright (C) 2001-2002 Yet Another Society Hello, I'm Configure. My job is to poke and prod your system to figure out how to build Parrot. The process is completely automated, unless you passed in the `--ask' flag on the command line, in which case it'll prompt you for a few pieces of info. Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST...done. Setting up Configure's data structures...done. Checking for --miniparrot...Yes..done. Loading platform hints file...(no hints) done. Enabling debugging...(none requested) done. Determining what C compiler and linker to use...done. Determining what types Parrot should use...done. Determining what opcode files should be compiled in...done. Setting up experimental systems...done. Determining what pmc files should be compiled in...done. Tweaking ccflags...done. Determining your minimum pointer alignment...done. Probing for C headers...done. Determining some sizes...done. Determining stack growth direction...done. Computing native byteorder for Parrot's wordsize...done. Figuring out how to pack() Parrot's types...done. Figuring out what formats should be used for sprintf...done. Determining if your C compiler is actually gcc...done. Determining architecture, OS and JIT capability...done. Verifying that the compiler supports function pointer casts...done. Determining if your compiler supports computed goto...done. Determining what allocator to use ... (gc) done. Generating config.h...done. Writing Parrot::Config module...done. Generating Makefiles...done. Recording this configuration in myconfig...done. Moving platform files into place...done. Generating libparrot.def...done. Generating core pmc list...done. Okay, we're done! You can now use `make' (or your platform's equivalent to `make') to build your Parrot. After that, you can use `make test' to run the test suite. Happy Hacking, The Parrot Team ** tools/dev/rebuild_miniparrot.pl: initiating parrot prebuild - make miniparrot-prebuild make[1]: Entering directory `/home/josh/devel/parrot-rw' perl vtable_h.pl perl ops2c.pl C core.ops debug.ops io.ops math.ops rx.ops perl ops2c.pl CPrederef core.ops debug.ops io.ops math.ops rx.ops perl ops2pm.pl core.ops debug.ops io.ops math.ops rx.ops perl fingerprint_c.pl fingerprint.c ** tools/dev/rebuild_miniparrot.pl: removing files in miniparrot directory - cd classes; make array.c boolean.c continuation.c coroutine.c csub.c default.c intlist.c intqueue.c key.c multiarray.c perlarray.c perlhash.c perlint.c perlnum.c perlstring.c perlundef.c pointer.c scalar.c sub.c make[2]: Entering directory `/home/josh/devel/parrot-rw/classes' perl pmc2c.pl array.pmc Scanning /home/josh/devel/parrot-rw/classes/array.pmc... perl pmc2c.pl boolean.pmc Scanning /home/josh/devel/parrot-rw/classes/boolean.pmc... Scanning /home/josh/devel/parrot-rw/classes/perlint.pmc... Scanning /home/josh/devel/parrot-rw/classes/scalar.pmc... perl pmc2c.pl continuation.pmc Scanning /home/josh/devel/parrot-rw/classes/continuation.pmc... perl pmc2c.pl coroutine.pmc Scanning /home/josh/devel/parrot-rw/classes/coroutine.pmc... perl pmc2c.pl csub.pmc Scanning /home/josh/devel/parrot-rw/classes/csub.pmc... perl pmc2c.pl default.pmc perl pmc2c.pl intlist.pmc Scanning /home/josh/devel/parrot-rw/classes/intlist.pmc... perl pmc2c.pl intqueue.pmc Scanning /home/josh/devel/parrot-rw/classes/intqueue.pmc... perl pmc2c.pl key.pmc Scanning /home/josh/devel/parrot-rw/classes/key.pmc... perl pmc2c.pl multiarray.pmc Scanning /home/josh/devel/parrot-rw/classes/multiarray.pmc... Scanning /home/josh/devel/parrot-rw/classes/array.pmc... perl pmc2c.pl perlarray.pmc Scanning /home/josh/devel/parrot-rw/classes/perlarray.pmc... Scanning /home/josh/devel/parrot-rw/classes/array.pmc... perl pmc2c.pl perlhash.pmc Scanning
Re: Primitive Boolean type?
Larry Wall wrote:
Please don't think of Cbit as a boolean type. There is no boolean
type in Perl, only a boolean context. Or looking at it from the
other direction, *every* type is a boolean type.
Er... dang. While I certainly agree with the concept in principle, I'm
having a hard time sticking to it when I'm writing beginner-level docs.
Suppose I'm declaring something like:
class Appliance {
has bit $.is_plugged_in;
has bit $.is_turned_on;
has bit $.has_ul_approval;
}
I'm declaring three attributes that are specifically always either true
or false. They can *only* be true/false, or yes/no, or 1/0 -- they have
no other possible values, and I want to declare them in such a way as to
clearly enforce that behavior. C$.is_plugged_in is never 5 or
timmy -- only true or false, period! By definition, my _intention_ is
therefore to declare these three attributes as containing boolean values.
The problem I'm having is that there are few good ways to describe the
above behavior without using the word boolean. The word is
conspicuous in its absence; it's like someone trying to describe Daffy
Duck to you without using the word duck. Perhaps boolean is spelled
bit (or type bool ::= bit), but the associated value is unambiguously
boolean, which makes the attribute logically boolean in type.
Similarly I would assume that we want the capability to refer to boolean
context by name (just as we can refer to scalar, list (array?), numeric,
string, and other contexts) if for no other reason than to be able to
make declarations like:
sub foo (int $i; str $s; bool $y) { ... }
which, from appearances, seems to strongly _imply_ to the user that
there is indeed a 'bool' type, just as there is an 'int' type and a
'str' type. (They may be wrong, but that's intuitively what the above
signature _appears_ to say.)
So while I understand the philosophical/semantic reasons for the absence
of a true boolean type, I wonder how easy it will be to describe the
principle to newcomers, and if it's worth it. When someone asks what's
the boolean type in Perl? I'd rather answer bit than Perl doesn't
have one, if for no other reason than the latter answer will completely
freak them out. :-)
Feedback? What am I missing?
MikeL
