Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
> -Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
> -Wmissing-prototypes -Winline -Wredundant-decls -Wnested-externs
> -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings
> -Wconversion -Waggregate-return -Winline
> The only pro
On Wed, May 30, 2001 at 06:27:39PM -0500, Jarkko Hietaniemi wrote:
> On Wed, May 30, 2001 at 03:51:11PM +0200, H.Merijn Brand wrote:
> > On Tue 29 May 2001 19:25, Dave Mitchell <[EMAIL PROTECTED]> wrote:
> > > =head2 Portability
> > >
> > > Related to extensibility is portability. Perl runs on ma
On Wed, May 30, 2001 at 06:58:50PM -0500, David L. Nicol wrote:
> > Of course, 'sub it():lvalue{$_}' gets you *most* of the benefit.
> ^^
You see that word? You know what it means?
> I want to buy the code, as listed in the code table, not the food
Simon Cozens wrote:
>
> On Wed, May 30, 2001 at 06:48:53PM +0100, Simon Cozens wrote:
> > *Nice*, but potentially a bugger to implement.
>
> Of course, 'sub it():lvalue{$_}' gets you *most* of the benefit.
um, no.
foreach(@foods){
# okay, I'll try...
ex
On Wed, May 30, 2001 at 03:51:11PM +0200, H.Merijn Brand wrote:
> On Tue 29 May 2001 19:25, Dave Mitchell <[EMAIL PROTECTED]> wrote:
> > =head2 Portability
> >
> > Related to extensibility is portability. Perl runs on many, many
> > platforms, and will no doubt be ported to ever more bizarre and
Larry Wall <[EMAIL PROTECTED]> writes:
> Dan Sugalski writes:
>> 1) The indentation should be all tabs or all spaces. No mix, it's a
>> pain.
> This will devolve into an editor war, and I don't think it's a real
> issue.
I'm not positive that it will. I can provide the magic incantations that
David wrote:
>defined $thing and return $thing
Why not use the existing mechanism? Namely:
return $_ for grep{defined} $thing;
which also scales rather nicely:
return $_ for grep{defined} $thing, $otherthing, $somethingelse;
As for the original problem of:
1
David L. Nicol wrote:
> some expressiveness is gained, and a creation of a temporary variable
> can be avoided.
>
> when $thing is a complex expression, a temporary variable must be
> explicitly assigned. "it" holds the place in my pseudocode.
If you have a complex expression, there's no way to
On Wed, May 30, 2001 at 06:48:53PM +0100, Simon Cozens wrote:
> *Nice*, but potentially a bugger to implement.
Of course, 'sub it():lvalue{$_}' gets you *most* of the benefit.
--
The complex-type shall be a simple-type. ISO 10206:1991 (Extended Pascal)
On Wed, May 30, 2001 at 02:54:27PM -0500, David L. Nicol wrote:
> small incremental improvement to [read|writ]ability
>
> writability:
>
> one less variable name to have to remember not to collide with
I think you have this one backwards. This is one giant, ambiguous
global variable whose valu
On Wed, May 30, 2001 at 02:39:57PM -0500, David L. Nicol wrote:
> ...
> defined $thing and return $thing
> ...
>
> when $thing is a complex expression, a temporary variable must be
> explicitly
> assigned. "it" holds the place in my pseudocode.
Hmmm, if $thing is a complex ex
Buddha Buck wrote:
> Why is [...] better than
>
> 1 until defined($foo=getvalue()); return $foo;
small incremental improvement to [read|writ]ability
writability:
one less thing to write
one less variable name to have to remember not to collide with
readability:
keyword "it" means look at v
Michael G Schwern wrote:
> That aside, could you put together a code example of what this wins?
some expressiveness is gained, and a creation of a temporary variable
can be avoided.
...
defined $thing and return $thing
...
is my working idiom for checking which case
Simon Cozens wrote:
> semantic ambiguity in there if you look hard enough, but
> can't come up with any example off hand.
I think I don't like the proposition that "it"
refer to the most recent *lexically* referenced scalar.
For example, in
$x ? $y : $z;
I think "it" should refer to whichever
Simon Cozens wrote:
> $foo = 5;
> print it + ($bar = 10) + it;
>
> 20 or 25?
or 30?
--
John Porter
On Wed, May 30, 2001 at 02:00:59PM -0400, Buddha Buck wrote:
> I'd be interested in seeing how "it" would be better than what works now.
>
> Why is:
>
> 1 until defined(getvalue()); return it;
>
> better than
>
> 1 until defined($foo=getvalue()); return foo;
Done properly, it would have to be
On Wed, May 30, 2001 at 06:48:53PM +0100, Simon Cozens wrote:
> *Nice*, but potentially a bugger to implement. I'm also sure you
> can find semantic ambiguity in there if you look hard enough, but
> can't come up with any example off hand.
$foo = 5;
print it + ($bar = 10) + it;
20 or 25?
--
"E
At 06:54 PM 05-30-2001 +0100, Michael G Schwern wrote:
>On Wed, May 30, 2001 at 12:38:50PM -0500, David L. Nicol wrote:
> > while pseudocoding something I realized that it would be really
> > cool if there was another magical default shelf, like $_ or _ but
> > subtly different, that stores, if l
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The size of the generated bytecode's likely not going to be
DS> directly an issue in determining speed. (And we can't count on
DS> keep the locals exclusively in the register set either, as
DS> otherwise string eval won't be able
On Wed, May 30, 2001 at 12:38:50PM -0500, David L. Nicol wrote:
> while pseudocoding something I realized that it would be really
> cool if there was another magical default shelf, like $_ or _ but
> subtly different, that stores, if lexically used, the object of the
> most recent "defined" or "e
On Wed, May 30, 2001 at 12:38:50PM -0500, David L. Nicol wrote:
> or maybe even the most recently referred to scalar, just the way
> "it" works in English. "it" would change much more often than $_
> does.
*Nice*, but potentially a bugger to implement. I'm also sure you
can find semantic ambigui
while pseudocoding something I realized that it would be really
cool if there was another magical default shelf, like $_ or _ but
subtly different, that stores, if lexically used, the object of the
most recent "defined" or "exists" --
or maybe even the most recently referred to scalar, just
> While RISC style opcodes have a certain pleasant simplicity to them, the
> opcode overhead'll kill us. (If perl 5's anything to go by, and in this
> case I think it might be)
I don't understand what the opcode overhead you meant. It can not be worse
than stack based opcode.
> The size of the
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> We basically tried this experiment with Perl 5, and it's only a
LW> partial success. Yes, you end up with a Perl VM that can run Perl
LW> pretty fast, but it tends to complicate the mapping to other
LW> virtual machines. (Enough s
At 10:06 AM 5/30/2001 -0700, Hong Zhang wrote:
> > There's no reason why you can.t have a hybrid scheme. In fact I think
> > it's a big win over a pure register-addressing scheme. Consider...
>
>The hybrid scheme may be a win in some cases, but I am not sure if it
>worth the complexity. I persona
Me wrote:
>
> It was an informal finger-in-the-wind thing I sent to
> a perl beginners list. Nothing special, just a quick
> survey.
>
> http://www.self-reference.com/cgi-bin/perl6plurals.pl
>
> > I certainly do not see that many people on the
> > list agreeing with you.
>
> And that means I s
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
> NI> The "overhead of op dispatch" is a self-proving issue - if you
> NI> have complex ops they are expensive to dispatch.
>
>but as someone else said, we can design our own ops to be as high l
At 09:35 AM 5/30/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Right, but in this case we have the advantage of tailoring the instruction
>: set to the language, and given the overhead inherent in op dispatch we also
>: have an incentive to hoist opcodes up to as high a level as we can ma
> There's no reason why you can.t have a hybrid scheme. In fact I think
> it's a big win over a pure register-addressing scheme. Consider...
The hybrid scheme may be a win in some cases, but I am not sure if it
worth the complexity. I personally prefer a strict RISC style opcodes,
mainly load, s
Dan Sugalski writes:
: Right, but in this case we have the advantage of tailoring the instruction
: set to the language, and given the overhead inherent in op dispatch we also
: have an incentive to hoist opcodes up to as high a level as we can manage.
We basically tried this experiment with Pe
Dave Mitchell <[EMAIL PROTECTED]> writes:
>
>There's no reason why you can.t have a hybrid scheme. In fact I think
>it's a big win over a pure register-addressing scheme. Consider...
Which was more or less my own position...
>
>At the start of a new scope, the stack is extended by N to create a
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> The "overhead of op dispatch" is a self-proving issue - if you
NI> have complex ops they are expensive to dispatch.
but as someone else said, we can design our own ops to be as high level
as we want. lowering the number of op cal
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Uri Guttman <[EMAIL PROTECTED]> writes:
>>
>> think of this as classic CISC code generation with plenty of registers
>> and a scratch stack. this is stable technology. we could even find a
>> code generator guru (i don't kn
> >the op code is stored in network endian order and the interpreter will
> >always build a 16 bit int from the 2 bytes.
>
> Not network. Native. We can put a marker at the beginning of any bytecode
> stream, and provide an endian-swapper. That way we're always running at
> platform optimal enco
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 02:08 PM 5/30/2001 +, Nick Ing-Simmons wrote:
>>Classic CISC code generation taught "us" that CISC is a pain to code-gen.
>>(I am not a Guru but did design TMS320C80's RISC specifically to match
>>gcc of that vintage, and dabbled in a p-code for Pas
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> I don't like push/pop - they imply a lot of stack limit checking word-by-word
> when it is less overhead for compiler to analyse the needs of whole
basic-block
> check-for/make-space-on the stack _once_ then just address it.
There's no reason why you
On Wed 30 May 2001 16:37, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:23 PM 5/30/2001 +0200, H.Merijn Brand wrote:
> >But I know I'm rather alone on this, though I'm not just someone saying:
> >"Cause that looks nice". I have several reasons for dong so and can defend
> >my stance.
>
> Just
At 02:08 PM 5/30/2001 +, Nick Ing-Simmons wrote:
>Uri Guttman <[EMAIL PROTECTED]> writes:
> >
> >think of this as classic CISC code generation with plenty of registers
> >and a scratch stack. this is stable technology. we could even find a
> >code generator guru (i don't know any obvious ones
On Wed 30 May 2001 16:29, Graham Barr <[EMAIL PROTECTED]> wrote:
> On Wed, May 30, 2001 at 04:23:58PM +0200, H.Merijn Brand wrote:
> > On Wed 30 May 2001 16:12, Dave Mitchell <[EMAIL PROTECTED]> wrote:
:::
> > But I know I'm rather alone on this, though I'm not just someone saying: "Cause
> > that
At 04:23 PM 5/30/2001 +0200, H.Merijn Brand wrote:
>But I know I'm rather alone on this, though I'm not just someone saying:
>"Cause that looks nice". I have several reasons for dong so and can defend
>my stance.
Just to head off potential formatting/code style issues... (And this is
*not* dir
On Wed, May 30, 2001 at 04:23:58PM +0200, H.Merijn Brand wrote:
> On Wed 30 May 2001 16:12, Dave Mitchell <[EMAIL PROTECTED]> wrote:
> > > > "K&R" style for indenting control constructs: ie the closing C<}> should
> > > > line up with the opening C etc.
> > > >
> > > > =item *
> > > >
> > > > Wh
On Wed 30 May 2001 16:12, Dave Mitchell <[EMAIL PROTECTED]> wrote:
> > > "K&R" style for indenting control constructs: ie the closing C<}> should
> > > line up with the opening C etc.
> > >
> > > =item *
> > >
> > > When a conditional spans multiple lines, the opening brace must line up
> > > wi
Uri Guttman <[EMAIL PROTECTED]> writes:
>
>think of this as classic CISC code generation with plenty of registers
>and a scratch stack. this is stable technology. we could even find a
>code generator guru (i don't know any obvious ones in the perl6 world)
Classic CISC code generation taught "us"
> > "K&R" style for indenting control constructs: ie the closing C<}> should
> > line up with the opening C etc.
> >
> > =item *
> >
> > When a conditional spans multiple lines, the opening brace must line up
> > with the "if" or "while", or be at the end-of-line otherwise.
>
> I certainly will
Uri Guttman <[EMAIL PROTECTED]> writes:
> DS> The one handy thing about push and pop is you don't need to go
> DS> tracking the stack manually--that's taken care of by the push and
> DS> pop opcodes. They can certainly be replaced with manipulations of
> DS> a temp register and indirect regist
On Tue 29 May 2001 19:25, Dave Mitchell <[EMAIL PROTECTED]> wrote:
> =head2 Portability
>
> Related to extensibility is portability. Perl runs on many, many
> platforms, and will no doubt be ported to ever more bizarre and obscure
> ones over time. You should never assume an operating system, pr
On Tue 29 May 2001 19:25, Dave Mitchell <[EMAIL PROTECTED]> wrote:
> =item *
>
> "K&R" style for indenting control constructs: ie the closing C<}> should
> line up with the opening C etc.
>
> =item *
>
> When a conditional spans multiple lines, the opening brace must line up
> with the "if" or
> "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
Larry> : Nah, bytecode'll have an endianness marker at the top. If you
Larry> : load in bytecode with the wrong endianness, the loader will
Larry> : have to swap for you.
Larry> Er. If they're not bytes, we can't call it bytecode.
Unless
48 matches
Mail list logo
