William Tanksley | 2 Mar 19:36 2009
Picon

Re: [stack] function/object ambiguity + quotation alternative

Stevan Apter wrote:
> i don't want to spoil the party, but the fact is, i'm rarely in
> the position where i *want* to factor my code.

Yeah, well, you're a party-spoiler anyhow. :-)

> my building blocks
> are not words or code-fragments, they're *functions*.

I do not understand this. "Word" is the Forth term for what other
languages call "functions". And most of what other languages call
"functions" are built of code-fragments.

Being able to put together and take apart functions/words is pretty
useful to programming. That's what the functional programming mavens
talk about with their "referential transparency"... and concatenative
languages are a bit better at that.

In brief, I don't understand why you'd "complain" about being _able_ to
refactor code more easily. I understand that you want to analyse
requirements, architect solutions, and detail-design perfectly the first
time... But since none of these are possible, it makes sense to write
code that's as mutable as possible.

> typically,
> a function evolves over time in response to demands from the
> environment by acquiring new arguments and/or producing results
> with new components. the large-scale "topography" of the system
> is relatively stable.
> (come to think of it, this is a pretty
> good metaphor for how systems grow in the real world.)

Good for you -- I'm not so lucky. For me there are two ways that a
system changes: either we fix problems in the code that implemented the
old requirements, or new requirements get added. In both cases the
architecture usually has to change at least a bit.

> if i have
> to dig into the functions and move snippets of code around into
> a new functional architecture, then my original design was pitched
> at the wrong "level."

It probably _was_ pitched at the wrong level. This happens all the time.

> the kind of refactoring i want to avoid
> (because it is the most painful kind) is *renaming*. going from
> a set of several hundred functions a,b,c,... to a different set
> x,y,z,... .

I would classify renaming as the simplest kind of refactoring -- it can
usually be done with a simple search and replace, and then let the
compiler tell you if you missed anything. I wouldn't make a million name
changes at the same time, of course.

> code is committed to a function with a name when
> a judgement is made that that functionality will endure for the
> lifetime of the system, and that changes will for the most part
> be extensions rather than revisions.

I expect that from code that's been in production use for 10 years.
Nothing younger.

-Wm

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Search Ads

Get new customers.

List your web site

in Yahoo! Search.

Group Charity

Give a laptop

Get a laptop: One

laptop per child

.

__,_._,___
William Tanksley | 2 Mar 19:44 2009
Picon

Re: [stack] function/object ambiguity + quotation alternative

John Nowak wrote:
> I think you're absolutely right. Forth and friends *demand* short
> words, and consequently, demand factoring.A language like Scheme
> makes it harder to factor, but the nesting and locals means much
> larger definitions are readable, and consequently, much less factoring
> is required.

There's truth in what you're saying, but you're missing an important
fact: short definitions are easier to read in _any_ language. I admit
that it's important to be able to express longer words.

I do agree that Forth is a system language, with poor facilities for any
higher-level work. I don't concede anything :-) about "Forth and
friends", since I don't know what languages you're refering to.

It's good to be free from the restrictions of Forth. It's also good to
keep the benefits Forth has historically enjoyed, one of which is easy
refactoring.

Factor's EMACS mode, "Fuel", supports automated refactoring.

> - John

-Wm

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Search Ads

Get new customers.

List your web site

in Yahoo! Search.

Get in Shape

on Yahoo! Groups

Find a buddy

and lose weight.

.

__,_._,___
spir | 2 Mar 21:19 2009
Picon

[stack] What does "concatenative" actually mean?

Hello,

New to the list.
A long time ago, I was fascinated by Forth's ability to let one write programs/words by simply combining lower level words/programs. This was wonderfully illustrated by Logo's visual version of the feature.
I intuitively understand "concatenative" as meaning "constructive" in the sense of "brick programming". This is what I have always looked for, probably. Still, I do not really get why some languages may be so qualified; why most languages do not have this property.
I just discover that Forth (which I onlyused very few a long time ago) is supposed to be a concatenative language. I read the article on wikipedia, some more related texts and a few threads on this list. I do not know Joy (will read a bit while waiting for your replies ;-). Below my present ideas on the topic. I wish you would comment and criticize so that maybe... eurêka! (I am both an amateur and a non-english speaker: please be tolerant with my weird phrasing.)

I will use a notation where, for Forth like languages:
* Digits refer to literal data.
* An uppercase letters refers to a word/defined thing.
* A lowercase letter refers to any item inside a word definition, that may be a literal or another word

-1- referential transparency ================

In stack based langugages,
:W 1
actually means "push 1 (whatever it actually is) on top of the stack".
In a "real" OO language (based on messaged passing, such as usually done in prototypes languages like Io), a reference to a data slot actually calls a data accessor.
Is this analog to "pushing on the stack" ?

:X <do something with 2 values on top the stack>
:W 1 2 X

I intuitively think that this expression is analog to the following:

method X(a1,a2)
<do something with a1 & a2>
method W
x := 1 # literal value: call accessor
y := 2 # idem
X(x,y)

This leads me to wonder whether concatenation is related to referential transparency. Let us imagine a program which parse tree looks like this:
X
x1
x2
x3
Y
y1
y2
y3
Z
z1
z2
z3
A
a
X
Z
B
b
Y
Z

I have the impression that the language is concatenative iff we can safely translate A & B to:
A
a
x1
x2
x3
z1
z2
z3
B
b
y1
y2
y3
z1
z2
z3

Id est replace words with their definitions. This means that a word's definition only relies on the definitions on the words it references. So what makes most languages "unsafe" in this aspect? What kind of element in a definition breaks the scheme? My hypethesis is: definitions may use outer things like environment, state, variables... In the tree above, this translates to the fact that several occurrences of, say, z1 do not perform exactly the same action. For instance, it may not push the same value a stack: then, if z2 uses this value, it will not have the same result.

What lets me uneasy with this point of view is that "concatenative" is not supposed to be a synonym of "purely functional". Or what? Are purely functional languages necessarily, logically, concatenative? But maybe there are other ways to achieve this property, meaning that concatenative is a superset of functional?
Or am I totally wrong?
Anyway, forth is not qualified as functional. Also, stack based languages can well use data external to a word definition (outside the stack). Are they then still concatenative?

-2- the self expression hypothesis ================

Another unusual feature of Forth is its ability to compile itself. This is related I guess to the property that new words are equally treated as builtin words. Io has a similar feature and, as I understand it, a consequence is that it has no keyword in the usual sense of the term.
To allow such a property, these languages' grammars map directly to a parse tree (like Lisp, too) without any structural transformation. This is related, if I understand it correctly, to the fact that the grammar itself does not hold semantics. Or not the same way as for other languages; rather it is basically formal.
Still, there must some primitives here or there, "under the hood", else such a language would really be a pure form and a program would execute without *doing* anything ;-) These primitives are not expressed in the language itself. There are operational primitives (such as IO), but also some minimal "meta-linguistic" ones such as in Forth:

* A number token means "push this number (value) on the stack"
* ':...;' means "parse and store this definition"
* A word token means "recall this word's definiton"
[Expressed with my own words that may not be accurate.]

Analog operational and meta-linguistic primitives can be found in Io or other languages. In Io's case, and I guess in Forth too, even those things can be redefined. [E.g. in Io one can give a new definition to '(...)' which default is close to the one in Lisp.]

Now, my question is: is there any relation between such self-defining properties and the notion of "concatenativity"?

-3- human expressiveness ======================

I wonder about the practical usefulness of the concatenative propertie(s). The ability of building a program by pure composition is great. But it seems to lead to great modelizing restrictions, too. I will illustrate my question with a simple example.

Lets take the "mystery number" game. [Guess a number between eg 1 & 100. The "game master" answers "more" or "less" until found.] As I see it:

* There are 2 actors.
* They communicate: the player "guesses", the master "answers".
* The master holds a "secret" data item; the player has current "lower" and "upper" bounds.

This example really well maps to OO semantics, sure, I didn't choose it randomly;-) But I really think, too, that it illustrates a kind of natural way to express most of non-scientific models. (I.e. models that are rather a system than a "problem" mapping to a (possibly tree-like) process.)

How would a model of this game expressed in a concatenative language look like? (I really ask: if ever some of you want to answer with source code...)

I guess that in a functional language it would lead to conceptual distortion. Slight, manageable distortion, because the game is so simple. What I mean is that such langugages are often unable to allow a direct mapping from a model to source code expression. In other words: for me, a program should look like (be analog to) what it pretends to express.
This statement may only reflect a personal bias. Prototype based languges are, imo, the best metaphor / paradigm as of know, to allow direct, "natural", expression (In the OO world, most class-based languages yield on the contrary incredible and highly abstract complication -- and extreme dependencies!).

Is there a way to accord concatenation and basic OO? Or are these approaches -- as I suspect -- definitely incompatible?

Denis
------
la vita e estrany

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Need traffic?

Drive customers

With search ads

on Yahoo!

Group Charity

One Economy

Helping close the

digital divide

.

__,_._,___
John Nowak | 2 Mar 21:55 2009

Re: [stack] function/object ambiguity + quotation alternative

On Mar 2, 2009, at 1:44 PM, William Tanksley wrote:

> John Nowak wrote:
>
>> I think you're absolutely right. Forth and friends *demand* short
>> words, and consequently, demand factoring.A language like Scheme
>> makes it harder to factor, but the nesting and locals means much
>> larger definitions are readable, and consequently, much less
>> factoring
>> is required.
>
> There's truth in what you're saying, but you're missing an important
> fact: short definitions are easier to read in _any_ language. I admit
> that it's important to be able to express longer words.

You're right; I didn't mean to imply otherwise. Ideally, a language
should make writing long definitions possible (which I often find
useful in Scheme when prototyping and experimenting) and short
definitions elegant (which concatenative languages do well). I don't
know of a language that satisfies both of these criteria to the degree
I'd like, although some do come fairly close.

> I do agree that Forth is a system language, with poor facilities for
> any
> higher-level work. I don't concede anything :-) about "Forth and
> friends", since I don't know what languages you're refering to.

I was referring to stack-based languages in general; the average
length of a function definition needs to be shorter than in a language
like Scheme to achieve the same level of readability. The nesting in
Scheme helps visually and things remain mostly understandable even if
you don't know the arities of all the functions involved. That's only
my opinion of course; I've not launched a study to determine if this
goes for most people, although I suspect it does.

> Factor's EMACS mode, "Fuel", supports automated refactoring.

Aye, something like this likely helps by reducing the incentive to
write large definitions in the first place. It's a shame I've never
managed to convince myself to learn Emacs.

- John

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Ads on Yahoo!

Learn more now.

Reach customers

searching for you.

10 Day Club

on Yahoo! Groups

Share the benefits

of a high fiber diet.

.

__,_._,___
John Nowak | 2 Mar 22:23 2009

Re: [stack] What does "concatenative" actually mean?

On Mar 2, 2009, at 3:19 PM, spir wrote:

> I intuitively understand "concatenative" as meaning "constructive"
> in the sense of "brick programming". This is what I have always
> looked for, probably. Still, I do not really get why some languages
> may be so qualified; why most languages do not have this property.

The Wikipedia article was completely changed a few days ago and now
gives a (mostly) good definition of what qualifies; I'd start there:
http://en.wikipedia.org/wiki/Concatenative_programming_language

> In stack based langugages,
> :W 1
> actually means "push 1 (whatever it actually is) on top of the stack".
> In a "real" OO language (based on messaged passing, such as usually
> done in prototypes languages like Io), a reference to a data slot
> actually calls a data accessor.
> Is this analog to "pushing on the stack" ?

I'm not sure what you mean exactly, but I think the answer is probably
no. I don't think trying to understand concatenative languages in
terms of message passing is likely to yield good results. The problem
is that, unlike in Io, you don't really have a way of denoting the
receiver of a given message. Especially in the higher order languages
like Joy that have operations like 'dip', 'bi', etc, it's not clear
how a message passing semantics would work. (That's not to say you
couldn't make it work of course.)

The way to think about concatenative languages is in terms of function
composition. Each term in the language represents a function that
takes a stack as an argument and returns a new stack as a result. This
is most clearly seen in Joy where stacks are first class and
inexpensive to pass around freely. I'd try not to think about it in
the Forth sort of mindset where there's a single stack (or pair of
stacks) that all operations mutate.

> This leads me to wonder whether concatenation is related to
> referential transparency.

In Joy, most functions are referentially transparent. Depending on how
you look at it, you might even say that all functions are
referentially transparent because the compositional nature of the code
makes it possible to thread a single invisible state throughout the
entire program. Some degree of hand-waving is required however.

> I have the impression that the language is concatenative iff we can
> safely translate A & B to:
> ... Id est replace words with their definitions. This means that a
> word's definition only relies on the definitions on the words it
> references.

Correct.

> So what makes most languages "unsafe" in this aspect? What kind of
> element in a definition breaks the scheme? My hypethesis is:
> definitions may use outer things like environment, state, variables...

Correct; things like local variables make a language non-
concatenative. Factor offers locals but uses a compile-time transform
to convert definitions that use them to purely concatenative code.

> What lets me uneasy with this point of view is that "concatenative"
> is not supposed to be a synonym of "purely functional". Or what?

It depends on the language. For example, all data is persistent in
Joy; only IO will cause a visible side effect. In a language like
Factor, much data is not persistent.

> Are purely functional languages necessarily, logically, concatenative?

Not at all. Haskell is purely functional (i.e. there are *no* side
effects), but not concatenative.

> Another unusual feature of Forth is its ability to compile itself.
> This is related I guess to the property that new words are equally
> treated as builtin words. Io has a similar feature and, as I
> understand it, a consequence is that it has no keyword in the usual
> sense of the term.

Many languages have the property that new words are treated equally to
built-in words. What's unique about Io is that any function has access
to the message sent to it before any expressions associated with that
message are reduced. This is similar to the situation in Joy and XY
where functions can manipulate the functions passed to them (called
"quotations") as if they were lists. Factor offers a macro system that
lets you do the same sort of things you do in Forth.

> Still, there must some primitives here or there, "under the hood",
> else such a language would really be a pure form and a program would
> execute without *doing* anything

You may want to look at this page; it shows how concatenative
languages can be turing complete with a very minimal combinator
selection:
http://tunes.org/~iepos/joy.html

> Now, my question is: is there any relation between such self-
> defining properties and the notion of "concatenativity"?

The simple grammar of concatenative languages makes it easy to do the
sort of things you're talking about. It's not a property unique to
concatenative languages however.

> I wonder about the practical usefulness of the concatenative
> propertie(s).

They're useful. Tons of code is written in Forth. Factor has shown
tremendous progress in a very short period of time. If you're
interested in how such languages can be productive, I'd encourage you
to download Factor and get to work.

Factor offers an OO system which may make you feel more at home,
although it's based on multiple dispatch (I think) rather than message
passing; the former makes more sense for a concatenative language. I
don't know the system well enough to give you an example to your
problem, although I'm sure asking on the #concatenative channel on
Freenode would get you results; quite a few Factor programmers hang
out there.

> Is there a way to accord concatenation and basic OO? Or are these
> approaches -- as I suspect -- definitely incompatible?

They're not incompatible. Many Forths have objects, Factor has
objects, and I believe there was talk of adding a prototype-based
object system to Cat at one point as well. If you want to reimplement
Io in Factor, you'd be more than able to. I'd encourage you to try the
existing system first though and see what you think.

- John

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

New web site?

Drive traffic now.

Get your business

on Yahoo! search.

John McEnroe

on Yahoo! Groups

Join him for the

10 Day Challenge.

.

__,_._,___
Daniel Ehrenberg | 2 Mar 22:42 2009
Picon

Re: [stack] What does "concatenative" actually mean?

> They're useful. Tons of code is written in Forth. Factor has shown
> tremendous progress in a very short period of time. If you're
> interested in how such languages can be productive, I'd encourage you
> to download Factor and get to work.
>
> Factor offers an OO system which may make you feel more at home,
> although it's based on multiple dispatch (I think) rather than message
> passing; the former makes more sense for a concatenative language. I
> don't know the system well enough to give you an example to your
> problem, although I'm sure asking on the #concatenative channel on
> Freenode would get you results; quite a few Factor programmers hang
> out there.
>
>> Is there a way to accord concatenation and basic OO? Or are these
>> approaches -- as I suspect -- definitely incompatible?
>
> They're not incompatible. Many Forths have objects, Factor has
> objects, and I believe there was talk of adding a prototype-based
> object system to Cat at one point as well. If you want to reimplement
> Io in Factor, you'd be more than able to. I'd encourage you to try the
> existing system first though and see what you think.

Factor's OO system isn't based on message passing. Generic words are
words that can have methods defined on them for certain classes, like
Lisp. But multiple dispatch mostly isn't used (yet); there's a library
for multiple dispatch that's not in core.

Factor's object system used to be a unique hybrid between being
class-based and including delegation, but now it's more traditional.
There are things that are like structs, that can have single
inheritance among each other. Then, there are mixins, which are really
extensible union classes that take the place of declaring that a class
implements a certain interface. (It's not actually enforced that the
class does implement the interface.) There are also predicate classes,
singleton classes and a few other convenient things. The library
defines more (eg multimethods, delegation), since all the internals of
the object system are fully hackable.

I think Eduardo Cavazos wrote a prototype-based OO system in Factor,
but I'm not sure if it's still around. Generally, Factor is flexible
enough that you can implement whatever object system you want as a
library, and it can be made pretty efficient. Factor's object system
used to be just a library, but now it gets special help from the
compiler (type inference is used to reduce dispatch, etc), so it can't
really be considered that way now.

Dan

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Search Ads

Get new customers.

List your web site

in Yahoo! Search.

Yahoo! Groups

Cat Zone

Connect w/ others

who love cats.

.

__,_._,___
Don Groves | 3 Mar 01:19 2009
Picon

Re: [stack] What does "concatenative" actually mean?

On Mar 2, 2009, at 12:19 PM, spir wrote:

> Hello,
>
> New to the list.
> A long time ago, I was fascinated by Forth's ability to let one
> write programs/words by simply combining lower level words/programs.
> This was wonderfully illustrated by Logo's visual version of the
> feature.
> I intuitively understand "concatenative" as meaning "constructive"
> in the sense of "brick programming". This is what I have always
> looked for, probably. Still, I do not really get why some languages
> may be so qualified; why most languages do not have this property.
> I just discover that Forth (which I onlyused very few a long time
> ago) is supposed to be a concatenative language. I read the article
> on wikipedia, some more related texts and a few threads on this
> list. I do not know Joy (will read a bit while waiting for your
> replies ;-).

Warning: if you were inspired by Forth, Joy will
change your life!

You will become hooked on its ideas, just as so
many here have before you ;-)
--
don

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Ads on Yahoo!

Learn more now.

Reach customers

searching for you.

Y! Groups blog

The place to go

to stay informed

on Groups news!

.

__,_._,___
spir | 3 Mar 10:56 2009
Picon

Re: [stack] What does "concatenative" actually mean?

Le Mon, 2 Mar 2009 16:23:15 -0500,
John Nowak <john <at> johnnowak.com> s'exprima ainsi:

> On Mar 2, 2009, at 3:19 PM, spir wrote:
>
> > I intuitively understand "concatenative" as meaning "constructive"
> > in the sense of "brick programming". This is what I have always
> > looked for, probably. Still, I do not really get why some languages
> > may be so qualified; why most languages do not have this property.
>
> The Wikipedia article was completely changed a few days ago and now
> gives a (mostly) good definition of what qualifies; I'd start there:
> http://en.wikipedia.org/wiki/Concatenative_programming_language

Thank you for your extensive reply.
I have read this page numerous times ;-)

> > In stack based langugages,
> > :W 1
> > actually means "push 1 (whatever it actually is) on top of the stack".
> > In a "real" OO language (based on messaged passing, such as usually
> > done in prototypes languages like Io), a reference to a data slot
> > actually calls a data accessor.
> > Is this analog to "pushing on the stack" ?
>
> I'm not sure what you mean exactly, but I think the answer is probably
> no.

What I mean is (letting aside the notion of object to which a message are sent -- say that there a unique global object or talk of plain functions).

:plus <whatever> ;
:plus1 1 plus ;

Can we say that the code above is equivalent to:

func plus(a,b)
<whatever>
func plus1(n)
plus(n, 1)

or more explicitely:

:plus <whatever> push; # 'push' means push result on the stack
:plus1 1 push plus ; # result already on the stack

func plus(a,b)
<whatever>
resturn result
func plus1(n)
# equivalent to pushing 'data'?
x := n
y := 1
# then only call other func
plus(x, y)

I wonder if the functional way and the stack way are equivalent manners of defining code snippets -- that use variables in the math sense of "unpredictable values" (at design time) -- that are secure; meaning that they will perform a fully defined action and/or are concatenatable as code bricks.

> > This leads me to wonder whether concatenation is related to
> > referential transparency.
>
> In Joy, most functions are referentially transparent. Depending on how
> you look at it, you might even say that all functions are
> referentially transparent because the compositional nature of the code
> makes it possible to thread a single invisible state throughout the
> entire program. Some degree of hand-waving is required however.
[...]
> > What lets me uneasy with this point of view is that "concatenative"
> > is not supposed to be a synonym of "purely functional". Or what?
>
> It depends on the language. For example, all data is persistent in
> Joy; only IO will cause a visible side effect. In a language like
> Factor, much data is not persistent.

> > Are purely functional languages necessarily, logically, concatenative?
>
> Not at all. Haskell is purely functional (i.e. there are *no* side
> effects), but not concatenative.

Still unclear for me. (good, I have unknown worlds to explore ;-)

> > I wonder about the practical usefulness of the concatenative
> > propertie(s).
>
> They're useful. Tons of code is written in Forth.
[...]
I expressed myself unclearly.

> > Is there a way to accord concatenation and basic OO? Or are these
> > approaches -- as I suspect -- definitely incompatible?
>
> They're not incompatible. Many Forths have objects, Factor has
> objects, and I believe there was talk of adding a prototype-based
> object system to Cat at one point as well. If you want to reimplement
> Io in Factor, you'd be more than able to. I'd encourage you to try the
> existing system first though and see what you think.

This is something I really do not understand. In many OO languages, especially prototype-based ones, objects are simple map/dict like variables. They can be refered to from inside any word/func/'action'; so as I understand the point they act, at least can act, as global state, environment, variables that will necessarily break the (referential) "safety" of the function. Meaning that they have unpredictable effect/result. How can one then simply combine such functions as code bricks -- which is how I understand concatenativity?
There must be something my brain is unable to catch...

> - John

Thank you again,
Denis
------
la vita e estrany

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

New web site?

Drive traffic now.

Get your business

on Yahoo! search.

Weight Loss Group

on Yahoo! Groups

Get support and

make friends online.

.

__,_._,___
John Nowak | 3 Mar 11:14 2009

Re: [stack] What does "concatenative" actually mean?

On Mar 3, 2009, at 4:56 AM, spir wrote:

> :plus <whatever> ;
> :plus1 1 plus ;
>
> Can we say that the code above is equivalent to:
>
> func plus(a,b)
> <whatever>
> func plus1(n)
> plus(n, 1)

I'm not sure this'll help, but I'll try.

In a stack-based concatenative language, every function takes a stack
as input and returns a new stack as a result. Accordingly, we might
implement the 'plus' function of a concatenative language in Scheme as
such:

(lambda (s) (cons (+ (car s) (cadr s)) (cddr s)))

Another example would be 'dup':

(lambda (s) (cons (car s) s))

And 'dip':

(lambda (s) (cons (cadr s) ((car s) (cddr s))))

Of course, if you're not familiar with Lisp, I've just confused you
even more.

>> Not at all. Haskell is purely functional (i.e. there are *no* side
>> effects), but not concatenative.
>
> Still unclear for me. (good, I have unknown worlds to explore ;-)

In Haskell, not all terms denote functions. In concatenative
languages, all terms denote functions. In Haskell, juxtaposition
denotes application. In concatenative languages, juxtaposition denotes
composition.

> This is something I really do not understand. In many OO languages,
> especially prototype-based ones, objects are simple map/dict like
> variables. They can be refered to from inside any word/
> func/'action'; so as I understand the point they act, at least can
> act, as global state, environment, variables that will necessarily
> break the (referential) "safety" of the function.

The object systems in Factor and Forth do break referential
transparency. If this means that are not "purely concatenative"
depends on who you ask.

- John

__._,_.___
Recent Activity
Visit Your Group
Yahoo! Finance

It's Now Personal

Guides, news,

advice & more.

Search Ads

Get new customers.

List your web site

in Yahoo! Search.

Group Charity

Give a laptop

Get a laptop: One

laptop per child

.

__,_._,___
William Tanksley | 3 Mar 16:11 2009
Picon

Re: [stack] What does "concatenative" actually mean?

John Nowak wrote:
> The object systems in Factor and Forth do break referential
> transparency. If this means that are not "purely concatenative"
> depends on who you ask.

Thanks for taking the time to explain; I agree with most of what you've
said, but this is false.

Forth doesn't have any "the object system"; some of the open-source
alternatives available do destroy local concatenativity, but most of
them don't.

Factor's official object system is definitely fully concatenative. It
won't matter who you ask; if they disagree with me, they're wrong. ;-)

Technical point: Referential Transparency in a concatenative language is
different from the same concept in an applicative language. In one
sense, it's harder to use, since you can't simply move words from one
place to another (without rearranging the stack); in another sense it's
easier to use, since you can "factor out" a word without having to do
any work at all (cut and paste is sufficient). Unlike applicative
languages, you do NOT have to worry about functional state; the fact
that the stack acts as a monad means that the state is already
preserved; even I/O can be modelled properly.

> - John

-Wm

__._,_.___
Recent Activity
Visit Your Group
Give Back

Yahoo! for Good

Get inspired

by a good cause.

Y! Toolbar

Get it Free!

easy 1-click access

to your groups.

Yahoo! Groups

Start a group

in 3 easy steps.

Connect with others.

.

__,_._,___

Gmane