Define statements
Christopher Diggins — 2006-06-22 18:27:53
The current version of the Cat language borrows the define statement from
the Joy language (with a slight syntactic variation), but I have observed
that if I allowed symbols as data-types and provided operations on them, I
could further reduce the language footprint.
So for example currently in Cat one would write:
def inc = 1 +;
If I enable pushing symbols onto the stack as variables using an operator
such as "$" you could instead write:
$inc [1 +] def
So def no longer is some kind of keyword but just another function. The def
function takes a list of operations on the top of the stack, and a symbol
below that and associates the two.
This may seem trivial difference at first but there are some advantages:
- Parsing rules are simplified
- The def function itself can be redefined (thus allowing a form of Aspect
Oriented Programming)
- It allows the extension of the language to support overloaded definition
based on type (e.g. runtime polymorphism)
I'll probably support the new syntax in Cat v0.3
[Non-text portions of this message have been removed]
Joe Bowbeer — 2006-06-22 18:48:42
On 6/22/06, Christopher Diggins <
cdiggins@...> wrote:
>
> $inc [1 +] def
>
What's the difference between 'def' and '=' then?
Why not the following?
[1 +] $inc =
On 6/22/06, Christopher Diggins <cdiggins@...> wrote:
> The current version of the Cat language borrows the define statement from
> the Joy language (with a slight syntactic variation), but I have observed
> that if I allowed symbols as data-types and provided operations on them, I
> could further reduce the language footprint.
>
> So for example currently in Cat one would write:
>
> def inc = 1 +;
>
> If I enable pushing symbols onto the stack as variables using an operator
> such as "$" you could instead write:
>
> $inc [1 +] def
>
> So def no longer is some kind of keyword but just another function. The def
> function takes a list of operations on the top of the stack, and a symbol
> below that and associates the two.
>
> This may seem trivial difference at first but there are some advantages:
> - Parsing rules are simplified
> - The def function itself can be redefined (thus allowing a form of Aspect
> Oriented Programming)
> - It allows the extension of the language to support overloaded definition
> based on type (e.g. runtime polymorphism)
>
> I'll probably support the new syntax in Cat v0.3
>
Christopher Diggins — 2006-06-22 19:01:12
I see no problem with that. It is just a personal preference to avoid
overloading "=" and to place the symbol argument first.
So I could easily define def in my library using your syntax as follows:
$def [swap =] =
On 6/22/06, Christopher Diggins <
cdiggins@... <cdiggins%40gmail.com>>
wrote:
>
> $inc [1 +] def
>
What's the difference between 'def' and '=' then?
Why not the following?
[1 +] $inc =
[Non-text portions of this message have been removed]
John Cowan — 2006-06-22 19:03:35
Christopher Diggins scripsit:
> If I enable pushing symbols onto the stack as variables using an operator
> such as "$" you could instead write:
>
> $inc [1 +] def
>
> So def no longer is some kind of keyword but just another function. The def
> function takes a list of operations on the top of the stack, and a symbol
> below that and associates the two.
This allows redefinition of functions at runtime, which Joy deliberately
does not: symbols are defined at load time only. If they can be
redefined at runtime, that reintroduces state into the language.
As written, Joy has no state but the stack (and the file system).
--
John Cowan
cowan@... http://www.ccil.org/~cowan
Most languages are dramatically underdescribed, and at least one is
dramatically overdescribed. Still other languages are simultaneously
overdescribed and underdescribed. Welsh pertains to the third category.
--Alan King
Christopher Diggins — 2006-06-22 19:24:58
".. introduces state ... "
Good point John. Here is a possible (but not completely thought out)
solution: allow the definition of symbols as special hash-table values on
the stack. Global functions are defined at the bottom of the stack. Each
symbol-hash table acts like a local scope.
[Non-text portions of this message have been removed]
stevan apter — 2006-06-22 21:07:19
here's how you might adapt what is essentially the k
solution to the problem of variables.
introduce dictionaries as a first-class datatype.
let's use your $ as the symbol-prefix.
a dictionary is a mapping from symbols to values, which
themselves can be dictionaries.
if d is a dictionary, then
d $s get
leaves the associated value v on the stack.
d $s v set
associates $s with v in d and leaves the amended d on
the stack.
dot notation:
a name with embedded dots
d.a.b.c
is short-hand for
d $a get $b get $c get
btw, i agree with john's explanation for the two-tier
design of joy, and i think you have to weigh carefully
the decision to incorporate assignment into the semantics
of your language.
there *is* a middle-way (probably several), which is
single-assignment; i.e. assignment but not reassignment.
this is just adequate for the purpose of *definition*
within the language, but not state-keeping.
----- Original Message -----
From: "Christopher Diggins" <cdiggins@...>
To: <concatenative@yahoogroups.com>
Sent: Thursday, June 22, 2006 3:24 PM
Subject: Re: [stack] Define statements
> ".. introduces state ... "
>
> Good point John. Here is a possible (but not completely thought out)
> solution: allow the definition of symbols as special hash-table values on
> the stack. Global functions are defined at the bottom of the stack. Each
> symbol-hash table acts like a local scope.
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Christopher Diggins — 2006-06-22 21:49:38
> here's how you might adapt what is essentially the k
solution to the problem of variables.
That is essentially what I was proposing, just not as elegantly presented.
Thanks for that explanation.
- Christopher
[Non-text portions of this message have been removed]
Joe Bowbeer — 2006-06-22 22:34:05
On 6/22/06, Christopher Diggins <
cdiggins@...> wrote:
> I see no problem with that. It is just a personal preference to avoid
> overloading "=" and to place the symbol argument first.
>
A few thoughts:
If a program is a first-class value in your language then using "="
for assignment of these values seems natural. (Assuming a symbol can
only have one value.)
If you place the symbol second then it's easy for one program to
generate another program by leaving it on the stack, where it can be
assigned or applied -- or whatever.
This discussion reminds me a Scheme, where functions are first-class
values. In Scheme, though, closures (environment + continuation) eat
their own trail, leading toward stackless execution. While what you
are describing, storing assignments on the stack, seems more similar
to traditional dynamically-bound Lisp.
On 6/22/06, Christopher Diggins <cdiggins@...> wrote:
> I see no problem with that. It is just a personal preference to avoid
> overloading "=" and to place the symbol argument first.
>
> So I could easily define def in my library using your syntax as follows:
>
> $def [swap =] =
>
>
> On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>
> wrote:
> >
> > $inc [1 +] def
> >
>
> What's the difference between 'def' and '=' then?
>
> Why not the following?
>
> [1 +] $inc =
>
stevan apter — 2006-06-23 02:13:21
i can't possibly express how wrong-headed i think this is. = is a
function from values to truth-values. assignment has a side-effect.
besides, if symbols are first-class, then how do you test for equality
of symbols?
----- Original Message -----
From: "Joe Bowbeer" <joe.bowbeer@...>
To: <concatenative@yahoogroups.com>
Sent: Thursday, June 22, 2006 6:34 PM
Subject: Re: [stack] Define statements
> On 6/22/06, Christopher Diggins <cdiggins@...> wrote:
> > I see no problem with that. It is just a personal preference to avoid
> > overloading "=" and to place the symbol argument first.
> >
>
> A few thoughts:
>
> If a program is a first-class value in your language then using "="
> for assignment of these values seems natural. (Assuming a symbol can
> only have one value.)
>
> If you place the symbol second then it's easy for one program to
> generate another program by leaving it on the stack, where it can be
> assigned or applied -- or whatever.
>
> This discussion reminds me a Scheme, where functions are first-class
> values. In Scheme, though, closures (environment + continuation) eat
> their own trail, leading toward stackless execution. While what you
> are describing, storing assignments on the stack, seems more similar
> to traditional dynamically-bound Lisp.
>
>
> On 6/22/06, Christopher Diggins <cdiggins@...> wrote:
> > I see no problem with that. It is just a personal preference to avoid
> > overloading "=" and to place the symbol argument first.
> >
> > So I could easily define def in my library using your syntax as follows:
> >
> > $def [swap =] =
> >
> >
> > On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>
> > wrote:
> > >
> > > $inc [1 +] def
> > >
> >
> > What's the difference between 'def' and '=' then?
> >
> > Why not the following?
> >
> > [1 +] $inc =
> >
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
Joe Bowbeer — 2006-06-23 03:56:15
On 6/22/06, stevan apter <
sa@...> wrote:
>
> i can't possibly express how wrong-headed i think this is.
There's not enough context for me to figure what you mean by "this".
(It's something I wrote, right?)
> = is a function from values to truth-values. assignment has
> a side-effect. besides, if symbols are first-class, then how
> do you test for equality of symbols?
>
In what I wrote, I was assuming '=' was a function that associated
symbols with their values. It assigns. Whereas you are describing
something that tests for equality.
Assignment *can* be implemented purely on the stack -- to avoid
side-effects in a world where stack effects are not considered to be
side-effects.
Though I personally find it more interesting to explore what
programming would be like without assignment.
> ----- Original Message -----
> From: "Joe Bowbeer" <joe.bowbeer@...>
> To: <concatenative@yahoogroups.com>
> Sent: Thursday, June 22, 2006 6:34 PM
> Subject: Re: [stack] Define statements
>
>
> > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:
> > > I see no problem with that. It is just a personal preference to avoid
> > > overloading "=" and to place the symbol argument first.
> > >
> >
> > A few thoughts:
> >
> > If a program is a first-class value in your language then using "="
> > for assignment of these values seems natural. (Assuming a symbol can
> > only have one value.)
> >
> > If you place the symbol second then it's easy for one program to
> > generate another program by leaving it on the stack, where it can be
> > assigned or applied -- or whatever.
> >
> > This discussion reminds me a Scheme, where functions are first-class
> > values. In Scheme, though, closures (environment + continuation) eat
> > their own trail, leading toward stackless execution. While what you
> > are describing, storing assignments on the stack, seems more similar
> > to traditional dynamically-bound Lisp.
> >
> >
> > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:
> > > I see no problem with that. It is just a personal preference to avoid
> > > overloading "=" and to place the symbol argument first.
> > >
> > > So I could easily define def in my library using your syntax as follows:
> > >
> > > $def [swap =] =
> > >
> > >
> > > On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>
> > > wrote:
> > > >
> > > > $inc [1 +] def
> > > >
> > >
> > > What's the difference between 'def' and '=' then?
> > >
> > > Why not the following?
> > >
> > > [1 +] $inc =
> > >
>
stevan apter — 2006-06-23 09:54:32
----- Original Message -----
From: "Joe Bowbeer" <joe.bowbeer@...>
To: <concatenative@yahoogroups.com>
Sent: Thursday, June 22, 2006 11:56 PM
Subject: Re: [stack] Define statements
> On 6/22/06, stevan apter <sa@...> wrote:
> >
> > i can't possibly express how wrong-headed i think this is.
>
> There's not enough context for me to figure what you mean by "this".
> (It's something I wrote, right?)
yes - i assume that cat already uses "=" for equality, so to
overload it to mean assignment is a terrible idea.
>
> > = is a function from values to truth-values. assignment has
> > a side-effect. besides, if symbols are first-class, then how
> > do you test for equality of symbols?
> >
>
> In what I wrote, I was assuming '=' was a function that associated
> symbols with their values. It assigns. Whereas you are describing
> something that tests for equality.
yes
>
> Assignment *can* be implemented purely on the stack -- to avoid
> side-effects in a world where stack effects are not considered to be
> side-effects.
yes - i described one such design.
>
> Though I personally find it more interesting to explore what
> programming would be like without assignment.
i don't disagree.
>
>
> > ----- Original Message -----
> > From: "Joe Bowbeer" <joe.bowbeer@...>
> > To: <concatenative@yahoogroups.com>
> > Sent: Thursday, June 22, 2006 6:34 PM
> > Subject: Re: [stack] Define statements
> >
> >
> > > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:
> > > > I see no problem with that. It is just a personal preference to avoid
> > > > overloading "=" and to place the symbol argument first.
> > > >
> > >
> > > A few thoughts:
> > >
> > > If a program is a first-class value in your language then using "="
> > > for assignment of these values seems natural. (Assuming a symbol can
> > > only have one value.)
> > >
> > > If you place the symbol second then it's easy for one program to
> > > generate another program by leaving it on the stack, where it can be
> > > assigned or applied -- or whatever.
> > >
> > > This discussion reminds me a Scheme, where functions are first-class
> > > values. In Scheme, though, closures (environment + continuation) eat
> > > their own trail, leading toward stackless execution. While what you
> > > are describing, storing assignments on the stack, seems more similar
> > > to traditional dynamically-bound Lisp.
> > >
> > >
> > > On 6/22/06, Christopher Diggins <cdiggins@...> wrote:
> > > > I see no problem with that. It is just a personal preference to avoid
> > > > overloading "=" and to place the symbol argument first.
> > > >
> > > > So I could easily define def in my library using your syntax as follows:
> > > >
> > > > $def [swap =] =
> > > >
> > > >
> > > > On 6/22/06, Christopher Diggins <cdiggins@... <cdiggins%40gmail.com>>
> > > > wrote:
> > > > >
> > > > > $inc [1 +] def
> > > > >
> > > >
> > > > What's the difference between 'def' and '=' then?
> > > >
> > > > Why not the following?
> > > >
> > > > [1 +] $inc =
> > > >
> >
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
stevan apter — 2006-07-05 22:05:28
the solution i've settled on for F says that everything is a
function from (environment;stack;queue) to (environment;stack;queue).
The environment is an association of names and values. Assignment
updates the input environment and returns a new environment.
functions are free to do what they want with any component of an
input triple.
i suppose this is implementation-dependent, but keeping the
environment distinct from the stack, at least conceptually, seems
like a good thing. the stack is where results go; the environment
is where bindings go.
----- Original Message -----
From: "Christopher Diggins" <cdiggins@...>
To: <concatenative@yahoogroups.com>
Sent: Thursday, June 22, 2006 3:24 PM
Subject: Re: [stack] Define statements
> ".. introduces state ... "
>
> Good point John. Here is a possible (but not completely thought out)
> solution: allow the definition of symbols as special hash-table values on
> the stack. Global functions are defined at the bottom of the stack. Each
> symbol-hash table acts like a local scope.
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Christopher Diggins — 2006-07-06 15:48:32
Hi Stevan, What you propose is definitely a reasonable solution.
In Cat however I want to be able to incorporate the idea of nested scope and
nested namespaces. In other words, I want to create environments within
environments. This makes it easier for people developing very complex
software, and it makes mappings from other languages more smooth.
A natural way to do this is to say that each function can have its own
bindings (or environment if you prefer) which requires all definitions to be
unambiguous and resolvable at compile-time. So no reassignments.
In pseudo-code:
define f = a [define g = c; g d] e;
- Christopher
On 7/5/06, stevan apter <sa@...> wrote:
>
> the solution i've settled on for F says that everything is a
> function from (environment;stack;queue) to (environment;stack;queue).
>
> The environment is an association of names and values. Assignment
> updates the input environment and returns a new environment.
>
> functions are free to do what they want with any component of an
> input triple.
>
> i suppose this is implementation-dependent, but keeping the
> environment distinct from the stack, at least conceptually, seems
> like a good thing. the stack is where results go; the environment
> is where bindings go.
>
>
> ----- Original Message -----
> From: "Christopher Diggins" <cdiggins@... <cdiggins%40gmail.com>>
> To: <concatenative@yahoogroups.com <concatenative%40yahoogroups.com>>
> Sent: Thursday, June 22, 2006 3:24 PM
> Subject: Re: [stack] Define statements
>
> > ".. introduces state ... "
> >
> > Good point John. Here is a possible (but not completely thought out)
> > solution: allow the definition of symbols as special hash-table values
> on
> > the stack. Global functions are defined at the bottom of the stack. Each
> > symbol-hash table acts like a local scope.
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>
>
>
[Non-text portions of this message have been removed]
stevan apter — 2006-07-06 21:22:04
hi christopher
so you want to be able to say things like
f is g h
where g is i j
where i is ..
where j is ..
where h is ..
where g and h are local to f and i and j are local to g.
a couple of questions:
can g and h see each other?
can i see g? f?
what kind of scoping rules do you envision?
i realize that this is a well-worn topic in language theory,
although i'm not myself well-acquainted with all the options
or terminology. i had to work my way (painfully) through
the alternatives before i had something which was flexible
enough to scale to my satisfaction. here's my description
of the scoping rules for SLACK:
http://nsl.com/k/slack/slack.htm#2.4%20Definitions
and here's a ray-tracer which demonstrates nested scope:
http://nsl.com/k/slack/slack.htm#Ray%20tracer
would you want to supplement the expression language with non-
functional keywords like 'def' and 'where'?
this could be avoided with dot-notation. e.g. the above example
could be written:
g h : f
i j : f.g
.. : f.g.i
.. : f.g.j
.. : h
: is assignment. a name is explicitly scoped by its structure.
(leading dots climb the tree.)
(you don't even need the : since you don't support reassignment:
in interpretation, if a name is undefined, assign it; if it is
defined, use it.)
----- Original Message -----
From: "Christopher Diggins" <cdiggins@...>
To: <concatenative@yahoogroups.com>
Sent: Thursday, July 06, 2006 11:48 AM
Subject: Re: [stack] Define statements
> Hi Stevan, What you propose is definitely a reasonable solution.
>
> In Cat however I want to be able to incorporate the idea of nested scope and
> nested namespaces. In other words, I want to create environments within
> environments. This makes it easier for people developing very complex
> software, and it makes mappings from other languages more smooth.
>
> A natural way to do this is to say that each function can have its own
> bindings (or environment if you prefer) which requires all definitions to be
> unambiguous and resolvable at compile-time. So no reassignments.
>
> In pseudo-code:
>
> define f = a [define g = c; g d] e;
>
> - Christopher
>
> On 7/5/06, stevan apter <sa@...> wrote:
> >
> > the solution i've settled on for F says that everything is a
> > function from (environment;stack;queue) to (environment;stack;queue).
> >
> > The environment is an association of names and values. Assignment
> > updates the input environment and returns a new environment.
> >
> > functions are free to do what they want with any component of an
> > input triple.
> >
> > i suppose this is implementation-dependent, but keeping the
> > environment distinct from the stack, at least conceptually, seems
> > like a good thing. the stack is where results go; the environment
> > is where bindings go.
> >
> >
> > ----- Original Message -----
> > From: "Christopher Diggins" <cdiggins@... <cdiggins%40gmail.com>>
> > To: <concatenative@yahoogroups.com <concatenative%40yahoogroups.com>>
> > Sent: Thursday, June 22, 2006 3:24 PM
> > Subject: Re: [stack] Define statements
> >
> > > ".. introduces state ... "
> > >
> > > Good point John. Here is a possible (but not completely thought out)
> > > solution: allow the definition of symbols as special hash-table values
> > on
> > > the stack. Global functions are defined at the bottom of the stack. Each
> > > symbol-hash table acts like a local scope.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
Christopher Diggins — 2006-07-08 17:24:36
Hi Stevan,
I want to make Cat as close to a simple imperative language as
possible (like C). So the scoping will be resembly any other Algol
derived language.
def j { ... }
def h { ... }
def i { ... }
def g { i j }
def f { g h }
This is the reverse of what you propose. Definitions like this would
persist until the end of the closing block " { } ".
In this syntax I am using { } as grouping operators.
On 7/6/06, stevan apter <sa@...> wrote:
>
>
>
>
>
>
>
> hi christopher
>
> so you want to be able to say things like
>
> f is g h
> where g is i j
> where i is ..
> where j is ..
> where h is ..
>
> where g and h are local to f and i and j are local to g.
>
> a couple of questions:
>
> can g and h see each other?
>
> can i see g? f?
>
> what kind of scoping rules do you envision?
Manfred Von Thun — 2006-07-26 07:50:06
On 23/6/06 5:24 AM, "Christopher Diggins" <
cdiggins@...> wrote:
>
>
>
>
> ".. introduces state ... "
>
> Good point John. Here is a possible (but not completely thought out)
> solution: allow the definition of symbols as special hash-table values on
> the stack. Global functions are defined at the bottom of the stack. Each
> symbol-hash table acts like a local scope.
>
> [Non-text portions of this message have been removed]
>
I am very much behind in my reading of the mail selling a house and
clearing
out 34 years of accumulated junk takes a lot of time.
On the question whether a hashtable of symbolvalue associations sitting
somewhere on the stack would change Joy from being stateless (no assignment,
purely functional) to being ³statefull²: I think the answer is NO. Here is
my tentative argument for your consideration.
The argument takes the form
if p then q, if q then r, if r then s, if s then t, but not-t, therefore
not-p
If such a hashtable adds state, then so does a simpler less efficient
implementation that uses a linear list of symbol-value pairs. (Lookup and
update are quite easy.)
If such a linear list of associations adds state, then so does a more
primitive implementation of just a linear list of values. (Lookup is now by
operators such as first, second, third .. or by indexed access. Update also
straightforward.)
If such a list of values adds state, then so does a single list of just one
value. (Now lookup and update are quite trivial)
If a single list of just one value adds state, then so does a bare single
value.
(Now lookup is a noop, the value is just sitting there, and update is just
the use of some operator.)
But a bare single value does not add state.
Therefore a hashtable sitting somewhere on the stack does not add state.
Thoughts much appreciated.
- Manfred
[Non-text portions of this message have been removed]
Manfred Von Thun — 2006-07-26 08:22:05
On 7/7/06 1:48 AM, "Christopher Diggins" <
cdiggins@...> wrote:
>
>
>
>
> Hi Stevan, What you propose is definitely a reasonable solution.
>
> In Cat however I want to be able to incorporate the idea of nested scope and
> nested namespaces. In other words, I want to create environments within
> environments. This makes it easier for people developing very complex
> software, and it makes mappings from other languages more smooth.
>
> A natural way to do this is to say that each function can have its own
> bindings (or environment if you prefer) which requires all definitions to be
> unambiguous and resolvable at compile-time. So no reassignments.
>
> In pseudo-code:
>
> define f = a [define g = c; g d] e;
>
> - Christopher
>
In Joy you would write this as
DEFINE
HIDE g == c
IN f == a g d e.
You can even have several definitions in the HIDE-part and in the IN-part:
DEFINE
HIDE g1 == c1; g2 == c2
IN f1 == a g1 d e; f2 == h g1 g2 i.
Now f1 and f2 are globally defined, and both have access to g1 and g2. But
g1 and g2 are invisible outside the IN-part. Such a treatment of locality is
not possible in Algolic block structure. But to some extent the effect can
be achieved in the C language in which some declarations are local to a file
(the HIDE-part), and some declarations in that file become global (the
IN-part). But I don¹t think any construction in C would allow you to have
HIDE-parts and IN-parts inside other HIDE-parts and IN-parts, as you can in
Joy. Nevertheless, the inspiration came from C.
I was rather pleased with HIDE..IN.., but from memory the group did not
like it.
- Manfred
[Non-text portions of this message have been removed]
William Tanksley, Jr — 2006-07-26 15:39:03
Manfred Von Thun <
m.vonthun@...> wrote:
> If such a hashtable adds state, then so does a simpler less efficient
> implementation that uses a linear list of symbol-value pairs. (Lookup and
> update are quite easy.)
We have to appreciate having a professor of logic in our discussion group :-).
[...]
> If a single list of just one value adds state, then so does a bare single
> value.
> (Now lookup is a noop, the value is just sitting there, and update is just
> the use of some operator.)
> But a bare single value does not add state.
This is false. A bare single variable that can be updated and examined
does add state, because the actual value in the variable can affect
the execution of the program. In such a case, the value of the lone
variable, plus the value of the stack, plus the value of the 'queue'
(or whatever we use) would be called the state of the program. If you
did not know the value of the variable, you could never predict the
result of certain program operations.
> - Manfred
-Billy
Manfred Von Thun — 2006-08-04 08:25:14
On 27/7/06 1:39 AM, "William Tanksley, Jr" <
wtanksleyjr@...> wrote:
>
> Manfred Von Thun <m.vonthun@... <mailto:m.vonthun%40latrobe.edu.au>
> > wrote:
>
>> > If a single list of just one value adds state, then so does a bare single
>> > value.
>> > (Now lookup is a noop, the value is just sitting there, and update is just
>> > the use of some operator.)
>
>> > But a bare single value does not add state.
>
> This is false. A bare single variable that can be updated and examined
> does add state, because the actual value in the variable can affect
> the execution of the program. In such a case, the value of the lone
> variable, plus the value of the stack, plus the value of the 'queue'
> (or whatever we use) would be called the state of the program. If you
> did not know the value of the variable, you could never predict the
> result of certain program operations.
>
> -Billy
The argument starts with a hashtable somewhere on the stack, and ends with a
bare single value somewhere on the stack. That bare single value might be
just a number, say 5, on top of the stack. We can change it with an operator
(by doing taking its square, say) , thus updating what is on top of the
stack. That¹s just purely functional concatenative programming without a
separate state. So a bare single value does not add state. If there is a
flaw in my argument, it must be in one of the earlier (conditional)
premises.
But I cannot see which one it might be.
- Manfred
[Non-text portions of this message have been removed]
William Tanksley, Jr — 2006-08-04 14:01:13
Manfred Von Thun <
m.vonthun@...> wrote:
> On 27/7/06 1:39 AM, "William Tanksley, Jr" <wtanksleyjr@...> wrote:
> >> > (Now lookup is a noop, the value is just sitting there, and update is just
> >> > the use of some operator.)
> >> > But a bare single value does not add state.
> > This is false. A bare single variable that can be updated and examined
> > does add state, because the actual value in the variable can affect
> > the execution of the program. In such a case, the value of the lone
> > variable, plus the value of the stack, plus the value of the 'queue'
> > (or whatever we use) would be called the state of the program. If you
> > did not know the value of the variable, you could never predict the
> > result of certain program operations.
> The argument starts with a hashtable somewhere on the stack, and ends with a
> bare single value somewhere on the stack.
There's the missing link: I didn't know that you were talking about a
hashtable "somewhere on the stack". We were discussing redefinitions,
not mutable data.
> That bare single value might be
> just a number, say 5, on top of the stack. We can change it with an operator
> (by doing taking its square, say) , thus updating what is on top of the
> stack. That¹s just purely functional concatenative programming without a
> separate state. So a bare single value does not add state.
> If there is a
> flaw in my argument, it must be in one of the earlier (conditional)
> premises.
> But I cannot see which one it might be.
Let's go back to the list containing one item. Now suppose that you're
allowed to mutate it, and also at any point in the program get, store,
and manipulate a reference to it. NOW its value is considered state,
because you can't staticly track what its value might be. It's become
a variable, not merely a data item.
This is the issue with allowing redefinitions.
> - Manfred
-Billy
John Cowan — 2006-08-21 19:19:54
Manfred Von Thun scripsit:
> The argument starts with a hashtable somewhere on the stack, and ends with a
> bare single value somewhere on the stack. That bare single value might be
> just a number, say 5, on top of the stack. We can change it with an operator
> (by doing taking its square, say) , thus updating what is on top of the
> stack. That's just purely functional concatenative programming without a
> separate state. So a bare single value does not add state. If there is a
> flaw in my argument, it must be in one of the earlier (conditional)
> premises.
The flaw is that a hashtable cannot be reduced to a single unboxed value on
the stack; at best it can be reduced to a pointer to a boxed and mutable
value. Currently all the things that can be pushed on the stack are
immutable, being either atomic values or immutable lists (no set-car! or
set-cdr! operations in Joy).
--
With techies, I've generally found John Cowan
If your arguments lose the first round
http://www.ccil.org/~cowan
Make it rhyme, make it scan
cowan@...
Then you generally can
Make the same stupid point seem profound! --Jonathan Robie
Manfred Von Thun — 2006-08-29 06:45:44
On 22/8/06 5:19 AM, "John Cowan" <
cowan@...> wrote:
>
>
>
>
> Manfred Von Thun scripsit:
>
>> > The argument starts with a hashtable somewhere on the stack, and ends with
a
>> > bare single value somewhere on the stack. That bare single value might be
>> > just a number, say 5, on top of the stack. We can change it with an
>> operator
>> > (by doing taking its square, say) , thus updating what is on top of the
>> > stack. That's just purely functional concatenative programming without a
>> > separate state. So a bare single value does not add state. If there is a
>> > flaw in my argument, it must be in one of the earlier (conditional)
>> > premises.
>
> 0The flaw is that a hashtable cannot be reduced to a single unboxed value on
> the stack; at best it can be reduced to a pointer to a boxed and mutable
> value. Currently all the things that can be pushed on the stack are
> immutable, being either atomic values or immutable lists (no set-car! or
> set-cdr! operations in Joy).
First, let me make it clear that I was not arguing against implementing
hashtables
somewhere on the stack. Such facility would make a lot of programming in Joy
much
easier and clearer.
Ignoring get and put and other file manipulations, Joy programs compute
functions
from stacks to stacks. The programs can change the stack in its entirety.
But the
changes are not like assignment or set-car! or set-cdr!, as you rightly
observe,
so Joy is purely functional., and not procedural.
My argument had the conclusion: adding hashtable(s) somewhere on the stack
does not destroy the purely functional nature of Joy. The first step was
this:
hashtables are an efficient way to implement name/value associations, but
the efficiency is just a welcome bonus. Another way to implement such
associations is by a crude list of pairs, such as
[ [year 2006] [pi 3.16] [greeting ³hello my friend²] ...]
Anything hashtables can do can be done by such lists of association pairs,
initialisation, lookup, redefinition (!), undefine ...
Of some interest might be redefinition:
assuming the list has been taken to the top of the stack, here is how you
change the value of pi:
uncons unswons uncons pop [3.14] cons swons uncons
alternatively, you might use a search to find the pair that starts with pi
and then change to 3.14.
Since hashtables and lists of pairs differ only in their efficiency, not in
their
semantics, I maintain:
The first conditional:
if adding hashtables somewhere on the stack makes Joy procedural,
then adding lists of association pairs on the stack makes Joy
procedural.
Are we at least agreed on this conditional?
I am a little puzzled by what you meant by ³reduced² here I was only
concerned with the question whether hashtables change the nature of Joy.
But thanks for the comment, John. I have finally been thrown off
the old mainframe (they had to kill it to get me off, screaming loud
protests). Now somebody here is going to implant gcc into this
dreadful eMac that I have been condemned to use, for sins that
I must have committed. I still dread the entire transplant, and fear
the worst. But one day I shall be ready to try out your Scheme
implementation of Joy. In the meantime I wish you luck with it.
As I mentioned some time ago, I have sold my house and emptied
it of more than 3 decades of accumulated junk, and that has kept
me rather busy. I hope to be around uni a bit more.
Best wishes to all
- Manfred
[Non-text portions of this message have been removed]