From nickle@nickle.org  Fri Feb  7 20:43:49 2003
From: nickle@nickle.org (Ireland Peddlar)
Date: Fri, 07 Feb 2003 20:43:49 +0000
Subject: [Nickle] bug
Message-ID: <F9g5GYu7wAK45iJLNP9000338fa@hotmail.com>

In nickle, **= does not work although the manual says it does.  For example:
int x = 2;
x **= 2;
   Unhandled exception "invalid_argument" at <stdin>:2
     2
     0
     "Incompatible argument"
Is what nickle returns.




_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail



From nickle@nickle.org  Fri Feb  7 21:01:20 2003
From: nickle@nickle.org (Keith Packard)
Date: Fri, 07 Feb 2003 13:01:20 -0800
Subject: [Nickle] Bug in exponentiation
In-Reply-To: Your message of "Fri, 24 Jan 2003 21:41:59 GMT."
 <F386YHkidcDjoYAPNXR0000b7d1@hotmail.com>
Message-ID: <E18hFce-00034M-00@localhost>

Around 21 o'clock on Jan 24, "Ireland Peddlar" wrote:

> In writing a testing suite for nickle, I noticed that when dealing with a 
> perfect square nickle doesn't find a perfect answer.  For example, when 
> asked to evaluate 4**.5 nickle returns 1.99999999.

That's because ** calls the pow function and that function evaluated 
all non-integer exponents the same way (exp (log(a) * b)).  I've changed 
that function to recognise powers of 1/2 and 1/3 and call sqrt and cbrt.

> In nickle, **= does not work although the manual says it does.

There was a bug in the compiler that compiled the operands in the wrong 
order.

Thanks for your bug reports!

-keith




From nickle@nickle.org  Sat Feb  8 01:14:01 2003
From: nickle@nickle.org (Ireland Peddlar)
Date: Sat, 08 Feb 2003 01:14:01 +0000
Subject: [Nickle] bug
Message-ID: <F65GpaoG1VRIjn04x2900034a4a@hotmail.com>

Yet another nickle bug!
int x = 0;
x == 0 ? x = 1 : x = 2 is evaluated as (x == 0 ? x) = (1 : x = 2)
so it must be typed as x == 0 ? (x = 1) : (x = 2).



_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus



From nickle@nickle.org  Sat Feb  8 01:49:19 2003
From: nickle@nickle.org (Keith Packard)
Date: Fri, 07 Feb 2003 17:49:19 -0800
Subject: [Nickle] bug
In-Reply-To: Your message of "Sat, 08 Feb 2003 01:14:01 GMT."
 <F65GpaoG1VRIjn04x2900034a4a@hotmail.com>
Message-ID: <E18hK7L-0003VA-00@localhost>

Around 1 o'clock on Feb 8, "Ireland Peddlar" wrote:

> Yet another nickle bug!
> int x = 0;
> x == 0 ? x = 1 : x = 2 is evaluated as (x == 0 ? x) = (1 : x = 2)
> so it must be typed as x == 0 ? (x = 1) : (x = 2).

Would you believe the grammar was factored to avoid a shift/reduce conflict
in array/struct initializers?

Consider the two initializers:

	typedef struct { int y; } Y;

	Y	x = { y = 7 };

	int 	y;
	int[1]	z = { y = 7 };

The second initializer is syntactically indistinguishable from the first.

The current grammar avoids this ambiguity by making assignments invalid in 
initializers -- they're factored out by creating an intermediate 
non-terminal for assignment expressions above the rest of the expression 
productions and having initializers use the lower level non-terminal.

I just reworked the grammar to move assignment back into the lower level 
non-terminal.  This yields an additional shift/reduce conflict, but shift
yields a struct initializer while reduce yields an array initializer, which
is what you want.  If you want an array initializer to be an assignment
expression, just place it in parens.

Make sure you do 'make clean' after checking this change out; the makefile
doesn't rebuild the right things after the grammar changes.  Bart should 
fix this.

-keith




From nickle@nickle.org  Sat Feb  8 01:52:37 2003
From: nickle@nickle.org (Keith Packard)
Date: Fri, 07 Feb 2003 17:52:37 -0800
Subject: [Nickle] bug
In-Reply-To: Your message of "Sat, 08 Feb 2003 01:14:01 GMT."
 <F65GpaoG1VRIjn04x2900034a4a@hotmail.com>
Message-ID: <E18hKAX-0003a9-00@localhost>

Around 1 o'clock on Feb 8, "Ireland Peddlar" wrote:

> x == 0 ? x = 1 : x = 2

btw -- even after the grammar was fixed, this expression isn't valid -- the
?: operator has higher precedence than assignment, so you'll actually be 
compiling:

  ((x == 0) ? (x = 1) : x) = 2

so you'll get an invalid lvalue error.  That just means you'll need parens
around the right assignment:

 x == 0 ? x = 1 : (x = 2)

which looks weird, but follows all of the rules.

-keith
 



From nickle@nickle.org  Fri Feb 14 19:30:09 2003
From: nickle@nickle.org (Ireland Peddlar)
Date: Fri, 14 Feb 2003 19:30:09 +0000
Subject: [Nickle] sort of a bug
Message-ID: <F41gC4Z9ep7KSEoTT2w00005e14@hotmail.com>

Factorial is binding tighter than the preinrement operator.
++x! is parsed as ++(x!) and dies.

Erin



_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail



From nickle@nickle.org  Fri Feb 14 20:02:45 2003
From: nickle@nickle.org (Keith Packard)
Date: Fri, 14 Feb 2003 12:02:45 -0800
Subject: [Nickle] sort of a bug
In-Reply-To: Your message of "Fri, 14 Feb 2003 19:30:09 GMT."
 <F41gC4Z9ep7KSEoTT2w00005e14@hotmail.com>
Message-ID: <E18jm2n-0001Hc-00@localhost>

Around 19 o'clock on Feb 14, "Ireland Peddlar" wrote:

> Factorial is binding tighter than the preinrement operator.
> ++x! is parsed as ++(x!) and dies.

Hmm.  C has a single level of precedence for unary operators and groups 
them from right to left.  You'll get the same error from the C compiler 
with:

	int foo (int x) { return --x++; }

Because of the right to left binding, any postfix unary operators with the 
are effectively given higher precedence than prefix unary operators with 
the same specified precedence.

There's a problem here though; the grammar does operator precedence based
on the operator tokens in the input stream.  So, I can't change the 
precedence of the factorial operator without also changing the precedence 
of the boolean negation opertor as they share the same token.

I think that means we're stuck with this precedence inversion; I don't 
want to gratuitously differ from C in such a subtle way.

-keith




From nickle@nickle.org  Fri Feb 14 20:46:26 2003
From: nickle@nickle.org (Ireland Peddlar)
Date: Fri, 14 Feb 2003 20:46:26 +0000
Subject: [Nickle] sort of a bug
Message-ID: <F45t1ngGO8QEsje8c0000017d03@hotmail.com>

When Bart was looking at what I was doing and noticed this, he said it 
shouldn't be this way and post a bug report.  You might want to talk to him 
about it, he knows more than I do about what is going on.
Erin



----Original Message Follows----
From: Keith Packard <keithp@keithp.com>
Reply-To: nickle@nickle.org
To: nickle@nickle.org
CC: Keith Packard <keithp@keithp.com>
Subject: Re: [Nickle] sort of a bug
Date: Fri, 14 Feb 2003 12:02:45 -0800
MIME-Version: 1.0
Received: from home.keithp.com ([63.227.221.253]) by 
mc8-f40.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 14 Feb 
2003 12:03:04 -0800
Received: from localhost ([127.0.0.1] helo=home.keithp.com)by 
home.keithp.com with esmtp (Exim 3.36 #1 (Debian))id 18jm34-0006nU-00; Fri, 
14 Feb 2003 12:03:02 -0800
Received: from evo.keithp.com ([10.0.0.6] helo=localhost)by home.keithp.com 
with esmtp (Exim 3.36 #1 (Debian))id 18jm2n-0006n7-00for 
<nickle@nickle.org>; Fri, 14 Feb 2003 12:02:45 -0800
Received: from localhost ([127.0.0.1] helo=keithp.com)by localhost with 
esmtp (Exim 3.36 #1 (Debian))id 18jm2n-0001Hc-00; Fri, 14 Feb 2003 12:02:45 
-0800
X-Message-Info: dHZMQeBBv44lPE7o4B5bAg==
X-Mailer: exmh version 2.3.1 11/28/2001 with nmh-1.0.4+dev
In-reply-to: Your message of "Fri, 14 Feb 2003 19:30:09 GMT."             
<F41gC4Z9ep7KSEoTT2w00005e14@hotmail.com>
Message-Id: <E18jm2n-0001Hc-00@localhost>
Sender: nickle-admin@nickle.org
Errors-To: nickle-admin@nickle.org
X-BeenThere: nickle@nickle.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:nickle-request@nickle.org?subject=help>
List-Post: <mailto:nickle@nickle.org>
List-Subscribe: 
<http://nickle.org/mailman/listinfo/nickle>,<mailto:nickle-request@nickle.org?subject=subscribe>
List-Id: Nickle language list <nickle.nickle.org>
List-Unsubscribe: 
<http://nickle.org/mailman/listinfo/nickle>,<mailto:nickle-request@nickle.org?subject=unsubscribe>
List-Archive: <http://nickle.org/pipermail/nickle/>
Return-Path: nickle-admin@nickle.org
X-OriginalArrivalTime: 14 Feb 2003 20:03:05.0108 (UTC) 
FILETIME=[16059D40:01C2D464]


Around 19 o'clock on Feb 14, "Ireland Peddlar" wrote:

 > Factorial is binding tighter than the preinrement operator.
 > ++x! is parsed as ++(x!) and dies.

Hmm.  C has a single level of precedence for unary operators and groups
them from right to left.  You'll get the same error from the C compiler
with:

	int foo (int x) { return --x++; }

Because of the right to left binding, any postfix unary operators with the
are effectively given higher precedence than prefix unary operators with
the same specified precedence.

There's a problem here though; the grammar does operator precedence based
on the operator tokens in the input stream.  So, I can't change the
precedence of the factorial operator without also changing the precedence
of the boolean negation opertor as they share the same token.

I think that means we're stuck with this precedence inversion; I don't
want to gratuitously differ from C in such a subtle way.

-keith



_______________________________________________
Nickle mailing list
Nickle@nickle.org
http://nickle.org/mailman/listinfo/nickle


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus



From nickle@nickle.org  Fri Feb 14 22:48:32 2003
From: nickle@nickle.org (Keith Packard)
Date: Fri, 14 Feb 2003 14:48:32 -0800
Subject: [Nickle] sort of a bug
In-Reply-To: Your message of "Fri, 14 Feb 2003 20:46:26 GMT."
 <F45t1ngGO8QEsje8c0000017d03@hotmail.com>
Message-ID: <E18jodE-0001TT-00@localhost>

Around 20 o'clock on Feb 14, "Ireland Peddlar" wrote:

> When Bart was looking at what I was doing and noticed this, he said it 
> shouldn't be this way and post a bug report.  You might want to talk to him 
> about it, he knows more than I do about what is going on.

Yes, I agree it's busted, but I'm not sure what we can do about it; yacc 
isn't generating the right parser when I do try the "correct" fix.

-keith




From nickle@nickle.org  Sat Feb 15 00:42:38 2003
From: nickle@nickle.org (Bart Massey)
Date: Fri, 14 Feb 2003 16:42:38 -0800
Subject: [Nickle] sort of a bug
In-Reply-To: Your message of "Fri, 14 Feb 2003 12:02:45 PST."
 <E18jm2n-0001Hc-00@localhost>
Message-ID: <E18jqPe-0006vu-00@bart.cs.pdx.edu>

This is a bug, darnit :-).

First, Nickle evaluates from left to right: you've gone to a
lot of trouble to make this happen.  Why should operator
order be any different?  (BTW, is right-to-left
associativity a part of the C standard, or just standard in
implementations?  I need to purchase or steal a copy of the
C90 spec someday...)

Second, s far as making the precedence of making postfix !
different precedence from prefix !, it should just require a
%prec declaration, no?

But this precedence change doesn't really fix the problem:
in Nickle ~x++ will still be handled the same way as in C,
which is arguably a bug because darnit, it should be
left-to-right.  Perhaps the right answer is to make ++ and
-- have higher precedence than other unary operators in
Nickle.  The current equal precedence is arguably a defect
in C, since the implicit parens will either continue to do
the same thing or detect a conceptual bug.

	Bart

In message <E18jm2n-0001Hc-00@localhost> you wrote:
> 
> Around 19 o'clock on Feb 14, "Ireland Peddlar" wrote:
> 
> > Factorial is binding tighter than the preinrement operator.
> > ++x! is parsed as ++(x!) and dies.
> 
> Hmm.  C has a single level of precedence for unary operators and groups 
> them from right to left.  You'll get the same error from the C compiler 
> with:
> 
> 	int foo (int x) { return --x++; }
> 
> Because of the right to left binding, any postfix unary operators with the 
> are effectively given higher precedence than prefix unary operators with 
> the same specified precedence.
> 
> There's a problem here though; the grammar does operator precedence based
> on the operator tokens in the input stream.  So, I can't change the 
> precedence of the factorial operator without also changing the precedence 
> of the boolean negation opertor as they share the same token.
> 
> I think that means we're stuck with this precedence inversion; I don't 
> want to gratuitously differ from C in such a subtle way.
> 
> -keith
> 
> 
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle


From nickle@nickle.org  Sat Feb 15 00:56:05 2003
From: nickle@nickle.org (Bart Massey)
Date: Fri, 14 Feb 2003 16:56:05 -0800
Subject: [Nickle] Boom
Message-ID: <E18jqcf-0006yO-00@bart.cs.pdx.edu>

  $ nickle
  > int x = 0;
  > fork(x = 1);
  > Thread::join(%51)
  nickle: compile.c:2430: _CompileExpr: Assertion `0' failed.
  $ 

	Bart


From nickle@nickle.org  Sat Feb 15 02:43:20 2003
From: nickle@nickle.org (Keith Packard)
Date: Fri, 14 Feb 2003 18:43:20 -0800
Subject: [Nickle] sort of a bug
In-Reply-To: Your message of "Fri, 14 Feb 2003 16:42:38 PST."
 <E18jqPe-0006vu-00@bart.cs.pdx.edu>
Message-ID: <E18jsIS-0001bP-00@localhost>

Around 16 o'clock on Feb 14, Bart Massey wrote:

> (BTW, is right-to-left
> associativity a part of the C standard, or just standard in
> implementations?  I need to purchase or steal a copy of the
> C90 spec someday...)

Yes.  Otherwise *a++ would "do the wrong thing".

> Second, s far as making the precedence of making postfix !
> different precedence from prefix !, it should just require a
> %prec declaration, no?

Nope.  Yacc maps the %prec to the operator token; the same token always 
yields the same precedence.  I looked at the y.output file in some detail 
to verify this.

> But this precedence change doesn't really fix the problem:
> in Nickle ~x++ will still be handled the same way as in C,
> which is arguably a bug because darnit, it should be
> left-to-right.

Why is left-to-right "correct"?  It's just a matter of implicit 
parenthesis.

-keith




From nickle@nickle.org  Tue Feb 18 04:28:40 2003
From: nickle@nickle.org (Keith Packard)
Date: Mon, 17 Feb 2003 20:28:40 -0800
Subject: [Nickle] Boom
In-Reply-To: Your message of "Fri, 14 Feb 2003 16:56:05 PST."
 <E18jqcf-0006yO-00@bart.cs.pdx.edu>
Message-ID: <E18kzN2-0000Zf-00@localhost>

Around 16 o'clock on Feb 14, Bart Massey wrote:

  > int x = 0;
  > fork(x = 1);
  > Thread::join(%51)
  nickle: compile.c:2430: _CompileExpr: Assertion `0' failed.

Oops.  Couple of trivial bugs.  Note, however, that this syntax is not 
very useful any longer.  That's because threads are removed from the run 
queue when finished, so there's no way to map numbers to threads for 
completed threads; you have to save the thread object in a variable:

 	int	x = 0;
	thread t = fork (x = 1);
	Thread::join(t)

Looks like thread numbers are a whole lot less useful this way, but the 
alternative was to have exited threads clog up memory without serving any 
purpose in case someone "happened" to use the % notation in an expression.

-keith




From nickle@nickle.org  Fri Feb 28 21:54:32 2003
From: nickle@nickle.org (Ireland Peddlar)
Date: Fri, 28 Feb 2003 21:54:32 +0000
Subject: [Nickle] bugs
Message-ID: <F15jT8S1M1GvE0uY2at0002121e@hotmail.com>

Error:
x!==x! is evaluated as x(!=)=x!
According the the manual it should be evaluated (x!)==(x!)

Also:
It should be noted in the manual probably that
---x is evaluated as --(-x) instead of -(--x) and nickle chokes on it.
especially since -++x is evaluated as -(++x) correctly.



_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus



