Re: [stack] conk manual
stevan apter — 2000-06-23 16:51:42
----- Original Message -----
From: stevan apter <apter@...>
To: <concatenative@egroups.com>
Sent: Friday, June 23, 2000 10:40 AM
Subject: [stack] conk manual
> each-
> right. the latter two may always be replaced by projection-with-each:
> a f each-left b -> f[a]each b, and a f each-right b -> f[;b]each a.
of course, i defined these backwards. should be:
a f each-right b -> f[a]each b, and a f each-left b -> f[;b]each a.
> (i exclude
> dictionary recursion from consideration, since a conservative
> extension of atomic application to those datatypes is well known).
so well known, in fact, that i've added it to the latest version
of conk; e.g.
k>[[ten 10][twenty 20][thirty 30]]d 1 +
k>[[ten 11 nil] [twenty 21 nil] [thirty 31 nil]] d
a further (conservative) extension involves defining the shape of
a dictionary to be the list of its entries, &c., and, in general,
extending the list primitives to dictionaries. for example, the
transpose of an n-dimensional dictionary is a dictionary with its
first two levels swapped. this is particularly useful when we
represent crosstabulations as two dimensional dictionaries of
atomic elements. i haven't implemented the list extensions yet
(although i probably will).
you may wonder about the nils in conk's dictionary display.
the explanation is that k dictionaries are structures of
triples - name, value, dictionary or nil. the third element
is a dictionary of what we call attributes. for example, the
variable a.b (the entry `b in the dictionary a) may have a
value (e.g. 20), and it may also have a set of attributes;
for example, foreground and background colors a..fg and a..bg.
fg and bg are variables in the attribute dictionary of a.
they in turn may have attributes as well as values, &c.
this seques into an interesting question - i think it may be a
central one for conk. namely, the effect of identifying lists
with intensional quotation (i know this question vexes you billy).
for example, in k, i can define a list
(2+2;3-4)
which is fully evaluated to be
(4;-1)
but of course in joy the list
[[2 2 +][3 4 -]]
is a list of unevaluated programs. so while in k i can say
.((`one;10;.((`fg;99);(`bg;9900)));(`two;20))
in conk i cannot say
[[one 10 [[fg 99][bg 9900]]d][two 20]]d
the attribute dictionary for entry one is not constructed. instead,
i have to do by explicitly amending one dictionary at the appropriate
attribute dictionary position with a second dictionary:
k>[[one 10][two 20]]d one dot [is] [[fg 99][bg 9900]]d id atofwith
[[one 10 [[fg 99 nil] [bg 9900 nil]] d] [two 20 nil]] d
which in turn is a translation into conk of the k expression:
@[.((`one;10);(`two;20));`one.;:;.((`fg;99);(`bg;9900))]
.((`one
10
.((`fg;99;)
(`bg;9900;)))
(`two;20;))
in focussing on applicative/combinative vs. concatenative, we
may tend to lose sight of this further difference, which (i think)
has an equally significant impact on programming. (i think manfred
has something to say about this issue in the 'rewriting' paper on
his website.)
Louis Madon — 2000-06-24 05:46:35
stevan apter wrote:
> for example, in k, i can define a list
>
> (2+2;3-4)
>
> which is fully evaluated to be
>
> (4;-1)
>
> but of course in joy the list
>
> [[2 2 +][3 4 -]]
>
> is a list of unevaluated programs. so while in k i can say
>
> .((`one;10;.((`fg;99);(`bg;9900)));(`two;20))
>
> in conk i cannot say
>
> [[one 10 [[fg 99][bg 9900]]d][two 20]]d
>
> the attribute dictionary for entry one is not constructed.
I agree that the way Joy blends aggregation and quotation with the []
syntax is not always convenient. Perhaps there should be a separate
syntax for specifying just aggregation. For example, if the curly
brackets denoted this, then your example would be:
{{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d
Notice that 'one' and 'two' are still quoted since we only want their
symbols. Everything else will be fully evaluated. In effect, the above
exression could be syntactic sugar for:
[[fg 99][bg 9900]]d unitlist 10 cons [one] cons 20 unitlist [two] cons
pair d
So, {} need not represent any fundamental changes to the language.
>
> in focussing on applicative/combinative vs. concatenative, we
> may tend to lose sight of this further difference, which (i think)
> has an equally significant impact on programming.
I don't see how its equally significant. Its just a matter of not
applying quotation needlessly. Any system that supports quotation will
have this issue. (Can you meta-program in K?).
--
Louis.
stevan apter — 2000-06-24 12:29:29
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Saturday, June 24, 2000 1:46 AM
Subject: Re: [stack] conk manual
> Perhaps there should be a separate
> syntax for specifying just aggregation. For example, if the curly
> brackets denoted this, then your example would be:
>
> {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d
>
> Notice that 'one' and 'two' are still quoted since we only want their
> symbols. Everything else will be fully evaluated. In effect, the above
> exression could be syntactic sugar for:
>
> [[fg 99][bg 9900]]d unitlist 10 cons [one] cons 20 unitlist [two] cons
> pair d
>
> So, {} need not represent any fundamental changes to the language.
this is a very nice idea. thanks!
>
> >
> > in focussing on applicative/combinative vs. concatenative, we
> > may tend to lose sight of this further difference, which (i think)
> > has an equally significant impact on programming.
>
> I don't see how its equally significant. Its just a matter of not
> applying quotation needlessly. Any system that supports quotation will
> have this issue. (Can you meta-program in K?).
i think so (i never understand what people have in mind when they
use this term).
thanks again.
>
>
> --
> Louis.
>
> ------------------------------------------------------------------------
> Special eGroups Offer: Save On Long Distance Today!
> http://click.egroups.com/1/5073/7/_/_/_/961825285/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
stevan apter — 2000-06-24 13:08:45
the simplest implementation would seem to be to modify the parser
to invoke the evaluater on braced expressions:
k>{2 2 +}
k>5
this approach is easy to code, requiring the single line
i.e:{n:(=/+\'x=/:"{}")?1;((n+1)_ x;y,().k.E/I 1_ n#x)}
that is, if the first character is a '{', find the mated '}',
parse what's between them, evaluate that, and return it and
what's left to parse.
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Saturday, June 24, 2000 1:46 AM
Subject: Re: [stack] conk manual
> stevan apter wrote:
>
> > for example, in k, i can define a list
> >
> > (2+2;3-4)
> >
> > which is fully evaluated to be
> >
> > (4;-1)
> >
> > but of course in joy the list
> >
> > [[2 2 +][3 4 -]]
> >
> > is a list of unevaluated programs. so while in k i can say
> >
> > .((`one;10;.((`fg;99);(`bg;9900)));(`two;20))
> >
> > in conk i cannot say
> >
> > [[one 10 [[fg 99][bg 9900]]d][two 20]]d
> >
> > the attribute dictionary for entry one is not constructed.
>
> I agree that the way Joy blends aggregation and quotation with the []
> syntax is not always convenient. Perhaps there should be a separate
> syntax for specifying just aggregation. For example, if the curly
> brackets denoted this, then your example would be:
>
> {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d
>
> Notice that 'one' and 'two' are still quoted since we only want their
> symbols. Everything else will be fully evaluated. In effect, the above
> exression could be syntactic sugar for:
>
> [[fg 99][bg 9900]]d unitlist 10 cons [one] cons 20 unitlist [two] cons
> pair d
>
> So, {} need not represent any fundamental changes to the language.
>
> >
> > in focussing on applicative/combinative vs. concatenative, we
> > may tend to lose sight of this further difference, which (i think)
> > has an equally significant impact on programming.
>
> I don't see how its equally significant. Its just a matter of not
> applying quotation needlessly. Any system that supports quotation will
> have this issue. (Can you meta-program in K?).
>
>
> --
> Louis.
>
> ------------------------------------------------------------------------
> Special eGroups Offer: Save On Long Distance Today!
> http://click.egroups.com/1/5073/7/_/_/_/961825285/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
wtanksley@bigfoot.com — 2000-06-24 17:59:41
From: Louis Madon [mailto:
madonl@...]
>I agree that the way Joy blends aggregation and quotation with the []
>syntax is not always convenient. Perhaps there should be a separate
>syntax for specifying just aggregation. For example, if the curly
>brackets denoted this, then your example would be:
I agree. However, because I also believe that we need a 'function' datatype
and a way to enter 'function' literals, I would prefer using ` to indicate
quotation. Thus,
[this is aggregation]
`[this is quoted aggregation]
[`this `is `quoted `aggregation]
`this `is `quotation `without `aggregation
See what I mean?
>Louis.
-Billy
Louis Madon — 2000-06-25 08:29:51
wtanksley@... wrote:
>
> From: Louis Madon [mailto:madonl@...]
>
> >I agree that the way Joy blends aggregation and quotation with the []
> >syntax is not always convenient. Perhaps there should be a separate
> >syntax for specifying just aggregation. For example, if the curly
> >brackets denoted this, then your example would be:
>
> I agree. However, because I also believe that we need a 'function'
> datatype
> and a way to enter 'function' literals, I would prefer using ` to
> indicate
> quotation. Thus,
>
> [this is aggregation]
> `[this is quoted aggregation]
> [`this `is `quoted `aggregation]
> `this `is `quotation `without `aggregation
>
> See what I mean?
Yes, I like this. It makes aggregation and quotation orthogonal. I
wonder about quotation+aggregation which seems to be a very common case.
I would prefer not to have to type two characters ('[) every time
(though I certainly recognize the mnemonic benefit of doing it that
way).
Also, a possible alternative to backquote is backslash. Backslash is
consistent with escaping inside strings (why introduce a different
character for something that is conceptually similar?) and it is not
easy to confuse with forward quote.
For example:
[this is quoted aggregation]
{this is aggregation}
\this \is \quotation \without \aggregation
I think its hard to decide without gaining some experience with a few
styles. Whatever syntax is chosen, I'm quite certain its worth doing.
--
Louis.
Louis Madon — 2000-06-25 10:37:20
stevan apter wrote:
>
> ----- Original Message -----
> From: Louis Madon <madonl@...>
> > I don't see how its equally significant. Its just a matter of not
> > applying quotation needlessly. Any system that supports quotation
> will
> > have this issue. (Can you meta-program in K?).
>
> i think so (i never understand what people have in mind when they
> use this term).
Yes, it is a rather loose term. What I meant was: does K allow you to
treat code as data? To do that it must provide some means to distinguish
between code to be executed and code to be treated as data, ie.
quotation. If so, then K programmers need to deal with the exact same
issue.
--
Louis.
stevan apter — 2000-06-25 12:59:07
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Sunday, June 25, 2000 4:29 AM
Subject: Re: [stack] conk manual
> wtanksley@... wrote:
> >
> > From: Louis Madon [mailto:madonl@...]
>
> For example:
>
> [this is quoted aggregation]
> {this is aggregation}
> \this \is \quotation \without \aggregation
>
>
> I think its hard to decide without gaining some experience with a few
> styles. Whatever syntax is chosen, I'm quite certain its worth doing.
in conk, extracting a function from its quotation leaves it on the stack:
k>1 2 [+] first
1 2 +
at which point it can be applied with i:
k>i
3
so
q == [id] step
gives:
k>[+ - *]q
+ - *
>
>
> --
> Louis.
>
> ------------------------------------------------------------------------
> STEALS AND DEALS! Cheapest prices on airfare, new cars, insurance, maids,
> contractors, collectibles, more. Get exactly what you want at the lowest
> price. New FREE service!
> http://click.egroups.com/1/5746/7/_/_/_/961921482/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
stevan apter — 2000-06-25 13:13:24
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Sunday, June 25, 2000 6:37 AM
Subject: Re: [stack] conk manual
> stevan apter wrote:
> >
> > ----- Original Message -----
> > From: Louis Madon <madonl@...>
> > > I don't see how its equally significant. Its just a matter of not
> > > applying quotation needlessly. Any system that supports quotation
> > will
> > > have this issue. (Can you meta-program in K?).
> >
> > i think so (i never understand what people have in mind when they
> > use this term).
>
> Yes, it is a rather loose term. What I meant was: does K allow you to
> treat code as data? To do that it must provide some means to distinguish
> between code to be executed and code to be treated as data, ie.
> quotation. If so, then K programmers need to deal with the exact same
> issue.
yes, we can represent code as data, in the form of a string; and there is
an execute operation. but strings have no structure, and consequently
execute executes the whole string:
s:"((2+3);(4*5-6))"
. s
5 -4
by contrast, joy quotations have structure, and, like the one we were
discussing, we often want some parts evaluated and others not. that's
why your proposal for adding {} solves the problem - it gives us the
structuring power of lists without the quotational property.
>
>
> --
> Louis.
>
> ------------------------------------------------------------------------
> Get a NextCard Visa, in 30 seconds!
> 1. Fill in the brief application
> 2. Receive approval decision within 30 seconds
> 3. Get rates as low as 2.9% Intro or 9.9% Fixed APR
> http://click.egroups.com/1/5197/7/_/_/_/961929130/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
Louis Madon — 2000-06-26 01:16:57
[I also posted an earlier response yesterday via the egroups' website
but it hasn't appeared. Does anyone know if posting that way ever
works?]
stevan apter wrote:
> > wtanksley@... wrote:
> > >
> > > From: Louis Madon [mailto:madonl@...]
> >
> > For example:
> >
> > [this is quoted aggregation]
> > {this is aggregation}
> > \this \is \quotation \without \aggregation
> >
> >
> > I think its hard to decide without gaining some experience with a
> few
> > styles. Whatever syntax is chosen, I'm quite certain its worth
> doing.
>
> in conk, extracting a function from its quotation leaves it on the
> stack:
>
> k>1 2 [+] first
> 1 2 +
Same as in Joy, but I would prefer that the response was:
k>1 2 [+] first
1 2 \+
since I feel that any particular state of the stack should be rendered
in a way that replaying that sequence onto an emtpy stack will reproduce
the original state.
Pushing,
1 2 + gives 3 (this is not the original 1 2 + )
whereas, if we have a quotation syntax, then
1 2 \+ gives 1 2 \+ (original state reproduced)
>
> at which point it can be applied with i:
> k>i
> 3
So in conk, i is able to accept individually quoted functions in
addition to normal (aggregate) quotations. I fully agree with this
because essentially the meaning of i is execution. Quoted functions and
aggregate quotations are both executable (allowing i for one and not the
other - as in Joy - seems to be an anomaly; what justification could
there be?).
>
> so
>
> q == [id] step
>
> gives:
>
> k>[+ - *]q
> + - *
Are you intending q to be an alternative for backquote/backslash? If so,
then:
k>1 2 [+] first
1 2 [+]q
--
Louis.
stevan apter — 2000-06-26 03:40:03
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Sunday, June 25, 2000 9:16 PM
Subject: Re: [stack] conk manual
> [I also posted an earlier response yesterday via the egroups' website
> but it hasn't appeared. Does anyone know if posting that way ever
> works?]
>
> stevan apter wrote:
> > > wtanksley@... wrote:
> > > >
> > > > From: Louis Madon [mailto:madonl@...]
> > >
> > > For example:
> > >
> > > [this is quoted aggregation]
> > > {this is aggregation}
> > > \this \is \quotation \without \aggregation
> > >
> > >
> > > I think its hard to decide without gaining some experience with a
> > few
> > > styles. Whatever syntax is chosen, I'm quite certain its worth
> > doing.
> >
> > in conk, extracting a function from its quotation leaves it on the
> > stack:
> >
> > k>1 2 [+] first
> > 1 2 +
>
> Same as in Joy, but I would prefer that the response was:
>
> k>1 2 [+] first
> 1 2 \+
>
> since I feel that any particular state of the stack should be rendered
> in a way that replaying that sequence onto an emtpy stack will reproduce
> the original state.
a nice property to have, i agree, although i can think of two
ways to achieve it without introducing a new type of quotation
or a new datatype: signal an error when an operation threatens
to leave a naked function on the stack, or proceed immediately
to execute it. in the second case,
k>1 2 [+] first
3
is there any other reason to have individual quotation?
Louis Madon — 2000-06-27 04:14:00
stevan apter wrote:
> From: Louis Madon <madonl@...>
> > stevan apter wrote:
> > > in conk, extracting a function from its quotation leaves it on the
> > > stack:
> > >
> > > k>1 2 [+] first
> > > 1 2 +
> >
> > Same as in Joy, but I would prefer that the response was:
> >
> > k>1 2 [+] first
> > 1 2 \+
> >
> > since I feel that any particular state of the stack should be
> rendered
> > in a way that replaying that sequence onto an emtpy stack will
> reproduce
> > the original state.
>
> a nice property to have, i agree, although i can think of two
> ways to achieve it without introducing a new type of quotation
> or a new datatype: signal an error when an operation threatens
> to leave a naked function on the stack, or proceed immediately
> to execute it. in the second case,
>
> k>1 2 [+] first
> 3
But the second case is not a solution at all: if I interrupt a program
at point A, render and then reproduce the state of the stack at that
point, and finally try to resume running from point A - it may fail. The
sought after property is that the stack be rendered _accurately_ so that
any subsequent reproduction is indistinguishable from the original.
The first suggestion (the stack is never permitted to contain bare
functions) is a solution but not, IMHO, a desirable one. For one, the
symmetry between stack and list is broken; lists can contain bare
functions, yet stacks cannot. Is it really worth introducing such
restrictions just to avoid adding one new character to the syntax?
>
> is there any other reason to have individual quotation?
I'm not sure. I think its useful that quotation need not involve
aggregation. Its more orthogonal and can make for a simpler core
language - aggregate types can be defined in the standard library (or at
higher levels) rather than being primitive.
--
Louis.
sa@dfa.com — 2000-06-26 18:09:19
the latest version, implmenting voracious evaluation, has
been posted to www.kx.com/technical/contribs/stevan/joy/
sa@dfa.com — 2000-06-27 19:31:13
stevan apter wrote:
> From: Louis Madon <madonl@...>
> > stevan apter wrote:
> > > in conk, extracting a function from its quotation leaves it on the
> > > stack:
> > >
> > > k>1 2 [+] first
> > > 1 2 +
> >
> > Same as in Joy, but I would prefer that the response was:
> >
> > k>1 2 [+] first
> > 1 2 \+
> >
> > since I feel that any particular state of the stack should be
> rendered
> > in a way that replaying that sequence onto an emtpy stack will
> reproduce
> > the original state.
>
> a nice property to have, i agree, although i can think of two
> ways to achieve it without introducing a new type of quotation
> or a new datatype: signal an error when an operation threatens
> to leave a naked function on the stack, or proceed immediately
> to execute it. in the second case,
>
> k>1 2 [+] first
> 3
But the second case is not a solution at all: if I interrupt a program
at point A, render and then reproduce the state of the stack at that
point, and finally try to resume running from point A - it may fail. The
sought after property is that the stack be rendered _accurately_ so that
any subsequent reproduction is indistinguishable from the original.
you may be right, but i can't think of a case where
run-stop-resume does not equal run.
The first suggestion (the stack is never permitted to contain bare
functions) is a solution but not, IMHO, a desirable one. For one, the
symmetry between stack and list is broken; lists can contain bare
functions, yet stacks cannot. Is it really worth introducing such
restrictions just to avoid adding one new character to the syntax?
i don't like the error solution either, which is why
i didn't choose to implement it in conk.
>
> is there any other reason to have individual quotation?
I'm not sure. I think its useful that quotation need not involve
aggregation. Its more orthogonal and can make for a simpler core
language - aggregate types can be defined in the standard library (or at
higher levels) rather than being primitive.
is the first of a list a member of that list? if so,
then [+] first is a member of [+], so `+ is identical
to +, and [+] is identical to [`+].
--
Louis.
------------------------------------------------------------------------
I'm sure this will offend some people, but I think it's funny!
http://click.egroups.com/1/6001/7/_/_/_/962118651/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
concatenative-unsubscribe@egroups.com
wtanksley@bigfoot.com — 2000-06-28 22:50:20
From:
sa@... [mailto:
sa@...]
> is the first of a list a member of that list? if so,
> then [+] first is a member of [+], so `+ is identical
> to +, and [+] is identical to [`+].
Yes, I would expect [x] to be identical to [`x], because quotation implies
escaping as well as aggregation.
However, `x is clearly not in general equivalent to x, because x will do
something, and `x will merely push `x on the stack.
It's imaginable that we seperate lists from quotations, so that it would be
impossible to dequote a list, and impossible to uncons a quotation. This
would certainly make [x] different from [`x]. I don't see a real reason to
do this, though.
Another way to seperate [x] and [`x] is to make aggregation not imply
quotation -- thus, [x] would actually be a list containing the results of x,
and [`x] would be a list containing x itself.
-Billy
Louis Madon — 2000-06-28 23:30:44
sa@... wrote:
>
> > From: Louis Madon <madonl@...>
> But the second case is not a solution at all: if I interrupt a program
> at point A, render and then reproduce the state of the stack at that
> point, and finally try to resume running from point A - it may fail.
> The
> sought after property is that the stack be rendered _accurately_ so
> that
> any subsequent reproduction is indistinguishable from the original.
>
> you may be right, but i can't think of a case where
> run-stop-resume does not equal run.
Ok, here's an example:
1 2 [+] first pop pop
^---- stop here
If you run this straight through, the answer is 1
If you stop at the point indicated, use voracious evaluation to reduce
the state of the stack to 3 and then resume you'll get a stack
underflow.
--
Louis.
stevan apter — 2000-06-29 01:14:17
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Wednesday, June 28, 2000 7:30 PM
Subject: Re: [stack] conk manual
> sa@... wrote:
> >
> > > From: Louis Madon <madonl@...>
> > But the second case is not a solution at all: if I interrupt a program
> > at point A, render and then reproduce the state of the stack at that
> > point, and finally try to resume running from point A - it may fail.
> > The
> > sought after property is that the stack be rendered _accurately_ so
> > that
> > any subsequent reproduction is indistinguishable from the original.
> >
> > you may be right, but i can't think of a case where
> > run-stop-resume does not equal run.
>
> Ok, here's an example:
>
> 1 2 [+] first pop pop
> ^---- stop here
>
> If you run this straight through, the answer is 1
no, it's not. at the stop-point, the stack contains one
item, namely 3. here's the session transcript:
1 2 [+] first stop pop pop
stop
{x;{'`stop}[];x}
^
> x <-- stack
,3
> : <-- resume
(note empty stack after resuming from the stop with :)
> If you stop at the point indicated, use voracious evaluation to reduce
> the state of the stack to 3 and then resume you'll get a stack
> underflow.
actually, in conk, pop of an empty stack is the empty stack,
so we never get an underflow. but that's beside the point.
my understanding (and implementation) of v.e. is that you
you never leave the evaluation of a primitive (in this case,
first) without compressing the stack fully.
>
>
> --
> Louis.
>
> ------------------------------------------------------------------------
> Get a NextCard Visa, in 30 seconds!
> 1. Fill in the brief application
> 2. Receive approval decision within 30 seconds
> 3. Get rates as low as 2.9% Intro or 9.9% Fixed APR
> http://click.egroups.com/1/5197/7/_/_/_/962234728/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
stevan apter — 2000-06-29 01:21:49
----- Original Message -----
From: <wtanksley@...>
To: <concatenative@egroups.com>
Sent: Wednesday, June 28, 2000 6:50 PM
Subject: RE: [stack] conk manual
> From: sa@... [mailto:sa@...]
>
> > is the first of a list a member of that list? if so,
> > then [+] first is a member of [+], so `+ is identical
> > to +, and [+] is identical to [`+].
>
> Yes, I would expect [x] to be identical to [`x], because quotation implies
> escaping as well as aggregation.
>
> However, `x is clearly not in general equivalent to x, because x will do
> something, and `x will merely push `x on the stack.
exactly. which is why i dislike this approach. v.e. avoids
introducing a new (and mysterious) datatype, avoids violating
substitutivity of identicals, and keeps the symmetry of stack
and list. moreover, (i think) there is no computation which
leaves the stack in a state which it couldn't have gotten into
by simply entering the items which it contains.
>
> It's imaginable that we seperate lists from quotations, so that it would be
> impossible to dequote a list, and impossible to uncons a quotation. This
> would certainly make [x] different from [`x]. I don't see a real reason to
> do this, though.
>
> Another way to seperate [x] and [`x] is to make aggregation not imply
> quotation -- thus, [x] would actually be a list containing the results of x,
> and [`x] would be a list containing x itself.
as per louis's suggestion, this is what {} does in conk - grouped evaluation.
but i think you're moving away from the purity and simplicity of joy.
>
> -Billy
>
> ------------------------------------------------------------------------
> Join beMANY! CLICK HERE!
> http://click.egroups.com/1/5062/7/_/_/_/962232599/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
Louis Madon — 2000-06-29 01:40:26
stevan apter wrote:
> From: Louis Madon <madonl@...>
> > >
> > > you may be right, but i can't think of a case where
> > > run-stop-resume does not equal run.
> >
> > Ok, here's an example:
> >
> > 1 2 [+] first pop pop
> > ^---- stop here
> >
> > If you run this straight through, the answer is 1
>
> no, it's not. at the stop-point, the stack contains one
> item, namely 3. here's the session transcript:
Ah, I misunderstood your proposal! I thought you had meant that v.e.
only happens at render time but you mean it happens after every
operation. This is interesting, I'll have to think about this ...
--
Louis.
Louis Madon — 2000-06-29 10:23:40
Louis Madon wrote:
> stevan apter wrote:
> > From: Louis Madon <madonl@...>
> > > >
> > > > you may be right, but i can't think of a case where
> > > > run-stop-resume does not equal run.
> > >
> > > Ok, here's an example:
> > >
> > > 1 2 [+] first pop pop
> > > ^---- stop here
> > >
> > > If you run this straight through, the answer is 1
> >
> > no, it's not. at the stop-point, the stack contains one
> > item, namely 3. here's the session transcript:
>
> Ah, I misunderstood your proposal! I thought you had meant that v.e.
> only happens at render time but you mean it happens after every
> operation. This is interesting, I'll have to think about this ...
>
I've thought about it some more but there seem to be at least two
problems
Problem 1
---------
[+] first
Even with v-e you'll still have a bare plus left on the stack, correct?
Problem 2
---------
unpair pair == id
this identity does not always hold in the presence of v-e.
(eg. consider 1 [2 +] unpair pair != 1 [2 +] id).
In other words we can no longer use local reasoning - the context has
to be considered too. I believe other identities may be broken in this
way too.
There could be other problems, I'd have to think about it some more, but
already it seems to me that v-e is not a solution.
Note that the notion of an individually quoted function _type_ is
already mentioned in Manfreds' Rewriting paper (see the section
'Rewriting for Joy Types'). He refers to it as a 'type cancellation' and
says [type cancellation] "... is new and has no counterpart program
constructor". But I see no justification for not having such a
constructor (and AFAICT, the paper does not try to justify why we
_should not_ have one). The ` or \ syntax would provide it.
--
Louis.
stevan apter — 2000-06-29 11:03:35
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Thursday, June 29, 2000 6:23 AM
Subject: Re: [stack] conk manual
> Louis Madon wrote:
> > stevan apter wrote:
> > > From: Louis Madon <madonl@...>
> > > > >
> > > > > you may be right, but i can't think of a case where
> > > > > run-stop-resume does not equal run.
> > > >
> > > > Ok, here's an example:
> > > >
> > > > 1 2 [+] first pop pop
> > > > ^---- stop here
> > > >
> > > > If you run this straight through, the answer is 1
> > >
> > > no, it's not. at the stop-point, the stack contains one
> > > item, namely 3. here's the session transcript:
> >
> > Ah, I misunderstood your proposal! I thought you had meant that v.e.
> > only happens at render time but you mean it happens after every
> > operation. This is interesting, I'll have to think about this ...
> >
>
> I've thought about it some more but there seem to be at least two
> problems
>
>
> Problem 1
> ---------
>
> [+] first
>
> Even with v-e you'll still have a bare plus left on the stack, correct?
no, here you have an underflow, since [+] first == +.
>
>
>
> Problem 2
> ---------
>
> unpair pair == id
>
> this identity does not always hold in the presence of v-e.
> (eg. consider 1 [2 +] unpair pair != 1 [2 +] id).
yes, i agree.
> In other words we can no longer use local reasoning - the context has
> to be considered too. I believe other identities may be broken in this
> way too.
i don't find that troubling. if '[x] first' means 'push x on the stack',
and pushing x on the stack means 'evaluate x', then '[+] first' means
'evaluate +'. i.e.,
[x] first == [x] i
for non-function x, this agrees with joy's current behavior.
>
>
> There could be other problems, I'd have to think about it some more, but
> already it seems to me that v-e is not a solution.
>
>
> Note that the notion of an individually quoted function _type_ is
> already mentioned in Manfreds' Rewriting paper (see the section
> 'Rewriting for Joy Types'). He refers to it as a 'type cancellation' and
> says [type cancellation] "... is new and has no counterpart program
> constructor". But I see no justification for not having such a
> constructor (and AFAICT, the paper does not try to justify why we
> _should not_ have one). The ` or \ syntax would provide it.
but then other identities would seem to be threatened:
[x] first unitlist <-> [x]
what exactly is [+] first unitlist? is it [\+] or [+]?
>
>
> --
> Louis.
>
> ------------------------------------------------------------------------
> Win A Digital Camera Today!
> Girlgeeks!
> http://click.egroups.com/1/6083/7/_/_/_/962273904/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
Louis Madon — 2000-06-29 15:38:24
stevan apter wrote:
> From: Louis Madon <madonl@...>
> >
> > Problem 1
> > ---------
> >
> > [+] first
> >
> > Even with v-e you'll still have a bare plus left on the stack,
> correct?
>
> no, here you have an underflow, since [+] first == +.
Ok, thats a reasonable outcome.
> >
> > Problem 2
> > ---------
> >
> > unpair pair == id
> >
> > this identity does not always hold in the presence of v-e.
> > (eg. consider 1 [2 +] unpair pair != 1 [2 +] id).
>
> yes, i agree.
>
> > In other words we can no longer use local reasoning - the context
> has
> > to be considered too. I believe other identities may be broken in
> this
> > way too.
>
> i don't find that troubling.
Before I accept this, I'll have to think some more about the full extent
to which local reasoning is being compromised.
> if '[x] first' means 'push x on the
> stack',
> and pushing x on the stack means 'evaluate x', then '[+] first' means
> 'evaluate +'. i.e.,
>
> [x] first == [x] i
>
> for non-function x, this agrees with joy's current behavior.
This is another example of local reasoning being lost: we can no longer
say that 'first' satisfies the rule
[a L] first => a
unconditionally.
Your identity holds when x is a niladic function returning one value
(ie. literals) because such functions can be identified by their result
and therefore such values can be treated as their own quotation (so 3 i
== 3 since there is no ambiguity regarding what function the number 3
identifies - it is the function that pushes 3). In this special case,
the above identity holds without violating any laws of either first or
i.
>
> >
> >
> > There could be other problems, I'd have to think about it some more,
> but
> > already it seems to me that v-e is not a solution.
> >
> >
> > Note that the notion of an individually quoted function _type_ is
> > already mentioned in Manfreds' Rewriting paper (see the section
> > 'Rewriting for Joy Types'). He refers to it as a 'type cancellation'
> and
> > says [type cancellation] "... is new and has no counterpart program
> > constructor". But I see no justification for not having such a
> > constructor (and AFAICT, the paper does not try to justify why we
> > _should not_ have one). The ` or \ syntax would provide it.
>
> but then other identities would seem to be threatened:
>
> [x] first unitlist <-> [x]
>
> what exactly is [+] first unitlist? is it [\+] or [+]?
There is no such distinction as '+' vs '\+'. They are the same value.
Specifying the \ inside the square brackets is redundant. [+] is
shorthand for putting \+ in a list. Consider - in something like [1 2 +]
what exactly is that third element supposed to be? It can't be the +
function itself or else the list would instantly collapse into [3].
Introducing individual quotation is simply acknowledging that it is ok
to have these values outside of an aggregate too.
--
Louis.
wtanksley@bigfoot.com — 2000-06-29 16:41:21
From: stevan apter [mailto:
apter@...]
>From: <wtanksley@...>
>> From: sa@... [mailto:sa@...]
>> > is the first of a list a member of that list? if so,
>> > then [+] first is a member of [+], so `+ is identical
>> > to +, and [+] is identical to [`+].
>> Yes, I would expect [x] to be identical to [`x], because
>> quotation implies
>> escaping as well as aggregation.
>> However, `x is clearly not in general equivalent to x,
>> because x will do
>> something, and `x will merely push `x on the stack.
>exactly. which is why i dislike this approach. v.e. avoids
>introducing a new (and mysterious) datatype, avoids violating
>substitutivity of identicals, and keeps the symmetry of stack
>and list.
v.e. doesn't avoid the new datatype; it merely hides it, and makes it
impossible to manipulate. I have no idea why you should call the 'function'
datatype "mysterious". I can't even guess what the rest of your accusations
mean -- adding a function datatype fully preserves substitution, and also
allows list manipulation, which would be practically impossible with v.e.
except in precisely controlled situations.
>moreover, (i think) there is no computation which
>leaves the stack in a state which it couldn't have gotten into
>by simply entering the items which it contains.
True; that doesn't mean that this is a good idea.
>> Another way to seperate [x] and [`x] is to make aggregation not imply
>> quotation -- thus, [x] would actually be a list containing
>> the results of x, and [`x] would be a list containing x itself.
>as per louis's suggestion, this is what {} does in conk -
>grouped evaluation.
>but i think you're moving away from the purity and simplicity of joy.
I don't like {} at _all_. I think it's a terrible idea. It makes FAR more
sense to use the ` or \ operator to quote both functions and aggregations.
I also disagree that either one would be moving away from purity; on the
contrary, it would make all of the datatype which Joy _currently_ supports
completely defined and easily available. How can we be moving away by
supporting simply what we already support fully?
-Billy
sa@dfa.com — 2000-06-29 17:24:08
>
> what exactly is [+] first unitlist? is it [\+] or [+]?
There is no such distinction as '+' vs '\+'. They are the same value.
Specifying the \ inside the square brackets is redundant. [+] is
shorthand for putting \+ in a list. Consider - in something like [1 2 +]
what exactly is that third element supposed to be? It can't be the +
function itself or else the list would instantly collapse into [3].
Introducing individual quotation is simply acknowledging that it is ok
to have these values outside of an aggregate too.
the third element in [1 2 +] *is* the + function itself.
the list isn't evaluated because lists are quotations.
i agree that \ as you explain it rationalizes joy's current
behavior (leaving bare functions on the stack). i disagree
that joy should behave this way. i think it's simpler to
say that disquotation always implies evaluation.
but let's think about this some more.
--
Louis.
------------------------------------------------------------------------
Get Red Herring perspective on the flood of venture capital here and
abroad with FREE e-newsletters: Dealflow, Dealflow Europe and VCPS.
http://click.egroups.com/1/5015/7/_/_/_/962292819/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
concatenative-unsubscribe@egroups.com
sa@dfa.com — 2000-06-29 17:36:53
From: stevan apter [mailto:
apter@...]
>From: <wtanksley@...>
>> From: sa@... [mailto:sa@...]
>> > is the first of a list a member of that list? if so,
>> > then [+] first is a member of [+], so `+ is identical
>> > to +, and [+] is identical to [`+].
>> Yes, I would expect [x] to be identical to [`x], because
>> quotation implies
>> escaping as well as aggregation.
>> However, `x is clearly not in general equivalent to x,
>> because x will do
>> something, and `x will merely push `x on the stack.
>exactly. which is why i dislike this approach. v.e. avoids
>introducing a new (and mysterious) datatype, avoids violating
>substitutivity of identicals, and keeps the symmetry of stack
>and list.
v.e. doesn't avoid the new datatype; it merely hides it, and makes it
impossible to manipulate. I have no idea why you should call the
'function'
datatype "mysterious". I can't even guess what the rest of your
accusations
mean -- adding a function datatype fully preserves substitution, and also
allows list manipulation, which would be practically impossible with v.e.
except in precisely controlled situations.
relax. this is just programming. ;-)
we have no examples of any interesting joy program
producing an intermediate result of the stack which
contains a bare function. none of manfred's examples
do, as far as i can tell. so this is really just
an argument about what to do in certain (possibly)
pathological circumstances, such as [+] first.
now, there are two further questions: what use is
this new style of quotation (` or \)?; what use is
v.e?
>moreover, (i think) there is no computation which
>leaves the stack in a state which it couldn't have gotten into
>by simply entering the items which it contains.
True; that doesn't mean that this is a good idea.
i was replying to the louis's original complaint
that [+]first produced a stack that couldn't be
constructed directly.
>> Another way to seperate [x] and [`x] is to make aggregation not imply
>> quotation -- thus, [x] would actually be a list containing
>> the results of x, and [`x] would be a list containing x itself.
>as per louis's suggestion, this is what {} does in conk -
>grouped evaluation.
>but i think you're moving away from the purity and simplicity of joy.
I don't like {} at _all_. I think it's a terrible idea. It makes FAR more
sense to use the ` or \ operator to quote both functions and aggregations.
huh? {} was introduced to allow grouped evaluation-at-depth,
which is more convenient than constructing lists explicitly
by means of cons and unitlist. {}'s really are pure syntax,
and can be eliminated at parse time (i don't do this).
I also disagree that either one would be moving away from purity; on the
contrary, it would make all of the datatype which Joy _currently_ supports
completely defined and easily available. How can we be moving away by
supporting simply what we already support fully?
well, that's a good point.
-Billy
------------------------------------------------------------------------
Lonely? Get Firetalk!
Free, unlimited calls anywhere in the world.
Free voice chat on hundreds of topics.
http://click.egroups.com/1/5477/7/_/_/_/962296863/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
concatenative-unsubscribe@egroups.com
William Tanksley — 2000-06-29 21:29:01
--- In
concatenative@egroups.com, sa@d... wrote:
> From: stevan apter [mailto:apter@p...]
> >From: <wtanksley@b...>
> >> From: sa@d... [mailto:sa@d...]
> >exactly. which is why i dislike this approach. v.e. avoids
> >introducing a new (and mysterious) datatype, avoids violating
> >substitutivity of identicals, and keeps the symmetry of stack
> >and list.
> v.e. doesn't avoid the new datatype; it merely hides it, and
> makes it
> impossible to manipulate. I have no idea why you should call the
> 'function'
> datatype "mysterious". I can't even guess what the rest of your
> accusations
> mean -- adding a function datatype fully preserves substitution,
> and also
> allows list manipulation, which would be practically impossible
> with v.e. except in precisely controlled situations.
> relax. this is just programming. ;-)
Grin. Thanks for taking that lightly -- I forget that this isn't
speaking. I should have put quotes around "accusations".
> we have no examples of any interesting joy program
> producing an intermediate result of the stack which
> contains a bare function. none of manfred's examples
> do, as far as i can tell. so this is really just
> an argument about what to do in certain (possibly)
> pathological circumstances, such as [+] first.
I'm not sure that the absence of interesting Joy problems is a useful
measure -- the fact is that there are no interesting Joy programs for
any purpose :-). Joy's purpose is didactic (so to speak).
> now, there are two further questions: what use is
> this new style of quotation (` or \)?; what use is
> v.e?
Good question. The place I'd use the new \ is wherever I wanted to
get a function in the same way I'd want to get a quotation. I was
working a proof earlier (in this NG) and ran into a problem where I
had to do something like [+] first, when I could have done \+.
This is especially vital when you're attempting to build a quotation;
suppose, for example, you were trying to write "concat". Concat
_requires_ the ability to dequote things without executing them.
> >> Another way to seperate [x] and [`x] is to make aggregation not
> >> imply
> >> quotation -- thus, [x] would actually be a list containing
> >> the results of x, and [`x] would be a list containing x itself.
> >as per louis's suggestion, this is what {} does in conk -
> >grouped evaluation.
> >but i think you're moving away from the purity and simplicity of
> >joy.
> I don't like {} at _all_. I think it's a terrible idea. It makes
> FAR more
> sense to use the ` or \ operator to quote both functions and
> aggregations.
> huh? {} was introduced to allow grouped evaluation-at-depth,
> which is more convenient than constructing lists explicitly
> by means of cons and unitlist. {}'s really are pure syntax,
> and can be eliminated at parse time (i don't do this).
I like what {} does, but I don't like having both {} and [] in the
same language. I prefer having only one, and having \ be able to
escape an entire aggregation.
That's completely my own preference, though; I shouldn't have said
that {} was a terrible idea.
-Billy
Louis Madon — 2000-06-30 01:12:25
sa@... wrote:
>
> now, there are two further questions:
>what use is this new style of quotation (` or \)?;
As Billy mentioned, you can do single quotation without having to
involve aggregation. Plus it fixes the stack representation issue.
Overall, the language is providing better support for the function
datatype.
> what use is v.e?
I thought the possibility of eliminating function types was very
interesting - if it were possible without compromising the language in
other ways (I'm quite pessimistic about that now).
While we're on this topic, I thought I'd point out that Joys' function
type is actually more complex than what is normally considered a
function type: its a mixture of symbol, function and program and
supports intensional equality. For example, assume we have defined
'square' somewhere:
square == dup *
then:
[square] first name => "square" // the symbol
[square] first body => [dup *] // the program
4 square => 16 // the function applied to
4
[square] first dup = => true // equality
predefined functions don't support body:
[+] first body => error: requires user defined function
undefined functions support name and equality only:
[undefined_foo] first name => "undefined foo"
[undefined_foo] first dup = => true
the equality operation is intensional rather than extensional, for
example if we also have defined the following function:
selfmul == dup *
then:
[square] first [selfmul] first = => false
So even though square and selfmul perform the same function (and even
have the same implementation) they are still considered distinct under
the equality operation.
There may be other properties of these data types that I've missed, but
clearly this is an area of the language that needs to be properly
defined (especially considering that in most languages, a "function
type" really only means a function as a first-class value and the only
thing you can do with it is apply it.)
--
Louis.
stevan apter — 2000-06-30 01:51:46
----- Original Message -----
From: Louis Madon <madonl@...>
>
> While we're on this topic, I thought I'd point out that Joys' function
> type is actually more complex than what is normally considered a
> function type: its a mixture of symbol, function and program and
> supports intensional equality. For example, assume we have defined
> 'square' somewhere:
>
> square == dup *
>
> then:
>
> [square] first name => "square" // the symbol
> [square] first body => [dup *] // the program
> 4 square => 16 // the function applied to
> 4
> [square] first dup = => true // equality
>
>
> predefined functions don't support body:
>
> [+] first body => error: requires user defined function
>
>
> undefined functions support name and equality only:
>
> [undefined_foo] first name => "undefined foo"
> [undefined_foo] first dup = => true
>
>
> the equality operation is intensional rather than extensional, for
> example if we also have defined the following function:
>
> selfmul == dup *
>
> then:
>
> [square] first [selfmul] first = => false
>
>
> So even though square and selfmul perform the same function (and even
> have the same implementation) they are still considered distinct under
> the equality operation.
these properties fall out of the conk implementation (with v.e. turned
off). this is because a primitive is represented as a symbol which points
to a k lambda, and a joy list as a k list. so `square = *,`square (first
of the list containing `square).
to implement function quotation, i have to push everything down one level.
a primitive is represented as a lambda, and a function quotation as
the symbol which points to that primitive. this requires changes in
eval, input parsing, and output representation. not hard, but more
code than what is required now. i may try implementing over the weekend.
stevan apter — 2000-06-30 11:17:11
----- Original Message -----
From: stevan apter <apter@...>
To: <concatenative@egroups.com>
Sent: Thursday, June 29, 2000 9:51 PM
Subject: Re: [stack] conk manual
> to implement function quotation, i have to push everything down one level.
> a primitive is represented as a lambda, and a function quotation as
> the symbol which points to that primitive. this requires changes in
> eval, input parsing, and output representation. not hard, but more
> code than what is required now. i may try implementing over the weekend.
>
>
i was wrong, and you and billy were right: ` is (almost) mere syntax,
and is surprisingly easy to add to the language, requiring no changes
to evaluation or internal representation.
on input, if the scanner detects `xyz, it represents it as [xyz] first.
on output, if the scanner detects a symbol, then if it is inside a list,
it prints it (as before), else it prefixes it with `.
stevan apter — 2000-06-30 13:20:17
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Thursday, June 29, 2000 9:12 PM
Subject: Re: [stack] conk manual
> While we're on this topic, I thought I'd point out that Joys' function
> type is actually more complex than what is normally considered a
> function type: its a mixture of symbol, function and program and
> supports intensional equality.
equality is extensional under v.e. (quotation is still opaque).
wtanksley@bigfoot.com — 2000-06-30 17:06:25
From: stevan apter [mailto:
apter@...]
>i was wrong, and you and billy were right: ` is (almost) mere syntax,
>and is surprisingly easy to add to the language, requiring no changes
>to evaluation or internal representation.
I'm suspicious.
>on input, if the scanner detects `xyz, it represents it as [xyz] first.
>on output, if the scanner detects a symbol, then if it is
>inside a list, it prints it (as before), else it prefixes it
>with `.
This won't work; [item] is different from `item, since `item isn't a list.
In addition, {`item} is a quotation which when executed (using 'i') will
execute item. Under your implementation, executing {`item} would actually
place `item onto the stack.
(I'm using your definition of {}, even though I don't like to have that many
braces.)
Hmm, that may be a good question. How do you make a quotation place the
address of a function on the stack?
If I write [item], I have a quotation which when executed will execute item.
Theoretically, when I run {`item} I should also execute item. But what
about [`item]? I would expect that to return `item when executed.
This is implementationally interesting. :-)
-Billy
stevan apter — 2000-06-30 18:28:49
----- Original Message -----
From: <wtanksley@...>
To: <concatenative@egroups.com>
Sent: Friday, June 30, 2000 1:06 PM
Subject: RE: [stack] conk manual
> From: stevan apter [mailto:apter@...]
>
> >i was wrong, and you and billy were right: ` is (almost) mere syntax,
> >and is surprisingly easy to add to the language, requiring no changes
> >to evaluation or internal representation.
>
> I'm suspicious.
well then, i'm sure the fbi has a dossier.
>
> >on input, if the scanner detects `xyz, it represents it as [xyz] first.
>
> >on output, if the scanner detects a symbol, then if it is
> >inside a list, it prints it (as before), else it prefixes it
> >with `.
>
> This won't work; [item] is different from `item, since `item isn't a list.
> In addition, {`item} is a quotation which when executed (using 'i') will
> execute item. Under your implementation, executing {`item} would actually
> place `item onto the stack.
i had to make both input and output processing aware of the "level" of
the expression. thus
input on the stack
`foo `foo
[`foo] [foo]
{`foo} `foo
{[`foo]} [foo]
etc.
>
> (I'm using your definition of {}, even though I don't like to have that many
> braces.)
i like {} - it's very convenient.
>
> Hmm, that may be a good question. How do you make a quotation place the
> address of a function on the stack?
what's "the address of a function"? not another new type!! ;-)
>
> If I write [item], I have a quotation which when executed will execute item.
> Theoretically, when I run {`item} I should also execute item. But what
> about [`item]? I would expect that to return `item when executed.
[`item] == [item]
>
> This is implementationally interesting. :-)
my input and output routines are recursive. to support `item, i pass
along a further argument, which is either 0 if we are parsing or formatting
at the top level, or 1, if we are recursing. primitives are symbols,
e.g. `plus. if level = 0, and `xyz is encountered, then return the parse
of [xyz]first; if level = 1, and `xyz is encountered, then return xyz. on
evaluation, the first expression will leave xyz on the stack, where the
output routine (see below) will print it as `xyz; evaluating the second
expression - a symbol -- will execute it.
on output, if level = 0, and `xyz is encountered, output `xyz;
if level = 1, and `xyz is encountered, output xyz (no initial quote).
>
> -Billy
>
> ------------------------------------------------------------------------
> Special Offer-Earn 300 Points from MyPoints.com for trying @Backup
> Get automatic protection and access to your important computer files.
> Install today:
> http://click.egroups.com/1/5667/7/_/_/_/962384762/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
stevan apter — 2000-06-30 19:53:23
----- Original Message -----
From: <wtanksley@...>
To: <concatenative@egroups.com>
Sent: Friday, June 30, 2000 1:06 PM
Subject: RE: [stack] conk manual
>
> If I write [item], I have a quotation which when executed will execute item.
> Theoretically, when I run {`item} I should also execute item. But what
> about [`item]? I would expect that to return `item when executed.
>
i only caught this while re-reading your message. {x} is evaluated *at parse
time* on the empty stack. so e.g.
1 2 {2 1+} 4 5 6
is pre-processed into
1 2 3 4 5 6
during parsing, when i encounter {, i find its mate, parse & evaluate what's
betweeen them, append the result to what's so far parsed, and continue
parsing.
wtanksley@bigfoot.com — 2000-06-30 20:17:09
From: stevan apter [mailto:
apter@...]
>From: <wtanksley@...>
>> From: stevan apter [mailto:apter@...]
>> I'm suspicious.
>well then, i'm sure the fbi has a dossier.
We've been keeping an eye on you for quite some time, Mr. Baggins.
(Interesting fact: the actor who will play Elrond in the upcoming "Lord of
The Rings" movie is the same actor who played Agent Smith in "Matrix".
Well, I found it an interesting thought -- about as interesting as
discovering that Samuel Jackson was going to be chief of the jedi in Episode
I way back when. :-)
>> >on input, if the scanner detects `xyz, it represents it as
>> >[xyz] first.
>> >on output, if the scanner detects a symbol, then if it is
>> >inside a list, it prints it (as before), else it prefixes it
>> >with `.
>> This won't work; [item] is different from `item, since `item
>> isn't a list.
>> In addition, {`item} is a quotation which when executed
>> (using 'i') will
>> execute item. Under your implementation, executing {`item}
>> would actually
>> place `item onto the stack.
>i had to make both input and output processing aware of the "level" of
>the expression. thus
> input on the stack
> `foo `foo
> [`foo] [foo]
> {`foo} `foo
> {[`foo]} [foo]
>etc.
>> (I'm using your definition of {}, even though I don't like
>> to have that many braces.)
>i like {} - it's very convenient.
Wait. You discussed {} earlier, but there was a miscommunication -- I had
thought that you said that {} did grouping without quotation; in other
words, {3 4 +} == [7]. That seemed to me to be a waste of time, since under
my scheme you'd use [3 4 +] == [7] and `[3 4 +] == [3 4 `+].
From now on I'm going to switch to my terminology: [3 4 +] == [7], and `[3 4
+] == [3 4 `+] (sort of, there are problems.
I won't use your {}, but I agree with you that they're very useful. I
wouldn't be suprised if I wound up using them in my implementation; Forth
has a similar concept in IMMEDIATE words, but Chuck Moore has since gotten
rid of IMMEDIATE in his own work, and how he uses something faintly like
what you're using.
>> Hmm, that may be a good question. How do you make a
>> quotation place the
>> address of a function on the stack?
>what's "the address of a function"? not another new type!! ;-)
No, the same type we've been discussing all along.
But what happens if I type
`[3 4 + `foo] dup . cr i . .
I would expect to see (cr prints a carrige return, BTW):
`[3 4 + `foo]
`foo 7
Do you see what's happening? The problem is that all along I've been
thinking of quotations as the same thing as lists, but here we see that they
aren't. If `[3 4] == [3 4], then when I print `[3 4 + `foo] I would expect
to see [3 4 `+ ``foo] (notice the odd double-backtick on the foo). I don't
like that double-backtick; it looks very strange indeed.
>> If I write [item], I have a quotation which when executed
>> will execute item.
>> Theoretically, when I run {`item} I should also execute
>> item. But what
>> about [`item]? I would expect that to return `item when executed.
>[`item] == [item]
This makes sense in both of our notations. However, in my notation, what
does
`[`item]
mean? It seems to me that this proves that the quotation, "`[]", is a
primitive concept. That does NOT bode well for my ideas. Ick.
-Billy
stevan apter — 2000-06-30 21:15:32
----- Original Message -----
From: <wtanksley@...>
To: <concatenative@egroups.com>
Sent: Friday, June 30, 2000 4:17 PM
Subject: RE: [stack] conk manual
> From: stevan apter [mailto:apter@...]
> >From: <wtanksley@...>
> >> From: stevan apter [mailto:apter@...]
>
> >> I'm suspicious.
>
> >well then, i'm sure the fbi has a dossier.
>
> We've been keeping an eye on you for quite some time, Mr. Baggins.
>
> (Interesting fact: the actor who will play Elrond in the upcoming "Lord of
> The Rings" movie is the same actor who played Agent Smith in "Matrix".
> Well, I found it an interesting thought -- about as interesting as
> discovering that Samuel Jackson was going to be chief of the jedi in Episode
> I way back when. :-)
i've seen the trailer for LotR - spectacular.
>
> >> >on input, if the scanner detects `xyz, it represents it as
> >> >[xyz] first.
>
> >> >on output, if the scanner detects a symbol, then if it is
> >> >inside a list, it prints it (as before), else it prefixes it
> >> >with `.
>
> >> This won't work; [item] is different from `item, since `item
> >> isn't a list.
> >> In addition, {`item} is a quotation which when executed
> >> (using 'i') will
> >> execute item. Under your implementation, executing {`item}
> >> would actually
> >> place `item onto the stack.
>
> >i had to make both input and output processing aware of the "level" of
> >the expression. thus
>
> > input on the stack
> > `foo `foo
> > [`foo] [foo]
> > {`foo} `foo
> > {[`foo]} [foo]
>
> >etc.
>
> >> (I'm using your definition of {}, even though I don't like
> >> to have that many braces.)
>
> >i like {} - it's very convenient.
>
> Wait. You discussed {} earlier, but there was a miscommunication -- I had
> thought that you said that {} did grouping without quotation; in other
> words, {3 4 +} == [7]. That seemed to me to be a waste of time, since under
> my scheme you'd use [3 4 +] == [7] and `[3 4 +] == [3 4 `+].
i prefer to describe it as structured evaluation. recall louis's way
to construct dictionaries and their attributes:
{{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d
if the result of {x} was [eval x] instead of eval x, this code would fail.
>
> >From now on I'm going to switch to my terminology: [3 4 +] == [7], and `[3 4
> +] == [3 4 `+] (sort of, there are problems.
>
> I won't use your {}, but I agree with you that they're very useful. I
> wouldn't be suprised if I wound up using them in my implementation; Forth
> has a similar concept in IMMEDIATE words, but Chuck Moore has since gotten
> rid of IMMEDIATE in his own work, and how he uses something faintly like
> what you're using.
aha
>
> >> Hmm, that may be a good question. How do you make a
> >> quotation place the
> >> address of a function on the stack?
>
> >what's "the address of a function"? not another new type!! ;-)
>
> No, the same type we've been discussing all along.
>
> But what happens if I type
>
> `[3 4 + `foo] dup . cr i . .
>
> I would expect to see (cr prints a carrige return, BTW):
>
> `[3 4 + `foo]
> `foo 7
>
> Do you see what's happening? The problem is that all along I've been
> thinking of quotations as the same thing as lists, but here we see that they
> aren't. If `[3 4] == [3 4], then when I print `[3 4 + `foo] I would expect
> to see [3 4 `+ ``foo] (notice the odd double-backtick on the foo). I don't
> like that double-backtick; it looks very strange indeed.
indeed. again, i thought we had agreed that (i) in joy, you can compute
a result for which there was no constructor (namely, bare functions), and
that (ii) since the language already contained these types, all we need
is a piece of syntax which allows us to enter them directly (the constructor).
although i am still a bit dim about the use of `foo, i agree that having
it is good for completeness. regarding `[foo] and [`goo], well, there
i am utterly at sea regarding the intended meaning.
>
> >> If I write [item], I have a quotation which when executed
> >> will execute item.
> >> Theoretically, when I run {`item} I should also execute
> >> item. But what
> >> about [`item]? I would expect that to return `item when executed.
>
> >[`item] == [item]
>
> This makes sense in both of our notations. However, in my notation, what
> does
>
> `[`item]
>
> mean? It seems to me that this proves that the quotation, "`[]", is a
> primitive concept. That does NOT bode well for my ideas. Ick.
i know the feeling.
>
> -Billy
>
> ------------------------------------------------------------------------
> Get a NextCard Visa, in 30 seconds!
> 1. Fill in the brief application
> 2. Receive approval decision within 30 seconds
> 3. Get rates as low as 2.9% Intro or 9.9% Fixed APR
> http://click.egroups.com/1/5197/7/_/_/_/962396206/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
wtanksley@bigfoot.com — 2000-06-30 21:20:24
From: stevan apter [mailto:
apter@...]
>From: <wtanksley@...>
> {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d
>if the result of {x} was [eval x] instead of eval x, this code
>would fail.
Yes, but I can't read that code either way. I'm afraid it means little or
nothing to me.
>> I won't use your {}, but I agree with you that they're very
>> useful. I
>> wouldn't be suprised if I wound up using them in my
>> implementation; Forth
>> has a similar concept in IMMEDIATE words, but Chuck Moore
>> has since gotten
>> rid of IMMEDIATE in his own work, and how he uses something
>> faintly like
>> what you're using.
>aha
His current work is called "Color Forth". In Color Forth, instead of having
immediate words, you use mode changing tokens to tell the compiler how to
treat the next group of words. His editor displays the words in color, so
that a definition shows up as a red word, and a word which is being executed
shows up blue, and a word being compiled, green.
>indeed. again, i thought we had agreed that (i) in joy, you
>can compute
>a result for which there was no constructor (namely, bare
>functions), and
>that (ii) since the language already contained these types, all we need
>is a piece of syntax which allows us to enter them directly
>(the constructor).
Yes.
>although i am still a bit dim about the use of `foo, i agree
>that having
>it is good for completeness. regarding `[foo] and [`goo], well, there
>i am utterly at sea regarding the intended meaning.
I think the solution is to remove `[foo]. We'll keep the meaning of [foo]
the same as it currently is, and we'll add the ability to immediately
execute words even in the middle of a quotation. As I understand, this is
what your {} does.
-Billy
stevan apter — 2000-06-30 21:41:58
----- Original Message -----
From: <wtanksley@...>
To: <concatenative@egroups.com>
Sent: Friday, June 30, 2000 5:20 PM
Subject: RE: [stack] conk manual
> >aha
>
> His current work is called "Color Forth". In Color Forth, instead of having
> immediate words, you use mode changing tokens to tell the compiler how to
> treat the next group of words. His editor displays the words in color, so
> that a definition shows up as a red word, and a word which is being executed
> shows up blue, and a word being compiled, green.
the best programmer i know is red-green color-blind. but it's a
nice idea.
>
> >indeed. again, i thought we had agreed that (i) in joy, you
> >can compute
> >a result for which there was no constructor (namely, bare
> >functions), and
> >that (ii) since the language already contained these types, all we need
> >is a piece of syntax which allows us to enter them directly
> >(the constructor).
>
> Yes.
>
> >although i am still a bit dim about the use of `foo, i agree
> >that having
> >it is good for completeness. regarding `[foo] and [`goo], well, there
> >i am utterly at sea regarding the intended meaning.
>
> I think the solution is to remove `[foo]. We'll keep the meaning of [foo]
> the same as it currently is, and we'll add the ability to immediately
> execute words even in the middle of a quotation. As I understand, this is
> what your {} does.
{2 +} is a stack underflow error in conk. what is [2 +] for you?
>
> -Billy
>
> ------------------------------------------------------------------------
> BeMANY, where eGroups members SAVE on long distance.
> http://click.egroups.com/1/4121/7/_/_/_/962400000/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
wtanksley@bigfoot.com — 2000-06-30 21:41:41
From: stevan apter [mailto:
apter@...]
>From: <wtanksley@...>
>> His current work is called "Color Forth". In Color Forth,
>> instead of having
>> immediate words, you use mode changing tokens to tell the
>> compiler how to
>> treat the next group of words. His editor displays the
>> words in color, so
>> that a definition shows up as a red word, and a word which
>> is being executed
>> shows up blue, and a word being compiled, green.
>the best programmer i know is red-green color-blind. but it's a
>nice idea.
Then perhaps that programmer should use his own editor instead of Chuck's,
where his editor didn't colorise the marks in the same way. It's not really
a problem. Another possibility is that Chuck would do some research and
choose color tones which were deliberately different, so that even a fully
color-blind programmer could distinguish them. (I doubt that he did this.)
>> I think the solution is to remove `[foo]. We'll keep the
>> meaning of [foo]
>> the same as it currently is, and we'll add the ability to immediately
>> execute words even in the middle of a quotation. As I
>> understand, this is
>> what your {} does.
>{2 +} is a stack underflow error in conk.
So may I suppose that {2 2 +} is [4]?
In Color Forth, the closest equivalent to {2 +} would be simply immediate
execution of 2 +, and the exact result would depend on whether there was
something on the stack at the time.
>what is [2 +] for you?
Same as it is for Joy -- [2 +] uncons == 2 [+].
-Billy
stevan apter — 2000-06-30 21:54:13
----- Original Message -----
From: <wtanksley@...>
To: <concatenative@egroups.com>
Sent: Friday, June 30, 2000 5:41 PM
Subject: RE: [stack] conk manual
>
> >{2 +} is a stack underflow error in conk.
>
> So may I suppose that {2 2 +} is [4]?
no - it's just 4
>
> In Color Forth, the closest equivalent to {2 +} would be simply immediate
> execution of 2 +, and the exact result would depend on whether there was
> something on the stack at the time.
>
> >what is [2 +] for you?
>
> Same as it is for Joy -- [2 +] uncons == 2 [+].
ok, i thought you were proposing that [] would not have quotational
properties. i'm confused - there are too many alternative proposals
flying around. time for a movie.
>
> -Billy
>
> ------------------------------------------------------------------------
> Explore the popular High-End Room -
> Go To Where The Smart People Shop-uBid.com
> http://click.egroups.com/1/6141/7/_/_/_/962401284/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
wtanksley@bigfoot.com — 2000-06-30 22:07:18
From: stevan apter [mailto:
apter@...]
>From: <wtanksley@...>
>> >{2 +} is a stack underflow error in conk.
>> So may I suppose that {2 2 +} is [4]?
>no - it's just 4
Good. That's what I would want it to be.
>> >what is [2 +] for you?
>> Same as it is for Joy -- [2 +] uncons == 2 [+].
>ok, i thought you were proposing that [] would not have quotational
>properties. i'm confused - there are too many alternative proposals
>flying around. time for a movie.
I did propose that, and quite a while ago decided not to bother.
-Billy
Louis Madon — 2000-06-30 23:58:15
stevan apter wrote:
> From: Louis Madon <madonl@...>
> > While we're on this topic, I thought I'd point out that Joys'
> function
> > type is actually more complex than what is normally considered a
> > function type: its a mixture of symbol, function and program and
> > supports intensional equality.
>
> equality is extensional under v.e. (quotation is still opaque).
Is that extensional equality with respect to function or implementation?
For example, if I have these two functions:
foo == dup +
bar == 2 *
is foo and bar considered equal? (In terms of _function_ they are equal
since they define the same map, yet they have different
implementations).
I'd be suprised if you can do that.
--
Louis.
Louis Madon — 2000-07-01 00:13:13
stevan apter wrote:
> > Wait. You discussed {} earlier, but there was a miscommunication --
> I had
> > thought that you said that {} did grouping without quotation; in
> other
> > words, {3 4 +} == [7]. That seemed to me to be a waste of time,
> since under
> > my scheme you'd use [3 4 +] == [7] and `[3 4 +] == [3 4 `+].
>
> i prefer to describe it as structured evaluation. recall louis's way
> to construct dictionaries and their attributes:
>
> {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d
>
> if the result of {x} was [eval x] instead of eval x, this code would
> fail.
Why? My impression was that {} is aggregation without quotation - that
does mean that the result of {x} is [eval x]. This is the form required
by d to build a dictionary right? (I'm not saying that your notion of
structured evaluation is neccesarily bad - it may even be a better way
to go - but its not what I was thinking of).
--
Louis.
stevan apter — 2000-07-01 11:48:16
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Friday, June 30, 2000 7:58 PM
Subject: Re: [stack] conk manual
> stevan apter wrote:
> > From: Louis Madon <madonl@...>
> > > While we're on this topic, I thought I'd point out that Joys'
> > function
> > > type is actually more complex than what is normally considered a
> > > function type: its a mixture of symbol, function and program and
> > > supports intensional equality.
> >
> > equality is extensional under v.e. (quotation is still opaque).
>
> Is that extensional equality with respect to function or implementation?
implementation, hence not equality.
> For example, if I have these two functions:
>
> foo == dup +
> bar == 2 *
>
> is foo and bar considered equal? (In terms of _function_ they are equal
> since they define the same map, yet they have different
> implementations).
>
> I'd be suprised if you can do that.
me too. ;)
>
>
> --
> Louis.
>
> ------------------------------------------------------------------------
> You have to check this out and pass it along!
> http://click.egroups.com/1/6016/7/_/_/_/962409175/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
stevan apter — 2000-07-01 12:41:25
----- Original Message -----
From: Louis Madon <madonl@...>
To: <concatenative@egroups.com>
Sent: Friday, June 30, 2000 8:13 PM
Subject: Re: [stack] conk manual
> stevan apter wrote:
>
> > > Wait. You discussed {} earlier, but there was a miscommunication --
> > I had
> > > thought that you said that {} did grouping without quotation; in
> > other
> > > words, {3 4 +} == [7]. That seemed to me to be a waste of time,
> > since under
> > > my scheme you'd use [3 4 +] == [7] and `[3 4 +] == [3 4 `+].
> >
> > i prefer to describe it as structured evaluation. recall louis's way
> > to construct dictionaries and their attributes:
> >
> > {{[one] 10 [[fg 99][bg 9900]]d}{[two] 20}}d
> >
> > if the result of {x} was [eval x] instead of eval x, this code would
> > fail.
>
> Why? My impression was that {} is aggregation without quotation - that
> does mean that the result of {x} is [eval x]. This is the form required
> by d to build a dictionary right? (I'm not saying that your notion of
> structured evaluation is neccesarily bad - it may even be a better way
> to go - but its not what I was thinking of).
i don't know quite what i was thinking, but i do know that it was wrong.
as was my implementation.
{} DOES aggregate. in fact, if it didn't, then i couldn't build dictionaries
or other complex structures this way.
{10}
[10]
{10 20 +}
[30]
{a 10 {[bg 99][fg 100]}d}[[b 20]]d
[a 10 [[bg 99 nil] [fg 100 nil]] d] [[b 20 nil]] `d
a dictionary is a *list* of pairs (or triples).
given this definition of {}, it is easy to get what i was calling
structured evaluation:
{2 3 +}
[5]
disperse
5
>
>
> --
> Louis.
>
> ------------------------------------------------------------------------
> Whassuuup?!
> http://click.egroups.com/1/6014/7/_/_/_/962410075/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> concatenative-unsubscribe@egroups.com
>
>
>
>
stevan apter — 2000-07-01 13:00:42
----- Original Message -----
From: stevan apter <apter@...>
To: <concatenative@egroups.com>
Sent: Saturday, July 01, 2000 8:41 AM
Subject: Re: [stack] conk manual
> {a 10 {[bg 99][fg 100]}d}[[b 20]]d
> [a 10 [[bg 99 nil] [fg 100 nil]] d] [[b 20 nil]] `d
{{a 10 [[bg 99][fg 100]]d}[b 20]}d
[[a 10 [[bg 99 nil] [fg 100 nil]] d] [b 20 nil]] `d
i wish i could say that i am not normally this careless, and blame
it on caffeine-deprivation, but honesty compels me ...
anyway, the expression is a list of two items - a triple, consisting
of a name a, a value 10, and a dictionary [[bg 99][fg 100]d, and a
pair [b 20]. the outer braces make it a list, which is acceptable
to the d operator, and the inner braces allow the inner d to apply
immediately.
now, for that fourth cup of cofee ..