Re: scalar subscripting
Larry Wall [EMAIL PROTECTED] writes:
No, just currently wrong. :-) I changed my mind about it in A12,
partly on the assumption that $object.attr would actually be more
common than $file.ext,
Speaking of which, what's the cleanest way to interpolate filenames
with a fixed extension now? ${file}.ext ? $file\.ext ?
Also, I guess that if $foo.bar is taken as a method call, then
$file.$ext is going to be trouble also, is that right? An error?
Or will it treat the value of $ext as the name of a method, or maybe
look for a method starting with $ ?
but also because a bogus method call is likely to be noticed sooner
than bad output data, and because noticing goofs sooner rather than
later is often construed to be a good thing. (Though this attitude
can be taken to extremes--see static typing.)
Quite. Perl6 is last I checked moving in the direction of giving a
more informative error message later, rather than a syntax error
sooner, which IMO is a good thing. Not that this is a case of that,
but it demonstrates that noticing sooner isn't necessarily always the
best way to go. (Static typing is certainly an annoying limitation,
and I'm sure there are other examples.)
However, while it's a shame not to be able to interpolate $file.ext,
I can certainly see the argument for $object.method being a common
case, one that I imagine I'll use quite often.
Of course, this leaves open the question of whether there are any
fairly common filename extensions that happen to be spelled the same
as a method on Perl6's string class, that might ought to have a
warning generated... Are there any three-letter methods on the
string class? (Maybe there shouldn't be, in the core language...)
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: push with lazy lists
On Wed, Jul 14, 2004 at 07:40:33AM +0200, Ph. Marek wrote: To repeat Dave and myself - if @x = 1 .. Inf; then rand(@x) should be Inf, and so print $x[rand(@x)]; should give Inf, as the infinite element of @x is Inf. Does it even make sense to take the Infiniteth element of an array?...after all, array indices are integers, and Inf is not an integer. If we allow it, should we also allow people to take the NaNth element of an array? How about the 'foobar'th element? What happens if I take the Infiniteth element of a finite list? I think I would prefer if using Inf as an array index resulted in a trappable error. --Dks
Re: push with lazy lists
On Wednesday 14 July 2004 08:39, David Storrs wrote:
To repeat Dave and myself - if
@x = 1 .. Inf;
then
rand(@x)
should be Inf, and so
print $x[rand(@x)];
should give Inf, as the infinite element of @x is Inf.
Please take my words as my understanding, ie. with no connection to mathmatics
or number theory or whatever. I'll just say what I believe is practical.
Does it even make sense to take the Infiniteth element of an
array?...after all, array indices are integers, and Inf is not an
integer.
I'd believe that infinity can be integer, ie. has no numbers after the comma;
and infinity is in the natural numbers (?), which are a subset of integers.
If we allow it, should we also allow people to take the
NaNth element of an array?
NaN is already a number (internal representation), so it doesn't get
converted.
As there is no NaNth element, it would return either undef (as in (0,1,2)[8] )
or an exception, as it is no numeric index.
How about the 'foobar'th element?
'foobar' is converted to a number, so the 0th element is taken.
What happens if I take the Infiniteth element of a finite list?
undef, as in 8th element of (1,2,3).
I think I would prefer if using Inf as an array index resulted in a
trappable error.
That's a possibility. It could raise an exception as with NaN.
To summarize:
@x= ('a', 5 .. Inf, 'b');
$x[0] is 'a'
$x['foo'] is 'a'
$x[-1] is 'b'
$x[2] is 6
$x[2002] is 2006
I believe these are clear and understandable.
$x[Inf] is 'b'
$x[-2] is Inf
$x[-10] is Inf
$x[-2] is Inf
These would result in simply interpolating the indizes.
$x[NaN] gets an exception
because NaN is already of numeric type (as in $x=tan(pi/2)), but can not be
associated to any index.
So I'd propose to solve this argument based on can be used as an index.
An infinite array (and even an finite) can be asked for an infinite index -
which has an value for infinite arrays.
This is just so there's no special coding for some indizes necessary - imagine
a lookup like
@x = (10,9,9,8,8,8,6,3,2,1,1,1,1,0);
$number = scalar(STDIN)+0;
print $x[10/$number];
which would work for *any* input, and just give undef for most of them.
Regards,
Phil
BTW: is it possible to define a look-up table as in
@x = (1, 2, 3, 4, 5, Inf .. Inf)
to get everything from [5] on to be Inf?
Re: Phalanx: What if full coverage isn't possible?
On Sun, Jul 11, 2004 at 10:09:38PM +0200, James Mastros wrote: All unreachable code is either people misusing the term unreachable, a bug in Devel::Cover, or dead code that should be removed. Here's a puzzle, then. I just ran into a similar problem in POE::Driver::SysRW. For portability I have a couple lines similar to $! = 0 if $! == EAGAIN or $! == EWOULDBLOCK; EAGAIN and EWOULDBLOCK are identical on most systems. In fact, one is usually defined in terms of the other. They differ on a few platforms, however, and it's important to check both. The expression boils down to this on my test system: A B dec $! == 35 or $! == 35 0 0 0 (green, tested) 0 1 0 (red, impossible to test) 1 X 1 (green, tested) It may be possible to notice that you're running under Devel::Cover and run the look under every rock tests only in that case. But if it's your goal to cover everything and get that 100% there, then you need to try harder before declaring something unreachable. Note that this shouldn't be construed as saying that you should create insane tests, just to get 100% coverage. My point is almost the exact oppisate: that it's not reasonable to try for 100% conditional coverage. While I'd like 100% coverage, I've decided to live with 98.3% because of these untestable (at least on my machine) conditions. It's nice to have the red flags pointing at some silly code, and maybe an improvement will come later. I don't advocate that the improvement appear in Perl or Devel::Cover. On the contrary, logic errors like this should be pointed out to make better code. -- Rocco Caputo - http://poe.perl.org/
Re: Perl script to .so file
RaghavendraK 70574 writes: Hi, Am a hardcore C++ guy and don;t know much abt the Perl. But one of my friend has proved that the fastest way to RAD is Perl. I need to know if we can convert a Perl script to a dynamic link library under unix only. I don't know what RAD is, but I know you're asking the wrong place. Send your question to [EMAIL PROTECTED] This is a list for discussing the design and implementation of the Parrot virtual machine (parrotcode.org). Luke
Re: = brother
Luke Palmer [EMAIL PROTECTED] writes:
strange, but :shift«value» looks a little more noisy to me than
shift = 'value',
For some reason, it looks that way to me, too.
Me three.
Perhaps:
:shift« value »
I *think* that's better...
To me, that's even worse. My brain sees spaces within the value, even
though I technically know that the operator throws them out.
To me, :shift value looks somewhat better (if it means the same
thing...), but I still like the old = syntax even more, perhaps
because I'm accustomed to it; assuming it still DWIM it's what I'll
probably continue to use, personally.
%hash = ( :key«value»
:key2«value»
:key3
key4 = 'value',
'key5','value',
«key6 value key7 value» )
Did I make mistakes here?
I don't think so.
In terms of maintainability, I'd rather see any given chunk of code
pick a syntax and stick with it for at least long enough to complete
one entire assignment, for crying out loud. (No, I don't think the
language should enforce that; I just think it would be better practice
in almost all cases.)
Though that probably isn't what the OP was asking.
:foo« bar »
:ziph« zam »
:split« spork »
Although I'll admit that looks a little strange.
A little. It's better than not lining up, IMO.
ah.. sorry about messing up all question in one post, but I have
one more:) if key could be of any type, not only strings, than
what will be with numeric keys? would they be converted to strings
automatically?
It's Perl: what's the difference?
There are probably subtle differences hiding in the pathological
corner cases, but they are probably not important, IMO. The more
important reason not to flatten hashkeys into strings is so that
references and objects can be used as hash keys without loss of
information.
Say you have an object that numerifies to 42 but stringifies to
The answer to the ultimate question of life, the universe, and everything.
Now it suddenly matters whether hash keys get autostringified or not.
FWIW, if they did I could have lived with that just fine. (You can
always keep a copy of the reference in the value, along with whatever
else you're storing there, in an anonymous hash or array; this is not
one of the limitations of Perl5 that bugs me.) But it will be
important to know one way or the other.
If the = stringifies where another syntax does not, that will IMO not
be a bad thing. MTOWTDI. But I'm not going to get excited about it
one way or the other, assuming it's well-documented, which I'm sure it
will be.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
pie-thon converter
I'm putting the piethon conversion program up for folks to look at. Far from done, but tonight (hopefully) will be productive. http://www.sidhe.org/~dan/piethon/translator.pl -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
semi-stack code
Okay, here's a really, really evil idea. (And yes, bluntly, it's triggered by the pie-thon bytecode translator's needs) I need a stack, and one that's faster than our current stack which, while snappy for what it does, is still burdened by generality. I also need a stack that's generally not very big. So... The fake stack. The idea is this. PMC registers 18-29 are used as a 12 element stack. PMC register 31 is used as a stack overflow array. Integer register I31 is used as the stack depth register. We add in the ops: fakepush [Px|Ix] This pushes the contents of Px onto the top of the stack, or pushes the stack down by Ix entries. Note that the Ix form does *not* set these new slots to anything! They're left as-is, which can be an issue for the GC. fakepop [ix] This pops Ix entries off the stack, default of one. Note that there's no need for any destination--if you're popping the TOS into a register then just do a set first. iset Px, Iy This does a set of register Px to PMC register #Y. iset Ix, Py This sets the PMC register #X to Py. The last two are pretty standard indirect register access. If someone wants to propose a more generic syntax for it we might want to generalize on, that's fine--do it *after* OSCON, thanks. :) The reason for the odd register count and register number usage is twofold. First, it leaves some of the top-half registers free for other things. Second, the registers used will be 8-byte aligned and a multiple of 8 bytes on systems with 4-byte pointers. Not likely a huge deal, but it may shave a cycle off here or there, and it does mean we have a few spare registers in the upper half. Note that this stack does *not* need rot, swap, dup, or other funky 'move the things around' ops, since that can already be done. For example: dup: fakepush 1 dup2 (the top two entries are duplicated) fakepush 2 swap: exchange P18, P19 rot3: exchange P18, P20 exchange P19, P20 And it means that stack based ops turn to: add (pop the top two entries, add them, and push the result): new P17 add P17, P18, P19 fakepop set P18, P17 and something like add-in-place (new TOS = oldTOS+1 + oldTOS): add P18, P19, P18 fakepop It seems sensible, which of course worries me, as do so many things I think are sensible, but I think we should do this--it'll be useful for other languages that like being stack based. (If I'd any sense, I'd have done this ages ago as it'd have made the forth implementation nicer) We should get x86 JIT code for the new ops, since I expect they'll be used rather a lot. Full-fledged tracking of used stack slots within basic blocks with register coloring and cross-block register exchanges would, of course, make a lot of sense and be faster, but I'm a bit pressed for time here, so we'll make do. Only the fake push and pop ops are at all odd, so I'll put those in experimental.ops for now. iset will go into set.ops, though if we decide that we want a more general indirect register access scheme we can see about renaming them. (We probably should put in an opname aliasing feature to the pir and pasm compilers, but we'll deal with that later, unless someone's feeling like a project) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: push with lazy lists
On Wednesday 14 July 2004 04:55 am, Ph. Marek wrote:
On Wednesday 14 July 2004 08:39, David Storrs wrote:
To repeat Dave and myself - if
@x = 1 .. Inf;
then
rand(@x)
should be Inf, and so
print $x[rand(@x)];
should give Inf, as the infinite element of @x is Inf.
Please take my words as my understanding, ie. with no connection to
mathmatics or number theory or whatever. I'll just say what I believe is
practical.
Does it even make sense to take the Infiniteth element of an
array?...after all, array indices are integers, and Inf is not an
integer.
I'd believe that infinity can be integer, ie. has no numbers after the
comma; and infinity is in the natural numbers (?), which are a subset of
integers.
Infinity is outside of the numbers. When we speak of infinity we mean not some
particular number which is greater than all the other ones, but rather some
variable which has escaped the bounds of the finite and the numbers.
[etc.]
To summarize:
@x= ('a', 5 .. Inf, 'b');
$x[0] is 'a'
$x['foo'] is 'a'
$x[-1] is 'b'
$x[2] is 6
$x[2002] is 2006
I believe these are clear and understandable.
$x[Inf] is 'b'
$x[-2] is Inf
$x[-10] is Inf
$x[-2] is Inf
These would result in simply interpolating the indizes.
Personally I think it's a fairly bad idea to be able to index an array on Inf;
we have $x[-1] and such already to get the right side of an array, and I
think it makes more sense, especially in light of the fact that you can
reasonably ask for $x[-2], but not $x[Inf-1]. And, you might want to think of
it in terms of behavior. Not because I say cop out and go with whatever has
the easiest implementation, but because if the mechanism for array
subscripting is anything but simple, nobody will ever know if they've got it
right.
I think I agree that the conceptually neatest way to look at fancy lazyish
arrays is by using iterators. An iterator should be able to support at least
one of: getting elements in sequence from left to right, getting elements
in sequence from the right to the left, and indexing straight into the middle
of things. push and pop work the obvious way based on this, and I suggest
that indexing should behave as though it's merely counting elements from
left or right by taking elements from the iterator, even if it skips
doing it for real for purposes of speed or other implementation fun.
So if we have @x = [1, 3, 5, 6 .. 9, 10 .. Inf, 42];
Then conceptually it's three (or maybe a little more) array-iterators on the
inside, and one smart meta-iterator that knows how to take elements from its
child iterators in order, and knows how to do the math to support indexing
when possible. As for the component iterators: [1, 3, 5] is like any regular
array, we know it can get its first, its last, or any one by index. And it
knows its length. Good. [6 .. 9], might be driven by a function that returns
{ $^index + 6 }. It knows how long it is, it can index in all three ways, and
it knows where it starts, which means we can convert an index on the outer
array into an index on this chunk. [10 .. Inf] is similar; again we can
generate it by a simple function, and come in from the right; but its
length is Inf, and if we ask it to iterate starting at the right, it should
return an endless stream of Inf. Similarly a lookup on any negative index
inside it should return Inf. 42 is just one number, so questions of indexing
it are moot, but its distance from the left is Inf. So, there's no way to
access the 42 by any positive index of @x, and no way to ever get it by
successive shift. Overall I suggest
(all code is sequential)
$a = shift @x; # $a = 1; @x = [3, 5, 6 .. 9, 10 .. Inf, 42]
shift @x; shift @x; # @x = [6 .. 9, 10 .. Inf, 42]
$a = $x[0]; # 6
$a = $x[1]; #7
$a = $x[5]; # 10
$a = $x[-1];#42
$a = $x[Inf]; # No thanks
$a = $x[-2];# Inf
$a = pop @x;# $a = 42; @x = [ 6 .. 9, 10 .. Inf ]
repeat { $a = pop @x; } until $a != Inf; # Heat death
--Andrew Rodland [EMAIL PROTECTED]
Re: scalar subscripting
On Sun, Jul 11, 2004 at 11:06:30PM -0400, Jonadab the Unsightly One wrote:
: Larry Wall [EMAIL PROTECTED] writes:
:
: No, just currently wrong. :-) I changed my mind about it in A12,
: partly on the assumption that $object.attr would actually be more
: common than $file.ext,
:
: Speaking of which, what's the cleanest way to interpolate filenames
: with a fixed extension now? ${file}.ext ? $file\.ext ?
Cleanliness is a relative concept, but I'd tend to go with the
backslash in this case.
Another alternative is $( $file ).ext. I'd tend to use that before
${file}.ext these days. Perhaps that's irrational--but it was hard
to get the special-case ${name} form to work right in the Perl 5
lexer, and that bugs me. If we're going to get rid of the autoquoting
of $hash{shift}, we likely ought to undo the autoquoting of ${shift}
as well, even if that gives heartburn to a certain number of shell
programmers.
: Also, I guess that if $foo.bar is taken as a method call, then
: $file.$ext is going to be trouble also, is that right? An error?
: Or will it treat the value of $ext as the name of a method, or maybe
: look for a method starting with $ ?
It will use the value of $ext as the name of the method. Alternately,
we could simply disallow indirect method names inside interpolations.
They're very rare, and you could always say $( $file.$ext ) in that case.
: but also because a bogus method call is likely to be noticed sooner
: than bad output data, and because noticing goofs sooner rather than
: later is often construed to be a good thing. (Though this attitude
: can be taken to extremes--see static typing.)
:
: Quite. Perl6 is last I checked moving in the direction of giving a
: more informative error message later, rather than a syntax error
: sooner, which IMO is a good thing. Not that this is a case of that,
: but it demonstrates that noticing sooner isn't necessarily always the
: best way to go. (Static typing is certainly an annoying limitation,
: and I'm sure there are other examples.)
One error message that would be of great benefit to novices is if we
could guess where the missing brace is based on indentation. (But not
*assuming* the missing brace, of course--this isn't Python... :-)
: However, while it's a shame not to be able to interpolate $file.ext,
: I can certainly see the argument for $object.method being a common
: case, one that I imagine I'll use quite often.
It's also a philosophical issue of making trying to make $object.method
look and behave exactly like a variable. This carries through to several
other design decisions, such as allowing temp $object.method.
: Of course, this leaves open the question of whether there are any
: fairly common filename extensions that happen to be spelled the same
: as a method on Perl6's string class, that might ought to have a
: warning generated... Are there any three-letter methods on the
: string class? (Maybe there shouldn't be, in the core language...)
Yes. We might also need to be careful about doing failover from
$foo.bar(1) to bar($foo,1). Otherwise any multimethod that allows a
string as the first argument could also be confused with an extension.
I suppose another approach is simply to declare that dot is always a
metacharacter in double quotes, and you have to use \. for a literal
dot, just as in regexen. That approach would let us interpolate
things like .foo without a variable on the left. That could cause
a great deal of cultural confusion in the short term, however.
On the other hand, that raises the issue of what this should match:
/$foo.bar/
and if we let people interpolate .bar into strings, then what will they
expect this to do:
/.bar/
Ouch. I'm thinking we allow $foo.bar in both strings and regexen, but
not .bar in either case. Gotta use $_.bar inside strings and regexen.
(Or $(.bar) would work too.) Possibly we even complain about /.bar/
and force them to write /. bar/.
Likewise, /$foo.$bar/ should probably also be forcibly disambiguated
to either /$( $foo.$bar )/ or /$foo . $bar/.
Larry
Re: scalar subscripting
On Wed, Jul 14, 2004 at 10:23:18AM -0700, Larry Wall wrote:
: Another alternative is $( $file ).ext. I'd tend to use that before
: ${file}.ext these days. Perhaps that's irrational--but it was hard
: to get the special-case ${name} form to work right in the Perl 5
: lexer, and that bugs me. If we're going to get rid of the autoquoting
: of $hash{shift}, we likely ought to undo the autoquoting of ${shift}
: as well, even if that gives heartburn to a certain number of shell
: programmers.
And if we do that, I guess that means that $«file».ext could
be made to work as a replacement, which seems conceptually clean if
you don't think about it too hard.
Larry
Re: semi-stack code
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, here's a really, really evil idea. (And yes, bluntly, it's triggered by the pie-thon bytecode translator's needs) I need a stack, Do you? I've converted all stack stuff at compile time, till now. I don't see the point, why this might not work for all opcodes. ... and one that's faster than our current stack which, while snappy for what it does, is still burdened by generality. I also need a stack that's generally not very big. So... Generally. Have a look at BUILD_TUPLE or BUILD_LIST. The limited stack will not work, you have to do overflow checking all the time and you'll have 2 addressing modes, one in registers and one in overflow. iset Px, Iy This does a set of register Px to PMC register #Y. Csetp_ind *is* in set.ops. If above is the other direction, then that should be named accordingly. leo
Re: enhanced open-funktion
On Tue, Jul 13, 2004 at 03:44:11PM -0600, John Williams wrote:
: On Tue, 13 Jul 2004, Larry Wall wrote:
: On Tue, Jul 13, 2004 at 07:24:55AM -0600, Luke Palmer wrote:
: : But in Perl 6, you don't have to specify things like that through the
: : mode string: you can specify them through named parameters:
: :
: : my $fh = open $filename :excl;
:
: While that probably works, I think better style would be to use a comma:
:
: my $fh = open $filename, :excl;
:
: That explicitly passes :excl to open as a term in a list rather
: than relying on the magical properties of :foo to find the preceding
: operator adverbially when used where an operator is expected. We may
: have to tighten up the definition of operator :foo a bit, since it's
: not always going to be clear which preceding operator is intended.
: Even quotes are operators if you squint.
: [snip]
: I see several directions we could go to clarify this, and I don't
: entirely like any of them. [snip]
:
: Operator adverbs are, in essence, postfix operators with weird
: precedence. We're going to have to be very explicit about what we
: mean by weird here. Unfortunately, this morning I don't feel
: very explicit.
:
: My understanding is that the :adverb is at the end because it is passed as
: a named argument, which must be after the positional arguments. And that
: is certainly unambiguous with the comma.
It's unambiguous becase a term is expected at that point, so :adverb
isn't really an adverb--it's just a pair constructor.
: However we have a precedent in m:i// where the :adverb comes directly
: after the operator. It's probably special because it is parsed that
: way, but it's so common that I feel I can use it as a precedent anyway.
:
: So if :adverbs are having such a weird time finding their verbs, wouldn't
: it be easier to allow them to be placed directly after the verb all the
: time? Then the magic is merely moving it into the named args section
: instead of wondering which operator's named args section it belongs to.
:
: Then
:
: my $fh = open $filename :excl;
:
: is unambiguously
:
: my $fh = open (circumfix:('$filename', :excl));
:
: while what was actually wanted is written as either of
:
: my $fh = open $filename, :excl; # part of the arg list
: my $fh = open :excl $filename; # adverb to open
:
: And besides, I think it reads better when the adverb is next to the verb.
:
: yes, no, maybe?
Except that you've but :excl where the parse is expecting a term, so it
isn't an adverb. It's just a pair constructor. Which means that after
it the parser is expecting an operator, and blows up on the string literal.
The adverb notation as currently defined only works where an operator
is expected. Which means it can't really be used on unary operators
unless there's some kind of pecking order where we try to apply it to
the unary operator, and if that fails, apply it to the preceding binary
operator. But that's a headache waiting to happen. I'm more inclined
to say that the adverb notation only works for binary operators, and
you have to use pair args with unaries. So you can't write
$x = rand 20 :bell_curve
because it would try to apply :bell_curve to the assignment, but you
can write
$x = rand(20, :bell_curve)
I know it seems like the adverb syntax is misplacing the modifier with
respect to the binary operator it's modifying, but I think most of its
uses are actually very short:
1..100:by(3)
If you really want something fancy, you'd be better off to write it
in functional form with a normal named pair argument:
infix:..(1, some_big_hairy_expression, :by(3))
instead of
1 .. some_big_hairy_expression :by(3)
Alternately, I do see an easy formatting hack:
1 .. (some_big_hairy_expression)
:by(3)
Just don't anyone suggest that we indicate what's modified
*syntactically* by placing the adverb directly under it...
Hmm. Maybe with an extra uparrow?
1 .. (some_big_hairy_expression)
^:by(3)
Yow. Two-dimensional programs. Reminds me of BF...
But we'd have to pay really close attention to how indenting is done.
Maybe we should just pass this suggestion on to Guido... :-)
Larry
Re: semi-stack code
At 7:43 PM +0200 7/14/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, here's a really, really evil idea. (And yes, bluntly, it's triggered by the pie-thon bytecode translator's needs) I need a stack, Do you? I've converted all stack stuff at compile time, till now. I don't see the point, why this might not work for all opcodes. There's the issue of basic block analysis which, bluntly, I'm not comfortable counting on being able to do in the time I've got. I may do a quick scan tonight, if I have time to hack it up, to see what the stack looks like going into the blocks. If a block's got multiple entry points then I need to coordinate register usage across all the places that could call it, which I'm not sure I've time for. ... and one that's faster than our current stack which, while snappy for what it does, is still burdened by generality. I also need a stack that's generally not very big. So... Generally. Have a look at BUILD_TUPLE or BUILD_LIST. The limited stack will not work, you have to do overflow checking all the time and you'll have 2 addressing modes, one in registers and one in overflow. I know there are a few nasty ones. I'm sorely tempted to toss the alignment bit and make the stack the same number of registers as we use for calling conventions, and turn those two into subs, in which case the setup for the call is a quick copy of the stack registers to the calling registers, with the overflow array matching for both. iset Px, Iy This does a set of register Px to PMC register #Y. Csetp_ind *is* in set.ops. If above is the other direction, then that should be named accordingly. I thought that was in there, but I missed that one. I'll add in its complement. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: semi-stack code
Dan Sugalski wrote: At 7:43 PM +0200 7/14/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, here's a really, really evil idea. (And yes, bluntly, it's triggered by the pie-thon bytecode translator's needs) I need a stack, Do you? I've converted all stack stuff at compile time, till now. I don't see the point, why this might not work for all opcodes. There's the issue of basic block analysis which, AFAIK not. The branch opcodes have a POP_TOP to get rid of the TOS, when its not consumed by the compare. I've no indication so far, that this is a problem. Please look (again) at pie-thon.pl. Check the code in CVS. Look at the tests. A lot is already there. Function calls (_VAR, _KW) need work *and* classes, objects, classes, objects ... Did I already mention objects? leo
Re: scalar subscripting
Larry Wall wrote:
On Wed, Jul 14, 2004 at 10:23:18AM -0700, Larry Wall wrote:
: Another alternative is $( $file ).ext. I'd tend to use that before
: ${file}.ext these days. Perhaps that's irrational--but it was hard
: to get the special-case ${name} form to work right in the Perl 5
: lexer, and that bugs me. If we're going to get rid of the autoquoting
: of $hash{shift}, we likely ought to undo the autoquoting of ${shift}
: as well, even if that gives heartburn to a certain number of shell
: programmers.
And if we do that, I guess that means that $«file».ext could
be made to work as a replacement, which seems conceptually clean if
you don't think about it too hard.
Maybe I'm missing something here, but this looks just plain cruel. Is
it easier to parse ...um... that? It's that same debate that's been
here before, but a lot of us can't type it yet. I probably could, but I
don't know the incantation for mozilla on windows. If I did, it bet it
wouldn't be the same as as the raindance for notepad. If it is the
same, then it probably isn't the same as the incantation in vi or emacs
on linux or aix.
I use ...${var}... a lot, and unfortunately, I have to use a number of
different programs and oses. Unfortunately, typing '«' '»' (thank you
cutpaste) is not as portable on the keyboard as say '{' '}' (or ''
for that matter).
Is ${var} really that rare in real world perl? Are we going to try to
have ascii equivalents like '' '' in quoted strings? (Please no.)
Do I need to put a unicode keyboard next to the APL keyboard on my
wishlist?
Dan
Converter mark two
Okay, so it's not done, but I put a new version up to be looked at. I'm taking Leo at his word on how the stack behaves, as I've not had time to look that closely at it to see myself. (Though by inspection it does still look like stack usage is pretty low, and is either 0 or 1 at labels (and only 1 when the label is a pop_top op)) We'll see how well it all responds to static analysis. So... ignore the ops I was talking about earlier. They may be useful, but not for this right now. There's a new version of Python::Bytecode (on CPAN, 2.5) that can at least parse, if not actually handle, unicode, complex numbers, and some weird bits in with the extended precision numbers, so all the compiled bytecode modules at least fully parse. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
