Hi All,
I had a look at the specifications of D, after reading the article on
(surprise! ;-) Slashdot

1st comment: It looks great! ;-)
I'd really like to get my hands on a D compiler.

2nd, one question:
In the section "TYPES"; why isn't "function returning.." mentioned as a
derived type?
How/where do functions fit in D's type system?
(apologies if this has been asked already)

Cheers,
--Luigi

LuigiG wrote in message <9ljn4e$239i$1@digitaldaemon.com>...
>Hi All,
>I had a look at the specifications of D, after reading the article on
>(surprise! ;-) Slashdot
>
>1st comment: It looks great! ;-)
>I'd really like to get my hands on a D compiler.


Thanks!

>2nd, one question:
>In the section "TYPES"; why isn't "function returning.." mentioned as a
>derived type?
>How/where do functions fit in D's type system?
>(apologies if this has been asked already)


Functions are a derived type too. I'll fix the doc. -Walter

Walter wrote:
> 
> LuigiG wrote in message <9ljn4e$239i$1@digitaldaemon.com>...
> >Hi All,
> >I had a look at the specifications of D, after reading the article on
> >(surprise! ;-) Slashdot
> >
> >1st comment: It looks great! ;-)
> >I'd really like to get my hands on a D compiler.
> 
> Thanks!
> 
> >2nd, one question:
> >In the section "TYPES"; why isn't "function returning.." mentioned as a
> >derived type?
> >How/where do functions fit in D's type system?
> >(apologies if this has been asked already)
> 
> Functions are a derived type too. I'll fix the doc. -Walter

This looks like a great place to stir up a mess.  How about anonymous functions?  Granted, they would be worth more once a good solution is found for generics.  Say anywhere you could pass a pointer to function you could also write an inline

	int[] list = transform(otherlist, lambda(int x){return x*x;};

Just to note, I'm endorsing the functionality, but not necessarily this
syntax.  I just know I writing a million different little functions in
C/C++ to print a variable a certain way or to install a temporary event
handler of some sort is messy and it just makes me feel dirty.  Some
tasks are so trivial that they don't deserve a name or they should be
"declared" where they are needed for clarity.
	I will punt on the issue of using variables in the enclosing scope
(closure style) until I see how this is excepted.  :->

Dan

Anonymous functions are a good idea, I'll have to think about it. -Walter

"Dan Hursh" <hursh@infonet.isl.net> wrote in message news:3B873562.896B7FED@infonet.isl.net...
> This looks like a great place to stir up a mess.  How about anonymous functions?  Granted, they would be worth more once a good solution is found for generics.  Say anywhere you could pass a pointer to function you could also write an inline
>
> int[] list = transform(otherlist, lambda(int x){return x*x;};
>
> Just to note, I'm endorsing the functionality, but not necessarily this
> syntax.  I just know I writing a million different little functions in
> C/C++ to print a variable a certain way or to install a temporary event
> handler of some sort is messy and it just makes me feel dirty.  Some
> tasks are so trivial that they don't deserve a name or they should be
> "declared" where they are needed for clarity.
> I will punt on the issue of using variables in the enclosing scope
> (closure style) until I see how this is excepted.  :->
>
> Dan

	Geez!  I was expecting to get shot down on this one.  I always do when
I suggest it for C++.  Now I feel obligated to go into the ideas I've
had for enclosing scopes.  Oh well, feel free to say if this is too
much.

1) static scope
	This is the easiest.  The anon gets no variable from the enclosing
scope.  It is a function like any other.  If declared in an object, go
ahead and give it object scope if that isn't too hard.  Passing around a
reference to the anon is safe.

		int f(){
			int i = 5;
			thing t[8];
			map(t, anon(thing t){t.add(i++);}); // illegal
			return i;
		}

2) implied copy
	This is similar to the above.  The difference is that the code above
would work.  Any use of variable would imply a local variable set to the
same variable within the anon.  The anon does not share the variable
though.  It only copies that value, so f() would return 5.
	The best way to implement this is to implicitly create an object that
contain the variable referenced and copy the values in the object where
the anon is declared.  The anon would run in this object's scope, so
passing a reference to the anon out of the scope where it was declared
would work.


3) implied reference
	In this case, the example for 1 would work.  The anon would have
references to the real variables in the enclosing scope.  In this case
then, f() would return 13;
	Now this has a serious potential for gross errors.  If a reference to
the anon were to be passed around, any variables referenced from an
enclosing scope would be out of scope after exiting the enclosing
scope.  Since objects and arrays are all dynamically allocated they
could be safe, but built-ins are a serious problem.
	Unfortunately the compiler probably could not detect all the way a
function pointer could get passed beyond it's scope.  We should only
pick this one if we are willing to live with the possibility for
misuse.  Think of it like the delete operator.  Powerful, but easily
misused.

4) anonymous object scope
	Here we have another anonymous object created.  This time however, the
object is created when you enter a scope that uses an anon.  Any
variable that an anon might use from that scope is in the object instead
of on the stack.  All the anons in the scope share this object with the
enclosing scope.  When exiting the scope defining the object, any anons
that are still referenced would share this object.  Re-entering the
scope would create a new object.
	This is the safest.  I think it might be real closures.  (I always get
confused about what is or isn't a closure.  If it is, it is.  If it's
not, it's not.)  There may be the need to have an object of each scope,
and the anon would have to reference the object of each scope contain a
variable it references.
	This is also the most complex and hence the most likely to get turned
down.
Well maybe 3 would get turned down first.


	Anyhow, I know this might be inappropriate for D given it's design
goals, but I've missed anonymous functions ever since I played with my
lisp-a-like.

Dan


Walter wrote:
> 
> Anonymous functions are a good idea, I'll have to think about it. -Walter
> 
> "Dan Hursh" <hursh@infonet.isl.net> wrote in message news:3B873562.896B7FED@infonet.isl.net...
> > This looks like a great place to stir up a mess.  How about anonymous functions?  Granted, they would be worth more once a good solution is found for generics.  Say anywhere you could pass a pointer to function you could also write an inline
> >
> > int[] list = transform(otherlist, lambda(int x){return x*x;};
> >
> > Just to note, I'm endorsing the functionality, but not necessarily this
> > syntax.  I just know I writing a million different little functions in
> > C/C++ to print a variable a certain way or to install a temporary event
> > handler of some sort is messy and it just makes me feel dirty.  Some
> > tasks are so trivial that they don't deserve a name or they should be
> > "declared" where they are needed for clarity.
> > I will punt on the issue of using variables in the enclosing scope
> > (closure style) until I see how this is excepted.  :->
> >
> > Dan

Making them static is the best idea.

Dan Hursh wrote in message <3B8DCC3E.D59FEA4A@infonet.isl.net>...
> Geez!  I was expecting to get shot down on this one.  I always do when
>I suggest it for C++.  Now I feel obligated to go into the ideas I've had for enclosing scopes.  Oh well, feel free to say if this is too much.
>
>1) static scope
> This is the easiest.  The anon gets no variable from the enclosing
>scope.  It is a function like any other.  If declared in an object, go ahead and give it object scope if that isn't too hard.  Passing around a reference to the anon is safe.
>
> int f(){
> int i = 5;
> thing t[8];
> map(t, anon(thing t){t.add(i++);}); // illegal
> return i;
> }
>
>2) implied copy
> This is similar to the above.  The difference is that the code above
>would work.  Any use of variable would imply a local variable set to the same variable within the anon.  The anon does not share the variable though.  It only copies that value, so f() would return 5.
> The best way to implement this is to implicitly create an object that
>contain the variable referenced and copy the values in the object where the anon is declared.  The anon would run in this object's scope, so passing a reference to the anon out of the scope where it was declared would work.
>
>
>3) implied reference
> In this case, the example for 1 would work.  The anon would have
>references to the real variables in the enclosing scope.  In this case
>then, f() would return 13;
> Now this has a serious potential for gross errors.  If a reference to
>the anon were to be passed around, any variables referenced from an enclosing scope would be out of scope after exiting the enclosing scope.  Since objects and arrays are all dynamically allocated they could be safe, but built-ins are a serious problem.
> Unfortunately the compiler probably could not detect all the way a
>function pointer could get passed beyond it's scope.  We should only pick this one if we are willing to live with the possibility for misuse.  Think of it like the delete operator.  Powerful, but easily misused.
>
>4) anonymous object scope
> Here we have another anonymous object created.  This time however, the
>object is created when you enter a scope that uses an anon.  Any variable that an anon might use from that scope is in the object instead of on the stack.  All the anons in the scope share this object with the enclosing scope.  When exiting the scope defining the object, any anons that are still referenced would share this object.  Re-entering the scope would create a new object.
> This is the safest.  I think it might be real closures.  (I always get
>confused about what is or isn't a closure.  If it is, it is.  If it's not, it's not.)  There may be the need to have an object of each scope, and the anon would have to reference the object of each scope contain a variable it references.
> This is also the most complex and hence the most likely to get turned
>down.
>Well maybe 3 would get turned down first.
>
>
> Anyhow, I know this might be inappropriate for D given it's design
>goals, but I've missed anonymous functions ever since I played with my lisp-a-like.
>
>Dan
>
>
>Walter wrote:
>>
>> Anonymous functions are a good idea, I'll have to think about it. -Walter
>>
>> "Dan Hursh" <hursh@infonet.isl.net> wrote in message news:3B873562.896B7FED@infonet.isl.net...
>> > This looks like a great place to stir up a mess.  How about anonymous functions?  Granted, they would be worth more once a good solution is found for generics.  Say anywhere you could pass a pointer to function you could also write an inline
>> >
>> > int[] list = transform(otherlist, lambda(int x){return x*x;};
>> >
>> > Just to note, I'm endorsing the functionality, but not necessarily this
>> > syntax.  I just know I writing a million different little functions in
>> > C/C++ to print a variable a certain way or to install a temporary event
>> > handler of some sort is messy and it just makes me feel dirty.  Some
>> > tasks are so trivial that they don't deserve a name or they should be
>> > "declared" where they are needed for clarity.
>> > I will punt on the issue of using variables in the enclosing scope
>> > (closure style) until I see how this is excepted.  :->
>> >
>> > Dan

	Do you think there would be a way to pass info from the outside world
(say the block that declares the function) into the declaration of the
function that would not violate the design goals of D?  That would make
them a lot more useful.  It would be nice to be able the get result
back, but that could be done with a pointer if there is a way to pass
data into it.

	int foo(int a[], char prefix[]){
		int ret = 0;  // yes I know it's redundant
		// and yes I know a for() would work just fine here
		map(t, annon(int i){
			printf("%.*s %d\n", prefix, i);
			ret += i;
		});
		return ret;   // it's just an example
	}

This is an idealized chunk of code.  I know the static version would require a lot less (almost no?) black magic in the compiler.  Static annons would be cool, but the above feature (though maybe not the syntax) will be the first thing people ask for after they see annons. Just thought I'd see what you think would be the hardest part.

Dan

Walter wrote:
> 
> Making them static is the best idea.
> 
> Dan Hursh wrote in message <3B8DCC3E.D59FEA4A@infonet.isl.net>...
> > Geez!  I was expecting to get shot down on this one.  I always do when
> >I suggest it for C++.  Now I feel obligated to go into the ideas I've had for enclosing scopes.  Oh well, feel free to say if this is too much.
> >
> >1) static scope
> > This is the easiest.  The anon gets no variable from the enclosing
> >scope.  It is a function like any other.  If declared in an object, go ahead and give it object scope if that isn't too hard.  Passing around a reference to the anon is safe.
> >
> > int f(){
> > int i = 5;
> > thing t[8];
> > map(t, anon(thing t){t.add(i++);}); // illegal
> > return i;
> > }
> >
> >2) implied copy
> > This is similar to the above.  The difference is that the code above
> >would work.  Any use of variable would imply a local variable set to the same variable within the anon.  The anon does not share the variable though.  It only copies that value, so f() would return 5.
> > The best way to implement this is to implicitly create an object that
> >contain the variable referenced and copy the values in the object where the anon is declared.  The anon would run in this object's scope, so passing a reference to the anon out of the scope where it was declared would work.
> >
> >
> >3) implied reference
> > In this case, the example for 1 would work.  The anon would have
> >references to the real variables in the enclosing scope.  In this case
> >then, f() would return 13;
> > Now this has a serious potential for gross errors.  If a reference to
> >the anon were to be passed around, any variables referenced from an enclosing scope would be out of scope after exiting the enclosing scope.  Since objects and arrays are all dynamically allocated they could be safe, but built-ins are a serious problem.
> > Unfortunately the compiler probably could not detect all the way a
> >function pointer could get passed beyond it's scope.  We should only pick this one if we are willing to live with the possibility for misuse.  Think of it like the delete operator.  Powerful, but easily misused.
> >
> >4) anonymous object scope
> > Here we have another anonymous object created.  This time however, the
> >object is created when you enter a scope that uses an anon.  Any variable that an anon might use from that scope is in the object instead of on the stack.  All the anons in the scope share this object with the enclosing scope.  When exiting the scope defining the object, any anons that are still referenced would share this object.  Re-entering the scope would create a new object.
> > This is the safest.  I think it might be real closures.  (I always get
> >confused about what is or isn't a closure.  If it is, it is.  If it's not, it's not.)  There may be the need to have an object of each scope, and the anon would have to reference the object of each scope contain a variable it references.
> > This is also the most complex and hence the most likely to get turned
> >down.
> >Well maybe 3 would get turned down first.
> >
> >
> > Anyhow, I know this might be inappropriate for D given it's design
> >goals, but I've missed anonymous functions ever since I played with my lisp-a-like.
> >
> >Dan
> >
> >
> >Walter wrote:
> >>
> >> Anonymous functions are a good idea, I'll have to think about it. -Walter
> >>
> >> "Dan Hursh" <hursh@infonet.isl.net> wrote in message news:3B873562.896B7FED@infonet.isl.net...
> >> > This looks like a great place to stir up a mess.  How about anonymous functions?  Granted, they would be worth more once a good solution is found for generics.  Say anywhere you could pass a pointer to function you could also write an inline
> >> >
> >> > int[] list = transform(otherlist, lambda(int x){return x*x;};
> >> >
> >> > Just to note, I'm endorsing the functionality, but not necessarily this
> >> > syntax.  I just know I writing a million different little functions in
> >> > C/C++ to print a variable a certain way or to install a temporary event
> >> > handler of some sort is messy and it just makes me feel dirty.  Some
> >> > tasks are so trivial that they don't deserve a name or they should be
> >> > "declared" where they are needed for clarity.
> >> > I will punt on the issue of using variables in the enclosing scope
> >> > (closure style) until I see how this is excepted.  :->
> >> >
> >> > Dan

The most obvious model for doing that is Pascal, which gives nested functions access to lexically enclosed local variables. -Walter

a wrote in message <3BAFEA9E.2FAE409@b.c>...
>
> Do you think there would be a way to pass info from the outside world
>(say the block that declares the function) into the declaration of the function that would not violate the design goals of D?  That would make them a lot more useful.  It would be nice to be able the get result back, but that could be done with a pointer if there is a way to pass data into it.
>
> int foo(int a[], char prefix[]){
> int ret = 0;  // yes I know it's redundant
> // and yes I know a for() would work just fine here
> map(t, annon(int

> printf("%.*s %d\n", prefix, i);
> ret += i;
> });
> return ret;   // it's just an example
> }
>
>This is an idealized chunk of code.  I know the static version would require a lot less (almost no?) black magic in the compiler.  Static annons would be cool, but the above feature (though maybe not the syntax) will be the first thing people ask for after they see annons. Just thought I'd see what you think would be the hardest part.
>
>Dan
>
>Walter wrote:
>>
>> Making them static is the best idea.
>>
>> Dan Hursh wrote in message <3B8DCC3E.D59FEA4A@infonet.isl.net>...
>> > Geez!  I was expecting to get shot down on this one.  I always do when
>> >I suggest it for C++.  Now I feel obligated to go into the ideas I've had for enclosing scopes.  Oh well, feel free to say if this is too much.
>> >
>> >1) static scope
>> > This is the easiest.  The anon gets no variable from the enclosing
>> >scope.  It is a function like any other.  If declared in an object, go ahead and give it object scope if that isn't too hard.  Passing around a reference to the anon is safe.
>> >
>> > int f(){
>> > int i = 5;
>> > thing t[8];
>> > map(t, anon(thing t){t.add(i++);}); // illegal
>> > return i;
>> > }
>> >
>> >2) implied copy
>> > This is similar to the above.  The difference is that the code above
>> >would work.  Any use of variable would imply a local variable set to the same variable within the anon.  The anon does not share the variable though.  It only copies that value, so f() would return 5.
>> > The best way to implement this is to implicitly create an object that
>> >contain the variable referenced and copy the values in the object where the anon is declared.  The anon would run in this object's scope, so passing a reference to the anon out of the scope where it was declared would work.
>> >
>> >
>> >3) implied reference
>> > In this case, the example for 1 would work.  The anon would have
>> >references to the real variables in the enclosing scope.  In this case
>> >then, f() would return 13;
>> > Now this has a serious potential for gross errors.  If a reference to
>> >the anon were to be passed around, any variables referenced from an enclosing scope would be out of scope after exiting the enclosing scope.  Since objects and arrays are all dynamically allocated they could be safe, but built-ins are a serious problem.
>> > Unfortunately the compiler probably could not detect all the way a
>> >function pointer could get passed beyond it's scope.  We should only pick this one if we are willing to live with the possibility for misuse.  Think of it like the delete operator.  Powerful, but easily misused.
>> >
>> >4) anonymous object scope
>> > Here we have another anonymous object created.  This time however, the
>> >object is created when you enter a scope that uses an anon.  Any variable that an anon might use from that scope is in the object instead of on the stack.  All the anons in the scope share this object with the enclosing scope.  When exiting the scope defining the object, any anons that are still referenced would share this object.  Re-entering the scope would create a new object.
>> > This is the safest.  I think it might be real closures.  (I always get
>> >confused about what is or isn't a closure.  If it is, it is.  If it's not, it's not.)  There may be the need to have an object of each scope, and the anon would have to reference the object of each scope contain a variable it references.
>> > This is also the most complex and hence the most likely to get turned
>> >down.
>> >Well maybe 3 would get turned down first.
>> >
>> >
>> > Anyhow, I know this might be inappropriate for D given it's design
>> >goals, but I've missed anonymous functions ever since I played with my lisp-a-like.
>> >
>> >Dan
>> >
>> >
>> >Walter wrote:
>> >>
>> >> Anonymous functions are a good idea, I'll have to think about
it. -Walter
>> >>
>> >> "Dan Hursh" <hursh@infonet.isl.net> wrote in message news:3B873562.896B7FED@infonet.isl.net...
>> >> > This looks like a great place to stir up a mess.  How about
anonymous
>> >> > functions?  Granted, they would be worth more once a good solution
is
>> >> > found for generics.  Say anywhere you could pass a pointer to
function
>> >> > you could also write an inline
>> >> >
>> >> > int[] list = transform(otherlist, lambda(int x){return x*x;};
>> >> >
>> >> > Just to note, I'm endorsing the functionality, but not necessarily
this
>> >> > syntax.  I just know I writing a million different little functions
in
>> >> > C/C++ to print a variable a certain way or to install a temporary
event
>> >> > handler of some sort is messy and it just makes me feel dirty.  Some tasks are so trivial that they don't deserve a name or they should
be
>> >> > "declared" where they are needed for clarity.
>> >> > I will punt on the issue of using variables in the enclosing scope
>> >> > (closure style) until I see how this is excepted.  :->
>> >> >
>> >> > Dan

	Can you pass around pointers to functions in pascal?  I don't know
pascal well enough to know.  If so, did they try to do something to keep
the user from returning a pointer to the nested function?  I don't think
any C based language should have to, but I always got the impression
that the pascal based languages tried to keep the programmer from
shooting himself in the foot at (almost) any expense.

Dan

Walter wrote:
> 
> The most obvious model for doing that is Pascal, which gives nested functions access to lexically enclosed local variables. -Walter
> 
> a wrote in message <3BAFEA9E.2FAE409@b.c>...
> >
> > Do you think there would be a way to pass info from the outside world
> >(say the block that declares the function) into the declaration of the function that would not violate the design goals of D?  That would make them a lot more useful.  It would be nice to be able the get result back, but that could be done with a pointer if there is a way to pass data into it.
> >
> > int foo(int a[], char prefix[]){
> > int ret = 0;  // yes I know it's redundant
> > // and yes I know a for() would work just fine here
> > map(t, annon(int
> 
> > printf("%.*s %d\n", prefix, i);
> > ret += i;
> > });
> > return ret;   // it's just an example
> > }
> >
> >This is an idealized chunk of code.  I know the static version would require a lot less (almost no?) black magic in the compiler.  Static annons would be cool, but the above feature (though maybe not the syntax) will be the first thing people ask for after they see annons. Just thought I'd see what you think would be the hardest part.
> >
> >Dan
> >
> >Walter wrote:
> >>
> >> Making them static is the best idea.
> >>
> >> Dan Hursh wrote in message <3B8DCC3E.D59FEA4A@infonet.isl.net>...
> >> > Geez!  I was expecting to get shot down on this one.  I always do when
> >> >I suggest it for C++.  Now I feel obligated to go into the ideas I've had for enclosing scopes.  Oh well, feel free to say if this is too much.
> >> >
> >> >1) static scope
> >> > This is the easiest.  The anon gets no variable from the enclosing
> >> >scope.  It is a function like any other.  If declared in an object, go ahead and give it object scope if that isn't too hard.  Passing around a reference to the anon is safe.
> >> >
> >> > int f(){
> >> > int i = 5;
> >> > thing t[8];
> >> > map(t, anon(thing t){t.add(i++);}); // illegal
> >> > return i;
> >> > }
> >> >
> >> >2) implied copy
> >> > This is similar to the above.  The difference is that the code above
> >> >would work.  Any use of variable would imply a local variable set to the same variable within the anon.  The anon does not share the variable though.  It only copies that value, so f() would return 5.
> >> > The best way to implement this is to implicitly create an object that
> >> >contain the variable referenced and copy the values in the object where the anon is declared.  The anon would run in this object's scope, so passing a reference to the anon out of the scope where it was declared would work.
> >> >
> >> >
> >> >3) implied reference
> >> > In this case, the example for 1 would work.  The anon would have
> >> >references to the real variables in the enclosing scope.  In this case
> >> >then, f() would return 13;
> >> > Now this has a serious potential for gross errors.  If a reference to
> >> >the anon were to be passed around, any variables referenced from an enclosing scope would be out of scope after exiting the enclosing scope.  Since objects and arrays are all dynamically allocated they could be safe, but built-ins are a serious problem.
> >> > Unfortunately the compiler probably could not detect all the way a
> >> >function pointer could get passed beyond it's scope.  We should only pick this one if we are willing to live with the possibility for misuse.  Think of it like the delete operator.  Powerful, but easily misused.
> >> >
> >> >4) anonymous object scope
> >> > Here we have another anonymous object created.  This time however, the
> >> >object is created when you enter a scope that uses an anon.  Any variable that an anon might use from that scope is in the object instead of on the stack.  All the anons in the scope share this object with the enclosing scope.  When exiting the scope defining the object, any anons that are still referenced would share this object.  Re-entering the scope would create a new object.
> >> > This is the safest.  I think it might be real closures.  (I always get
> >> >confused about what is or isn't a closure.  If it is, it is.  If it's not, it's not.)  There may be the need to have an object of each scope, and the anon would have to reference the object of each scope contain a variable it references.
> >> > This is also the most complex and hence the most likely to get turned
> >> >down.
> >> >Well maybe 3 would get turned down first.
> >> >
> >> >
> >> > Anyhow, I know this might be inappropriate for D given it's design
> >> >goals, but I've missed anonymous functions ever since I played with my lisp-a-like.
> >> >
> >> >Dan
> >> >
> >> >
> >> >Walter wrote:
> >> >>
> >> >> Anonymous functions are a good idea, I'll have to think about
> it. -Walter
> >> >>
> >> >> "Dan Hursh" <hursh@infonet.isl.net> wrote in message news:3B873562.896B7FED@infonet.isl.net...
> >> >> > This looks like a great place to stir up a mess.  How about
> anonymous
> >> >> > functions?  Granted, they would be worth more once a good solution
> is
> >> >> > found for generics.  Say anywhere you could pass a pointer to
> function
> >> >> > you could also write an inline
> >> >> >
> >> >> > int[] list = transform(otherlist, lambda(int x){return x*x;};
> >> >> >
> >> >> > Just to note, I'm endorsing the functionality, but not necessarily
> this
> >> >> > syntax.  I just know I writing a million different little functions
> in
> >> >> > C/C++ to print a variable a certain way or to install a temporary
> event
> >> >> > handler of some sort is messy and it just makes me feel dirty.  Some tasks are so trivial that they don't deserve a name or they should
> be
> >> >> > "declared" where they are needed for clarity.
> >> >> > I will punt on the issue of using variables in the enclosing scope
> >> >> > (closure style) until I see how this is excepted.  :->
> >> >> >
> >> >> > Dan