From keithp@keithp.com Tue, 13 Feb 2001 17:31:57 -0800
Date: Tue, 13 Feb 2001 17:31:57 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]First post

This is mostly to get the archive running.

-keith






From bart@cs.pdx.edu Wed, 14 Feb 2001 12:04:53 -0800
Date: Wed, 14 Feb 2001 12:04:53 -0800
From: Barton C Massey bart@cs.pdx.edu
Subject: [Nickle]Nickle functionality and documentation

In message <2213.982178850@localhost> you wrote:
> In message <200102140912.BAA17828@sirius.cs.pdx.edu>, Barton C Massey writes:> 
>     There's namespaces, with appropriate scoping rules.
>     One of the examples should show this.  Do you need more?
> 
> Woah, coooool. I think I'm impressed!

:-)

> > Note that there are also first-class functions with static
> > scope and highly controllable lifetime for locals.
> 
> So when do you present a paper on this, or didn't you already?
> Where's the PostScript?

The paper has been accepted for the Freenix track of Usenix
this summer: all we have right now is an extended abstract,
which really doesn't say very much yet.  I'm working on docs
in my copious spare time; I'll write the paper after the
docs are done and the language is mostly frozen and
generally released.  Hopefully that's sometime soon.

> I think it's time for a Nickle FAQ, don't you?

Probably should finish the documentation first.  Updating
the manual page will be a good start: we should probably
mention some of these features you've been discussing
(threads, namespaces, first-class functions) in there.  :-)

> I've notified
> NetApp management that I'm on the project, so I should be able
> to put time into it now without worries.

Very cool!  One first possibility would be for you to read
the grammar for namespaces, experiment until you understand
it or get explanations from Keith or myself, and then write
that section of the manual...  This is on the top of my
documentation to-do list, actually.

> I'd like to make it easy for you guys, so if you have any
> preferences for formatting tools let me know.

Not particularly.  We use everything, and hate it all. :-)
You don't know of anything *nice*, do you?  HTML-ability a
big plus.  My first choice would be a full SGML
implementation, but last I checked Jade wasn't quite there
yet, IIRC.

The paper will be in LaTeX, of course, so detailed technical
description probably just wants to start there.

			Bart




From bart@cs.pdx.edu Sat, 17 Feb 2001 21:51:00 -0800
Date: Sat, 17 Feb 2001 21:51:00 -0800
From: Barton C Massey bart@cs.pdx.edu
Subject: [Nickle]Nickle: new builtins

New builtins checked into nickle:

  New scope strings, with functions
    int length(string)
    int index(target-string, match-string)
    string substr(target-string, start-index, length)
  All of these have essentially the AWK semantics,
  except 0-based instead of 1-based.

  int dim(array)
    Number of elements in a 1-dimensional array.
  array dims(array)
    1-dimensional array of n elements giving
    each dimension in an n-dimensional array.

I'll get the library autoloader installed and re-install the
rest of the PRNG shortly.  I'll probably also slightly clean
up the nickle command-line argument handling here shortly.

Have fun!

		Bart




From keithp@keithp.com Mon, 19 Feb 2001 18:45:46 -0800
Date: Mon, 19 Feb 2001 18:45:46 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]Re: Nickle: array assignment?

Around 21 o'clock on Feb 17, Barton C Massey wrote:
> Right now, after
>   a = [3]{1,2,3};
>   b = a;
> b is a reference to the same array as a.  Is this the
> "right" semantic?  If so, is there any way to make b be a
> copy of a, which is also often desirable?  In particular,
> if a is immutable, can I make b be a mutable copy of a?
> 
> I hate deep-copy/shallow-copy semantics.

I did shallow copy so that function arguments would work like C does.
Alternatively, we could always do deep-copy and pass references around 
instead.  But the additional syntax required is a pain:

	function bar (ref a)
	{
		(*a)[0] = 12;
	}

	array q = [3];
	bar(&q);
	

Oh, I know, I know!  We could use C++ semantics; I love them:

	foo (int &a)
	{
		a = 27;
	}

	bar ()
	{
		int	b;

		foo (b);
		return b;
	}
	
Those seem so clear and unambiguous to me.

Are there better boxing/unboxing syntax schemes?

keithp@keithp.com	 XFree86 Core Team		SuSE, Inc.






From keithp@keithp.com Mon, 19 Feb 2001 21:16:30 -0800
Date: Mon, 19 Feb 2001 21:16:30 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]Mystic shallow copy semantics solved

Try:

	a = [3]{1,2,3};
	b = a;
	b[0] = 2;
	a

Now try:

	array a = [3]{1,2,3};
	array b = a;
	b[0] = 2;
	a

When 'b' is undeclared, the assignment 'b = a' makes a shallow copy of 'a',
when 'b' is declared as an array, the copy is deep.

Oops.

keithp@keithp.com	 XFree86 Core Team		SuSE, Inc.






From keithp@keithp.com Mon, 19 Feb 2001 21:54:27 -0800
Date: Mon, 19 Feb 2001 21:54:27 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]Mystic shallow copy semantics solved

Around 21 o'clock on Feb 19, Keith Packard wrote:
> 
> When 'b' is undeclared, the assignment 'b = a' makes a shallow copy of 'a',
> when 'b' is declared as an array, the copy is deep.
> 
> Oops.

And fixed in CVS now -- the type of copy depended on the declaration of 
the lvalue instead of the type of the object itself, now the object type 
is all that matters.

There is still a hack here -- objects declared 'double' always have their 
values stored in 'double' form.  'double's are the only imprecise datatype 
supported currently, and I don't have any special operators for dealing 
with imprecise numbers yet.

I'll poke through the scheme spec and try to remember how they did this 
stuff.

-keith






From keithp@keithp.com Tue, 20 Feb 2001 20:22:22 -0800
Date: Tue, 20 Feb 2001 20:22:22 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]Twixt and exceptions

Two of the unfinished pieces in nickle are exception handling and "critical 
sections" -- pieces of code executed on the way out of a stack context 
during exeception handling.

* critical sections

A big problem Bart and I have seen with other languages is that the 
enter/leave portions of "critical sections" is assymetrical, we usually 
have:

	lock_mutex ()
	try {

		... lots of code here ...

	} finally {
		unlock_mutex ();
	}

or some such; this is unpleasing to the eye; the lock and unlock are
separated both by a large distance and are actually at different 
indentation levels.

Instead, Bart came up with the following syntax:

	twixt (<enter-expr>; <leave-expr>) <statement>

After <enter-expr> is executed, <leave-expr> is guaranteed to be executed.

So, you would do:

	twixt (mutex.acquire (m); mutex.release (m)) 
	{
		stuff with m locked
	}

Questions: how should this work with non-blocking syncronization 
primitives (mutex.tryAcquire, semahpore.test)?

Suggestion: initial statement is boolean, entry to twixt is denied if the 
first statement evaluates to False.

	twixt (mutex.tryAcquire (m); mutex.release (m))
	{
		stuff with m locked
	}

Problem: assymetry returns, need to capture tryAcquire result to learn if
'stuff' was executed.

Alternative: force program to handle this case:

	twixt (got = mutex.tryAcquire (m); got ? mutex.release (m) : 0)
	{
		if (got) {
			stuff with m locked;
		}
	}

or
	if (mutex.tryAcquire(m) twixt (; mutex.release (m)) 
	{
		stuff with m locked;
	}


Problem: Extra scope, or assymetrical usage.

Suggestions are welcome; I'm leaning towards the predicated twixt form.

* Exceptions.

Here's the current plan, it's not implemented but probably will be soon.

Exceptions are symbols declared with function-like syntax that can
be dynamically bound to a particular lamda.  Uncaught exceptions terminate 
the thread with an error.  An example would be helpful here:

	exception missing_q (string line);

	...

	s = "foobar";
	try {
		if (strings.index (s, "q") < 0)
			throw missing_q (s);
	} catch missing_q (string line) {
		printf ("Hey, bozo, no 'q' found in %s\n", line);
	}

Question: the 'catch' and 'throw' keywords are completely gratuitous 
syntactic sugar.  Can I get rid of them?  Or would the alternative be too 
confusing?

Would you prefer this syntax instead:

	{
		catch missing_q (string line) 
		{
			printf ("Hey, bozo, no 'q' found in %s\n", line);
		}

		if (strings.index (s, "q") < 0)
			throw missing_q (s);

	}

One I'm not fond of:

	catch missing_q (string line)
	{
		printf ("Hey, bozo, no 'q' found in %s\n", line);
	}
	{
		if (strings.index (s, "q") < 0)
			throw missing_q (s);
	}

This last form would require the 'catch' keyword to keep it parsable.

Complaints? Comments?

-keith






From bart@cs.pdx.edu Tue, 20 Feb 2001 22:38:13 -0800
Date: Tue, 20 Feb 2001 22:38:13 -0800
From: Barton C Massey bart@cs.pdx.edu
Subject: [Nickle]Twixt and exceptions

Do the predicated twixt with an optional else
part:
	twixt (mutex.tryAcquire (m); mutex.release (m))
	{
		stuff with m locked
	} else {
	        tryAcquire() failed
	}

		Bart

In message <20010221042338.EC46BDF801@orestes.keithp.com> you wrote:
> 
> Two of the unfinished pieces in nickle are exception handling and "critical 
> sections" -- pieces of code executed on the way out of a stack context 
> during exeception handling.
> 
> * critical sections
> 
> A big problem Bart and I have seen with other languages is that the 
> enter/leave portions of "critical sections" is assymetrical, we usually 
> have:
> 
> 	lock_mutex ()
> 	try {
> 
> 		... lots of code here ...
> 
> 	} finally {
> 		unlock_mutex ();
> 	}
> 
> or some such; this is unpleasing to the eye; the lock and unlock are
> separated both by a large distance and are actually at different 
> indentation levels.
> 
> Instead, Bart came up with the following syntax:
> 
> 	twixt (<enter-expr>; <leave-expr>) <statement>
> 
> After <enter-expr> is executed, <leave-expr> is guaranteed to be executed.
> 
> So, you would do:
> 
> 	twixt (mutex.acquire (m); mutex.release (m)) 
> 	{
> 		stuff with m locked
> 	}
> 
> Questions: how should this work with non-blocking syncronization 
> primitives (mutex.tryAcquire, semahpore.test)?
> 
> Suggestion: initial statement is boolean, entry to twixt is denied if the 
> first statement evaluates to False.
> 
> 	twixt (mutex.tryAcquire (m); mutex.release (m))
> 	{
> 		stuff with m locked
> 	}
> 
> Problem: assymetry returns, need to capture tryAcquire result to learn if
> 'stuff' was executed.
> 
> Alternative: force program to handle this case:
> 
> 	twixt (got = mutex.tryAcquire (m); got ? mutex.release (m) : 0)
> 	{
> 		if (got) {
> 			stuff with m locked;
> 		}
> 	}
> 
> or
> 	if (mutex.tryAcquire(m) twixt (; mutex.release (m)) 
> 	{
> 		stuff with m locked;
> 	}
> 
> 
> Problem: Extra scope, or assymetrical usage.
> 
> Suggestions are welcome; I'm leaning towards the predicated twixt form.
> 
> * Exceptions.
> 
> Here's the current plan, it's not implemented but probably will be soon.
> 
> Exceptions are symbols declared with function-like syntax that can
> be dynamically bound to a particular lamda.  Uncaught exceptions terminate 
> the thread with an error.  An example would be helpful here:
> 
> 	exception missing_q (string line);
> 
> 	...
> 
> 	s = "foobar";
> 	try {
> 		if (strings.index (s, "q") < 0)
> 			throw missing_q (s);
> 	} catch missing_q (string line) {
> 		printf ("Hey, bozo, no 'q' found in %s\n", line);
> 	}
> 
> Question: the 'catch' and 'throw' keywords are completely gratuitous 
> syntactic sugar.  Can I get rid of them?  Or would the alternative be too 
> confusing?
> 
> Would you prefer this syntax instead:
> 
> 	{
> 		catch missing_q (string line) 
> 		{
> 			printf ("Hey, bozo, no 'q' found in %s\n", line);
> 		}
> 
> 		if (strings.index (s, "q") < 0)
> 			throw missing_q (s);
> 
> 	}
> 
> One I'm not fond of:
> 
> 	catch missing_q (string line)
> 	{
> 		printf ("Hey, bozo, no 'q' found in %s\n", line);
> 	}
> 	{
> 		if (strings.index (s, "q") < 0)
> 			throw missing_q (s);
> 	}
> 
> This last form would require the 'catch' keyword to keep it parsable.
> 
> Complaints? Comments?
> 
> -keith
> 
> 
> 
> _______________________________________________
> Nickle mailing list
> Nickle@keithp.com
> http://keithp.com/mailman/listinfo/nickle




From keithp@keithp.com Fri, 23 Feb 2001 00:27:38 -0800
Date: Fri, 23 Feb 2001 00:27:38 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]Type names

Ok, so the current typedef scheme is ugly:

	typedef int foo;
	type foo bar;

Bart proposed:

	typedef int Foo;
	Foo bar;

This reserves every name begining with [A-Z] for typedef names.
That's also ugly.

We could also use

	typedef int _foo;
	_foo bar;

or any other character (except ;,$.()[]{}+-*/%!#^&|~=<>?: )

I don't think we can preserve our current type syntax and usage and get 
arbitrary names as typedefs, the '*' really makes it hard.

-keith






From mike@ducky.net Fri, 23 Feb 2001 00:32:41 -0800
Date: Fri, 23 Feb 2001 00:32:41 -0800
From: Mike Haertel mike@ducky.net
Subject: [Nickle]Type names

I'd vote for the capitalized typedef style.
(Do I get a vote? :-)




From bart@cs.pdx.edu Fri, 23 Feb 2001 00:42:00 -0800
Date: Fri, 23 Feb 2001 00:42:00 -0800
From: Barton C Massey bart@cs.pdx.edu
Subject: [Nickle]Type names

Of course you get a vote.  My vote is "none of the above": I
haven't given up yet on something less horrible.  I'll try
to grub around in the innards this weekend unless somebody
beats me to it...  My second choice would be a leading ".",
which currently has no meaning AFAIK and is fairly
unobtrusive at least.

		Bart

In message <200102230832.f1N8WfD84334@ducky.net> Mike wrote:
> I'd vote for the capitalized typedef style.
> (Do I get a vote? :-)




From keithp@keithp.com Fri, 23 Feb 2001 00:46:15 -0800
Date: Fri, 23 Feb 2001 00:46:15 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]Type names

Around 0 o'clock on Feb 23, Mike Haertel wrote:
> I'd vote for the capitalized typedef style.

I kinda like the '_' style myself; it has the advantage of not abusing 
mathematical formulas which include capital letters.  We could also use a 
different token to indicate a type name where it's used; suggestions
are quite welcome.

> (Do I get a vote? :-)

Everyone can vote; you'll need CVS access to effect any real changes
though... (Keith imagines a skirmish where the language syntax changes
minute by minute as people commit changes which quickly escalates to
automated CVS scripts eventually melting the P166 CVS server).

-keith






From keithp@keithp.com Fri, 23 Feb 2001 00:57:53 -0800
Date: Fri, 23 Feb 2001 00:57:53 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]Type names

Around 0 o'clock on Feb 23, Barton C Massey wrote:
> Of course you get a vote.  My vote is "none of the above": I
> haven't given up yet on something less horrible.  I'll try
> to grub around in the innards this weekend unless somebody
> beats me to it...  My second choice would be a leading ".",
> which currently has no meaning AFAIK and is fairly
> unobtrusive at least.

You can use:

	. 	,	^	:	|	@	%	_	?

"_" has the advantage that it's currently allowed in the middle of 
identifiers but not at the begining, "." is so unobtrusive as to be lost
occaisionally, perhaps ':' or '|' would be better?  I don't like '@' or 
'%', those seem likely to obscure the typename a bit.

-keith






From keithp@keithp.com Fri, 23 Feb 2001 09:58:24 -0800
Date: Fri, 23 Feb 2001 09:58:24 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]Numeric type heirarchy

Nickle currently incorporates several internal numeric representations and 
exposes several numeric datatypes.  While these use the same names, the 
language groups several representations together as a single datatype.

In the implementation, there are:

	type_int		32 bit integer
	type_integer		arbitrary precision natural + sign
	type_rational		two naturals + sign
	type_double		C 'double'.

In the language, there are:

	int		type_int
	integer		type_int or type_integer
	rational	type_int, type_integer or type_rational
	double		type_int, type_integer, type_rational or type_double

I think I should remove 32-bit integers from the language; they're not 
useful.

I'm about to add a 'type_float' which uses a natural mantissa, natural
exponent two signs and a 32-bit integer indicating the number of bits in 
the mantissa.  This will eliminate the inability to convert large or small
values into an imprecise representation.

Once this new representation is available, I'd like to change the
internal names to:

	type_int		natural + sign
	type_ratio		two naturals + sign
	type_float		two naturals, two signs and a 32-bit precision

The language datatypes become:

	integer			type_int
	rational		type_ratio or type_int
	real			type_float, type_ratio or type_int

As for datatype conversions:

real imprecise (real value, integer bits)

	Convert 'value' to an imprecise repsentation using no more than 
	'bits' bits.

integer floor (real value)
integer ceil (real value)
integer round (real value)

	Convert 'value' to the nearest integer in the indicated direction.

Is there any conventional function name for converting an imprecise number 
into a nearby rational approximation?  Certainly it's easy to do:

	rational function nearby (real value, integer denom) {
		return round (value * denom) / denom;
	}

-keith






From keithp@keithp.com Wed, 28 Feb 2001 00:29:50 -0800
Date: Wed, 28 Feb 2001 00:29:50 -0800
From: Keith Packard keithp@keithp.com
Subject: [Nickle]A usable calculator again

With much typing, I've replaced the old machine-specific floating point 
code with arbitrary precision stuff; this is useful, but it temporarily 
reduced the utility of nickle as a calculator -- the C math library can no 
longer be used.  

So I wrote an arbitrary precision math library in nickle itself; with
Bart's code to load a startup file when nickle launches, we'll be back to
where we were a week ago, except that there are still a lot of functions to
implement.

I've got sqrt, cbrt, exp, log, log10, sin, cos, sin_cos, tan, arcsin,
arccos, arctan and arctan2.  I'll have to do a bit of work to get the '^'
operator to use the nickle library code, but I think that's worth the
effort rather than recoding exp/log in C.

-keith







From bart@cs.pdx.edu Wed, 28 Feb 2001 01:52:21 -0800
Date: Wed, 28 Feb 2001 01:52:21 -0800
From: Barton C Massey bart@cs.pdx.edu
Subject: [Nickle]A usable calculator again

Nice job!  

I've checked in the autoconf etc. changes to get nickle to
load DATADIR/nickle/builtin.5c by default.  Note that this
means that running nickle out of the source directory will
load the library from the standard place rather than out of
the source directory: this is arguable, but the alternative
is a giant pain to implement given the current setup.

I import the math namespace in builtin.5c: if this isn't
what people want, we should talk.  (It's what *I* want,
anyway.)

I'll try to update the examples RSN to accomodate various
changes (notably Keith's new .5c extension :-).

Keith: sin(0) seems to infinite-loop for me.  Also,
shouldn't sin(pi) and friends be 0 given the default
precisions of sin() and pi?

I've seen the convention around (and like it) that says that
log == log_base_10, lg == log_base_2, ln == log_base_e.  The
downside is that C math library users will get horribly
surprised.  Perhaps log10(), lg(), ln(), and make log() take
two arguments (base + target)?  Then C users would get
whined at...  Or is everybody happy with log == log_base_e?

		Bart

In message <20010228083105.51B81DF801@orestes.keithp.com> you wrote:
> 
> With much typing, I've replaced the old machine-specific floating point 
> code with arbitrary precision stuff; this is useful, but it temporarily 
> reduced the utility of nickle as a calculator -- the C math library can no 
> longer be used.  
> 
> So I wrote an arbitrary precision math library in nickle itself; with
> Bart's code to load a startup file when nickle launches, we'll be back to
> where we were a week ago, except that there are still a lot of functions to
> implement.
> 
> I've got sqrt, cbrt, exp, log, log10, sin, cos, sin_cos, tan, arcsin,
> arccos, arctan and arctan2.  I'll have to do a bit of work to get the '^'
> operator to use the nickle library code, but I think that's worth the
> effort rather than recoding exp/log in C.
> 
> -keith
> 
> 
> 
> 
> _______________________________________________
> Nickle mailing list
> Nickle@keithp.com
> http://keithp.com/mailman/listinfo/nickle




From mike@ducky.net Wed, 28 Feb 2001 02:16:28 -0800 (PST)
Date: Wed, 28 Feb 2001 02:16:28 -0800 (PST)
From: Mike Haertel mike@ducky.net
Subject: [Nickle]A usable calculator again

I happen to like log = log_base_e.  Anyone with half a clue in math
knows it's One True Logarithm.  I'd vote for log10, log, and log2,
and conversely exp10, exp, and exp2.




