Re: perl6 operator precedence table
On Thu, 24 Oct 2002, Larry Wall wrote:
> It's possible the syntax for substitution should be wrapped around the syntax
> for matching, whatever that turns out to be.
That strikes me as promising...
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};
(hyper, however it's spelt, will have some way for the RHS to reference the
LHS, won't it?)
-Martin
--
4GL ... it's code Jim, but not as we know it.
Re: [OT] Power of Lisp macros?
On Wednesday 23 October 2002 17:58, Luke Palmer wrote: > > From: Adriano Nagelschmidt Rodrigues <[EMAIL PROTECTED]> >> [...] > > 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. We're probably not talking about Turing-completeness here, so I'm not sure your point is valid. You sure can 'do more thing' in a language with Lisp-style macros (read _On Lisp_ and blow your mind). As for the competitive advantage etc., this does have a lot to see with the programmer. As for OOP or patterns or whatever, there is no silver bullet. > Lisp is implemented in C, and C's macros are certainly not essential > to its functionality. Humph. What does the fact that Lisp *can be* implemented in C have to see with C macros? BTW, it would be an insult to Lisp to compare C's macros to Lisp's macros. C macros are a stupid text replacement facility, they don't have anything to see with Lisp-style macros. > But think of what macros in general provide: > > * Multi-platform compatability > * Easier maintenance That's for C macros. It doesn't make much sense if you are talking about Lisp macros. > However, they are intending to make it possible to write things like > C with subs, which will imply most of the power of > macros... Well, if it means controling evaluation and making arbitrary code manipulation, then yes, probably... > though I imagine it won't be possible to have the level of > introspection lisp macros have (infinite). ? Manipulating arbitrary AST in Perl would be very complicated, those 'pesky' parenthesis in Lisp account for a lot of the magic that can go on while keeping things at a reasonable amount of complexity. Guillaume
Re: [CVS ci] datatypes (was: Parrot 0.0.9)
Steve Fink wrote: On Oct-24, Leopold Toetsch wrote: Thanks! It's a little scary how fast you are. This depends on the RL work I've waiting to be done. The more is in the queue (especially putting invoices together for the revenue office), the more I'll code parrot stuff ;-) leo
Re: Parrot 0.0.9
Steve Fink wrote: On Oct-23, Leopold Toetsch wrote: 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? Macros, currently. When we have a macros preprocessor, we could toss the assemble.pl. ... 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? imcc has a slightly stricter syntax WRT subroutines, though this is not final. And there are some keyword clashes, e.g. imcc »if« vs pasm »if«. 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. This is current behaviour. There are 2 possible ways to switch to pasm: .emit pasm code is here .. .eom and unrecognized keywords are looked up as pasm opnames in all lines. But the assembler seems to be a somewhat religious issue, so I'll not jump to conclusions. The assembler is slow, but has this nice macro feature, which is heavily used in some tests. * Bytecode format ... We could use existing ELF tools to, at the very least, provide test result verification. This is an argument. If we get e.g. bsr fixup at load time done by the elf loader, it would be nice. OTOH fixup is not complicated (imcc does it), but when we have e.g. native dynamic libraries mixed with PBC, and ELF does the right thing, it would be an advantage. Using gdb is another nice feature - but what with different platforms not having all these tools? leo
Re: Parrot 0.0.9
Steve Fink wrote: On Oct-24, Leopold Toetsch wrote: ... is there anything perl-specific about PerlInt? PerlNum? This depends. The PerlScalars change there types on demand. add PerlInt, PerlInt, PerlNum changes the type of the LHS to a PerlNum. Other languages might prefer to round the result to an int and keep the type -- I dunno. Although if we're going to change PerlInt to Int (or just make a new Int base class that PerlInt would inherit from), then we should probably handle the question of how many bits these integers should have, and possibly create a couple of PMCs -- Int32, Int64, IntAtLeast32, NativeInt, UnboundedInt, IntAsBigAsYourHead, etc. Int's with size <= sizeof(INTVAL) will be handled natively (or by Int.pmc) + some bit adjustment/sign promotion ops. Integers bigger then INTVAL need there own class. Fixed sized ints could be mapped at configure time to an appropriate type. Dan, do you have any design guidance to kick in here? What Parrot Int/Num PMCs do we need, and how should PerlInt relate to them? IMHO we should currently concentrate on the PerlScalars - as we don't have other major HLs now. But as soon as they start using parrot, we will know, how these scalars should behave. A long with the variable/value split, we will get some more modular VTABLE. Eventually we will have a scalar constructor like: new Int, [ size 32, tieable yes, morph_type perl, taint_check yes ] and put appropriate VTABLE pieces together, to achieve the desired behaviour. [ past 0.0.9 ] Fair enough. Although it looks like this release is still going to take some time to stabilize; there are still an uncomfortable number of warnings and GC bugs. These warnings and GC bugs should definitely be weeded out, yes. leo
[RFC] Buffer/PMC unification, variable/value vtable split, tied scalars
Attached is a test program showing some features, how a PMC could look
like in the future.
1)
PMCs/Buffer are both based on the same bufferlike structure - I called
it Pobj (Parrot Object)
- There is no need, that all PMCs are of same size, the bufferlike code
in smallobjects.c / headers.c takes care of these.
- mark/GC would be unified - marking all Pobj's does it.
- Eliminates a fair amount on now duplicate code.
Steps towards that would include:
- encapsulate flags and other Buffer/PMC members in accessor macros
- unify the BUFFER/PMC_xx_FLAGs
- unify mark and general code clean up
2)
Variable/value VTABLE split
As layed out by Dan, the access to a value inside a PMC has - in the
general form - to be done in 2 separate steps:
- get the variable PMC (+ handle side effects like tied variables)
- get the value out of this PMC
The same rule holds for setting a value inside a PMC.
By splitting the VTABLE into different pieces, we can avoid to do these
separate steps for plain scalars, which wouldn't need it.
Please have a look at »scalar_vt« and »tied_scalar_vt« in the test
program, how this could work:
For plain scalars the first vtable->var.get_integer does it all - finito
- like current operation. For tied scalars, the vtable has different
entries, to accomplish both steps.
The test program shows additionally, how other methods would be
implemented - they all are in the vtable->val part, calling
vtable->var.get/set_{type} for obtaining/setting values.
Putting these methods into the vtable->val piece provides for a small
vtable->var piece, which only holds (duplicates of) the direct
get/set_{type} methods. So vtable duplication is minimal.
3) Tied scalars
Based on above scheme, the test program shows, how this actually works
by tieing a scalar to a (fixed) function, which increments the value on
each access. Using this tied scalar in an »add« methods does the right
thing.
Unsolved - as mentioned in the program - is how to handle these now
dynamically allocated vtable (pieces) WRT memory management. But we
could probably allocate these vtable pieces as bufferlike small objects
and keep them in pools. Many different PMCs (all of the same type/class)
are having the same vtable anyway. Subclassing or tieing a variable
would generate one or more new vtable pieces for this variable type.
Finally, the test program can be run in the parrot main dir by:
$ cc -o tt -Wall -g tt.c -Iinclude && ./tt
(The syntax for different platforms might differ ;-)
Please give it a try, to see implications for different platforms and -
as always - coments welcome,
especially e.g.
- how would references fit, how will the look like
- objects and methods/attributes and subclassing
- and the whole and everything ...
Have fun,
leo
Re: Parrot 0.0.9
Leopold Toetsch <[EMAIL PROTECTED]> writes: [imcc...] > >>>* Bytecode format > > > > ... We could use existing ELF tools to, at the very least, > > provide test result verification. > > > This is an argument. If we get e.g. bsr fixup at load time done by the > elf loader, it would be nice. > > > OTOH fixup is not complicated (imcc does it), but when we have > e.g. native dynamic libraries mixed with PBC, and ELF does the right > thing, it would be an advantage. Using gdb is another nice feature - > but what with different platforms not having all these tools? For our own bytecode format there are also platforms not having this tools: All. So its a bit less discriminating but not necessary better. Dynamic libraries are not simple, and if we get it for free one platform this is a good thing. Use it on other platforms is a matter of porting ld.so (which is far from simple). bye b. -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Execute in place?
I was just having a look at the packfile format code, and I have a suggestion on load-time performance of the code segment. Currently, you read the file, parse out the various sections, copy them elsewhere in memory, and byte-swap as necessary. The overhead of doing this could be quite significant on large applications/modules. A "trick" that I've found very useful in the past is to design the bytecode format so that it can be mmap'ed into a block of memory, and then executed almost immediately with the minimum number of fixups. Rather than copying the instructions, you execute them directly out of the mmap'ed region. This has several benefits. The obvious one is less copying during program loading. But less obvious is that it can make the OS kernel do the hard work for you. When a region is mmap'ed read-only, the OS kernel can manage memory better. When memory gets tight, it can simply discard the page, as it can always go back to the file to get it again. A malloc'ed page, by comparison, must be copied out to the swap file, which incurs additional overhead. Even better, the kernel will perform demand-paging of the bytecode into memory as the code is executed, giving much faster startup times. Multiple processes accessing the same module will share the same page. Copying everything into a malloc'ed region defeats demand-paging. Of course, this is only going to work if the packfile matches the host endianness exactly. A byteswap is still required if the endianness doesn't match. However, in any given install, it is 95% likely that the pre-compiled modules will be set up with the host order. Key to making this work is that fixup information must be well isolated within the file. e.g. references to external functions is by static index into a fixup table, not by applying a relocation directly to the main code segment. If you ever wonder why PIC-format ELF binaries are so weird, it is to harness the mmap system deep inside the kernel to do most of the hard work. Just an idea. Apologies if I'm rehashing something that has already been discussed previously and discarded. Cheers, Rhys.
Re: [perl x18078] Patty's login stuff
On Thu, 2002-10-24 at 19:15, Robert Spier wrote: > > 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) Nukes. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: [PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
On Thu, Oct 24, 2002 at 06:16:55PM -0400, Jason Gloudon wrote: > On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote: > > 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 ) What is wrong with any of 1: Duplicating the above loop (which isn't large), one for upwards stack, the other for downwards stack, and switching (outside) between the two based on an if statement on a global stack direction variable. (Globals bad, I know, but I assume that no-one has yet made an INTERCAL-eqse OS where the stack direction can change between threads of the same process) That gets the if test outside the loop, and keeps the loop construction optimisable at compile time 2: Pulling all of trace_system_stack out into its own source file, compiling it twice (once for up, once for down) with different names, and choosing the correct function pointer once based on a run time test 3: Keeping things as it is, and having miniparrot #define PARROT_STACK_DIR as a global variable containing the (run time determined) stack direction, whereas configured parrot #defines it as -1 or +1 Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [perl x18078] Patty's login stuff
On Fri, Oct 25, 2002 at 07:55:45AM -0400, Bryan C. Warnock wrote: > On Thu, 2002-10-24 at 19:15, Robert Spier wrote: > > -R (pondering his next move in the unending war against spam) > > Nukes. my thoughts entirely > -- > Bryan C. Warnock > bwarnock@(gtemail.net|raba.com) When the spammers figure out how to parse regexps to get the address out, are you going to start using pathological expressions with greedy matches inside nested captures that will tie them up until the heat death of the universe? :-) Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Execute in place?
On Fri, Oct 25, 2002 at 09:15:07PM +1000, Rhys Weatherley wrote: > A "trick" that I've found very useful in the past is to design > the bytecode format so that it can be mmap'ed into a block of > memory, and then executed almost immediately with the minimum > number of fixups. Rather than copying the instructions, you > execute them directly out of the mmap'ed region. [snip advantages of a read only mmap over other options] > Just an idea. Apologies if I'm rehashing something that has > already been discussed previously and discarded. IIRC speed is parrot's number 2 priority (after correctness), so anything that makes parrot faster is good. I remember that a while back Dan was suggesting some change or addition to the bytecode format that would have meant that the file could not have been mapped read only. Two people (I was one) commented that this was a bad thing, because being able to mmap read only was very useful, for the reasons you describe. I wasn't aware that the bytecode format had changed sufficiently to preclude mapping the whole file in read only (even if the current reader doesn't do this), but I admit that I've not been following changes closely. Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
[CVS ci] WRT 0.0.9 - test failures /GC
I did ci 2 changes: - headers.c was a little bit to drastic in stressing the system. e.g. t/op/stacks_4 ran just out of mem after allocating 800K new_blocks. - spf_vtable did use string_make (with BUFFER_external_FLAG) after my patch, both are wrong. string_copy i.e. make a COW string - is the way to go. I did only adjust _one_ occurence, but added some comments. Please have a look at these other places marked XXX. I have now only 2 failures (manifest ;-) and pmc_76 (75) WRT multiarray. leo
RE: Parrot 0.0.9
At 12:30 PM -0700 10/25/02, Brent Dax wrote: Dan Sugalski: # I'm thinking something else, actually. Names made perfect sense # except for encoding info and duplication. We can put limits on the # name encoding if we want, but... really, who cares? It's only useful # for introspection purposes and while that's certainly important, I'm # not sure it's worth much hassle. # # Instead, lets just give an entry number. We can have arbitrary data # chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having # names attached. What happens if two tools (say, a custom debugger and the Perl compiler) both use the same segment number for something? Names make collisions less likely. Whoever's writing the bytecode file needs to deal with that--hopefully there's only one writer. I'm in the middle of getting the API down on electrons, so we should have something to savage reasonably soon. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Execute in place?
At 9:15 PM +1000 10/25/02, Rhys Weatherley wrote: I was just having a look at the packfile format code, and I have a suggestion on load-time performance of the code segment. Currently, you read the file, parse out the various sections, copy them elsewhere in memory, and byte-swap as necessary. The overhead of doing this could be quite significant on large applications/modules. A "trick" that I've found very useful in the past is to design the bytecode format so that it can be mmap'ed into a block of memory, and then executed almost immediately with the minimum number of fixups. Rather than copying the instructions, you execute them directly out of the mmap'ed region. Gah. This was how things were originally done, and what was supposed to be followed through on--if the segment on disk matched the host size/endianness, it's supposed to be just mmapped in. The constants section may need fixup (string and PMC constants, certainly) but the code itself is supposed to be shared. This is good for both speed reasons (as you noted) and for process size reasons, since we're definitely facing the potential for a half-zillion Apache mod_parrot processes mapping in the same bytecode to execute server-side programs. If this has been broken, then we need to fix it, as it's a bug. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 Operator List
Brent Dax wrote:
Larry Wall:
# We're obviously missing the "force to string context, negate"
# operator. :-)
Which would create a superposition of all strings besides the given one,
right? (Oh crap, I think I gave Damian an idea... :^) )
The C<~none> operator covers that quite nicely:
$not_foo = ~none('foo');
...
if $str eq $not_foo {
print "Not 'foo'\n"
}
H. Maybe C is starting to grow on me. Bwah-ha-ha-ha-hah! >;-)
Damian
Re: Perl6 Operator List
On Fri, 25 Oct 2002, Michael Lazzaro wrote:
: What's the Official Perl difference between a named unary op and a
: one-arg universal method?
The Perl 5 definition of named unary op is an operator with the
precedence of UNIOP in perly.c.
: E.g. why are "temp" and "let" both ops but
: "my, our, hash" are not?
Well, "temp" and "let" both have their primary function at run time.
"my" and "our" are declarative, so their primary function is at
compile time, though either can function as an lvalue at run time.
So while things like "my" might parse at the same precedence level
as a UNIOP, they're somewhat disqualified by not really being an
operator in the usual sense. Of course, you can always think of
them as operators that just happen to run immediately at compile time
'cuz they're too impatient to wait for run time. But they also tend
to require special syntax following them, such as "is", that isn't
allowed in the case of general
"hash {...}" can be considered an operator if "sub {...}" is.
But again, its primary function is to clarify the declarative intent
of the following braces, even though the braces do have a run-time
meaning. Ordinarily though, the braces are disambiguated by whether
there is => at the top level.
: (I also missed 'err', not sure on that one either.)
Yes, that should be there too.
Larry
Re: Perl6 Operator List
On Fri, 25 Oct 2002, Michael Lazzaro wrote:
: What's the Official Perl difference between a named unary op and a
: one-arg universal method?
I didn't give the other half of the answer. A method is a term,
not an operator. It's the . in front of it that's the operator...
It's just that, in indirect-object syntax, the colon on
length $object:
is optional, so it looks a lot like unary operator. But I think
the precedence is probably LISTOP, not UNIOP, at least if we
stick with the Perl 5 approach of any listop grabbing all the
available args to the right. I don't see a good way to keep
the precedence of length and friends at UNIOP--at least, not
without having universal subroutines that just pass their
single arguments off to the object as a real method. The
question is whether there's any way to keep Perl 5's
print length $a, "\n";
so it still parses as expected. It seems a bit silly to have to
declare a universal sub like
sub *length ($x) { $x.length() }
On the other hand, we would like to make methods obey the same
argument parsing rules as subs. Which means that the above behavior
could be implied for untyped objects via
class Object {
method length ($x) {...}
}
without having to declare a universal sub. But that depends on our
assumption that any method call's syntax can be determined by looking
at the type of its left side. That has ramifications if the declared
type of the left side is a base class and we really want to call a
method in a derived class that exceeds the contract of the base class.
We can probably defer some of these decisions till run time, such
as whether to interpret an @foo argument in scalar or list context.
But changing the precedence of length from a LISTOP to a UNIOP can't
be deferred that way. Which is why we either need the parser to know
the uniop declaration of
sub *length ($x) { $x.length() }
or we have to make
print length $a, "\n";
illegal, and require people to say one of:
print length($a), "\n";
print (length $a), "\n";
print $a.length, "\n";
if there's a following list. The latter approach seems quite a bit
cleaner, in that it doesn't require either the parser or the programmer
to maintain special knowledge about a unary function called "length".
I think we also need to fix this:
print (length $a), "\n";
The problem with Perl 5's rule, "If it looks like a function, it *is*
a function", is that the above doesn't actually look like a function
to most people. I'm thinking we need a rule that says you can't put
a space before a dereferencing (...), just as you can't with {...}
or [...]. If you want to, then, as with {...} or [...] you have to
use .(...) instead. That is,
print .(length $a), "\n";
means
print(length $a), "\n";
but
print (length $a), "\n";
means
print( (length $a), "\n" );
If we ever allow a syntax like C++'s foo for who knows what
purpose, then it would have to follow the same rules, since it would
otherwise be ambigous with a < operator. So maybe we should start
telling people not to say things like $a<$b when they mean $a < $b.
One could argue that this rule should be followed for all bracketing
syntax, including Unicode. That would be consistent, at least. The
real name of subscripts is then always with the dot:
operator:.[]# subscript []
operator:.{}# subscript {}
operator:.()# subscript () aka function args
operator:.<># subscript <> (reserved)
...
operator:[] # array composer
operator:{} # hash or closure
operator:() # regular parens
operator:<> # an op that screws up <, <<, <=, and <=> :-)
...
That's assuming that matched brackets are always recognized and assumed to
have an expression in the middle.
Actually, it's not clear that operator:<> would mess up binary <
and friends. It looks as if those four are really:
term:[] # array composer
term:{} # hash or closure
term:() # regular parens
term:<> # the input symbol AKA call the iterator
...
So we note that we can actually get away with having all of:
operator:.<>
operator:<
term:<>
without ambiguity (assuming a consistent space rule). However,
if we ever had
operator:{
we couldn't do the trick of assuming an implicit operator before a
block in
if $a eq $b {...}
But now note how we could have all three of
$a++# operator:.++
$a ++ $b# operator:++
++$b# term:++
by applying the rule to non-bracketing characters as well. Basically,
operator:.op vs operator:op allows us to distinguish postfix ops from
binary ops, if we want. That might be cool.
But we have a problem if we want to specify a binary operator that begins
with dot. So it probably has to be:
postfix:++
infix:++
prefix:++
or some such. That still leaves us with a problem if they
Re: Perl6 Operator List
So many operators... It's now clear what we need. Unicode operators. That should buy us at least another week to hash out the rest of the necessary operators. ;-) It'd also silence the legions of critics who complain about Perl being too easy to read if we, for instance, used the Kanji character for watashi in place of $self, and the character(s) for anata for the default topic.
Re: Perl6 Operator List
On Fri, 25 Oct 2002, Chris Dutton wrote: : So many operators... : : It's now clear what we need. Unicode operators. That should buy us at : least another week to hash out the rest of the necessary operators. ;-) : : It'd also silence the legions of critics who complain about Perl being : too easy to read if we, for instance, used the Kanji character for : watashi in place of $self, and the character(s) for anata for the : default topic. Er, yeah. And one of the overriding design goals of Perl 6 is that programs spend more time undefining operators than defining them. :-) Unfortunately, anata doesn't work for the default topic. The whole point of the default topic in Japanese is that it's the 0-pronoun. So it'd have to be referenced as the null string if we went that route. Come to think of it, that's precisely what's happening with .method(). But anata means "you", and you're generally the topic only if I say "anata wa", semantically speaking. You can also be the topic in a pragmatic sense if I'm asking you a question. But most topics are third person, not second. We'd have to use something like "kore" or "sore" if we wanted something for an explicit topic reference. But usually it's implicit in Japanese. In fact, in Japanese, that last sentence wouldn't have an "it": "But in Japanese is usually implicit." Or in Japanese word order, "But Japanese-in usually implicit-is." In any event, there isn't really a third person pronoun meaning "it". "that" is about as close as you get. Larry
Re: Parrot 0.0.9
At 9:13 AM +1000 10/26/02, Rhys Weatherley wrote: Dan Sugalski wrote: ># Instead, lets just give an entry number. We can have arbitrary data ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having ># names attached. > >What happens if two tools (say, a custom debugger and the Perl compiler) >both use the same segment number for something? Names make collisions >less likely. Whoever's writing the bytecode file needs to deal with that--hopefully there's only one writer. I'm in the middle of getting the API down on electrons, so we should have something to savage reasonably soon. I don't think you can guarantee that. Sooner or later someone will download the packfile spec and write a stand-alone compiler that generates bytecode directly, using none of the Parrot tools. If such a compiler needs an extension section, what number do they give it? (I'll be using imcc for C#, but others might want to do things manually). Huh? No, you misunderstand. Each chunk of the bytecode has a separate TOC for stuff like this. The full identifier would be file/chunk/entry, which should be reasonably guaranteed to be unique. When the compiler's emitting code to reference a piece of binary data (which is essentially a big binary string constant, but I realize that having it in separate segments is terribly useful) it can turn any human-readable identifier into the internal identifier the engine needs to look up the actual data. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Parrot 0.0.9
Dan Sugalski:
# Huh? No, you misunderstand. Each chunk of the bytecode has a separate
# TOC for stuff like this. The full identifier would be
# file/chunk/entry, which should be reasonably guaranteed to be unique.
# When the compiler's emitting code to reference a piece of binary data
# (which is essentially a big binary string constant, but I realize
# that having it in separate segments is terribly useful) it can turn
# any human-readable identifier into the internal identifier the engine
# needs to look up the actual data.
DIRECTORY:
SEG 1 OFFSET: 324
SEG 2 OFFSET: 2496
SEG 3 OFFSET: 32482
...
SEG 1:
TYPE: Line Locations
LENGTH: 2070
DATA: 101011101001...
I was thinking in terms of what TYPE: stores; it seems you were thinking
about how you identify a particular segment. Yeah, you can probably get
away with just numbering the segments, although that might slow things
down a bit when you're looking for a particular type of segment. (In
foo.pbc, the line location segment might be 1, but in bar.pbc, it's 2.)
BTW, my father (a programmer too, although most of his work is with
database-driven programs) suggested a solution that's half-way between
string and number: hash the string and use the hash as the number. With
a good hashing function (say, MD5 with the four chunks XORed together)
you'll probably be able to avoid collisions but still have unique
identifiers.
--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: Parrot 0.0.9
At 12:23 PM +0200 10/25/02, Juergen Boemmels wrote: Leopold Toetsch <[EMAIL PROTECTED]> writes: [imcc...] >>>* Bytecode format > ... We could use existing ELF tools to, at the very least, > provide test result verification. This is an argument. If we get e.g. bsr fixup at load time done by the elf loader, it would be nice. OTOH fixup is not complicated (imcc does it), but when we have e.g. native dynamic libraries mixed with PBC, and ELF does the right thing, it would be an advantage. Using gdb is another nice feature - but what with different platforms not having all these tools? For our own bytecode format there are also platforms not having this tools: All. So its a bit less discriminating but not necessary better. Dynamic libraries are not simple, and if we get it for free one platform this is a good thing. Use it on other platforms is a matter of porting ld.so (which is far from simple). Dynamic libraries aren't really a player here, as we're not going to be dynamically generating platform-native shared libraries on disk. Bytecode yes, but that's definitely not the same thing. FWIW, I really don't have any vested interest in any bytecode format as long as we: *) Standardize on one before release *) Find or build one that can properly version and tag itself so we can handle backwards compatibility *) Get one that meets our needs -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RFC] Buffer/PMC unification, variable/value vtable split, tied scalars
Leopold Toetsch wrote: > Attached is a test program showing some features, how a PMC could look > like in the future. and where's the attachment? cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [RFC] Buffer/PMC unification, variable/value vtable split, tied scalars
Leopold Toetsch wrote: Attached is a test program showing some features, how a PMC could look like in the future. Arg mozilla did show it.
Re: [CVS ci] datatypes (was: Parrot 0.0.9)
On Oct-24, Leopold Toetsch wrote: > 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 Thanks! It's a little scary how fast you are.
Re: Parrot 0.0.9
On Oct-24, Leopold Toetsch wrote: > 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. Well, it definitely bothers me, but maybe I'm just being anal retentive. Maybe this is the right time to ask another question I've been wondering about: is there anything perl-specific about PerlInt? PerlNum? Although if we're going to change PerlInt to Int (or just make a new Int base class that PerlInt would inherit from), then we should probably handle the question of how many bits these integers should have, and possibly create a couple of PMCs -- Int32, Int64, IntAtLeast32, NativeInt, UnboundedInt, IntAsBigAsYourHead, etc. Dan, do you have any design guidance to kick in here? What Parrot Int/Num PMCs do we need, and how should PerlInt relate to them? > 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. Fair enough. Although it looks like this release is still going to take some time to stabilize; there are still an uncomfortable number of warnings and GC bugs.
Re: Parrot 0.0.9
At 5:28 PM +0200 10/24/02, Juergen Boemmels wrote: 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. I'm thinking something else, actually. Names made perfect sense except for encoding info and duplication. We can put limits on the name encoding if we want, but... really, who cares? It's only useful for introspection purposes and while that's certainly important, I'm not sure it's worth much hassle. Instead, lets just give an entry number. We can have arbitrary data chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having names attached. > 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. Yep, but only a little. But it would be nice if you could write a new packfile. This would be very handy for writing compilers. Writing a new packfile is definitely a different beast than altering an existing one. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Parrot 0.0.9
Dan Sugalski:
# I'm thinking something else, actually. Names made perfect sense
# except for encoding info and duplication. We can put limits on the
# name encoding if we want, but... really, who cares? It's only useful
# for introspection purposes and while that's certainly important, I'm
# not sure it's worth much hassle.
#
# Instead, lets just give an entry number. We can have arbitrary data
# chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having
# names attached.
What happens if two tools (say, a custom debugger and the Perl compiler)
both use the same segment number for something? Names make collisions
less likely.
--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)
[PATCH] Implicit stack direction probe
On Fri, Oct 25, 2002 at 01:01:16PM +0100, Nicholas Clark wrote:
> What is wrong with any of
>
> 1: Duplicating the above loop (which isn't large), one for upwards stack,
>the other for downwards stack, and switching (outside) between the two
>based on an if statement on a global stack direction variable.
Here is what I suggested in a previous email. Always walk the stack in the same
direction, regardless of the direction in which it grows. PARROT_STACK_DIR is
not used.
Non-contiguous stack systems will have to use an entirely different version of
the stack walking function. This is left as an exercise for the reader.
--
Jason
Index: dod.c
===
RCS file: /cvs/public/parrot/dod.c,v
retrieving revision 1.24
diff -u -r1.24 dod.c
--- dod.c 23 Oct 2002 05:27:01 - 1.24
+++ dod.c 25 Oct 2002 21:55:24 -
@@ -460,7 +460,7 @@
{
size_t lo_var_ptr = (size_t)interpreter->lo_var_ptr;
size_t hi_var_ptr = (size_t)&lo_var_ptr;
-size_t prefix;
+size_t prefix, tmp_ptr;
ptrdiff_t cur_var_ptr;
size_t buffer_min = get_min_buffer_address(interpreter);
@@ -471,6 +471,12 @@
size_t mask = find_common_mask(buffer_min < pmc_min ? buffer_min: pmc_min,
buffer_max > pmc_max ? buffer_max : pmc_max);
+if(lo_var_ptr > hi_var_ptr){
+tmp_ptr = hi_var_ptr;
+hi_var_ptr = lo_var_ptr;
+lo_var_ptr = tmp_ptr;
+}
+
/* Get the expected prefix */
prefix = mask & buffer_min;
@@ -478,10 +484,8 @@
return last;
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 )
+cur_var_ptr < hi_var_ptr;
+cur_var_ptr = (size_t)((ptrdiff_t)cur_var_ptr + PARROT_PTR_ALIGNMENT)
) {
size_t ptr = *(size_t *)cur_var_ptr;
Re: Parrot 0.0.9
Dan Sugalski wrote: > ># Instead, lets just give an entry number. We can have arbitrary data > ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having > ># names attached. > > > >What happens if two tools (say, a custom debugger and the Perl compiler) > >both use the same segment number for something? Names make collisions > >less likely. > > Whoever's writing the bytecode file needs to deal with > that--hopefully there's only one writer. I'm in the middle of getting > the API down on electrons, so we should have something to savage > reasonably soon. I don't think you can guarantee that. Sooner or later someone will download the packfile spec and write a stand-alone compiler that generates bytecode directly, using none of the Parrot tools. If such a compiler needs an extension section, what number do they give it? (I'll be using imcc for C#, but others might want to do things manually). Numbers need to be centrally managed to prevent conflicts, because it is impossible for an independent person to "make up a number" and guarantee no conflicts. Names are easier to make unique, as the name of the language/project/author/DNS name will normally be unique enough to act as a prefix. No central management required. e.g. compare the MIME type system with SNMP's ASN.1 based object identifiers. Picking a new MIME type out of thin air is easy. Adding a new field identifier in SNMP requires massive co-ordination, and sacrificing of large numbers of rubber chickens to the IETF gods. Names are also easier to remember. Quick now: what is the MIME type for HTML? What is the SNMP object identifier for the IP default TTL? Cheers, Rhys.
Re: Perl6 Operator List
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> 'kay. As an aside, I've always itched for a qlike op that was
> matrix-like, e.g.
>
> my Pet @list = qm{
> fido dog collie
> fluffy cat siamese
> };
That should be qo, and possibly @qo or qoo -- it quotes an object.
Since c knows what type thing $lunch is, there's no
reason not to either automagically invoke a constructor or list of
init-funcs for $lunch, or at least create a temporary anonymous Pet and
then copy/clone it.
Likewise, either @lunch implies that qo takes multiple (perhaps a
single object can simply init with { attr, attr, ... }) or qoo does
arrays...
my Pet @dogs = qo{ # Note {} delims looks more like collars ...
fidodogcollie
fluffy catsiamese
};
> And I always wished
>
> $=
> @=
> %=
Isn't % the modulus (remainder-after-division) operator? And isn't %=
the perform-and-assign version thereof?
---
In the manner of Accent, I'd like @ reserved as the RPC operator.
(There aren't many Accent programmers, but I am one of them, and it's a
[barely] living language used in a production environment. I'm not
proud of this, mind you ... :-)
$result = myfunc($arg, $arg2) @ $host;
This implies that @= is a pretty useless op, but maybe if tasks are
objects it's not so bad.
my Task dostuff = qo( myfunc 0 ); # function, priority
$dostuff @= $otherhost;
$dostuff.start;
This is admittedly a stretch.
-
Perhaps $ could be catenation as well as scalar reference?
Discrete scalars with or without intervening unescaped whitespace are
concatenated. '$' is used to make explicit the treatment of any
subexpression as a scalar.
$a = $b $" " $c;
$a = $b$c; # Tres DWIM, sir. And the shell programmers will get it.
$a = $b $ f(g($x));
@a = @b ^$ @c;
@a $= @b; # @a = @a $ @b, aka @a.push(@b);
$a $= $b; # $a = $a $ $b, or $a$b
> <$>
> <@>
> <%>
>
> would do something, too, because they look so pretty. :-D
>
Would you like breaktyping with that, sir?
=Austin
__
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
Re: Perl6 Operator List
On Friday, October 25, 2002, at 02:38 PM, Austin Hastings wrote: In the manner of Accent, I'd like @ reserved as the RPC operator. The Role Playing Character operator? Hmm, that has possibilities. What would this statement do? +--+ |..@...| |d.| |..| +--+ MikeL
Re: Perl6 Operator List
On Fri, Oct 25, 2002 at 01:00:59PM -0700, Larry Wall wrote: > On Fri, 25 Oct 2002, Michael Lazzaro wrote: > : binary operators: > : + -*/%** x~<< >> > : += -= *= /= %= **= x= ~= <<= >>= > > We could distinguish an xx operator (along with xx=) that does list > replication, rather than requiring parens around the left argument. I initially thought that ^x would be a good way of expressing this, but now I'm not so sure. A hyper operator does some sort of vector version of an operator based on the dimensionality of the left argument. But for x vs xx the left argument has no change in dimensionality, and even swapping things round doesn't help, as the replication count is scalar. Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl6 Operator List
From: "Larry Wall" <[EMAIL PROTECTED]> > : ? - force to bool context > : ! - force to bool context, negate > : + - force to numeric context > : - - force to numeric context, negate > : ~ - force to string context > > We're obviously missing the "force to string context, negate" operator. :-) Mr. Wall, may I be excused? My brain is full. Oh, I have to stick it out with everyone else? OK, um Just so I understand... why do we need "force to blah context" operators at all? Are we planning on doing a lot of context forcing? Isn't "a lot of context forcing" mean that the context concept isn't working? Nay, say I. I think context will continue to work. Which means... maybe we don't need all that shorthand. I've been quite happy with the scalar function in Perl5. What if we just had a few more functions like that for the occasional context forcing, or even just one "context" function that takes a context name as the first argument. -Miko uh oh, I just forced myself into numeric context and negated myself
Perl6 Operator List, Take 2
Here's try #2. Things that are not true operators or have other
caveats are marked, where known. LMKA.
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
+ - force to numeric context
- - force to numeric context, negate
~ - force to string context
. - method call on current topic
++ - preincrement
-- - predecrement
unary (postfix) operators:
++ - postincrement
-- - postdecrement
other postfix operators:
() - [when operator is expected]
[] - array access
{} - hash access
hyperoperators:
^ - as prefix to any unary/binary operator, "vectorizes" the
operator
binary operators:
+ -*/%** xxx ~
+= -= *= /= %= **= x= xx= ~=
<><= >= == != <=>
lt gt le ge eq ne cmp
&&||!!//- boolean operations
&&= ||= !!= //=
and orxor err
.&.|.!<< >> - bitwise operations
.&= .|= .!= <<= >>= - (or is that .<<, .>>, etc?)
& | ! - superpositional
all any one (none?)
~~ !~ - smartmatch and/or perl5 '=~' (?)
like unlike- (tentative names)
=> - pair creator
, - list creator
; - "lesser comma", list-of-lists creator
: - adverbial
. - method call
.. - range
... - (maybe range exclusive of endpoint, or maybe ..Inf)
= - assignment
:= - binding
::= - binding, but more so
trinary operators:
?? ::
parens, misc, and quotelike operators:
()
[] - [when term is expected]
{} - [when term is expected]
m// - shorthand for something else
s/// - shorthand for something else
tr///- shorthand for something else
'...' "..." `...` /.../ << >>
q qq qx qr qw
(heredocs) - [exact format unknown]
named unary (prefix) operators, terms, and other assorted hangers-on,
identified when possible:
-X - [op] filetest operators
temp- [op]
let - [op]
ref - [op]
defined - [op]
undef - [op]
undef - [term]
exists - [op]
delete - [op]
${ }- [deref] dereference scalarref
@{ }- [deref] dereference arrayref
%{ }- [deref] dereference hashref
&{ }- [deref] dereference coderef
... - [term] yada**3
Inf - [term]
NaN - [term]
is - [declar] var properties
but - [op?]val properties
-> - [declar] like 'sub'
hash- [declar] force hash context
methods and listops, uncategorized:
my our
map grep
sqrtlogsin cos tan
lc lcfirstuc ucfirst
int ordoct hex (bin?)
MikeL
Re: [OT] Power of Lisp macros?
On 25 Oct 2002, Marco Baringer wrote: : Luke Palmer <[EMAIL PROTECTED]> writes: : >But think of what macros in general provide: : > : > * Multi-platform compatability : > * Easier maintenance : * Creating/Embedding custom languages. aka - adapting the : langauge to your problem domain. : : common lisp macros allow you to locally extend the vocabulary of : common lisp in the same way engineers have locally (ie within the : engineering domain) extended english with new syntax/semantics to deal : with engineering problems. Only up to a point. Engineers sometimes muck with the language at the parse level, before the macro processor even has a shot at it. Lisp gets away with this only because its syntax unambiguously distinguishes verbs from nouns. But engineers are always messing around with their word categories. How about using a verb as a predicate adjective: All systems are go for launch. That's probably derived from something more like: All systems are "go" for launch. So a macro system that takes preparsed text is still not powerful enough. It could be argued that you just pass in a string of data tokens without parentheses to get any arbitrary language, but you still can't parse a sentence like: All systems are ( for launch. : macros are functions which are run when the source code is read : (parsed). the argument to a macro is source code (expressed as a data : structure and not simple text) and the return value is source code : (not text). this is a fundamental difference between C's : text-processing macros, without this macros lose most of their power : and become too hard to write to be used. Yes, source filters have the same problem. : - what macros are really good at is embedding mini-languages and : creating new idioms, this often goes with, but is not nessecarily : related to, reducing lines of code. example: CLOS/MOP (common lisp : object system/meta object protocol) are implemented as macros on top : of non-OO lisp (this statement maybe be a lie if you go deep enough : into the specifics of some implementations). Support for mini-languages is a major design goal for Perl 6. : - the power of lisp's macros is that they allow you to perform : arbitrary code transformations by working with code as if it was : data. at one point there was discussion about having perl subs with : "auto-args" (i forget where i read about this) where by the : arguments to the sub where determined by parsing the body of the sub : itself and looking at what variables where used, this is a trivial : macro in lisp. adding this to perl5 required a source filter which : took forever to write and was never used because is was never : reliable enough (this may say more about my capabilities as a : programmer than about perl5 source filters). But we want auto-args by marking the args themselves, not by mentioning a special macro name in front. So support has to be built-in. : - everything you can do with macros you can do without, since macros : always get expaned (translated) into "regular" common lisp : code. however, sometimes (like with CPS) hand writing the output is : prohibitly difficult. Sure. : - some people consider macros to actually reduce maintainability since : they perform arbitrary code manipulations, so you have _no_ idea of : what is going on if you don't know what the macro does. macros which : introduce new symbols are especially vulnerable to this. Well, same is true of any built-in. But macros get really nasty if they cause your program to throw error messages that are impossible to understand. : - any sufficently powerful tool can be used to shot yourself in the : foot (or blow off your head). i doubt this java-esque argument : (let's "protect" the programmers from themselves) has any weight : with perl programmers, but it's something i've heard more than once. Actually, it has a lot of weight, but not in the sense of preventing Perl programmers from using the powerful features. What we really try to do is to avoid requiring the novice programmer to know abou the powerful features before they need to know them. If a Perl programmer has to do grammar munging in order to write a CGI script, something is terribly wrong. They might use a module that does grammar munging on their behalf, but that's different, because presumably someone else with more expertise wrote that module. So grammar munging is there to make life easier for today's source filter writers, not to make life harder for the novice. : - writing realiable/robust source filters is hard (do able, but hard, : even with The Damien's Filter::Simple). writing grammars is better, : but still hard, and more importantly, both require a rdically : different mind set from "regular" programming. the ease of writing : lisp macros is largely due to the fact that lisp has no syntax : (almost), and that
Perl6 Operator List
Since it's been a full month since the start of the monster "operator
precedence" thread, here's what I've been able to gather as the
revised, new-and-improved list of Perl6 operators, IF we did all the
xor/cat/regex-related changes as discussed as of this moment. ;-) I
think this list is accurate and complete so far, LMK?
unary (prefix) operators:
\ - reference to
$ - dereference scalarref
@ - dereference arrayref
% - dereference hashref
& - dereference coderef
* - list flattening
? - force to bool context
! - force to bool context, negate
+ - force to numeric context
- - force to numeric context, negate
~ - force to string context
. - method call on current topic
-X - filetest operators
++ - preincrement
-- - predecrement
unary (postfix) operators:
++ - postincrement
-- - postdecrement
other postfix operators:
[] - array access
{} - hash access
hyperoperators:
^ - as prefix to any unary/binary operator, "vectorizes" the
operator
binary operators:
+ -*/%** x~<< >>
+= -= *= /= %= **= x= ~= <<= >>=
<><= => == != <=>
lt gt le ge eq ne cmp
&&||!!//- boolean operations
&&= ||= !!= //=
and orxor
.&.|.! - bitwise operations
.&= .|= .!=
& | ! - superpositional
all any one (none?)
~~ !~ - smartmatch and/or perl5 '=~' (?)
like unlike
=> - pair creator
, - list creator
; - "lesser comma", list-of-lists creator
: - adverbial
. - method call
.= - (?)
-> - like 'sub'
.. - range
... - yada**3
= - assignment
:= - binding
::= - binding, but more so
is
but
trinary operators:
?? ::
parens, misc, and quotelike operators:
()
m//
s/// - still around, but maybe shorthand for something else
tr///
'...' "..." `...` /.../
q qq qx qr qw
(heredocs) - (exact format unknown)
named unary (prefix) operators:
my our temp
not ref definedundef
length exists delete
sqrtlogsin cos tan
lc lcfirstuc ucfirst
int ordoct hex (bin?)
(...etc...)
MikeL
Re: [OT] Power of Lisp macros?
Luke Palmer <[EMAIL PROTECTED]> writes: > If you define "powerful" as "can do more things," then of course not. > Lisp is implemented in C, and C's macros are certainly not essential [aside: most "major" common lisp implementations (cmucl, sbcl, openmcl, mcl, allegro and lispworks) are all native compilers implemented in lisp (and some assembler for boot straping). CLISP is the only "major" implementation whose core is in fact implemented in a C dialect (for speed reasons (the virtual machine is really slow))] >But think of what macros in general provide: > > * Multi-platform compatability > * Easier maintenance * Creating/Embedding custom languages. aka - adapting the langauge to your problem domain. common lisp macros allow you to locally extend the vocabulary of common lisp in the same way engineers have locally (ie within the engineering domain) extended english with new syntax/semantics to deal with engineering problems. macros are functions which are run when the source code is read (parsed). the argument to a macro is source code (expressed as a data structure and not simple text) and the return value is source code (not text). this is a fundamental difference between C's text-processing macros, without this macros lose most of their power and become too hard to write to be used. common lisp's LOOP is a great example of what you can do with macros (and the best iteration construct around). see http://www.lispworks.com/reference/HyperSpec/Body/06_a.htm for the spec and http://www.ai.sri.com/~pkarp/loop.html for a tutorial. random points and counter-points: - what macros are really good at is embedding mini-languages and creating new idioms, this often goes with, but is not nessecarily related to, reducing lines of code. example: CLOS/MOP (common lisp object system/meta object protocol) are implemented as macros on top of non-OO lisp (this statement maybe be a lie if you go deep enough into the specifics of some implementations). - the power of lisp's macros is that they allow you to perform arbitrary code transformations by working with code as if it was data. at one point there was discussion about having perl subs with "auto-args" (i forget where i read about this) where by the arguments to the sub where determined by parsing the body of the sub itself and looking at what variables where used, this is a trivial macro in lisp. adding this to perl5 required a source filter which took forever to write and was never used because is was never reliable enough (this may say more about my capabilities as a programmer than about perl5 source filters). - everything you can do with macros you can do without, since macros always get expaned (translated) into "regular" common lisp code. however, sometimes (like with CPS) hand writing the output is prohibitly difficult. - some people consider macros to actually reduce maintainability since they perform arbitrary code manipulations, so you have _no_ idea of what is going on if you don't know what the macro does. macros which introduce new symbols are especially vulnerable to this. - any sufficently powerful tool can be used to shot yourself in the foot (or blow off your head). i doubt this java-esque argument (let's "protect" the programmers from themselves) has any weight with perl programmers, but it's something i've heard more than once. - writing realiable/robust source filters is hard (do able, but hard, even with The Damien's Filter::Simple). writing grammars is better, but still hard, and more importantly, both require a rdically different mind set from "regular" programming. the ease of writing lisp macros is largely due to the fact that lisp has no syntax (almost), and that lisp's syntax is programmable. perl6 will have the second and can't do much about the first (sort of goes against "different things should look different"). just another lurker's rant... -- -Marco Ring the bells that still can ring. Forget your perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
Re: [OT] Power of Lisp macros?
Speaking about macros, I renember reading somewhere something about Scheme hygenic macros, but i didn't really understood it. Do they solve the maintenance problems of Lisp macros? Would they be applicable to perl? Thanks for any tips, -angel
Re: [OT] Power of Lisp macros?
Angel Faus <[EMAIL PROTECTED]> writes: > Speaking about macros, I renember reading somewhere something about > Scheme hygenic macros, but i didn't really understood it. > > Do they solve the maintenance problems of Lisp macros? Would they be > applicable to perl? Scheme hygenic macros do a lot of the bookkeeping for you, so you don't have to muck about with gensym and are generally safe. The problem is (judging by what the Common Lisp types say, I don't have experience in this area myself), sometimes you need to do things that would be considered 'dangerous' and, unless the scheme implementation you're working with has some none standard extensions giving a scheme like C, you're up the well known creek without a paddle. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Perl6 Operator List
On Fri, 25 Oct 2002, Michael Lazzaro wrote:
: Since it's been a full month since the start of the monster "operator
: precedence" thread, here's what I've been able to gather as the
: revised, new-and-improved list of Perl6 operators, IF we did all the
: xor/cat/regex-related changes as discussed as of this moment. ;-) I
: think this list is accurate and complete so far, LMK?
Getting there.
: $ - dereference scalarref
: @ - dereference arrayref
: % - dereference hashref
: & - dereference coderef
These are not currently operators, just as they aren't really operators
in Perl 5. If you say
$( foo() )
@( bar() )
you don't get a dereference as it currently stands. You'd have to use
${ foo() }
@{ bar() }
But maybe that's something we should talk about.
: * - list flattening
: ? - force to bool context
: ! - force to bool context, negate
: + - force to numeric context
: - - force to numeric context, negate
: ~ - force to string context
We're obviously missing the "force to string context, negate" operator. :-)
: -X - filetest operators
Which are actually considered a variant of named unaries, if I recall...
: other postfix operators:
:
: [] - array access
: {} - hash access
And () when an operator is expected rather than a term.
: hyperoperators:
:
: ^ - as prefix to any unary/binary operator, "vectorizes" the
: operator
One is tempted to make it "v" instead of "^", but then we couldn't have
any actual operators starting with "v".
: binary operators:
: + -*/%** x~<< >>
: += -= *= /= %= **= x= ~= <<= >>=
We could distinguish an xx operator (along with xx=) that does list
replication, rather than requiring parens around the left argument.
: <><= => == != <=>
: lt gt le ge eq ne cmp
Er, that would be >=, not =>.
: &&||!!//- boolean operations
: &&= ||= !!= //=
: and orxor
:
: .&.|.! - bitwise operations
: .&= .|= .!=
Now I'm wondering whether these should be split into:
+&+|+! - bitwise operations on int
+&= +|= +!=
~&~|~! - bitwise operations on str
~&= ~|= ~!=
Except the . looks more like a bit. And the current str/int rules don't
cause that much problem. One could perhaps force it this way:
+$x .| +$y
~$x .| ~$y
And it's more like the semantics people are used to, for some
definition of "people", and some definition of "used to". I dunno...
Maybe it's really
.&.|.! - bitwise operations on int
.&= .|= .!=
.and.or.xor - bitwise operations on str
.and= .or= .xor=
except that "and", "or" and "xor" aren't string ops in real life...
Could go with
.a.o.x - bitwise operations on str
.a= .o= .x=
Or we could leave .& et al. as the unmarked form, and just mark the
string-wise version, thus falling further into the Icon trap:
.~&.~|.~! - bitwise operations on str
.~&= .~|= .~!=
Then we could allow
@a ^.~|= @b;# hyper bitwise string or-equals
but only with a special rule in the grammar that makes the comment
mandatory. :-)
: & | ! - superpositional
: all any one (none?)
I think a good case can be made for *not* defining the corresponding
super assignment operators: &=, |=, and umm...I guess it would have
to be !=, er...
: ~~ !~ - smartmatch and/or perl5 '=~' (?)
: like unlike
Or something like/unlike that...
: .= - (?)
Not sure I believe in this one as method call because it confuses the
variable with the value. Besides, somebody's gonna expect it to mean
the same as .!($a .! $b), though that would be .== in fact, I suppose.
: -> - like 'sub'
Not really an operator. But if you count this you also have to count
the optional "hash" on the front of "hash { foo() }", where it's not
clear whether the {} is a hash or a sub.
: .. - range
: ... - yada**3
Mmm, not really. yada xx 3 is a term, not an operator. As an
operator, ... is likely to have the Ruby interpretation of omitting
the endpoint (unless we make it mean ..Inf or some such).
: is
Not really a general operator. Basically only availabe on declarators.
: parens, misc, and quotelike operators:
:
: ()
Plus [] and {} when a term is expected!
: m//
: s/// - still around, but maybe shorthand for something else
: tr///
Most special quote forms are likely to be shorthand for something else...
: '...' "..." `...` /.../
:q qq qx qr qw
I'd still love to the double angles for a qw synonym.
: (heredocs) - (exact format unknow
Re: Perl6 Operator List
On Fri, Oct 25, 2002 at 11:27:54AM -0700, Michael Lazzaro wrote: > &&||!!//- boolean operations > &&= ||= !!= //= > and orxor Hmmm, given Larry's comments just now about about similar things not looking similar, I really think | vs ! is a mistake. From a distance, (14 inches in my case), they really do look almost indistinguable. (IMHO) -- "Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony." Dennis - Monty Python and the Holy Grail.
Re: Perl6 Operator List
In the interest of email sanity, please make sure that neither Larry's
preferred : nor the more-common > are valid at statement start...
I'd hate to stumble across
: -> - like 'sub' ;
And run the risk of it compiling both as a quote and not.
=Austin
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, 25 Oct 2002, Michael Lazzaro wrote:
> : Since it's been a full month since the start of the monster
> "operator
> : precedence" thread, here's what I've been able to gather as the
> : revised, new-and-improved list of Perl6 operators, IF we did all
> the
> : xor/cat/regex-related changes as discussed as of this moment. ;-)
> I
> : think this list is accurate and complete so far, LMK?
>
> Getting there.
>
> : $ - dereference scalarref
> : @ - dereference arrayref
> : % - dereference hashref
> : & - dereference coderef
>
> These are not currently operators, just as they aren't really
> operators
> in Perl 5. If you say
>
> $( foo() )
> @( bar() )
>
> you don't get a dereference as it currently stands. You'd have to
> use
>
> ${ foo() }
> @{ bar() }
>
> But maybe that's something we should talk about.
>
> : * - list flattening
> : ? - force to bool context
> : ! - force to bool context, negate
> : + - force to numeric context
> : - - force to numeric context, negate
> : ~ - force to string context
>
> We're obviously missing the "force to string context, negate"
> operator. :-)
>
> : -X - filetest operators
>
> Which are actually considered a variant of named unaries, if I
> recall...
>
> : other postfix operators:
> :
> : [] - array access
> : {} - hash access
>
> And () when an operator is expected rather than a term.
>
> : hyperoperators:
> :
> : ^ - as prefix to any unary/binary operator, "vectorizes" the
>
> : operator
>
> One is tempted to make it "v" instead of "^", but then we couldn't
> have
> any actual operators starting with "v".
>
> : binary operators:
> : + -*/%** x~<< >>
> : += -= *= /= %= **= x= ~= <<= >>=
>
> We could distinguish an xx operator (along with xx=) that does list
> replication, rather than requiring parens around the left argument.
>
> : <><= => == != <=>
> : lt gt le ge eq ne cmp
>
> Er, that would be >=, not =>.
>
> : &&||!!//- boolean operations
> : &&= ||= !!= //=
> : and orxor
> :
> : .&.|.! - bitwise operations
> : .&= .|= .!=
>
> Now I'm wondering whether these should be split into:
>
> +&+|+! - bitwise operations on int
> +&= +|= +!=
>
> ~&~|~! - bitwise operations on str
> ~&= ~|= ~!=
>
> Except the . looks more like a bit. And the current str/int rules
> don't
> cause that much problem. One could perhaps force it this way:
>
> +$x .| +$y
> ~$x .| ~$y
>
> And it's more like the semantics people are used to, for some
> definition of "people", and some definition of "used to". I dunno...
>
> Maybe it's really
>
> .&.|.! - bitwise operations on int
> .&= .|= .!=
>
> .and.or.xor - bitwise operations on str
> .and= .or= .xor=
>
> except that "and", "or" and "xor" aren't string ops in real life...
>
> Could go with
>
> .a.o.x - bitwise operations on str
> .a= .o= .x=
>
> Or we could leave .& et al. as the unmarked form, and just mark the
> string-wise version, thus falling further into the Icon trap:
>
> .~&.~|.~! - bitwise operations on str
> .~&= .~|= .~!=
>
> Then we could allow
>
> @a ^.~|= @b; # hyper bitwise string or-equals
>
> but only with a special rule in the grammar that makes the comment
> mandatory. :-)
>
> : & | ! - superpositional
> : all any one (none?)
>
> I think a good case can be made for *not* defining the corresponding
> super assignment operators: &=, |=, and umm...I guess it would have
> to be !=, er...
>
> : ~~ !~ - smartmatch and/or perl5 '=~' (?)
> : like unlike
>
> Or something like/unlike that...
>
> : .= - (?)
>
> Not sure I believe in this one as method call because it confuses the
> variable with the value. Besides, somebody's gonna expect it to mean
> the same as .!($a .! $b), though that would be .== in fact, I
> suppose.
>
> : -> - like 'sub'
>
> Not really an operator. But if you count this you also have to count
> the optional "hash" on the front of "hash { foo() }", where it's not
> clear whether the {} is a hash or a sub.
>
> : .. - range
> : ... - yada**3
>
> Mmm, not really. yada xx 3 is a term, not an operator. As an
> operator, ... is likely to have the Ruby in
Re: Perl6 Operator List
On Friday, October 25, 2002, at 01:00 PM, Larry Wall wrote:
Not clear how many of these are just universal or near-universal
methods.
Which would make some of them list-op variants, if we follow Perl 5
rules...
What's the Official Perl difference between a named unary op and a
one-arg universal method? E.g. why are "temp" and "let" both ops but
"my, our, hash" are not?
(I also missed 'err', not sure on that one either.)
: '...' "..." `...` /.../
:q qq qx qr qw
I'd still love to the double angles for a qw synonym.
'kay. As an aside, I've always itched for a qlike op that was
matrix-like, e.g.
my Pet @list = qm{
fido dog collie
fluffy cat siamese
};
But that's not quite working, because you usually need to pass the
attribute names in order for it to be meaningful. Maybe something
adverbial like:
my Pet @list = qm{
fido dog collie
fluffy cat siamese
} : << name type breed >>;
or even
my Pet @list = qm : << name type breed >> {
fido dog collie
fluffy cat siamese
};
That's still a lot easier to type than some of the alternatives I've
had to do for larger structures.
And I always wished
$=
@=
%=
<$>
<@>
<%>
would do something, too, because they look so pretty. :-D
Anyway, I'll revise and repost the list.
MikeL
Re: Perl6 Operator List, Take 2
Excellent (and valuble) work Michael. Thank-you. My turn for a few comments: & | ! - superpositional all any one (none?) Although there certainly are good uses for a C superpositional: push @list, $newval if $newval eq none(@list); print "In range\n" if 1 > none(@values) > 10; they can always be achieved with C instead: push @list, $newval if $newval ne all(@list); print "In range\n" if 1 < all(@values) < 10; Then there's the problem of finding a suitable infix operator. Overall, I think adding a C might be multiplying entities unnecessarily. ~~ !~ - smartmatch and/or perl5 '=~' (?) like unlike- (tentative names) Do we *really* need the alphabetic synonyms here? Me no like! ; - "lesser comma", list-of-lists creator Actually, I'd describe this as "greater" comma. Sure, it has lower precedence, but that means its scope of effect is greater. Maybe we need another name entirely for it. "Sequence separator" perhaps? ... - (maybe range exclusive of endpoint, or maybe ..Inf) I'd much prefer the latter. But note that that semantics changes it from an binary to a postfix unary operator. trinary operators: Nit pick: s/s// '...' "..." `...` /.../ << >> q qq qx qr qw s/qr/rx/ but - [op?]val properties Yes, it's an operator. Damian
Re: Perl6 Operator List
On Fri, Oct 25, 2002 at 06:28:28PM -0400, Miko O'Sullivan wrote: > From: "Larry Wall" <[EMAIL PROTECTED]> > > : ? - force to bool context > > : ! - force to bool context, negate > > : + - force to numeric context > > : - - force to numeric context, negate > > : ~ - force to string context > > > > We're obviously missing the "force to string context, negate" operator. > :-) > > Mr. Wall, may I be excused? My brain is full. Oh, I have to stick it out > with everyone else? OK, um > > Just so I understand... why do we need "force to blah context" operators at > all? Are we planning on doing a lot of context forcing? Isn't "a lot of > context forcing" mean that the context concept isn't working? Nay, say I. I > think context will continue to work. Which means... maybe we don't need all > that shorthand. I've been quite happy with the scalar function in Perl5. > What if we just had a few more functions like that for the occasional > context forcing, or even just one "context" function that takes a context > name as the first argument. The negate operators we have already: perl -e '$x = "0"; print !$x' perl -e '$x = "10.000"; print -$x' The others save use doing: perl -e '$x = "2"; print !!$x' perl -e '$x = "10.000"; print -(-$x)' perl -e 'print "" . localtime' OK, Perl 5 doesn't have all these contexts, and these may be not the most compelling of examples, but you get the idea. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: Perl6 Operator List
Larry Wall:
# We're obviously missing the "force to string context, negate"
# operator. :-)
Which would create a superposition of all strings besides the given one,
right? (Oh crap, I think I gave Damian an idea... :^) )
--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)
