Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Damian Conway wrote: : Adam D. Lopresto wrote: : : > Really what I've been wishing for was an operator (or whatever) to let me do an : > s// without changing the variable. : : I would hope/expect that that's what the subroutine form of C would do. The problem with defining that as the primitive behavior is that some substitutions are very much faster in place, and it would be difficult to capture. : That is, it takes a string, a pattern, and a replacement string, : and returns a new string with substitution performed (without affecting : the original string): : : print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe him.'; It's possible the syntax for substitution should be wrapped around the syntax for matching, whatever that turns out to be. replace($statement =~ /\.$/, "") replace($statement like /\.$/, "") or even: replace($statement like /\.$/, with => "") We shouldn't limit our notions to strings: replace(@array like 1|2|3, $& + 1); or if @array is the topic replace(1|2|3, $& + 1) It's not yet clear where in-place vs en-passant fits in here. Perhaps there's two different functions, spliting replace into "inplace" and "outplace". :-) I'm sure there are better words with the right connotations though. Larry
Re: Parrot 0.0.9
Steve Fink wrote: ... If not, then just renaming it to Undef seems best. I had a closer look at it. Just renaming doesn't: PerlUndef is derived from PerlInt, which provides major funtionality for it. If this syllable "Perl" is really a problem, I will reorganize them again i a more hierarchical way, all perl classes on top of basic classes. But, as this is again a major patch I'd prefer to do it after 0.0.9, a long with PMC/Buffer unification and variable/value separation, as both steps will change the whole classes subdir drastically again. I have already a working example for PMC/Buffer unification and variable/value separation WRT tied/non tied scalars. I'll send a test program later. leo
Re: [OT] Power of Lisp macros?
On Thu, Oct 24, 2002 at 12:26:41PM -0300, Adriano Nagelschmidt Rodrigues wrote: > Luke Palmer writes: > > Lisp is implemented in C, and C's macros are certainly not essential > > to its functionality. But think of what macros in general provide: > > > > * Multi-platform compatability > > * Easier maintenance > > > > Perl has no problem with the former. It's multi-platform by nature. > > But is has as much of a problem with the latter as any other language, > > except Lisp. That is one of the continuing strong points of Lisp: it > > can change very, very quickly. > > Yes. And what would this kind of "meta programming" allow? Perhaps thoughts > like this: > > "Now I need code for these n cases. I will just write a macro." > > Maybe it makes complex problems suddenly appear more "tractable", allows for > more code reuse/factorization? Damian's Switch.pm is like a Lisp macro. It extends Perl syntax for a certain kind of problem, and makes it easier to write a common code pattern. The thought process might go something like this: "I want to check a variable against a variety of conditions, and I'm tired of writing the same long-winded and error prone if/elsif/elsif/elsif/else cascade. This is a common 'switch' statement, except that I want to match a variety of conditions intelligently (integers, string equality, regexes, etc.)." When Paul Graham writes that 25% of his Viaweb code was macros, he's really saying that Common Lisp wasn't well suited to his problem domain (writing an ecommerce app). However, Common Lisp *allowed* itself to be extended in that directon, with macros. The result is that the 75% of his code that comprised the guts of Viaweb could have been written without macros (or in a language other than Common Lisp), but would have taken significantly more effort and code (and led to more bugs). Perl source filters are similar to Lisp macros to a small degree. Lisp macros are Lisp functions that are invoked at compile time to transform a *tokenized* Lisp program (using Lisp data structures) into a different set of tokens (which are then compiled). Source filters tend to act on raw text, not tokenized source code, and need to deal with the problematic aspects of Perl syntax (comments, Pod, HEREDOCs, etc.) every time they are written/invoked. Because Lisp macros are real Lisp code, they are far more powerful than the textual substitutions that pass for "C macros". Perl6 is moving to include something like Lisp macros. Perl5 source filters are a rough approximation, and a preview of things to come. Z.
Re: perl6 operator precedence table
On Fri, 25 Oct 2002, Martin D Kealey wrote:
: Going back to Perl5 for a moment, we have
:
: substr($str,$start,$len) = $newstr
:
: why not simply extend pattern-matching in a similar way to substr, making it
: an L-value, so that one gets
:
: $str ~ /[aeiou]+/ = "vowels($&)"
:
: or
:
: $str ~ /\d/ {hyper-symbol}= (0) x {size-of-LHS-array};
Problem with that...the replacement argument has to be lazy, and currently
the RHS of an assignment is actually evaluated before the left. You'd
really need something more like
$str =~ /\d/ = { 0 }
However, I think readability suffers without a hint on the front what
you're trying to do. So I'd be more inclined to say that the general
syntax is really more in the spirit of a conditional:
where $str =~ /\d/ { 0 }
The difference between inplace and copying is then really the disposition
of the closure:
where $str =~ /\d/, replace => { 0 }
where $str =~ /\d/, return => { 0 }
But that's clunky. If replacement is the norm, then returning a copy is just
where $str =~ /\d/ { 0 }
where $str.dup =~ /\d/ { 0 }
The topicalized forms would then be:
where /\d/ { 0 }
where .dup =~ /\d/ { 0 }
Except that still doesn't tell it whether to return a boolean or a string...
Of course, most of the time you want to replace with a string, and
where /\d/ { "0" }
is still a lot clunkier than
s/\d/0/;
Maybe we end up with that form and a Ruby-esque
s(/\d/) { "0" }
in the general case. Or it could go in the parens. Hey, maybe that's
a good spot for an arrow:
s(/\d/ -> { "0" })
In any event, we still haven't really solved the want-a-string vs
the want-a-boolean problem. Maybe it's just context:
if s(/\d/ -> { "0" }) {...} # boolean context, in-place
s(/\d/ -> { "0" }); # void context, in-place
print s(/\d/ -> { "0" })# string context, return string
$result = ~s(/\d/ -> { "0" }) # string context, return string
$result = ?s(/\d/ -> { "0" }) # boolean context, return string
$result = s(/\d/ -> { "0" })# untyped context, return what?
But I suspect that's too much weight to put on the context system. It
doesn't really solve the readability problem, especially when we get more
that one {...} in a row.
By all accounts, a s/// is an odd thing to put in a smart match
anyway. You can't have a superposition of things with side effects,
for instance:
$str =~ s/a/b/ | s/b/c/
Though doubtless Damian can think of something indeterminate to make
it mean. :-)
The in-place really feels more like you want a method
$str.s/a/b/
@foo.s(1|2|3, {0})
or maybe
$str.subst/a/b/
@foo.subst(1|2|3, {0})
Maybe the return value form is also a method:
$result = $str.where/a/b/
@result = @foo.where(1|2|3 -> {0})
In typical topical string usage, that leaves us with
if .subst/a/b/ {...}
$result = .where/a/b/
That's quite livable, though the second is a bit odd, English-wise.
We could even keep around
s/a/b/
as a shorthand for .subst/a/b/. And maybe even add
w/a/b/
as a synonym for .where/a/b/.
If so, possibly we don't have .subst/a/b/, but just .subst(/a/ -> { "b" })
for the general form. But string-like method args are certainly a possibility
in general, provided we can keep the declarations in order. But if not,
there's a bad ambiguity between
.subst/a/b/
and things like
.size/2
: (hyper, however it's spelt, will have some way for the RHS to reference the
: LHS, won't it?)
Haven't specified one. @array ^= 0 is supposed to do the right thing already,
and doesn't require the right side to know anything about the left side.
Larry
Re: Parrot 0.0.9
On Thu, 24 Oct 2002, Leopold Toetsch wrote: > Andy Dougherty wrote: > > > Types: > > iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8, > > ptrsize=4, ptr_alignment=4 byteorder=87654321, > The INTVAL2PTR and PTR2INTVAL macros should take care of such a > configuration. Yes, I know. I'm the one who put those macros in parrot.h. >Though I'm not to sure, if we can get rid of all the > warnings. But above case seems to be missing in the macros. However, casting isn't always the correct solution. Sometimes the issue is that the underlying types ought to be changed. For example, I think that a number of variables currently of type UINTVAL really ought to be of tipe size_t. I have posted about this at length before but haven't fixed it myself due to both time constraints and laziness. -- Andy Dougherty [EMAIL PROTECTED]
Re: Configuring and DOD problems
On Wed, 23 Oct 2002, Erik Lechak wrote: Anyways, I am on Win XP using VC++. I look in Config.pm and I see this '#define PARROT_STACK_DIR'. It's not defined to anything, but the code tries to do math with it. What is this? This could well be my fault. I recently changed that test. But looking at your attachment, I don't see anything obviously related to the stack direction. Does your suggestion fix the stack direction problem, or does it just make it easier for you to now explore the problem? -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #18072] [PATCH] fingerprinting the PBC
Jürgen Bömmels (via RT) wrote: # New Ticket Created by Jürgen Bömmels # Please include the string: [perl #18072] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18072 > A PackFile created with a diffrent version of core.ops leads to strange not easy to find errors. Therefor a fingerprint of core.ops is entered to the packfile. Applied with little changes: - wrong fingerprint throughs an exception (the PIO_eprintf segfaulted, I didn't see the message) - major/minor _and_ patchlevel are checked too. (When core.ops stabilizes, the check WRT patchlevel can be taken out) leo
[perl #18078] Patty's login stuff
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #18078] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18078 > Ken, The already downloaded the new list so just tell Patty to start sending. They have the tracker back up again. See you guys on tuesday. John Espisito Gigable Graphics [EMAIL PROTECTED] http://66.46.145.35/members/lIlIlIlIlIlI/ username: pattyw passwd: Kr4syT62L
Re: [PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
On Wed, Oct 23, 2002 at 11:23:26PM -0400, Josh Wilmes wrote: > I've got a patch which switches this detection to happen at run-time > instead of at build-time. This is going to be necessary for miniparrot > (which has no "Configure" step) anyway. Have you checked how much this affects the performance of stack walking ? The current stack direction tests make the stack direction a compile time constant, so that the compiler can optimize away the multiplications in the stack walking loop which can be pretty expensive. The original stack direction tests were run-time, and I changed them to be done at configure time to simplify doing them in a more correct way while also making the code faster. One way of simplifying things here is to always walk the stack in the same direction (lowest address to higher address), and swap the lo and high pointer as the start and end points of the loop. This eliminates the need for an explicit stack growth direction test. One thing that will still remain is that the garbage collector must know the CPU instruction set so it can use the appropriate means to locate pointers in registers. I'm not sure if this can be done by testing for preprocessor symbols alone. -- Jason
Re: Parrot 0.0.9
Dan Sugalski <[EMAIL PROTECTED]> writes: > >The ability to embed arbitrary data in a pbc file under a > >named section. This data needs to be readable by the program > >when it runs, but is otherwise ignored by the rest of Parrot. > > Right, good call. This'll make perl's named embedded filehandles > (__DATA__ and suchlike things--I'm pretty sure Larry and Damian have > Evil Things in mind for this at some point in perl 6) a lot easier as > well. My proposed extension of the packfile format is going in this direction. But I'm not sure at the moment not sure about string encodings in the segment directory. I was thinking about limiting to ASCII because its an internal. Allowing diffrent encodings opens a can of worms. UTF-8 only may also be a possiblity. Furthermore a part of the namespace should be reserved for internal use only. ATM I use all-caps names, but think also about dot-prefix. > A binary data chunk section with named directory for it (per bytecode > segment, I think) would work pretty well for this. I'm not sure if I understand you correctly: You talk about more than one bytecode segment in a packfile and each of them has its own associated directory with independed namespace. Trickey. But it should be possible. Having a root directory segment and sub directories. > I don't think we'll > need it writable, though. Hopefully not, though there is the potential > for interesting things if it is. The main problem with writing to a pbc is the concurrend access. You need some kind of locking. But for read-only access no write should be required so you will never know if some other process is reading the file you want to change, and the reading process has no chance to be sure that the file will not change. But it would be nice if you could write a new packfile. This would be very handy for writing compilers. bye b.
Re: [PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
At 11:57 on 10/24/2002 EDT, Jason Gloudon <[EMAIL PROTECTED]> wrote: > On Wed, Oct 23, 2002 at 11:23:26PM -0400, Josh Wilmes wrote: > > > I've got a patch which switches this detection to happen at run-time > > instead of at build-time. This is going to be necessary for miniparrot > > (which has no "Configure" step) anyway. > > Have you checked how much this affects the performance of stack walking ? It shouldn't at all. It does the check once, when parrot starts up. > One way of simplifying things here is to always walk the stack in the same > direction (lowest address to higher address), and swap the lo and high pointe r > as the start and end points of the loop. This eliminates the need for an > explicit stack growth direction test. > > One thing that will still remain is that the garbage collector must know the > CPU instruction set so it can use the appropriate means to locate pointers in > registers. I'm not sure if this can be done by testing for preprocessor symbo ls > alone. *eyes glazed over* --Josh
Re: [PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote: > > > I've got a patch which switches this detection to happen at run-time > > > instead of at build-time. This is going to be necessary for miniparrot > > > (which has no "Configure" step) anyway. > > > > Have you checked how much this affects the performance of stack walking ? > > It shouldn't at all. It does the check once, when parrot starts up. It will. If you read the following paragraph I explained why it will be slower, and it has nothing to do with how often the check is performed. STACK_DIR is a compile time constant, so the multiplies in the following code are eliminated by the compiler if it does any optimization. By making STACK_DIR a variable, the compiler is no longer able to do this and has to generate code to do multiplies. for (cur_var_ptr = lo_var_ptr; (ptrdiff_t)(cur_var_ptr * PARROT_STACK_DIR) < (ptrdiff_t)(hi_var_ptr * PARROT_STACK_DIR); cur_var_ptr = (size_t)( (ptrdiff_t)cur_var_ptr + PARROT_STACK_DIR * PARROT_PTR_ALIGNMENT ) -- Jason
Re: [perl x18078] Patty's login stuff
Obviously spam, sorry folks. It snuck in under the spam filters. X-Spam-Status: No, hits=5.3 required=7.0 tests=CARRIAGE_RETURNS,FORGED_HOTMAIL_RCVD,MISSING_HEADERS,NORMAL_HTTP_TO_IP,NO_REAL_NAME,SPAM_PHRASE_00_01,TO_EMPTY version=2.41 -R (pondering his next move in the unending war against spam) [EMAIL PROTECTED] (via RT) writes: ># New Ticket Created by [EMAIL PROTECTED] ># Please include the string: [perl #18078] ># in the subject line of all future correspondence about this issue. ># http://rt.perl.org/rt2/Ticket/Display.html?id=18078 > >
Re: [PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
At 18:16 on 10/24/2002 EDT, Jason Gloudon <[EMAIL PROTECTED]> wrote: > STACK_DIR is a compile time constant, so the multiplies in the following code > are eliminated by the compiler if it does any optimization. By making > STACK_DIR a variable, the compiler is no longer able to do this and has to > generate code to do multiplies. Fair enough. I suspected it had to be something like that, but I was kind of dense and didn't follow what you were saying. If I rejigger my code to make it work both ways (run-time for miniparrot, compiled-in elsewise), will that be OK? (I can do this by #defining PARROT_STACK_DIR to either a number or a variable name in stackdir.pl) --Josh
Re: Parrot 0.0.9
On Oct-23, Leopold Toetsch wrote: > Steve Fink wrote: > > >I suppose I ought to try to wrap up a release one of these days. > > > > - Artificial goal: I want the list of pending patches to be smaller > >than one screenfull before I release. Fortunately, I have a large > >screen. > > I did set 2 of them to "Applied". I'll wade through my contributions and > set status accordingly. Thanks. > >* Keyed access > > - Either way, the current keyed support isn't complete. > > Adding a couple of lines to assemble.pl, which do the same as my patch > WRT imcc would make these multi_keyed operations available to HL. Then > we could look at usage patterns and finally decide, what to do. > (Who could extend the assembler?) Sounds good to me. But it does suggest a question -- are there any compelling reasons to preserve the separate assembler? Given that imcc appears to be a strict superset of the assembler these days, I'm tempted to standardize on imcc. Anyone want to argue otherwise? Architecturally, I suppose it would be nice to have a separate library for only processing PASM code, but I don't see that as hugely important. And perhaps the correct method of obtaining that would be by carving out a pasm component of imcc and having the main imcc delegate unrecognized lines to it. But the assembler seems to be a somewhat religious issue, so I'll not jump to conclusions. > >* Bytecode format > > > - I still don't understand why we can't write our own > >serializers/deserializers for ELF or some other standard format, > > I don't see the point, why to use ELF. The new proposed packfile format > should give us all we need. It's my knee-jerk "standards are good" reaction. While the proposed format provides everything we're thinking of at the moment, it seems like there are a lot of other things we might want to be able do with packfiles in the future. Our problem set feels pretty similar to the ELF problem set. The major counterargument I can envision is that it's too complicated and provides way more functionality than we need -- but although I really don't know that much about it, I'm under the impression that ELF is a pretty simple format. It mostly just sounds scary because it happens to be used for complex purposes. To my naive thinking, using a standard could provide some useful advantages. Mostly, I like the general idea of using a standard because a bunch of other presumably intelligent and motivated people have already dealt with all the niggling little issues of naming, referencing, total and partial symbol table stripping, etc. that we may not have thought of yet. ELF, and other formats like it, provides support for an arbitrary number of sections, a place to put indexes, segments, section attributes, etc. Going further out on a limb, it might even be possible to use ELF for some of the things it is normally used for, rather than just a hollow packaging that we stuff our own things into. gdb could make some sense of it automatically. We could store read-only bytecode wads in shared memory. PBC files could be executed as native binaries on ELF-based systems. We could use existing ELF tools to, at the very least, provide test result verification. ELF is certainly not the only possibility. In the past we've mentioned COFF and IFF. Java's .class file format comes to mind too. Even PNG could serve as a general-purpose container. They all pretty much boil down to a variant of a magic-number, some amount of versioning information, maybe an endianness specifier, and an index pointing to the offsets and sizes of a bunch of named sections. On the other hand, talk is cheap and I personally don't plan on trying to implement any of this, so it doesn't really matter what I think. :-)
Re: Variable/value split prelims
Dan Sugalski wrote: At 4:57 PM +0200 10/19/02, Leopold Toetsch wrote: [ Vtable union ] Well... the problem is with references. Larry's declared that a reference must act identically to its referent if used in the right context. We could force an explicit deref, but I'd rather not. Treating the reference as if it were the array or hash itself makes things fit better conceptually, at least for me. So the questions is, how does a reference look like - from a PMC POV? A PMC with an aggregate VTABLE and ->data pointing to the referents data? Or a PMC with a pointer to the aggregate in the ->data? So we would have e.g.: - Plain scalar: vtable->var.get_integer => return cache.int_val ->val.get_integer => return cache.int_val Yep. - Tied scalar: vtable->var.get_integer => call tie magic (updating the value) => ->val.get_integer => return cache.int_val Close. (Or the same if I'm misreading) Like: -tied vtable->var.get_integer => call tie magic to get value PMC ->tie_magic_returned_pmc.get_integer => reurn cache.int_val (Assuming in both cases that the int value is cached and doesn't need to be string converted or anything) Your descriptions seems to include another PMC in tie_magic, while mine just passes the value PMC to tie_magic. tie_magic updates the value, then the normal scalar behaviour jumps in. leo
Re: Parrot 0.0.9
Andy Dougherty wrote: Types: iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8, ptrsize=4, ptr_alignment=4 byteorder=87654321, The INTVAL2PTR and PTR2INTVAL macros should take care of such a configuration. Though I'm not to sure, if we can get rid of all the warnings. But above case seems to be missing in the macros. leo
Re: Parrot 0.0.9
Steve Fink wrote: Prerequisites for 0.0.9 release --- * Reclaim the tinderbox! On one machine I suddenly have additionally: Failed Test Status Wstat Total Fail Failed List of failed --- t/op/stacks.t353 8,57% 4, 7, 34 Running w/o --gc_debug is ok. This emerged after some code changes WRT datatypes. A second machine doesn't show these failures. Strange. leo
[CVS ci] datatypes (was: Parrot 0.0.9)
Steve Fink wrote: - the various unions should probably be coalesced into one I did check in my datatypes patch. - all? native and other data types are summarized in datatypes.h - hash and list use the same enums now - datatype.c has currently 2 functions to retrieve types per name/enum (conversion functions could go here later) - core.ops is adjusted, to retrieve data types or check, if a type enum is valid - test included leo
Re: Parrot 0.0.9
Steve Fink wrote: On Oct-23, Dan Sugalski wrote: It'd probably be a good idea for us to have a generic undef.pmc for undefined usage. Yes, that's what I was saying. Sorry the comment was vague -- all I meant was that general Parrot PMCs should not be creating Perl-specific PMCs. I agree completely with Dan's solution. Is there anything Perl-specific about the current PerlUndef? If not, then just renaming it to Undef seems best. I'll rename PerlUndef.pmc to undef.pmc and create a PerlUndef.pmc derived from it. leo
[perl #18072] [PATCH] fingerprinting the PBC
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18072]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18072 >
A PackFile created with a diffrent version of core.ops leads to
strange not easy to find errors. Therefor a fingerprint of core.ops is
entered to the packfile.
The fingerprint of the core.ops file is generated out of signatures of
the operations (comments and implementation details dont contribute).
This is relativ easy, because the complete parsing of core.ops is done
in OpsFile.pm.
I implemented in a really hacky way: abusing the padding bytes. But
this way it can be implemented *now*. When the named segments are in,
the fingerprint will go to a segment on its own. (Now I can only use
10 bytes of the 16 byte MD5-Hash, but hey we don't want to make
cryptography).
bye
b.
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/40500/32674/273ee1/fingerprint.diff
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.239
diff -u -r1.239 MANIFEST
--- MANIFEST 23 Oct 2002 05:33:39 - 1.239
+++ MANIFEST 24 Oct 2002 01:05:08 -
@@ -199,6 +199,7 @@
examples/pxs/PQt.C
examples/pxs/QtHelloWorld.pasm
exceptions.c
+fingerprint_c.pl
global_setup.c
hash.c
headers.c
Index: MANIFEST.SKIP
===
RCS file: /cvs/public/parrot/MANIFEST.SKIP,v
retrieving revision 1.6
diff -u -r1.6 MANIFEST.SKIP
--- MANIFEST.SKIP 4 Sep 2002 03:48:26 - 1.6
+++ MANIFEST.SKIP 24 Oct 2002 01:05:08 -
@@ -18,6 +18,8 @@
^core_ops\.c$
^core_ops_prederef\.c$
+^core_ops_cg\.c$
+^fingerprint\.c$
^lib/Parrot/Jit\.pm$
^lib/Parrot/PMC\.pm$
Index: fingerprint_c.pl
===
RCS file: fingerprint_c.pl
diff -N fingerprint_c.pl
--- /dev/null 1 Jan 1970 00:00:00 -
+++ fingerprint_c.pl 24 Oct 2002 01:05:08 -
@@ -0,0 +1,74 @@
+#! perl -w
+
+use strict;
+use lib 'lib';
+use Digest::MD5 qw(md5_hex);
+use Data::Dumper;
+use Parrot::OpLib::core;
+
+my $len = 10;
+my $fingerprint = md5_hex join "\n", map {
+ join '_', $_->{NAME}, @{$_->{ARGS}}
+} @$Parrot::OpLib::core::ops;
+
+print << "EOF";
+/*
+ * !!! DO NOT EDIT THIS FILE !!!
+ *
+ * This file is generated automatically from 'core.ops'
+ * by $0.
+ *
+ * Any changes made here will be lost!
+ *
+ */
+
+#include
+#include
+
+EOF
+
+if (-e 'DEVELOPING') {
+
+print "/* $fingerprint */\n";
+print "static const unsigned char fingerprint[] = {\n";
+for my $i (0..$len-1) {
+ print '0x', substr ($fingerprint, $i*2, 2), ",\n";
+}
+print "};\n";
+
+print << "EOF";
+
+int
+PackFile_check_fingerprint (void *cursor)
+{
+return memcmp (cursor, fingerprint, $len) == 0;
+}
+
+size_t
+PackFile_write_fingerprint (void *cursor)
+{
+memcpy (cursor, fingerprint, $len);
+return $len;
+}
+EOF
+
+} else { # !DEVELOPING
+
+ print << 'EOF';
+/* fingerprint checking is only in enabled in development versions */
+
+int
+PackFile_check_fingerprint (void *cursor)
+{
+return 1;
+}
+
+size_t
+PackFile_write_fingerprint (void *cursor)
+{
+memset (cursor, 0, $len);
+return $len;
+}
+EOF
+
+} # endif DEVELOPING
Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.93
diff -u -r1.93 assemble.pl
--- assemble.pl 18 Oct 2002 21:18:33 - 1.93
+++ assemble.pl 24 Oct 2002 01:05:10 -
@@ -427,6 +427,7 @@
use Parrot::Types; # For pack_op()
use Parrot::OpLib::core;
use Parrot::Config;
+use Digest::MD5 qw(md5_hex);
=head2 Assembler class
@@ -828,6 +829,17 @@
=cut
+sub _fingerprint {
+ my $fingerprint = md5_hex join "\n", map {
+join '_', $_->{NAME}, @{$_->{ARGS}}
+ } @$Parrot::OpLib::core::ops;
+ my @arr = ();
+ for my $i (0..9) {
+push @arr, hex substr ($fingerprint, $i*2, 2);
+ }
+ return @arr;
+}
+
sub output_bytecode {
my $self = shift;
my $wordsize;
@@ -847,20 +859,7 @@
flags => 0x00, # unsigned char flags
floattype => 0x00, # unsigned char floattype
-pad => [
-0x19, # unsigned char pad[0]
-0x40, # unsigned char pad[1]
-
-0xe4, # unsigned char pad[2]
-0x73, # unsigned char pad[3]
-0x09, # unsigned char pad[4]
-0x08, # unsigned char pad[5]
-
-0x00, # unsigned char pad[6]
-0x00, # unsigned char pad[7]
-0x00, # unsigned char pad[8]
-0x00 # unsigned char pad[9]
-],
+pad => [ _fingerprint ],
magic => 0x0131_55a1, # opcode_t magic
opcodetype => 0x5045_524c, # opcode_t opcodetype
Index: packout.c
Re: perl6 operator precedence table
Really what I've been wishing for was an operator (or whatever) to let me do an s// without changing the variable. print 'He said "'_($statement ~ s/\.$//)_'," but we didn't believe him.'; I'm not sure exactly what the semantics would be, but somehow =~ without the = seems appealing...it's always seemed annoying to have to make a new variable for things like that, instead of being able to do it in place. But then, perhaps that isn't justification for an entire operator so much as $statement.replace/\.$// or something Mental note: no more postings right before bed. > Brent Dax wrote: > > > Can the new nefarious use be concat? Pretty please? > > There was a brief period 18 months ago when tilde *was* the designated > Perl 6 concatenation operator. > > I certainly wouldn't mind seeing it return to that role, now that > it's not needed elsewhere. And, of course, that would actually be: > > $x ~ $y string concatentation > $x ~= $ystring append > ~$x stringification > > I guess the only concern is the potential for nasty surprises between: > > $str =~ s/a/b/; substitute a for b in $str > > and: > > $str ~= s/a/b/; substitute a for b in $_ and append result to $str > > But I guess that's no worse than: > > $x-=10; > > and > > $x=-10; > > which doesn't seem to be a problem for people in Perl 5. > > Damian > > -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Falls don't kill people. It's the deceleration trauma.
RE: perl6 operator precedence table
Damian Conway wrote:
>I certainly wouldn't mind seeing it return to that role, now that
>it's not needed elsewhere. And, of course, that would actually be:
>
> $x ~ $y string concatentation
> $x ~= $ystring append
> ~$x stringification
> ...
> $str =~ s/a/b/; substitute a for b in $str
>
> ...
> $x-=10;
> ...
> $x=-10;
> which doesn't seem to be a problem for people in Perl 5.
>
So now
$x = ~$y
is not the same as
$x =~ $y
but
$x =- $y
is same as
$x = -$y
Dont we have for consistency ( or may be I have a wrong idea of consistency )
to prohibit ( or rize warning ) when "=-" ( or "=+", "=/" and so on ) appear .
besides it will make "=" an operatorial prefix ( which beutifully makes sence
in "=~" operator) . And maybe in future we can find uses for "=|" , "=!" , ...
..
And to start with, we can make them legitimate operators to be overloaded .
Maybe , my question really is , how perl will behave if I will do
sub operator:=+ (str $x, str $y) { system( "$x | $y" ) } ;
so this is more question of qrammar ?
?
arcadi .
Literate programming (was Re: perl6 operator precedence table)
Larry,
As long as you're trying to figure out how to shoehorn in the last few
available punctuation symbols, and thinking about if there are any
bracketers left, I wondered if there was a chance of a chunking operator
for literate programming? So you can do something like this, if <<<>>>
were the operator:
=doc code
We loop through the array, operating on each item:
=cut
for @list -> $item is rw { # is 'is rw' assumed with for? I forget...
<<>>
}
=doc code
The operation performed is incrementing each item by one:
=chunk operation
$item++;
=cut
Trey
Re: perl6 operator precedence table
On Thursday, October 24, 2002, at 11:22 AM, Larry Wall wrote: But we also have to balance it against the desirability of using ~ for concatenation. Requiring whitespace around _ is a bit of a rationalization after the fact, and ~ escapes that problem in most cases. So (w/out whitespaces): $a~$b # (1) concat $a~=$b # (2) $a = $a ~ $b $a=~$b # (3) $a = the stringification of $b (using unary ~) and something similar to the following $a ~~ $b # maybe perl5 =~, the "logical" look $a $b# maybe perl5 =~, the "comparator" look $a like $b # maybe perl5 =~, the "english" look Hmm, something like that could work. From: Angel Faus <[EMAIL PROTECTED]> Oh, and =~ looks much more intimidating, which is good, given its.. err.. power. Well, I was sort of trying to _avoid_ the intimidating part, because Perl is already intimidating, or so we keep hearing. :-) :-) Stop being intimidating! But in any case (if ~ means concat) I don't think we could sensibly leave =~ as '=~'. I would think we'd want unary ~ to work after '=', which would nix it right there, unless we want required whitespace again. Plus, it's ugly and its parents dress it funny. MikeL
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Chris Dutton wrote: : Also, this brings to mind the one thing I actually remember about : Sather, and as long as we're discussing operators... : : Will we have similar to Sather's "::="? That was essentially the : "statically type this variable at run-time based on the type of it's : initial value" operator. I was thinking ::= would be a := variant that binds at compile time. A "latchy" operator seems a bit weird to me. I'm not sure what it buys you that you couldn't get more straightforwardly through eval. It's a bit like the /o modifier on regexes. If you don't know the type at compile time, it's unlikely that you'll want to nail it down to the first type that comes along when other types might also want to use the same code generically. Larry
Re: perl6 operator precedence table
Larry Wall wrote: > On 20 Oct 2002, Smylers wrote: > > : Seems like not too long ago we were short of punctuation symbols, > : and now you've got a spare one lying around. > > Pity there's no extra brackets lying around without going to > Unicode... Well if C<~> were made the hyper prefix (squiggly line suggesting motion or 'and so on' through a set of things?) that would free up C<^>. And the caret could be a bracket if you rotate your head to the right: ^ 1 2 3 v Might have to outlaw ending identifiers with "v" though ... Now that C<.> is used in bitwise operators, does it make sense to use it in bitwise shifts too: $a .< $b $a .> $b That would almost free up C< << > and C< >> > for being brackets of some sort, but only 'almost' here-docs use the former. Smylers
Re: perl6 operator precedence table
On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote: On the other hand, the current rule for recognizing the *end* of a name in the style of operator:=+ is to go till the next whitespace, on the assumption that we'll never have (shudder) whitespace operators. Oooh, I nominate whitespace to be the concatenation operator! my $foo = $bar $bat; ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
> From: Angel Faus <[EMAIL PROTECTED]> > Date: Fri, 25 Oct 2002 00:54:09 +0200 > > All this ones fit more with the concept of "mystical analogy" hinted > by =~ than with the plain similarity that one would expect from > "like" True. Can't say I like, um, like. > Oh, and =~ looks much more intimidating, which is good, given its.. > err.. power. I fancy ~ or ~~ at the moment. To me, =~ implies some sort of assignment, seeing as there's a single equal sign in it. =~= looks more like a comparison, but it's too ugly-prolog-like. Indeed, I like the I of out-of-place substitutions, and using ~= or ~~= (the duck) for in-place. Though, as pointed out, the in-place efficiency of such a thing would be hard to detect. But--that's for the practical perliticians to work out :) Luke
Re: perl6 operator precedence table
Or we could go with Valspeak:
$a is like $b and stuff
At the moment I like "like" the best, actually...
Hmmm... I could actually see "like" in a more active role. Along the
lines of:
my str $string;
my $other_string is like $string;
Analogous to saying:
my str $other_string
Except that it would get new type information if the type of $string is
changed at some point. Might be useful for generic classes.
class LimitedStack {
attr @.array;
my $init;
method new($first, *@others are like $first) {
$init = $first;
@.array.push($first, *@others);
}
method push(*@items are like $init) { ... }
method pop { ... }
}
Also, this brings to mind the one thing I actually remember about
Sather, and as long as we're discussing operators...
Will we have similar to Sather's "::="? That was essentially the
"statically type this variable at run-time based on the type of it's
initial value" operator.
Re: perl6 operator precedence table
>
> At the moment I like "like" the best, actually...
>
"like" is beautiful for old-style regex matching, but I find it
confusing for the new smart abilities:
$varlike Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10) # $digit is in 0..10 range
@array1 like @array2 # array intersection
$numlike &f# f($num) is true
All this ones fit more with the concept of "mystical analogy" hinted
by =~ than with the plain similarity that one would expect from
"like"
Oh, and =~ looks much more intimidating, which is good, given its..
err.. power.
-angel
Re: perl6 operator precedence table
Brent Dax wrote: Can the new nefarious use be concat? Pretty please? On Wednesday, October 23, 2002, at 07:46 PM, Damian Conway wrote: I guess the only concern is the potential for nasty surprises between: $str =~ s/a/b/; substitute a for b in $str and: $str ~= s/a/b/; substitute a for b in $_ and append result to $str On behalf of the Dumb People, I object. :-)... When I'm training newcomers to Perl, one of the hardest things for them to get is the =~ operator doing a regex. Regexen aren't a base part of most languages that beginning programmers use, but it's an integral part of Perl. Noone ever guesses that =~ means "matching": it looks like an assignment, which it sometimes is, and sometimes isn't, etc. It takes a lot of explaining, and even then people have often written ~= when they mean =~, and stared at it for a half hour not knowing why it didn't work. So I think the =~ vs ~= would be very, very confusing to people, just because =~ is already very confusing to start with, which, in turn, implies we can't use ~ for concat. If anything, I'd almost suggest the other way around, such that ~ means matching and ~= means matching assignment: $str1 ~ $str2# $str1 =~ m/$str2/ $str ~ /foo/ # $str1 =~ m/foo/ $str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2 $str ~= /foo/bar/; # perform subst, assign result to $str which sortof goes better with the new 'magic matching' usage of =~, and I could make some vague argument for matching +=, etc. IF we want to muck with it at all. MikeL
Re: [OT] Power of Lisp macros?
Luke Palmer writes: > > Do you think that Lisp macros make the language more powerful than > > others (eg Perl)? I mean, do they really give a competitive > > advantage, or are they being overrated (see below)? > > If you define "powerful" as "can do more things," then of course not. No, of course. I guess any language is a Turing Machine, after all... I mean power in the sense of "more high level", that could be measured in (fewer) lines of code. Would I exaggerate if I said that the C/Perl compression rate could approach 10 in certain cases? Then I could point you to some benefits Perl has over C, for some classes of problems: faster development, easier maintenance, capability to better develop bigger systems. And Perl excels in solving a wide range of problems. > Lisp is implemented in C, and C's macros are certainly not essential > to its functionality. But think of what macros in general provide: > > * Multi-platform compatability > * Easier maintenance > > Perl has no problem with the former. It's multi-platform by nature. > But is has as much of a problem with the latter as any other language, > except Lisp. That is one of the continuing strong points of Lisp: it > can change very, very quickly. Yes. And what would this kind of "meta programming" allow? Perhaps thoughts like this: "Now I need code for these n cases. I will just write a macro." Maybe it makes complex problems suddenly appear more "tractable", allows for more code reuse/factorization? > However, they are intending to make it possible to write things like > C with subs, which will imply most of the power of > macros... though I imagine it won't be possible to have the level of > introspection lisp macros have (infinite). But, that design team is > very clever, so you never know. Well, I have to confess that I'm asking about macros, but I don't even remember when was the last time I used a closure ;-) > This kind of thing should reveal itself in the next Apocalypse. Then > we can see Larry's "vision," and make appropriate adjustments in terms > of that. Right now, it's very fuzzy. Nice, I'm looking forward to reading it. > Oh, and you aren't being inconvenient. These kinds of questions are > what the list is for: ask away! Thanks! Best regards, -- Adriano
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Michael Lazzaro wrote: :$str1 ~ $str2# $str1 =~ m/$str2/ That would be a smart match, not m/$str2/. :$str ~ /foo/ # $str1 =~ m/foo/ That would work. :$str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2 : :$str ~= /foo/bar/; # perform subst, assign result to $str That can't work without the "s". The lexer can't tell if "bar" is a string or an operator. But the ~= is a cute trick. Not sure if it's more than that though. Gotta worry about s/// in a boolean context, for instance. And the current idiom ($str2 = $str1) =~ s/foo/bar; is not much longer than yours, though your parens are, I think, optional, while mine aren't. But we also have to balance it against the desirability of using ~ for concatenation. Requiring whitespace around _ is a bit of a rationalization after the fact, and ~ escapes that problem in most cases. Plus, smart matching is such a heavyweight, notionally speaking, that it really deserves a larger operator. Since there's no such thing as a "logical concat", we might get away with using ~~, and then people wouldn't have to wonder whether it was ~= or =~. Or we could make it ===. That would pretty much rule out having the corresponding assignment operator though... Or we could leave it =~ for old times sake, and make people learn the difference from ~=. Or go with something new: $a :~ $b $a =~= $b $a =? $b $a $b $a <~> $b $a >< $b $a ::: $b $a match $b $a like $b $a vs $b $a v $b If it is, in fact, a topicalizer, then the Japanese would very naturally parse a postpositional particle: $a wa $b Or we could go with Valspeak: $a is like $b and stuff At the moment I like "like" the best, actually... Larry
RE: perl6 operator precedence table
On Thu, 24 Oct 2002, fearcadi wrote:
: Maybe , my question really is , how perl will behave if I will do
:
: sub operator:=+ (str $x, str $y) { system( "$x | $y" ) } ;
:
: so this is more question of qrammar ?
The general rule in most lexers has always been that it grabs the
longest token it can recognize. So adding that definition would
change the meaning of
$a=+$b;
unless the lexer has a built-in rule that allows it to recognize
operators that haven't been defined yet. It's tempting to
require whitespace after certain classes of operators, but it
would certainly enrage a segment of the population.
On the other hand, the current rule for recognizing the *end* of a
name in the style of operator:=+ is to go till the next whitespace,
on the assumption that we'll never have (shudder) whitespace operators.
But that doesn't mean we have to require whitespace after every
operator. Putting the whitespace merely guarantees that it will
never be interpreted as a longer operator.
I think putting whitespace around any operator containing "=" is a
really good idea just on general principle. But I'm not willing to
inflict my principles on people mandatorily unless there's a really
good reason (as I think there is with mandatory curlies).
Larry
Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Deborah Ariel Pickett wrote: : Which looks better? : if ($a == 1|2|3 || $b eq "x"|"y"|"z") : or : if ($a == 1||2||3 | $b eq "x"||"y"||"z") : ? I think disjunctions of data values should be | and disjunctions of expressions should be ||, so that the "bigger" concept has the bigger operator. : Besides, maybe superposition is going to turn out to be a very common : thing in Perl after all. I think we'll see an awful lot of them that people won't even think of as superpositions, for instance: when 1 | 2 | 3 You know, we could go so far as to say that in regexen, | is unordered and || is ordered. Then we could optimize | to work via DFA or in parallel (for whatever definitions of parallel you want) . But that'd be a rather significant cultural change... : I think I've already decided that I prefer it the way it is (for recent : values of "is"). I just need some kind soul to pat me on the head and : tell me it's OK. It's really OK. The head pat is more problematic--I seem to flip my hemispherical sign bits one at a time, never both at once for the same trip. Perhaps Damian could give you a head pat by proxy next time you run into each other. Larry
Re: perl6 operator precedence table
On Thu, Oct 24, 2002 at 09:59:00AM -0700, Michael Lazzaro wrote: > Noone ever guesses that =~ means "matching" That's because it doesn't. =~ means something more akin to "apply" but it's only valid for the three m//, s///, tr/// ops. That'll change in perl 6 though :-) > If anything, I'd almost suggest the other way around, such that ~ means > matching and ~= means matching assignment: > >$str1 ~ $str2# $str1 =~ m/$str2/ >$str ~ /foo/ # $str1 =~ m/foo/ >$str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2 >$str ~= /foo/bar/; # perform subst, assign result to $str I like it even though the naked ~ always makes me think of awk. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: perl6 operator precedence table
In 'C', we have: a = b+c; In Perl, we can have: $a = $b$c; (Parseable as $a = $b operator:spacespace operator:tab operator:spacespace $c;) Oh frabjous day! =Austin --- David Wheeler <[EMAIL PROTECTED]> wrote: > On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote: > > > On the other hand, the current rule for recognizing the *end* of a > > name in the style of operator:=+ is to go till the next whitespace, > > on the assumption that we'll never have (shudder) whitespace > operators. > > Oooh, I nominate whitespace to be the concatenation operator! > >my $foo = $bar $bat; > > ;-) > > David > > -- > David Wheeler AIM: dwTheory > [EMAIL PROTECTED] ICQ: 15726394 > http://david.wheeler.net/ Yahoo!: dew7e > Jabber: > [EMAIL PROTECTED] > __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: perl6 operator precedence table
On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote: In 'C', we have: a = b+c; In Perl, we can have: $a = $b$c; (Parseable as $a = $b operator:spacespace operator:tab operator:spacespace $c;) Oh frabjous day! Good Lord, you're sicker than I am! :-D David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: perl6 operator precedence table
Um, I don't know about your mail program, but mine converts operator:tab to operator:spacespace operator:spacespace Anyone for makefiles? > -Original Message- > From: David Wheeler [mailto:david@;wheeler.net] > Sent: Thursday, October 24, 2002 5:59 PM > To: [EMAIL PROTECTED] > Cc: Larry Wall; fearcadi; Damian Conway; [EMAIL PROTECTED] > Subject: Re: perl6 operator precedence table > > > On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote: > > > In 'C', we have: > > > > a = b+c; > > > > In Perl, we can have: > > > > $a = $b$c; > > > > (Parseable as $a = $b operator:spacespace operator:tab > > operator:spacespace $c;) > > > > Oh frabjous day! > > Good Lord, you're sicker than I am! > > :-D > > David > > -- > David Wheeler AIM: dwTheory > [EMAIL PROTECTED] ICQ: 15726394 > http://david.wheeler.net/ Yahoo!: dew7e > Jabber: > [EMAIL PROTECTED] > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
