From cworth at cworth.org  Thu Jan  6 10:55:28 2005
From: cworth at cworth.org (Carl Worth)
Date: Thu Jan  6 11:10:09 2005
Subject: [Nickle] Re: [AI] Nickle Growing Pains 
In-Reply-To: <200412010828.iB18SGNx013125@adara.cs.pdx.edu>
References: <A23D349A-436C-11D9-AF91-000A95701ACA@cs.pdx.edu>
	<200412010828.iB18SGNx013125@adara.cs.pdx.edu>
Message-ID: <m37jmq4cbj.wl@raht.localdomain>

On Wed, 01 Dec 2004 00:28:16 -0800, Barton C Massey wrote:
> since all Nickle functions return a value.  It can
> be useful to use the void type with Nickle's disjoint
> union types.
> 
>   enum { a, b }
> 
> is shorthand for
> 
>   union { void a, void b }

The enum-as-disjoint-union is an interesting implementation detail,
but I would hope I could use enum types without having to know about
it.

> which should probably make your head hurt :-(.
> You can thus say things like
> 
>   typedef enum { a, b } e;
>   e v;
>   v.a = <>;
>   union switch(v) {
>   case a: printf("a\n"); break;
>   case b: printf("b\n"); break;
>   }  

The code above was written to demonstrate void and <>. Rewriting in a
more conventional enum style gives:

	typedef enum { a, b } e;
	e v;
	v = e.a;
	enum switch(v) {
	case a: printf("a\n"); break;
	case b: printf("b\n"); break;
	}

The "v = e.a" and "enum switch" syntax help hide the underlying
disjoint union quite well. But it leaks out quite badly with:

	> v
	a = <>

Can that be easily fixed to print "e.a" as expected?

-Carl

From keithp at keithp.com  Thu Jan  6 11:56:39 2005
From: keithp at keithp.com (Keith Packard)
Date: Thu Jan  6 11:56:54 2005
Subject: [Nickle] Re: [AI] Nickle Growing Pains 
In-Reply-To: Your message of "Thu, 06 Jan 2005 13:55:28 EST."
	<m37jmq4cbj.wl@raht.localdomain> 
Message-ID: <E1CmdkN-0006ts-MB@evo.keithp.com>


Around 13 o'clock on Jan 6, Carl Worth wrote:

> The enum-as-disjoint-union is an interesting implementation detail,
> but I would hope I could use enum types without having to know about
> it.

It would be better if we had more sane syntax for disjoint unions; having 
borrowed C's union syntax is not obviously the right answer here.

>	> v
>	a = <>
>
> Can that be easily fixed to print "e.a" as expected?

Because we use 'typedef' to bind the name 'e' to the union type, the value 
itself has no referent to that name, only the underlying union type.

We could easily fix it to pring only 'a' instead of 'a = <>', if that 
would appeal.

-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/20050106/9d95829f/attachment.pgp
From cworth at cworth.org  Thu Jan  6 12:30:38 2005
From: cworth at cworth.org (Carl Worth)
Date: Thu Jan  6 12:31:09 2005
Subject: [Nickle] Re: [AI] Nickle Growing Pains 
In-Reply-To: <E1CmdkN-0006ts-MB@evo.keithp.com>
References: <m37jmq4cbj.wl@raht.localdomain> <E1CmdkN-0006ts-MB@evo.keithp.com>
Message-ID: <m31xcy47wx.wl@raht.localdomain>

On Thu, 06 Jan 2005 11:56:39 -0800, Keith Packard wrote:
> Because we use 'typedef' to bind the name 'e' to the union type, the value 
> itself has no referent to that name, only the underlying union type.

Hmmm...

> We could easily fix it to pring only 'a' instead of 'a = <>', if that 
> would appeal.

Not much.

Neither one is usable as value to assign back to v. But I think you
were recently planning on reworking the printing to make things like
this more consistent anyway, right?

-Carl

From keithp at keithp.com  Thu Jan  6 12:50:51 2005
From: keithp at keithp.com (Keith Packard)
Date: Thu Jan  6 12:50:57 2005
Subject: [Nickle] Re: [AI] Nickle Growing Pains 
In-Reply-To: Your message of "Thu, 06 Jan 2005 15:30:38 EST."
	<m31xcy47wx.wl@raht.localdomain> 
Message-ID: <E1Cmeap-000756-2k@evo.keithp.com>


Around 15 o'clock on Jan 6, Carl Worth wrote:

> > Because we use 'typedef' to bind the name 'e' to the union type, the value 
> > itself has no referent to that name, only the underlying union type.
> 
> Hmmm...

We don't have names for structures and unions at present, but we could.  
And, we could make them 'type names', something C doesn't do; I suspect 
that's largely because C's typenames are unscoped.

So, you could declare:

	enum e { a, b, c };

and nickle could then print out the enum typename along with the tag:

	e.a

Of course, if you used a typedef:

	typedef enum { a, b, c } foo;

then there would be no name to print.  We could print out the value as:

	(enum { a, b, c }).a

in that case, which might encourage people to provide typenames...

-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/20050106/a1a3e59b/attachment.pgp
From nickle at po8.org  Fri Jan 14 01:46:44 2005
From: nickle at po8.org (nickle@po8.org)
Date: Fri Jan 14 01:46:50 2005
Subject: [Nickle] Nickle bug (I think): function reference return sugaring
Message-ID: <E1CpO2X-0006ja-00@po8.org>

Consider

    > &int f() { return &3; }	

OK, Nickle is happy with this.  But if I try to use it the
way I expected, I get troubles:

    > f()
    &3
    > f() + 1
    Unhandled exception invalid_array_bounds ("Element out of
    range in reference addition", &3, 1)
    <stdin>:3:     f () + 1;
    > *(f()) + 1
    4
    >

In short, for functions, Nickle seems to treat reference
returns just like pointer returns.  I want it to be sugared
like with other kinds of locations:

    > &int x = &3;
    > x
    3
    > x + 1
    4

Am I confused?

	Bart

From keithp at keithp.com  Fri Jan 14 08:59:15 2005
From: keithp at keithp.com (Keith Packard)
Date: Fri Jan 14 08:59:23 2005
Subject: [Nickle] Nickle bug (I think): function reference return sugaring
In-Reply-To: Your message of "Fri, 14 Jan 2005 01:46:44 PST."
	<E1CpO2X-0006ja-00@po8.org> 
Message-ID: <E1CpUn5-0002i6-V6@evo.keithp.com>


Around 1 o'clock on Jan 14, nickle@po8.org wrote:

> In short, for functions, Nickle seems to treat reference
> returns just like pointer returns.  I want it to be sugared
> like with other kinds of locations:

Just a bug.  As usual, 'cvs update' will fix it.

-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/20050114/436ddd5a/attachment.pgp
From nickle at po8.org  Sat Jan 15 00:47:43 2005
From: nickle at po8.org (Bart Massey)
Date: Sat Jan 15 00:47:48 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays
Message-ID: <E1Cpjax-0007rI-00@po8.org>

Nickle has a nice feature wrt arrays: storage is
auto-allocated.  For growable arrays, this means that
this works

    > int[...] x;
    > &int xr = &x[0]
    &<uninit>
    > xr = 3
    3
    > x
    (int [...]) {3}

But now consider the sad case of growable arrays of growable
arrays...

    > int[...][...] x;
    > &int[...] xr = &x[0]
    &<uninit>
    > &int xrr = &xr[0]
    Unhandled exception uninitialized_value ("Uninitialized value")
    <stdin>:3:     &int xrr = &xr[0]

The elements of the subarray appear not to be initialized on
demand as expected.

Am I missing something?

	Bart

From keithp at keithp.com  Sat Jan 15 11:06:26 2005
From: keithp at keithp.com (Keith Packard)
Date: Sat Jan 15 11:06:44 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays 
In-Reply-To: Your message of "Sat, 15 Jan 2005 00:47:43 PST."
	<E1Cpjax-0007rI-00@po8.org> 
Message-ID: <E1CptFi-0007HZ-8p@evo.keithp.com>


Around 0 o'clock on Jan 15, "Bart Massey" wrote:

> Nickle has a nice feature wrt arrays: storage is
> auto-allocated.  For growable arrays, this means that
> this works

Urgh.  Nickle has two separate mechanisms for initializing storage, one is 
when variables are declared -- the compiler emits code to create an 
appropriate value if none is provided.  The second mechanism is when an 
uninitialized box is fetched -- the box is filled with a default value for 
the specified type, but only if it is of type struct or union.  As boxes 
are rarely left uninitialized any more, this doesn't get hit all that 
often, except in the case of a resizable array.  You can see this with:

	> int[...] a;
	> &int ip = &a[0];
	> ip
	Unhandled exception uninitialized_value ("Uninitialized value")
	<stdin>:3:     ip;

Contrast this with:

	> typedef struct { int i; } s_t;
	> s_t[...] a;
	> &s_t sp = &a[0];
	> sp
	{i = <uninit>}

Arrays are currently not automatically included in this particular 
automatic initialization.

I tried (briefly) to make it work, but finding the array dimension 
information is hard -- the dimensions are stored in an array which is 
created and initialized when the array declaration is executed.  For 
declarations in global scope, or for resizable arrays, the answer is easy.

However, if this declaration is in a dynamic scope, the array itself is
hanging from a frame somewhere.  I don't currently have enough information
to go find this frame, and I'm not quite sure how I'm going to go about
locating it yet.

Also, what should I do with '*' arrays?  Any size I pick seems wrong.

-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/20050115/2ea6dfad/attachment.pgp
From nickle at po8.org  Sat Jan 15 11:48:43 2005
From: nickle at po8.org (Bart Massey)
Date: Sat Jan 15 11:48:47 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays 
In-Reply-To: <E1CptFi-0007HZ-8p@evo.keithp.com> 
References: <E1CptFi-0007HZ-8p@evo.keithp.com>
Message-ID: <E1Cptud-0008NE-00@po8.org>

In message <E1CptFi-0007HZ-8p@evo.keithp.com> you wrote:
> Around 0 o'clock on Jan 15, "Bart Massey" wrote:
> 
> > Nickle has a nice feature wrt arrays: storage is
> > auto-allocated.  For growable arrays, this means that
> > this works
> 
> Urgh.  Nickle has two separate mechanisms for initializing storage, one is 
> when variables are declared -- the compiler emits code to create an 
> appropriate value if none is provided.  The second mechanism is when an 
> uninitialized box is fetched -- the box is filled with a default value for 
> the specified type, but only if it is of type struct or
> union.

Sigh.  Do we want this
   struct {int x;} s;
to be different from this?
   struct {int x;} s = {};
I think there's a case to be made for this distinction.  If
so, it's clear what to do with structures, unions, and
normal arrays, and shouldn't require the current lazy
initialization mechanism.

For growable arrays, it gets more complicated, since
growable arrays of objects (of any type) don't have a
"default value" like hashes do.  This should probably be
fixed.  Perhaps things like
   int[...][...] a = {{} ...};
should work?

> Also, what should I do with '*' arrays?  Any size I pick seems wrong.

Given the previous it seems clear that a * array that is
uninitialized is not an array.  This makes things much easier.

Am I confused somewhere?

    Bart

From nickle at po8.org  Sat Jan 15 11:51:15 2005
From: nickle at po8.org (Bart Massey)
Date: Sat Jan 15 11:51:18 2005
Subject: [Nickle] Bug: reference addition bounds check on arrays
Message-ID: <E1Cptx5-0008Ne-00@po8.org>

I *think* this was supposed to work.

    $ nickle
    > int[3] a;
    > *(int[*]) ar = &a;
    > *(int[*]) ar = &a + 1;
    Unhandled exception invalid_array_bounds ("Element out of range in reference addition", &(int [3]) {<uninit>,<uninit>, <uninit>}, 1)
    <stdin>:3:     *int[*] ar = &a + 1;
    >

I'll look at this bug, but if someone beats me to it...

This is the last thing keeping LOL from working.  I will
implement some slightly icky workaround for now.

	Bart

From keithp at keithp.com  Sat Jan 15 13:35:00 2005
From: keithp at keithp.com (Keith Packard)
Date: Sat Jan 15 13:35:18 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays 
In-Reply-To: Your message of "Sat, 15 Jan 2005 11:48:43 PST."
	<E1Cptud-0008NE-00@po8.org> 
Message-ID: <E1CpvZU-0007Q2-PL@evo.keithp.com>


Around 11 o'clock on Jan 15, "Bart Massey" wrote:

> Sigh.  Do we want this
>    struct {int x;} s;
> to be different from this?
>    struct {int x;} s = {};

The reasoning was that in C, composite datatypes are automatically 
allocated but not automatically initialized, so we wanted things in nickle 
to work about the same -- storage automatically allocated, but values left 
uninitialized.

> For growable arrays, it gets more complicated, since
> growable arrays of objects (of any type) don't have a
> "default value" like hashes do.  This should probably be
> fixed.  Perhaps things like
>    int[...][...] a = {{} ...};
> should work?

We've shied from this because comprehensions make it "hard".  Although 
it would be cool:

	int[...] primes = { [i] = nth_prime(i,[]) };

could lazily compute all primes with a sieve...

-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/20050115/9baea9c8/attachment.pgp
From keithp at keithp.com  Sat Jan 15 13:36:28 2005
From: keithp at keithp.com (Keith Packard)
Date: Sat Jan 15 13:36:45 2005
Subject: [Nickle] Bug: reference addition bounds check on arrays 
In-Reply-To: Your message of "Sat, 15 Jan 2005 11:51:15 PST."
	<E1Cptx5-0008Ne-00@po8.org> 
Message-ID: <E1Cpvau-0007Rv-EJ@evo.keithp.com>


Around 11 o'clock on Jan 15, "Bart Massey" wrote:

> I *think* this was supposed to work.
> 
>     > int[3] a;
>     > *(int[*]) ar = &a;
>     > *(int[*]) ar = &a + 1;
>     Unhandled exception invalid_array_bounds ("Element out of range in reference addition", &(int [3]) {<uninit>,<uninit>, <uninit>}, 1)
>     <stdin>:3:     *int[*] ar = &a + 1;
>     >

Nope, this isn't supposed to work -- you're referencing the array, not an 
element of the array and the array is in a box with a single element.

What are you trying to get?

-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/20050115/2fc1f82b/attachment.pgp
From nickle at po8.org  Sat Jan 15 13:40:28 2005
From: nickle at po8.org (Bart Massey)
Date: Sat Jan 15 13:40:41 2005
Subject: [Nickle] Bug: reference addition bounds check on arrays 
In-Reply-To: <E1Cpvau-0007Rv-EJ@evo.keithp.com> 
References: <E1Cpvau-0007Rv-EJ@evo.keithp.com>
Message-ID: <E1Cpvem-0008UA-00@po8.org>

Trying to get the subarray starting at k.  Maybe I can't do that.

	Bart

In message <E1Cpvau-0007Rv-EJ@evo.keithp.com> you wrote:
> --===============0971340670==
> Content-Type: multipart/signed; boundary="==_Exmh_1310222828P";
> 	micalg=pgp-sha1; protocol="application/pgp-signature"
> Content-Transfer-Encoding: 7bit
> 
> --==_Exmh_1310222828P
> Content-Type: text/plain; charset=utf-8
> 
> 
> Around 11 o'clock on Jan 15, "Bart Massey" wrote:
> 
> > I *think* this was supposed to work.
> > 
> >     > int[3] a;
> >     > *(int[*]) ar = &a;
> >     > *(int[*]) ar = &a + 1;
> >     Unhandled exception invalid_array_bounds ("Element out of range in reference addition", &(int [3]) {<uninit>,<uninit>, <uninit>}, 1)
> >     <stdin>:3:     *int[*] ar = &a + 1;
> >     >
> 
> Nope, this isn't supposed to work -- you're referencing the array, not an 
> element of the array and the array is in a box with a single element.
> 
> What are you trying to get?
> 
> -keith
> 
> 
> 
> --==_Exmh_1310222828P
> Content-Type: application/pgp-signature
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Exmh version 2.3.1 11/28/2001
> 
> iD8DBQFB6YzcQp8BWwlsTdMRAhMrAKC6lmfjLhk+76C9zj5mG7hncLwGBgCgk4B8
> /Yb1ZTofuPg9OiJcxoMDjp0=
> =gkO0
> -----END PGP SIGNATURE-----
> 
> --==_Exmh_1310222828P--
> 
> 
> --===============0971340670==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle
> 
> --===============0971340670==--
> 

From nickle at po8.org  Sat Jan 15 13:45:08 2005
From: nickle at po8.org (Bart Massey)
Date: Sat Jan 15 13:45:14 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays 
In-Reply-To: <E1CpvZU-0007Q2-PL@evo.keithp.com> 
References: <E1CpvZU-0007Q2-PL@evo.keithp.com>
Message-ID: <E1CpvjI-0008Uj-00@po8.org>

If you want things to be like C, you can just make
   struct s;
mean
   struct s = {};
and similarly for arrays.

Shy of growable array initializers via continuations :-), I
would just like initializer expressions to work like they do
for hashes.  This would at least take care of the nested
growable array case, which is the thing I normally care
about anyhow.  And after all, we don't have hash
comprehensions.

	Bart

In message <E1CpvZU-0007Q2-PL@evo.keithp.com> you wrote:
> --===============1729504572==
> Content-Type: multipart/signed; boundary="==_Exmh_1309921132P";
> 	micalg=pgp-sha1; protocol="application/pgp-signature"
> Content-Transfer-Encoding: 7bit
> 
> --==_Exmh_1309921132P
> Content-Type: text/plain; charset=utf-8
> 
> 
> Around 11 o'clock on Jan 15, "Bart Massey" wrote:
> 
> > Sigh.  Do we want this
> >    struct {int x;} s;
> > to be different from this?
> >    struct {int x;} s = {};
> 
> The reasoning was that in C, composite datatypes are automatically 
> allocated but not automatically initialized, so we wanted things in nickle 
> to work about the same -- storage automatically allocated, but values left 
> uninitialized.
> 
> > For growable arrays, it gets more complicated, since
> > growable arrays of objects (of any type) don't have a
> > "default value" like hashes do.  This should probably be
> > fixed.  Perhaps things like
> >    int[...][...] a = {{} ...};
> > should work?
> 
> We've shied from this because comprehensions make it "hard".  Although 
> it would be cool:
> 
> 	int[...] primes = { [i] = nth_prime(i,[]) };
> 
> could lazily compute all primes with a sieve...
> 
> -keith
> 
> 
> 
> --==_Exmh_1309921132P
> Content-Type: application/pgp-signature
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Exmh version 2.3.1 11/28/2001
> 
> iD8DBQFB6YyEQp8BWwlsTdMRAkk6AKDcoPB+Sol7WOLE2KMeGrJjbyxorgCggNxL
> KotIs1Pl2rmg1wfg6jq6ZSc=
> =6aaR
> -----END PGP SIGNATURE-----
> 
> --==_Exmh_1309921132P--
> 
> 
> --===============1729504572==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle
> 
> --===============1729504572==--
> 

From keithp at keithp.com  Sat Jan 15 15:17:07 2005
From: keithp at keithp.com (Keith Packard)
Date: Sat Jan 15 15:17:25 2005
Subject: [Nickle] Bug: reference addition bounds check on arrays 
In-Reply-To: Your message of "Sat, 15 Jan 2005 13:40:28 PST."
	<E1Cpvem-0008UA-00@po8.org> 
Message-ID: <E1CpxAJ-0007XP-TN@evo.keithp.com>


Around 13 o'clock on Jan 15, "Bart Massey" wrote:

> Trying to get the subarray starting at k.  Maybe I can't do that.

You made me get rid of array indexing on pointers...

You can, however, do:

> int[10] a = { [i] = i };
> *int ap = &a[3];
> ap
&3
> *(ap + 1)
4
>

If you want re-indexable arrays, there's a bit of work to do.  I don't 
think it's impossible...

-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/20050115/85c63eff/attachment.pgp
From keithp at keithp.com  Sat Jan 15 15:37:46 2005
From: keithp at keithp.com (Keith Packard)
Date: Sat Jan 15 15:38:05 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays 
In-Reply-To: Your message of "Sat, 15 Jan 2005 13:45:08 PST."
	<E1CpvjI-0008Uj-00@po8.org> 
Message-ID: <E1CpxUI-0007d0-CR@evo.keithp.com>


Around 13 o'clock on Jan 15, "Bart Massey" wrote:

> If you want things to be like C, you can just make
>    struct s;
> mean
>    struct s = {};
> and similarly for arrays.

Right, that's what we have today.

> Shy of growable array initializers via continuations :-), I
> would just like initializer expressions to work like they do
> for hashes.  This would at least take care of the nested
> growable array case, which is the thing I normally care
> about anyhow.  And after all, we don't have hash
> comprehensions.

Hashes have a 'default value' which is used to initialize any 
uninitialized element when referenced.  We could do the same for growable 
arrays if that would be sufficient, and I can compute that when the array 
is computed.  The trouble I'm having now is how to compute a nested array 
value when the array is used in some completely different context.  I 
don't, in general, have a pointer back to the frame holding the dimension 
information for the nested array.

-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/20050115/09b34585/attachment.pgp
From keithp at keithp.com  Sat Jan 15 17:19:17 2005
From: keithp at keithp.com (Keith Packard)
Date: Sat Jan 15 17:19:35 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays 
In-Reply-To: Your message of "Sat, 15 Jan 2005 13:45:08 PST."
	<E1CpvjI-0008Uj-00@po8.org> 
Message-ID: <E1Cpz4X-0008Ea-Kr@evo.keithp.com>


Ok, so presumably:

	int[...] x = { 0 ... }; 

means to set the default array value to 0 and to initially create the 
array with zero elements.  That seems straightforward.  So, what does:

	int[...,...] x = { { 0, 1 ... }, { 2, 3 ... } ... };

mean?  Now the array has an ambiguous default value.  I guess the default 
value must occur as a bare value in the outermost array initializer?  Like:

	int[...,...] x = { { 0, 1 }, { 2, 3 }, 4 ... };

Does that look right?

-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/20050115/54e8a45c/attachment.pgp
From nickle at po8.org  Sat Jan 15 20:36:39 2005
From: nickle at po8.org (nickle@po8.org)
Date: Sat Jan 15 20:36:43 2005
Subject: [Nickle] Bug: reference addition bounds check on arrays 
In-Reply-To: <E1CpxAJ-0007XP-TN@evo.keithp.com> 
References: <E1CpxAJ-0007XP-TN@evo.keithp.com>
Message-ID: <E1Cq29X-0000Lo-00@po8.org>

Naw, leave them alone.  It's fine.

	Bart

In message <E1CpxAJ-0007XP-TN@evo.keithp.com> you wrote:
> --===============1046451306==
> Content-Type: multipart/signed; boundary="==_Exmh_1352835031P";
> 	micalg=pgp-sha1; protocol="application/pgp-signature"
> Content-Transfer-Encoding: 7bit
> 
> --==_Exmh_1352835031P
> Content-Type: text/plain; charset=utf-8
> 
> 
> Around 13 o'clock on Jan 15, "Bart Massey" wrote:
> 
> > Trying to get the subarray starting at k.  Maybe I can't do that.
> 
> You made me get rid of array indexing on pointers...
> 
> You can, however, do:
> 
> > int[10] a = { [i] = i };
> > *int ap = &a[3];
> > ap
> &3
> > *(ap + 1)
> 4
> >
> 
> If you want re-indexable arrays, there's a bit of work to do.  I don't 
> think it's impossible...
> 
> -keith
> 
> 
> 
> --==_Exmh_1352835031P
> Content-Type: application/pgp-signature
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Exmh version 2.3.1 11/28/2001
> 
> iD8DBQFB6aRzQp8BWwlsTdMRAoJVAJ41pqCc6h0qtB54TrAnx85/hNy2SgCgmz25
> DstAxxGwnGZIoTPgvIEpT/o=
> =L1CB
> -----END PGP SIGNATURE-----
> 
> --==_Exmh_1352835031P--
> 
> 
> --===============1046451306==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Nickle mailing list
> Nickle@nickle.org
> http://nickle.org/mailman/listinfo/nickle
> 
> --===============1046451306==--
> 

From nickle at po8.org  Sat Jan 15 20:42:43 2005
From: nickle at po8.org (nickle@po8.org)
Date: Sat Jan 15 20:42:49 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays 
In-Reply-To: <E1CpxUI-0007d0-CR@evo.keithp.com> 
References: <E1CpxUI-0007d0-CR@evo.keithp.com>
Message-ID: <E1Cq2FP-0000Mf-00@po8.org>

In message <E1CpxUI-0007d0-CR@evo.keithp.com> you wrote:
> Around 13 o'clock on Jan 15, "Bart Massey" wrote:
> 
> > If you want things to be like C, you can just make
> >    struct s;
> > mean
> >    struct s = {};
> > and similarly for arrays.
> 
> Right, that's what we have today.

It didn't sound like it for your earlier description.  It
sounded like you had some lazy initialization thing going
on.  Did I misunderstand?

> > Shy of growable array initializers via continuations :-), I
> > would just like initializer expressions to work like they do
> > for hashes.  This would at least take care of the nested
> > growable array case, which is the thing I normally care
> > about anyhow.  And after all, we don't have hash
> > comprehensions.
> 
> Hashes have a 'default value' which is used to initialize any 
> uninitialized element when referenced.  We could do the same for growable 
> arrays if that would be sufficient, and I can compute that when the array 
> is computed.

That's what I was hoping for.

> The trouble I'm having now is how to compute a nested array 
> value when the array is used in some completely different context.  I 
> don't, in general, have a pointer back to the frame holding the dimension 
> information for the nested array.

Just do the same thing with arrays you do with structs: let
  int[...][...] a;
be shorthand for
  int[...][...] a = {{} ...};
and the default value should take care of it, I think?

     bart

From keithp at keithp.com  Sun Jan 16 00:09:54 2005
From: keithp at keithp.com (Keith Packard)
Date: Sun Jan 16 00:10:15 2005
Subject: [Nickle] Nickle bug/misfeature: storage for growable arrays of
	growable arrays 
In-Reply-To: Your message of "Sat, 15 Jan 2005 20:42:43 PST."
	<E1Cq2FP-0000Mf-00@po8.org> 
Message-ID: <E1Cq5Tu-0008SQ-Nk@evo.keithp.com>


Around 20 o'clock on Jan 15, nickle@po8.org wrote:

> Just do the same thing with arrays you do with structs: let
>   int[...][...] a;
> be shorthand for
>   int[...][...] a = {{} ...};
> and the default value should take care of it, I think?

No, the problem is with:

	int[...][*] foo (int i) { return (int[...][i]) { { 1, ... } }; }
	a = foo (10);
	&int[*] b = &a[1];

At this point, I should have initialized a[1], but I no longer have any 
idea what size the array should be, even though the type declaration which 
created it makes the size quite evident.  The value for this array 
dimension is a local variable in foo scope...

With a single default value which is connected to the resizable array, 
this will be trivial.  I've gotten started on that, but it's a bit tricky 
as I have to semantically disambiguate between the default resizable array 
initializer and a repeated non-resizable array initializer.  There's no 
conflict; repeated initializers were not previous permitted for resiable 
arrays.

-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/20050116/43c4bfda/attachment-0001.pgp
From nickle at po8.org  Sun Jan 16 00:11:49 2005
From: nickle at po8.org (Bart Massey)
Date: Sun Jan 16 00:11:54 2005
Subject: [Nickle] LOL alpha release
Message-ID: <E1Cq5Vl-0000WD-00@po8.org>

The LOL LL(1) parser generator is a straightforward Nickle
implementation of an LL(1) parse-table builder.  It is
intended to supplant the ancient Lola tool that Keith wrote
in Kalypso ages ago and we've been using ever since.

LOL uses James and Emma's MINT parser-generator tools for
its description grammar, making it easy to adapt and giving
it reasonable syntax.  Indeed, the existence of MINT makes
MerryMINT largely of academic and historic interest, but
that's OK.  Sometimes LL(1) is what you wanted, although not
very often.

Please unpack the attached LOL source tarball in the latest
MINT CVS src directory.  We need to figure out how to
separate the MINT runtime from the MINT generator more
effectively, so that LOL can live in its own directory tree.

	Bart Massey
	bart@cs.pdx.edu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-tar
Size: 3031 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20050116/c34c9916/attachment.tar
