From bart at cs.pdx.edu  Sun Nov  7 00:44:13 2004
From: bart at cs.pdx.edu (Barton C Massey)
Date: Sun Nov  7 00:44:25 2004
Subject: [Nickle] Nickle storage lifetime modifiers
In-Reply-To: Your message of "Sat, 06 Nov 2004 22:03:02 PST."
	<Pine.GSO.4.58.0411062157370.20308@adara.cs.pdx.edu> 
Message-ID: <200411070844.iA78iDAw023962@wezen.cs.pdx.edu>

One valid way to think of global, static, and auto lifetimes
is this:
  + Storage with auto lifetime is allocated every time
    an auto definition is encountered.
  + Storage with global lifetime is allocated
    exactly once, when the function defining it is first
    encountered.
  + Storage with static lifetime is the tricky case.
    Static storage is allocated whenever the function
    containing it is defined, and reallocated whenever
    the definition is re-evaluated.
Note that because C doesn't have nested functions and
closures, global and static would both behave the same
there.  This is why C has only the static keyword :-).

We say that Nickle has separate notions of the scope of a
name and the lifetime of storage: a name may go out of scope
without its storage being deallocated, and may come into
scope and be bound to previously allocated storage.

Consider these functions, similar to yours:

  int() cntfac()
       /* counter factory */
  {
      return (int func() {
	  return (static int x = 0)++;
      });
  }

  int() cntfac2()
       /* counter factory */
  {
      int bar() {
	  return (static int x = 0)++;
      }
      return bar;
  }

These functions behave identically, as you would hope.  The
inner function definitions in both are evaluated every time
the outer function is invoked.  Thus, new storage is
allocated for x at that point, and returned.  Now consider
what happens if we say:

  int() cntfac3()
       /* shared counter factory */
  {
      static int bar() {
	  return (static int x = 0)++;
      }
      return bar;
  }

Because bar() itself is static, its definition is only
evaluated once, at the time the definition of cntfac3() is
evaluated.  Thus the definition of x is only evaluated
once, and all the "shared counters" returned by cntfac3() work
off the same storage for x.

Finally, consider more or less what you wrote:

  int cnt()
      /* counter */
  {
      int bar() {
	  return (static int x = 0)++;
      }
      return bar();
  }

Note the difference in return type: cnt() invokes bar() to
get an int result.  Since bar is auto, new storage will
be allocated for x on each call to cnt(), which is the
behavior you observed.

Changing the lifetime of x from static to global does, as
you observed, make x act like a counter: subsequent
re-evaluations of the definition of bar don't allocate new
storage for x.

  int cnt2()
      /* shared counter */
  {
      int bar() {
          return (global int x = 0)++;
      }
      return bar();
  }


(If you reload or re-type-in the definition of cnt2(), it
will start from 0 again.  This is because you effectively
define a "new" cnt2() the second time, and it has its
own new "bar()".  In a statically scoped world, names don't
uniquely identify storage.)

Finally, if you modify cnt() by making the definition of bar
static, you'll also get a useful counter.

  int cnt3()
       /* shared counter */
  {
      static int bar() {
	  return (static int x = 0)++;
      }
      return bar();
  }

By now, hopefully, the reasoning is obvious.

Somebody should probably put some of the above into
the tutorial.  Please let me know if you have further
questions.

	Bart

In message <Pine.GSO.4.58.0411062157370.20308@adara.cs.pdx.edu> you wrote:
> 	I am reading through the tutorial on the nickle.org site I was
> wondering if you could explaining the difference between the two following
> code samples reproduced below:
> 1)
> int() function incrementer () {
> 	return (func () {
> 		static int	x = 0;
> 		return ++x;
> 	});
> }
> int()	a = incrementer();
> int()	b = incrementer();
> 
> 2)
> function foo () {
> 	function bar ()	{
> 		global	g = 1;
> 		static	s = 1;
> 		g++;
> 		s++;
> 		return (int[2]) { g, s };
> 	}
> 	return bar ();
> }
> 
> 	So in 1) when a or b is called each has its own independent x, but
> when using foo() only g gets incremented and s is always 2.  I am not sure
> how to understand the difference?

From bart at cs.pdx.edu  Sat Nov 13 20:47:30 2004
From: bart at cs.pdx.edu (Barton C Massey)
Date: Sat Nov 13 20:47:41 2004
Subject: [Nickle] Re: Another nickle question 
In-Reply-To: Your message of "Sat, 13 Nov 2004 14:49:38 PST."
	<Pine.GSO.4.58.0411131444580.19710@atlas.cs.pdx.edu> 
Message-ID: <200411140447.iAE4lUNx011104@adara.cs.pdx.edu>

Couple of possible gotchas.  First, make sure you're using
sufficiently recent Nickle bits: we fixed some bugs a month
or so back.  Second, note that as they are currently
implemented, growable arrays aren't allocated until they're
initialized.  This is a bug, and should be fixed.  Finally,
note that until you've initialized a cell in the array, you
can't initialize its contents.

Here's some Nickle that works
  $ nickle
  > typedef struct { int x; } s;
  > s[...] a = {};
  > a[0] = (s){x=3};
  > setdim(a,2)
  > a
  (s [...]) {{x = 3}, <uninit>}
  > setdim(a,0)
  > 

	Bart

In message <Pine.GSO.4.58.0411131444580.19710@atlas.cs.pdx.edu> you wrote:
> 	I am trying to use the '...' to declare resizeable arrays, but I
> keep getting this exception:
> Unhandled exception uninitialized_value ("Uninitialized value")
> when ever I try to assign into the array I declared.
> 	Also I can't seem to find any documentation on setdim and setdims.
> When I try to use setdim with my resizable array, I also get the same
> exception.
> 	I declare the array with "location[...] bases" and call setdim
> with "setdim(bases,10)".

From jegreen at cs.pdx.edu  Sun Nov 14 12:29:54 2004
From: jegreen at cs.pdx.edu (Jeremy Greenwald)
Date: Sun Nov 14 15:59:42 2004
Subject: [Nickle] Re: Another nickle question 
In-Reply-To: <200411140447.iAE4lUNx011104@adara.cs.pdx.edu>
References: <200411140447.iAE4lUNx011104@adara.cs.pdx.edu>
Message-ID: <Pine.GSO.4.58.0411141229250.7094@wezen.cs.pdx.edu>

	Yeah I needed to initialize fir with "={}" after that everything
worked the way I expected it to.  Thanks.

Gentlemen . . . Behold!

On Sat, 13 Nov 2004, Barton C Massey wrote:

> Couple of possible gotchas.  First, make sure you're using
> sufficiently recent Nickle bits: we fixed some bugs a month
> or so back.  Second, note that as they are currently
> implemented, growable arrays aren't allocated until they're
> initialized.  This is a bug, and should be fixed.  Finally,
> note that until you've initialized a cell in the array, you
> can't initialize its contents.
>
> Here's some Nickle that works
>   $ nickle
>   > typedef struct { int x; } s;
>   > s[...] a = {};
>   > a[0] = (s){x=3};
>   > setdim(a,2)
>   > a
>   (s [...]) {{x = 3}, <uninit>}
>   > setdim(a,0)
>   >
>
> 	Bart
>
> In message <Pine.GSO.4.58.0411131444580.19710@atlas.cs.pdx.edu> you wrote:
> > 	I am trying to use the '...' to declare resizeable arrays, but I
> > keep getting this exception:
> > Unhandled exception uninitialized_value ("Uninitialized value")
> > when ever I try to assign into the array I declared.
> > 	Also I can't seem to find any documentation on setdim and setdims.
> > When I try to use setdim with my resizable array, I also get the same
> > exception.
> > 	I declare the array with "location[...] bases" and call setdim
> > with "setdim(bases,10)".
>

From bart at cs.pdx.edu  Mon Nov 15 01:38:52 2004
From: bart at cs.pdx.edu (Barton C Massey)
Date: Mon Nov 15 01:39:05 2004
Subject: [Nickle] Re: [psas-software] trouble with Nickle installation 
In-Reply-To: Your message of "Sun, 14 Nov 2004 23:10:24 PST."
	<41985660.9070104@verizon.net> 
Message-ID: <200411150938.iAF9cqAw004798@wezen.cs.pdx.edu>

Thanks Josh!

	Bart

In message <41985660.9070104@verizon.net> you wrote:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --===============1073714604==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature";
> 	boundary="------------enigC08A7F799D338AF308D0B4AF"
> 
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enigC08A7F799D338AF308D0B4AF
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> David Allen wrote:
> > I'm having trouble installing nickle on my new Debian installation, any 
> > suggestions?
> > 
> > Here is what happened:
> > 
> > Gyre:/etc/apt# apt-get install nickle
> > Reading Package Lists... Done
> > Building Dependency Tree... Done
> > The following NEW packages will be installed:
> >   nickle
> > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> > Need to get 186kB of archives.
> > After unpacking 696kB of additional disk space will be used.
> > Get:1 http://nickle.org ./ nickle 2.20-1 [186kB]
> > Fetched 187kB in 6s (27.4kB/s)
> > Failed to fetch http://nickle.org/debian/./nickle_2.20-1_i386.deb  Size 
> > mismatch
> > E: Unable to fetch some archives, maybe run apt-get update or try with 
> > --fix-missing?
> > Gyre:/etc/apt#
> 
> Looking at the apt repository on nickle.org, it appears that the
> Packages.gz file hasn't been updated since nickle 2.20, while the
> current .deb in that repository is 2.43-1.  Furthermore, the md5sum and
> size of the nickle 2.20 deb matches neither those in the Packages.gz
> file nor those in the 2.20 .dsc file.  Since 2.43-1 is also the current
> version available in Debian unstable, you might consider just fetching
> nickle packages from there.  (Note that nickle is not currently
> available in Debian testing.)
> 
> - Josh Triplett
> 
> --------------enigC08A7F799D338AF308D0B4AF
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
> 
> iD8DBQFBmFZpGJuZRtD+evsRAprlAKCphokIkd9vmOtkj5PDPXmHAoV85gCfXeRB
> Pk72NbNrHQz4RKA7daP/CXc=
> =3nJu
> -----END PGP SIGNATURE-----
> 
> --------------enigC08A7F799D338AF308D0B4AF--
> 
> 
> --===============1073714604==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> psas-software mailing list
> psas-software@lists.psas.pdx.edu
> http://lists.psas.pdx.edu/mailman/listinfo/psas-software
> 
> --===============1073714604==--

From keithp at keithp.com  Mon Nov 15 12:15:39 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Nov 15 12:15:44 2004
Subject: [Nickle] Remaining examples with missing copyright/license
	information
Message-ID: <E1CTnGF-0007H5-J8@evo.keithp.com>


I've spent a few minutes adding obvious copyright and license information 
to most of the examples.  However, there are three remaining bits which 
need to either be fixed or removed from the distribution (but not 
necessarily from CVS).

****	circle.5c:

Includes a reference to the original javascript version:

 * Bart Massey 2000
 * From Javascript by Jeff Waldock 1997
 * http://jeff.sci.shu.ac.uk/jw/javascript/js2.html

****	qbrating.5c:

 * Info from various web sources
 * 3 ways of computing the result: first uses no
 * decimal approximations, last only decimal approximations.

****	rijndael.5c

This, transliterated from C, includes a non-OSI "license"/disclaimer.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041115/e4f026f3/attachment.pgp
From giantrobot at f-m.fm  Thu Nov 18 17:11:59 2004
From: giantrobot at f-m.fm (James LaMar)
Date: Thu Nov 18 17:12:26 2004
Subject: [Nickle] Is this a bug?
Message-ID: <1100826719.29000.209003545@webmail.messagingengine.com>

Structs with uninitialized values can't be used as keys... is this a
bug?

> typedef struct { int k, s; } m;
> m k;
> k
{k = <uninit>, s = <uninit>}
> int[m] hsh = {} 
(int [m]) {}
> hsh[k]
Unhandled exception uninitialized_value ("uninitialized hash element")
<stdin>:5:     hsh[k];
-- 
  James
  giantrobot@f-m.fm


From giantrobot at f-m.fm  Thu Nov 18 22:13:55 2004
From: giantrobot at f-m.fm (James LaMar)
Date: Thu Nov 18 22:14:00 2004
Subject: [Nickle] Segmentation Fault in nickle
Message-ID: <1100844835.11593.209016966@webmail.messagingengine.com>

I get a bus error in FreeBSD and a segmentation fault on solaris with
the current Mint code.  Unfortunately, I don't have any linux machines
to test on since my CS linuxlab account doesn't have a home directory
(?)

The code is available at http://cs.pdx.edu/~jlamar/mint/mint.tar.gz --
it's not complete or commented.

You can recreate the bug simply by running the crashnickle.sh shell
script.

-- 
  James
  giantrobot@f-m.fm


From keithp at keithp.com  Thu Nov 18 22:54:08 2004
From: keithp at keithp.com (Keith Packard)
Date: Thu Nov 18 22:54:23 2004
Subject: [Nickle] Segmentation Fault in nickle 
In-Reply-To: Your message of "Thu, 18 Nov 2004 22:13:55 PST."
	<1100844835.11593.209016966@webmail.messagingengine.com> 
Message-ID: <E1CV2em-000825-NA@evo.keithp.com>


Around 22 o'clock on Nov 18, "James LaMar" wrote:

> You can recreate the bug simply by running the crashnickle.sh shell
> script.

The program was creating an array with negative dimension and the 
interpreter wasn't raising an exception.

I fixed the interpreter (thanks!), but didn't examine the program at all.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041118/0beb9c24/attachment.pgp
From bart at po8.org  Thu Nov 18 23:32:57 2004
From: bart at po8.org (Bart Massey)
Date: Thu Nov 18 23:33:58 2004
Subject: [Nickle] Segmentation Fault in nickle 
In-Reply-To: <1100844835.11593.209016966@webmail.messagingengine.com> 
References: <1100844835.11593.209016966@webmail.messagingengine.com>
Message-ID: <E1CV3HF-0000vk-00@po8.org>

Some array's size is getting mangled.  I haven't been able
to figure out why.  Hopefully Keithp can.  Crashes when
parse() is actually called at the end of gramtest.5c.

	Bart

In message <1100844835.11593.209016966@webmail.messagingengine.com> you wrote:
> I get a bus error in FreeBSD and a segmentation fault on solaris with
> the current Mint code.  Unfortunately, I don't have any linux machines
> to test on since my CS linuxlab account doesn't have a home directory
> (?)
> 
> The code is available at http://cs.pdx.edu/~jlamar/mint/mint.tar.gz --
> it's not complete or commented.
> 
> You can recreate the bug simply by running the crashnickle.sh shell
> script.
> 
> -- 
>   James
>   giantrobot@f-m.fm
> 
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle

From jegreen at cs.pdx.edu  Sun Nov 21 16:59:00 2004
From: jegreen at cs.pdx.edu (Jeremy Greenwald)
Date: Sun Nov 21 16:59:10 2004
Subject: [Nickle] petty feature request
Message-ID: <Pine.GSO.4.58.0411211658060.19153@adara.cs.pdx.edu>

	I do most of my programming in Java, so I keep typing // for
single line comments.  Any reason nickle can't allow that style of
commenting?

Gentlemen . . . Behold!

From keithp at keithp.com  Sun Nov 21 18:30:06 2004
From: keithp at keithp.com (Keith Packard)
Date: Sun Nov 21 18:30:18 2004
Subject: [Nickle] petty feature request 
In-Reply-To: Your message of "Sun, 21 Nov 2004 16:59:00 PST."
	<Pine.GSO.4.58.0411211658060.19153@adara.cs.pdx.edu> 
Message-ID: <E1CW3xv-0007dG-4O@evo.keithp.com>


Around 16 o'clock on Nov 21, Jeremy Greenwald wrote:

> 	I do most of my programming in Java, so I keep typing // for
> single line comments.  Any reason nickle can't allow that style of
> commenting?

// is already the integer division operator...

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041121/6a675745/attachment.pgp
From jegreen at cs.pdx.edu  Mon Nov 22 14:55:59 2004
From: jegreen at cs.pdx.edu (Jeremy Greenwald)
Date: Mon Nov 22 14:56:13 2004
Subject: [Nickle] Bug or misunderstanding
Message-ID: <Pine.GSO.4.58.0411221450550.24209@algol.cs.pdx.edu>

	The following was taken from an interactive nickle session:
> int[5,3] twoarr;
> printf("%d %d\n",dims(twoarr)[0], dims(twoarr)[1]);
3 5
Same with the initializer
>     int [*,*] twoarr2 = ([5, 3]) { [i, j] = -1};
> printf("%d %d\n",dims(tworr)[0], dims(twoarr2)[1]);
3 5

Why is the size in the first dimension stored in the second element and
the size in the second dimension stored in the first element returned by
dims?  I would expect the numbers returned by dims to be in the same order
as they were in the declaration/initializer.

Gentlemen . . . Behold!

From bart at cs.pdx.edu  Mon Nov 22 15:34:04 2004
From: bart at cs.pdx.edu (Barton C Massey)
Date: Mon Nov 22 15:34:44 2004
Subject: [Nickle] Re: Bug or misunderstanding 
In-Reply-To: Your message of "Mon, 22 Nov 2004 14:55:59 PST."
	<Pine.GSO.4.58.0411221450550.24209@algol.cs.pdx.edu> 
Message-ID: <200411222334.iAMNY4FD023476@murzim.cs.pdx.edu>

Bug.  I know why it's there, but it violates the principle
of least surprise, as illustrated by your great surprise.
Will fix it when I get a moment's peace :-).

	Bart

In message <Pine.GSO.4.58.0411221450550.24209@algol.cs.pdx.edu> you wrote:
> 	The following was taken from an interactive nickle session:
> > int[5,3] twoarr;
> > printf("%d %d\n",dims(twoarr)[0], dims(twoarr)[1]);
> 3 5
> Same with the initializer
> >     int [*,*] twoarr2 = ([5, 3]) { [i, j] = -1};
> > printf("%d %d\n",dims(tworr)[0], dims(twoarr2)[1]);
> 3 5
> 
> Why is the size in the first dimension stored in the second element and
> the size in the second dimension stored in the first element returned by
> dims?  I would expect the numbers returned by dims to be in the same order
> as they were in the declaration/initializer.
> 
> Gentlemen . . . Behold!

From keithp at keithp.com  Mon Nov 22 18:26:30 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Nov 22 18:26:49 2004
Subject: [Nickle] Re: Bug or misunderstanding 
In-Reply-To: Your message of "Mon, 22 Nov 2004 15:34:04 PST."
	<200411222334.iAMNY4FD023476@murzim.cs.pdx.edu> 
Message-ID: <E1CWQNy-0000E5-5L@evo.keithp.com>


Around 15 o'clock on Nov 22, Jeremy Greenwald wrote:

> Why is the size in the first dimension stored in the second element and
> the size in the second dimension stored in the first element returned by
> dims?  I would expect the numbers returned by dims to be in the same order
> as they were in the declaration/initializer.

Oh.  That does look broken.  Setdims takes the arguments in the other 
order.  One would think these would be symmetrical.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041122/771e3993/attachment.pgp
From giantrobot at f-m.fm  Sat Nov 27 15:05:08 2004
From: giantrobot at f-m.fm (James LaMar)
Date: Sat Nov 27 15:05:25 2004
Subject: [Nickle] Reference semantics are confusing in Nickle
Message-ID: <1101596708.6433.209567740@webmail.messagingengine.com>

I don't understand this behavior:

> &int i = 5
->     &int i = 5;
<stdin>:1: Incompatible types, storage '&int', value 'int', for
initializer
> &int i = reference(5)
&5

Ok, this makes sense.

> (&int)[int] j 
(&int [int]) {}
> j[5] = reference(5)
->     j[5] = reference (5);
<stdin>:4: Incompatible types, left 'int', right '&poly', for =
operation

Why is this ill-typed?

> j[5] = 5
Unhandled exception uninitialized_value ("uninitialized hash element")
<stdin>:5:     j[5] = 5;

Why doesn't this work?

Same confusion with [...] arrays:

> (&int)[...] k = {}
(&int [...]) {}
> k[0] = reference(5)
->     k[0] = reference (5);
<stdin>:9: Incompatible types, left 'int', right '&poly', for =
operation
> k[0] = 0
Unhandled exception invalid_array_bounds ("Array index out of bounds",
(&int [...]) {}, 0)
<stdin>:10:     k[0] = 0;
> 

Yet this works -- after a fashion:

> (&int)[10] l = {[i] = reference(i)}        
(&int [10]) {&0, &1, &2, &3, &4, &5, &6, &7, &8, &9}
> l[0] = 0
0
> l
(&int [10]) {&0, &1, &2, &3, &4, &5, &6, &7, &8, &9}
> l[0] = 1
1
> l
(&int [10]) {&1, &1, &2, &3, &4, &5, &6, &7, &8, &9}
> 

Can someone please straighten me out?
-- 
  James
  giantrobot@f-m.fm


From nickle at po8.org  Sat Nov 27 16:23:13 2004
From: nickle at po8.org (Bart Massey)
Date: Sat Nov 27 16:24:23 2004
Subject: [Nickle] Reference semantics are confusing in Nickle 
In-Reply-To: <1101596708.6433.209567740@webmail.messagingengine.com> 
References: <1101596708.6433.209567740@webmail.messagingengine.com>
Message-ID: <E1CYCrJ-0003e2-00@po8.org>

Confusing doesn't begin to describe it.

The deal is this: references are *initialized* to point to
storage, and then when they are *assigned to* the storage is
stored into.  IOW, the semantic of a reference *initializer*
is that it is treated as bare, while the semantic of a
reference *expression* is that it is syntactic sugar for the
corresponding pointer expression with a star on the front.

An example:

  $ nickle
  > &int x = reference(5);
  > &int x = &5;  /* this works, BTW, and does the right
                     thing with static typechecking */
  > x = &7;  /* static type error: equiv to *(x) = &5; */
  <stdin>:3: Incompatible types, left 'int', right '*int', for = operation
  > &x = &7;  /* ok, this makes x a reference to new storage */
  > x = 9;  /* this changes the value in x's current storage */
  
The hash just makes things more confusing: the same
semantics apply :-).

We're willing to listen to suggestions: we agree that it's
hard to understand.  However, we haven't cooked up any
scheme we like better yet.

HTH,

	Bart

In message <1101596708.6433.209567740@webmail.messagingengine.com> you wrote:
> I don't understand this behavior:
> 
> > &int i = 5
> ->     &int i = 5;
> <stdin>:1: Incompatible types, storage '&int', value 'int', for
> initializer
> > &int i = reference(5)
> &5
> 
> Ok, this makes sense.
> 
> > (&int)[int] j 
> (&int [int]) {}
> > j[5] = reference(5)
> ->     j[5] = reference (5);
> <stdin>:4: Incompatible types, left 'int', right '&poly', for =
> operation
> 
> Why is this ill-typed?
> 
> > j[5] = 5
> Unhandled exception uninitialized_value ("uninitialized hash element")
> <stdin>:5:     j[5] = 5;
> 
> Why doesn't this work?
> 
> Same confusion with [...] arrays:
> 
> > (&int)[...] k = {}
> (&int [...]) {}
> > k[0] = reference(5)
> ->     k[0] = reference (5);
> <stdin>:9: Incompatible types, left 'int', right '&poly', for =
> operation
> > k[0] = 0
> Unhandled exception invalid_array_bounds ("Array index out of bounds",
> (&int [...]) {}, 0)
> <stdin>:10:     k[0] = 0;
> > 
> 
> Yet this works -- after a fashion:
> 
> > (&int)[10] l = {[i] = reference(i)}        
> (&int [10]) {&0, &1, &2, &3, &4, &5, &6, &7, &8, &9}
> > l[0] = 0
> 0
> > l
> (&int [10]) {&0, &1, &2, &3, &4, &5, &6, &7, &8, &9}
> > l[0] = 1
> 1
> > l
> (&int [10]) {&1, &1, &2, &3, &4, &5, &6, &7, &8, &9}
> > 
> 
> Can someone please straighten me out?
> -- 
>   James
>   giantrobot@f-m.fm
> 
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle

From keithp at keithp.com  Sun Nov 28 14:09:06 2004
From: keithp at keithp.com (Keith Packard)
Date: Sun Nov 28 14:09:47 2004
Subject: [Nickle] Reference semantics are confusing in Nickle 
In-Reply-To: Your message of "Sat, 27 Nov 2004 15:05:08 PST."
	<1101596708.6433.209567740@webmail.messagingengine.com> 
Message-ID: <E1CYXEA-0007rb-Jl@evo.keithp.com>


Around 15 o'clock on Nov 27, "James LaMar" wrote:

> > &int i = reference(5)
> &5

You can also just use

	> &int i = &5;

The box operator '&' works fine on rvalues.

> ->     j[5] = reference (5);
> <stdin>:4: Incompatible types, left 'int', right '&poly', for =
> operation
> 
> Why is this ill-typed?

Remember that references are just syntactic sugar for pointers.  In this 
case, j[5] doesn't refer to the reference at j[5], but rather the value 
pointed at by that reference.  Think of any reference expression as the 
equivalent pointer expression with a '*' prepended, and any reference 
expression with '&' as the bare pointer expression.

	int i;
	int j;
	&int r = &i;
	*int p = &i;

	r = 5		 	<=>	*p = 5
	&r = &j;		<=>	p = &j;

So, to store into the array of references, you do:

	&j[5] = &3;

(I note here the pleasing symmetry of the box operator...)

> > j[5] = 5
> Unhandled exception uninitialized_value ("uninitialized hash element")
> <stdin>:5:     j[5] = 5;
> 
> Why doesn't this work?

Same reason; j[5] dereferences the value at j[5], which hasn't been 
initialized yet.

	> &j[5] = &0
	> j[5] = 5

works just fine.

The examples with arrays appear identical to the above discussion with 
hashes.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041128/c1607857/attachment.pgp
From giantrobot at f-m.fm  Mon Nov 29 19:19:09 2004
From: giantrobot at f-m.fm (James LaMar)
Date: Mon Nov 29 19:19:26 2004
Subject: [Nickle] Nickle Bug
Message-ID: <1101784749.7213.209707287@webmail.messagingengine.com>

http://cs.pdx.edu/~jlamar/mintbug.tar.gz

To recreate:

cd mint/src
nickle mint.5c ../grammars/nickle.mnt
-- 
  James
  giantrobot@f-m.fm


From keithp at keithp.com  Mon Nov 29 19:41:25 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Nov 29 19:42:16 2004
Subject: [Nickle] Nickle Bug 
In-Reply-To: Your message of "Mon, 29 Nov 2004 19:19:09 PST."
	<1101784749.7213.209707287@webmail.messagingengine.com> 
Message-ID: <E1CYytP-0002Up-4k@evo.keithp.com>


Cool.  Working...

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041129/11eaddf2/attachment.pgp
From keithp at keithp.com  Mon Nov 29 20:00:19 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Nov 29 20:01:12 2004
Subject: [Nickle] Nickle Bug 
In-Reply-To: Your message of "Mon, 29 Nov 2004 19:19:09 PST."
	<1101784749.7213.209707287@webmail.messagingengine.com> 
Message-ID: <E1CYzBc-0002VD-1z@evo.keithp.com>


You're doing a rather large ** operation; I've seen things like:

	2 ** 3826253832

in bset_union_array. That is rather a large number; are you sure it's 
correct?

(btw, (1 << x) is *way* faster than (2 ** x) in the current 
implementation.  Having nickle catch this case would be a very good idea, 
but you might want to just use << instead in any case; I think it's 
clearer.)

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041129/f843bbbe/attachment.pgp
From giantrobot at f-m.fm  Mon Nov 29 20:48:44 2004
From: giantrobot at f-m.fm (James LaMar)
Date: Mon Nov 29 20:48:51 2004
Subject: [Nickle] Nickle Bug
In-Reply-To: <E1CYzBc-0002VD-1z@evo.keithp.com>
References: <E1CYzBc-0002VD-1z@evo.keithp.com>
Message-ID: <1101790124.10641.209712032@webmail.messagingengine.com>

I'm pretty sure it's not correct, it was my first crack at working on
some speedup. (obviously I dorked something along the way, as Bart might
say)  Thanks for the heads up.
-- 
  James
  giantrobot@f-m.fm


From keithp at keithp.com  Mon Nov 29 21:25:10 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Nov 29 21:25:53 2004
Subject: [Nickle] Nickle Bug 
In-Reply-To: Your message of "Mon, 29 Nov 2004 20:48:44 PST."
	<1101790124.10641.209712032@webmail.messagingengine.com> 
Message-ID: <E1CZ0Vi-0002eh-Vf@evo.keithp.com>


Around 20 o'clock on Nov 29, "James LaMar" wrote:

> I'm pretty sure it's not correct, it was my first crack at working on
> some speedup. (obviously I dorked something along the way, as Bart might
> say)  Thanks for the heads up.

I found the seg fault too -- the call to panic had screwy arguments in 
this case.  Now it nicely aborts with a message.  That should be easier to 
understand at least.  Fixing nickle to gracefully handle out of memory 
even in this seemingly simple case is a much larger task...

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041129/9230fc27/attachment.pgp
From giantrobot at f-m.fm  Tue Nov 30 08:36:44 2004
From: giantrobot at f-m.fm (James LaMar)
Date: Tue Nov 30 08:37:12 2004
Subject: [Nickle] Bitsets considered harmful?
Message-ID: <1101832604.14475.209749476@webmail.messagingengine.com>

The audacious subject of this post is only half-serious -- I'm starting
to think reimplementing the Mint parser generator using bitsets as a set
representation may have been a bad idea.

The reason behind this has to do with the nature of the canonical
collection/closure/first set/goto system of algorithms.  A bit of a
review: this system manipulates sets of LR(1) items.  Closure closes a
set of LR(1) items such that if the parsing location (dot) is in front
of a nonterminal in the set -- a corresponding item is added to that
set.  Goto takes a set of LR(1) items and some symbol and returns a set
which represents a new state of the parser.  The canonical collection
set of algorithms seems to correspond roughly to a breadth first search
of the set of states in the DFA-like entity which represents the parser.

The current implementation maps LR(1) items to integers (powers of 2 in
CVS, but I experimented with consecutive low integers on my own) and one
of the major things that makes mint slow seemed  to be going to and from
this mapping.  Since the set of LR(1) items is so incredibly vast, it
takes a while for the lookup to find the corresponding integer in the
hash table mapping LR(1) items to integers.  This is done (mostly) for
the benefit of the bitsets.

I'm thinking (and tell me if my thinking is wrong) that the other
interesting problem with bitsets is that all set operations are (in
general) linear in the size of domain instead of in the size of the sets
involved.  Set membership in particular is very poor for large domains. 
The constants, however, are so incredibly low that in practice it's a
very efficient set representation -- it's also a good set representation
when the sets being operated on have lots of elements (with respect to
the domain.)  However, the set of all LR(1) items associated with a
grammar is pretty big.  It grows linearly in the number of symbols,
roughly linearly in the average length of the productions, and linearly
again in the number of productions.  Furthermore, the sets of LR(1)
representing the canonical collection are mostly disjoint meaning that
for any appreciable number of sets, the bitset representation becomes
very poor.

I'm starting to think the most efficient repesention of sets of LR(1)
items might be best achieved using a red-black tree -- this would
preclude the need for a mapping from LR(1) items to the integers or the
use of bitsets.  What do you folks think?
-- 
  James
  giantrobot@f-m.fm


From nickle at po8.org  Tue Nov 30 10:37:21 2004
From: nickle at po8.org (Bart Massey)
Date: Tue Nov 30 10:38:36 2004
Subject: [Nickle] Bitsets considered harmful? 
In-Reply-To: <1101832604.14475.209749476@webmail.messagingengine.com> 
References: <1101832604.14475.209749476@webmail.messagingengine.com>
Message-ID: <E1CZCtF-0006yG-00@po8.org>

Note that Nickle contains an efficient implementation of
Math::ilog() which would help a lot with your troubles.
Hashes really aren't the right way to find the first 1 bit.
Actually, ilog() does a lot of unecessary math: I just
checked in a version of Nickle with Math::lsb() in it.  I'll
be shocked if this doesn't solve your lookup speed problem.

Somebody should probably rewrite ilog() to work like lsb()
in the case where base == 2 someday.

	Bart

In message <1101832604.14475.209749476@webmail.messagingengine.com> you wrote:
> The audacious subject of this post is only half-serious -- I'm starting
> to think reimplementing the Mint parser generator using bitsets as a set
> representation may have been a bad idea.
> 
> The reason behind this has to do with the nature of the canonical
> collection/closure/first set/goto system of algorithms.  A bit of a
> review: this system manipulates sets of LR(1) items.  Closure closes a
> set of LR(1) items such that if the parsing location (dot) is in front
> of a nonterminal in the set -- a corresponding item is added to that
> set.  Goto takes a set of LR(1) items and some symbol and returns a set
> which represents a new state of the parser.  The canonical collection
> set of algorithms seems to correspond roughly to a breadth first search
> of the set of states in the DFA-like entity which represents the parser.
> 
> The current implementation maps LR(1) items to integers (powers of 2 in
> CVS, but I experimented with consecutive low integers on my own) and one
> of the major things that makes mint slow seemed  to be going to and from
> this mapping.  Since the set of LR(1) items is so incredibly vast, it
> takes a while for the lookup to find the corresponding integer in the
> hash table mapping LR(1) items to integers.  This is done (mostly) for
> the benefit of the bitsets.
> 
> I'm thinking (and tell me if my thinking is wrong) that the other
> interesting problem with bitsets is that all set operations are (in
> general) linear in the size of domain instead of in the size of the sets
> involved.  Set membership in particular is very poor for large domains. 
> The constants, however, are so incredibly low that in practice it's a
> very efficient set representation -- it's also a good set representation
> when the sets being operated on have lots of elements (with respect to
> the domain.)  However, the set of all LR(1) items associated with a
> grammar is pretty big.  It grows linearly in the number of symbols,
> roughly linearly in the average length of the productions, and linearly
> again in the number of productions.  Furthermore, the sets of LR(1)
> representing the canonical collection are mostly disjoint meaning that
> for any appreciable number of sets, the bitset representation becomes
> very poor.
> 
> I'm starting to think the most efficient repesention of sets of LR(1)
> items might be best achieved using a red-black tree -- this would
> preclude the need for a mapping from LR(1) items to the integers or the
> use of bitsets.  What do you folks think?
> -- 
>   James
>   giantrobot@f-m.fm
> 
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle

From giantrobot at f-m.fm  Tue Nov 30 11:11:32 2004
From: giantrobot at f-m.fm (James LaMar)
Date: Tue Nov 30 11:11:46 2004
Subject: [Nickle] Bitsets considered harmful?
In-Reply-To: <E1CZCtF-0006yG-00@po8.org>
References: <1101832604.14475.209749476@webmail.messagingengine.com>
	<E1CZCtF-0006yG-00@po8.org>
Message-ID: <1101841892.910.209764118@webmail.messagingengine.com>

Somehow I'm not making the right connection about how efficiently
finding the lsb solves the problem of mapping LR(1) items to consecutive
integers efficiently.  Can you explain this in more detail?  In the
current implementation, hashes are used only to map stuff (items,
strings) to consecutive integers so they can be used in bitsets -- is
this a wrongheaded notion?  If I have all the productions in the grammar
shoved into a similar integer <-> production mapping, I could create an
efficient bijection between the natural numbers like so:

For an LR(1) item with nonterminal S, production prod, and 'next' symbol
next:  
    
   S -> prod, next

Create an integer i such that:
i = (integer representing "next") + (integer representing "S") * (number
of symbols) +  (integer representing prod) * (number of symbols) ** 2

But this may not sufficiently speed up the set operation that's killing
us most -- union on bitsets in the domain of LR(1) item integer
representations.

On Tue, 30 Nov 2004 10:37:21 -0800, "Bart Massey" <nickle@po8.org> said:
> Note that Nickle contains an efficient implementation of
> Math::ilog() which would help a lot with your troubles.
> Hashes really aren't the right way to find the first 1 bit.
> Actually, ilog() does a lot of unecessary math: I just
> checked in a version of Nickle with Math::lsb() in it.  I'll
> be shocked if this doesn't solve your lookup speed problem.
> 
> Somebody should probably rewrite ilog() to work like lsb()
> in the case where base == 2 someday.
> 
> 	Bart
> 
> In message <1101832604.14475.209749476@webmail.messagingengine.com> you
> wrote:
> > The audacious subject of this post is only half-serious -- I'm starting
> > to think reimplementing the Mint parser generator using bitsets as a set
> > representation may have been a bad idea.
> > 
> > The reason behind this has to do with the nature of the canonical
> > collection/closure/first set/goto system of algorithms.  A bit of a
> > review: this system manipulates sets of LR(1) items.  Closure closes a
> > set of LR(1) items such that if the parsing location (dot) is in front
> > of a nonterminal in the set -- a corresponding item is added to that
> > set.  Goto takes a set of LR(1) items and some symbol and returns a set
> > which represents a new state of the parser.  The canonical collection
> > set of algorithms seems to correspond roughly to a breadth first search
> > of the set of states in the DFA-like entity which represents the parser.
> > 
> > The current implementation maps LR(1) items to integers (powers of 2 in
> > CVS, but I experimented with consecutive low integers on my own) and one
> > of the major things that makes mint slow seemed  to be going to and from
> > this mapping.  Since the set of LR(1) items is so incredibly vast, it
> > takes a while for the lookup to find the corresponding integer in the
> > hash table mapping LR(1) items to integers.  This is done (mostly) for
> > the benefit of the bitsets.
> > 
> > I'm thinking (and tell me if my thinking is wrong) that the other
> > interesting problem with bitsets is that all set operations are (in
> > general) linear in the size of domain instead of in the size of the sets
> > involved.  Set membership in particular is very poor for large domains. 
> > The constants, however, are so incredibly low that in practice it's a
> > very efficient set representation -- it's also a good set representation
> > when the sets being operated on have lots of elements (with respect to
> > the domain.)  However, the set of all LR(1) items associated with a
> > grammar is pretty big.  It grows linearly in the number of symbols,
> > roughly linearly in the average length of the productions, and linearly
> > again in the number of productions.  Furthermore, the sets of LR(1)
> > representing the canonical collection are mostly disjoint meaning that
> > for any appreciable number of sets, the bitset representation becomes
> > very poor.
> > 
> > I'm starting to think the most efficient repesention of sets of LR(1)
> > items might be best achieved using a red-black tree -- this would
> > preclude the need for a mapping from LR(1) items to the integers or the
> > use of bitsets.  What do you folks think?
> > -- 
> >   James
> >   giantrobot@f-m.fm
> > 
> > 
> > _______________________________________________
> > Nickle mailing list
> > Nickle@nickle.org
> > http://nickle.org/mailman/listinfo/nickle
-- 
  James
  giantrobot@f-m.fm


