headers
William Tanksley, Jr | 3 Aug 2005 00:18
Picon

Re: [stack] an exchange on flatness

Daniel Ehrenberg <microdan <at> gmail.com> wrote:
> > The code is represented by a data structure. You use a compile-time
> > list. A list is a great way to gather concatenative code together, but
> > a very poor way to dissect and manipulate code -- you can do things
> > with lists that aren't sensible with code.

> What are you saying? That a language needs to restrict how people
> manipulate code?

No. I'm saying that code isn't a data structure. Perhaps I'm
misphrasing that; perhaps I should say something like "computations
aren't data structures". I can see that my origiinal phrasing was
misleading. The reason I say that is that every data structure we've
used to represent computations implies that you can manipulate the
data structure to determine things about the computation.

And that's just not true. Turing proved it -- the only general way to
know things about computations is to actually run them. Languages that
allow you to know the data structure used to represent a computation
automatically put limitations on the computation.

For example, Joy's documentation mentions that identities such as "dup
drop == nop" don't hold within quotations, because someone might use
the length of the quotation (list).

> It is very useful to have code be
> [represented by] an accessable data structure;

Agreed. When I said "code" I should have said "computations". When you
say "code" you're referring to the stuff that the programmer
(Continue reading)

Permalink | Reply | 15 comments |
headers
William Tanksley, Jr | 3 Aug 2005 02:38
Picon

Re: [stack] an exchange on flatness

Mackenzie Straight <eizneckam <at> gmail.com> wrote:
> On 8/1/05, William Tanksley, Jr <wtanksleyjr <at> gmail.com> wrote:
> > No, it "is" not a quotation. Joy and Factor use quotations for it.
> > Forth doesn't define any data structure. It's easy to define an
> > improper subset of Forth, "flat Forth", that uses xts (which are
> > atoms) for the consequentials of conditionals.

> > Please don't confuse implementation with essence.

> I am well aware that Forth does not have quotations. Ask yourself
> this, though: what is the fundamental difference between a quotation
> and an xt? The answer is simple: xts are opaque, and can't really be
> manipulated. But aside from that they're basically the same thing.
> (Would an xt-forth qualify as 'flat'?)

Forth doesn't use xts for its conditionals, either. And yes, making it
impossible to manipulate an unexecuted computation accurately
represents the reality of a computation. The only operation that can
be performed in general on a computation is to execute it -- and of
course there's no guarantee that it'll halt.

> > > In the
> > > future, Factor is actually going to have a first class quotation type,
> > > and cons lists are going to have their role seriously reduced or
> > > eliminated, but that's beside the point. The point is that the code
> > > _is_ a data structure.

> > The code is represented by a data structure. You use a compile-time
> > list. A list is a great way to gather concatenative code together, but
> > a very poor way to dissect and manipulate code -- you can do things
(Continue reading)

Permalink | Reply | 57 comments |
headers
Daniel Ehrenberg | 3 Aug 2005 16:26
Picon

Re: [stack] an exchange on flatness

On 8/2/05, William Tanksley, Jr <wtanksleyjr <at> gmail.com> wrote:
> Daniel Ehrenberg <microdan <at> gmail.com> wrote:
> > > The code is represented by a data structure. You use a compile-time
> > > list. A list is a great way to gather concatenative code together, but
> > > a very poor way to dissect and manipulate code -- you can do things
> > > with lists that aren't sensible with code.
> 
> > What are you saying? That a language needs to restrict how people
> > manipulate code?
> 
> No. I'm saying that code isn't a data structure. Perhaps I'm
> misphrasing that; perhaps I should say something like "computations
> aren't data structures". I can see that my origiinal phrasing was
> misleading. The reason I say that is that every data structure we've
> used to represent computations implies that you can manipulate the
> data structure to determine things about the computation.
> 
> And that's just not true. Turing proved it -- the only general way to
> know things about computations is to actually run them. Languages that
> allow you to know the data structure used to represent a computation
> automatically put limitations on the computation.
> 
> For example, Joy's documentation mentions that identities such as "dup
> drop == nop" don't hold within quotations, because someone might use
> the length of the quotation (list).
> 
...ok, but I don't really see any place for 100% abstract computations
in any programming language, and it's still extremely useful to have
code be a data structure. The quotation *is* a list, and there's
nothing you could say to make it not. It makes no sense to do length
(Continue reading)

Permalink | Reply | 14 comments |
headers
William Tanksley, Jr | 4 Aug 2005 02:39
Picon

Re: [stack] an exchange on flatness

Daniel Ehrenberg <microdan <at> gmail.com> wrote:
> ...ok, but I don't really see any place for 100% abstract computations
> in any programming language, 

The only purpose for using a programming language is to express
computations. I don't know what you mean by 100% abstract, though;
perhaps there's something there.

> and it's still extremely useful to have
> code be a data structure.

I believe I agreed with this -- it's useful when you explicitly want
to be able to manipulate the code before the computation it implies
needs to be run. The problem is that if this abilitity remains open to
*all* computations,

> The quotation *is* a list, and there's
> nothing you could say to make it not.

I wouldn't want to do something like that. Quotations are lists.

But I'm not talking about quotations. I'm talking about computations
-- the things you pass to an 'if', the things your source code
represents when it's being executed. Those aren't lists. You might say
they're sequences of machine-language operations, but that doesn't
provide a useful connection to the language for most programmers. You
could say that they're sequences of virtual operations, but that would
cripple performance. You could say that they're sequences of
characters, but that makes manipulating them hard and slow. And so
on...
(Continue reading)

Permalink | Reply | 13 comments |
headers
Daniel Ehrenberg | 4 Aug 2005 04:49
Picon

Re: [stack] an exchange on flatness

On 8/3/05, William Tanksley, Jr <wtanksleyjr <at> gmail.com> wrote:
> Daniel Ehrenberg <microdan <at> gmail.com> wrote:
> > ...ok, but I don't really see any place for 100% abstract computations
> > in any programming language,
> 
> The only purpose for using a programming language is to express
> computations. I don't know what you mean by 100% abstract, though;
> perhaps there's something there.
> 
> > and it's still extremely useful to have
> > code be a data structure.
> 
> I believe I agreed with this -- it's useful when you explicitly want
> to be able to manipulate the code before the computation it implies
> needs to be run. The problem is that if this abilitity remains open to
> *all* computations,
> 
> > The quotation *is* a list, and there's
> > nothing you could say to make it not.
> 
> I wouldn't want to do something like that. Quotations are lists.
> 
> But I'm not talking about quotations. I'm talking about computations
> -- the things you pass to an 'if', the things your source code
> represents when it's being executed. Those aren't lists. You might say
> they're sequences of machine-language operations, but that doesn't
> provide a useful connection to the language for most programmers. You
> could say that they're sequences of virtual operations, but that would
> cripple performance. You could say that they're sequences of
> characters, but that makes manipulating them hard and slow. And so
(Continue reading)

Permalink | Reply | 12 comments |
headers
William Tanksley, Jr | 5 Aug 2005 06:50
Picon

Re: [stack] an exchange on flatness

Daniel Ehrenberg <microdan <at> gmail.com> wrote:
> William Tanksley, Jr <wtanksleyjr <at> gmail.com> wrote:
> > A computation is what you pass to 'if'. It's what the code that you
> > type into your editor represents. Deciding what you can do with a
> > computation is important. We both know that you can execute a

> Overall, I really don't understand where this idea of computations is
> comming from. In some implementations, during runtime, it is still the
> quotation, never at all anything else. A computation, as I understand
> it, is a completely abstract concept. Could someone please define it
> better for me?

Joy has two ways to express a computation. One example is a quotation,
the other is a function body. So it's not "never at all anything
else".

The concrete concept of "computation" is neccesary in order to compare
Forth and Joy's conditionals on equal terms, and in order to think
about the nature of a lazy concatenative language. If we only
understand "quotations", we'll only be able to work with Joy and
Factor, not Forth.

-Billy

------------------------ Yahoo! Groups Sponsor --------------------~--> 
<font face=arial size=-1><a
href="http://us.ard.yahoo.com/SIG=12hk3rtgc/M=362335.6886445.7839731.1510227/D=groups/S=1705006764:TM/Y=YAHOO/EXP=1123224605/A=2894361/R=0/SIG=13jmebhbo/*http://www.networkforgood.org/topics/education/digitaldivide/?source=YAHOO&cmpgn=GRP&RTP=http://groups.yahoo.com/">In
low income neighborhoods, 84% do not own computers. At Network for Good, help bridge the Digital Divide!</a>.</font>
--------------------------------------------------------------------~->
(Continue reading)

Permalink | Reply | 11 comments |
headers
Daniel Ehrenberg | 5 Aug 2005 16:59
Picon

Re: [stack] an exchange on flatness

> Joy has two ways to express a computation. One example is a quotation,
> the other is a function body. So it's not "never at all anything
> else".
> 
> The concrete concept of "computation" is neccesary in order to compare
> Forth and Joy's conditionals on equal terms, and in order to think
> about the nature of a lazy concatenative language. If we only
> understand "quotations", we'll only be able to work with Joy and
> Factor, not Forth.
> 
> -Billy

Hmm... ok, but what does that have to do with the abstract concept
you're talking about where [ dup drop ] is equivalent to [ nop ] ?

------------------------ Yahoo! Groups Sponsor --------------------~--> 
<font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12hqga9ht/M=362131.6882499.7825260.1510227/D=groups/S=1705006764:TM/Y=YAHOO/EXP=1123261233/A=2889191/R=0/SIG=10r90krvo/*http://www.thebeehive.org
">Get Bzzzy! (real tools to help you find a job) Welcome to the Sweet Life - brought to you by One Economy</a>.</font>
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/concatenative/

<*> To unsubscribe from this group, send an email to:
    concatenative-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Permalink | Reply | 10 comments |
headers
William Tanksley, Jr | 6 Aug 2005 03:57
Picon

Re: [stack] an exchange on flatness

Daniel Ehrenberg <microdan <at> gmail.com> wrote:
> > Joy has two ways to express a computation. One example is a quotation,
> > the other is a function body. So it's not "never at all anything
> > else".

> > The concrete concept of "computation" is neccesary in order to compare
> > Forth and Joy's conditionals on equal terms, and in order to think
> > about the nature of a lazy concatenative language. If we only
> > understand "quotations", we'll only be able to work with Joy and
> > Factor, not Forth.

> Hmm... ok, but what does that have to do with the abstract concept
> you're talking about where [ dup drop ] is equivalent to [ nop ] ?

As a compuation, the two are the same. As quoted lists, they're
obviously not. So therefore, quoted lists are not the same as
computations. This doesn't mean that they _can't_ be used to implement
computations (although Forth in fact doesn't use them); it just means
that you should be careful about "leaky abstractions" when lists allow
you to do things that real computations don't allow.

-Billy

------------------------ Yahoo! Groups Sponsor --------------------~--> 
<font face=arial size=-1><a
href="http://us.ard.yahoo.com/SIG=12h1testi/M=362335.6886445.7839731.1510227/D=groups/S=1705006764:TM/Y=YAHOO/EXP=1123300638/A=2894361/R=0/SIG=13jmebhbo/*http://www.networkforgood.org/topics/education/digitaldivide/?source=YAHOO&cmpgn=GRP&RTP=http://groups.yahoo.com/">In
low income neighborhoods, 84% do not own computers. At Network for Good, help bridge the Digital Divide!</a>.</font>
--------------------------------------------------------------------~->
(Continue reading)

Permalink | Reply | 9 comments |
headers
Daniel Ehrenberg | 6 Aug 2005 18:39
Picon

Re: [stack] an exchange on flatness

On 8/5/05, William Tanksley, Jr <wtanksleyjr <at> gmail.com> wrote:
> Daniel Ehrenberg <microdan <at> gmail.com> wrote:
> > > Joy has two ways to express a computation. One example is a quotation,
> > > the other is a function body. So it's not "never at all anything
> > > else".
> 
> > > The concrete concept of "computation" is neccesary in order to compare
> > > Forth and Joy's conditionals on equal terms, and in order to think
> > > about the nature of a lazy concatenative language. If we only
> > > understand "quotations", we'll only be able to work with Joy and
> > > Factor, not Forth.
> 
> > Hmm... ok, but what does that have to do with the abstract concept
> > you're talking about where [ dup drop ] is equivalent to [ nop ] ?
> 
> As a compuation, the two are the same. As quoted lists, they're
> obviously not. So therefore, quoted lists are not the same as
> computations. This doesn't mean that they _can't_ be used to implement
> computations (although Forth in fact doesn't use them); it just means
> that you should be careful about "leaky abstractions" when lists allow
> you to do things that real computations don't allow.
> 
> -Billy

You're using two different meanings of "computation". One is a body of
code, as you used for the Joy word/quotation thing, and another is the
abstract meaning of code. Could you define computation in a way that's
not just by example?

Daniel Ehrenberg
(Continue reading)

Permalink | Reply | 8 comments |
headers
William Tanksley, Jr | 6 Aug 2005 21:34
Picon

Re: [stack] an exchange on flatness

Daniel Ehrenberg <microdan <at> gmail.com> wrote:
> You're using two different meanings of "computation". One is a body of
> code, as you used for the Joy word/quotation thing, and another is the
> abstract meaning of code. Could you define computation in a way that's
> not just by example?

I'm not aware of using two different meanings; I changed from my old
and incorrect term "code" so that I could have a single meaning.
Computation as an idea is defined by compexity theory; as an object, a
computation should have an interface that allows you to do only the
things that you could do to a computation in the theoretical sense.

> Daniel Ehrenberg

-Billy

------------------------ Yahoo! Groups Sponsor --------------------~--> 
<font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12hsdvj05/M=362131.6882499.7825260.1510227/D=groups/S=1705006764:TM/Y=YAHOO/EXP=1123364053/A=2889191/R=0/SIG=10r90krvo/*http://www.thebeehive.org
">Get Bzzzy! (real tools to help you find a job) Welcome to the Sweet Life - brought to you by One Economy</a>.</font>
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/concatenative/

<*> To unsubscribe from this group, send an email to:
    concatenative-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 4 comments |

Gmane