Leo --
Here's a Jako snippet:
var int x = 5;
{
var int x = 3;
print x;
}
print x
A naiive translation to imcc might be:
.sub _foo
.local int x
x = 5
.local int x
x = 3
print x
print x
.end
but (of course) that leads to an "x already defined" error.
I was hoping
[Fri, Dec 06, 2002 at 05:01:21PM -0500: Dan Sugalski]
> At 5:47 PM -0500 12/3/02, David Robins wrote:
> >On Tue, 3 Dec 2002, Dan Sugalski wrote:
> >- create immutable "true" and "false" PMCs
>
> That's fine.
>
> >- have not P0, P1 set P0 to $1->get_bool ? true : false
>
> Sure, that works.
At 5:47 PM -0500 12/3/02, David Robins wrote:
On Tue, 3 Dec 2002, Dan Sugalski wrote:
At 4:29 PM -0500 12/3/02, David Robins wrote:
>Enlightenment appreciated as always.
This is something that'll come up with perl 6 reasonably soon as
well. The solution for us is to have truth and falsehood
Sent to the wrong list. Ignore, please.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
> This is a bit of an oversimplification. $foo and @foo do not always
> behave the same, even if $foo and @foo refer to the same array object.
> In particular, $foo doesn't behave like @foo in a list context.
> Scalars must continue to behave like scalars in list context, even
> if they're interna
> This is a bit of an oversimplification. $foo and @foo do not always
> behave the same, even if $foo and @foo refer to the same array object.
> In particular, $foo doesn't behave like @foo in a list context.
> Scalars must continue to behave like scalars in list context, even
> if they're interna
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
WOuld it help to split imcc.y into main/parser/parser_utils or are you
doing this anyway?
yes pushing some code from imcc.y into a seperate file is what I had in
mind ... But have not got to that yet ...
Ok, than I'll separa
If memory serves me right, Leopold Toetsch wrote:
> WOuld it help to split imcc.y into main/parser/parser_utils or are you
> doing this anyway?
yes pushing some code from imcc.y into a seperate file is what I had in
mind ... But have not got to that yet ...
Was curious about the following lines
[EMAIL PROTECTED] wrote:
Leo --
Here is a simple Jako test program, which exercises the assignment syntax:
Here it is compiled to IMC:
[ Q/A intersparsed in imcc code for clearness ]
.sub __MODULE__
.local int a # var int a;
Aaron Sherman wrote:
On Fri, 2002-12-06 at 10:40, [EMAIL PROTECTED] wrote:
Looks like the first stages of constant-folding to me, no?
No, but constant folding is done anyway. Both "3.14" are one constant
loation.
The constant folding may simply not deal with integers yet
No, integ
[EMAIL PROTECTED] wrote:
Leo --
If .sub ... .end bracket not a subroutine, but a unit of compilation
(module?), then
shouldn't we make the name reflect the purpose?
A thing compiled in one piece ist mostly a subroutine.
I disagree. A think what is most often compiled in one piece is a f
Leo --
> > If .sub ... .end bracket not a subroutine, but a unit of compilation
> > (module?), then
> > shouldn't we make the name reflect the purpose?
> A thing compiled in one piece ist mostly a subroutine.
I disagree. A think what is most often compiled in one piece is a file,
with a combina
On Fri, 2002-12-06 at 10:40, [EMAIL PROTECTED] wrote:
> set N0, 3.14
> set N0, 3.14
> set N0, 3.14
> I don't understand how d and e both become N0, nor how both f and g become
> S0. a, b, and c all seem to get their own registers. Is there some
>
Leo --
Here is a simple Jako test program, which exercises the assignment syntax:
var int a, b, c;
var num d, e;
var str f, g;
a = 5;
a = b = c = 5;
d = 3.14;
d = e = 3.14;
f = "Howdy";
f = g = "Howdy";
a = b;
a = b = c;
Here it is compiled to IMC:
.sub __MODULE__
[EMAIL PROTECTED] wrote:
Leo --
If .sub ... .end bracket not a subroutine, but a unit of compilation
(module?), then
shouldn't we make the name reflect the purpose?
A thing compiled in one piece ist mostly a subroutine.
BTW, what is the difference between .sym and .local?
UTSL ;-) no
Gopal V wrote:
iANY("add", R3(r0,r1,r2))
Better use INS (the public interface of above functions)
Thanks, a shared library implementation of such a thing is what I'm
looking for ... I'll take a look at doing that ...
WOuld it help to split imcc.y into main/parser/parser_utils or are you
Leo --
OK. I'll have a look at a single outer .sub ... .end, and implementing
subs with
regular labels along with the .param stuff.
If .sub ... .end bracket not a subroutine, but a unit of compilation
(module?), then
shouldn't we make the name reflect the purpose?
BTW, what is the difference b
17 matches
Mail list logo
