# Java Factor

## Slava Pestov — 2004-11-16 17:28:34

    Hi everybody,

    I'm in the process of stripping down Java Factor to just a syntax

    parser, and jEdit plugin module that communicates with CFactor over a

    socket.

    I did some line number counts. The compiler portion of Java Factor was

    approximately 10,000 lines of Java code. In comparison, the x86 compiler

    in CFactor is only 1300 lines! The x86 compiler doesn't handle one case

    Java Factor does, the compilation of combinators -- however adding this

    shouldn't substantially increase the line count.

    Is this just sloppy Java coding on my part (and it WAS sloppy), or do

    concatenative languages have an inherent advantage in compactness? For

    the record, I don't find the x86 compiler code any less readable -- on

    the contrary, the code is succinct and expresses what it does exactly,

    without duplicatin of control structure and general verbosity that one

    finds in Java.

    Slava

## Philippa Cowderoy — 2004-11-16 18:11:54

    On Tue, 16 Nov 2004, Slava Pestov wrote:

     > Is this just sloppy Java coding on my part (and it WAS sloppy), or do

    > concatenative languages have an inherent advantage in compactness?

     I think it's more that languages that aren't Java have an inherant

    advantage in compactness :-)

    --

    flippa@...

## William Tanksley, Jr — 2004-11-16 20:24:03

    Philippa Cowderoy <flippa@...> wrote:

     > On Tue, 16 Nov 2004, Slava Pestov wrote:

    > > Is this just sloppy Java coding on my part (and it WAS sloppy), or do

    > > concatenative languages have an inherent advantage in compactness?

    > I think it's more that languages that aren't Java have an inherant

    > advantage in compactness :-)

     Heh :-).

    Seriously, a lot of Forth programmers, myself included, believe that

    there is indeed an advantage. I could spout a few reasons, but I think

    it's more important to note that like the entire rest of the field of

    concatenative languages, there's very little decent study on this. Any

    real answer would have to include more than just my justification.

    But with that said, here's my jusification: concatenative languages

    make it easy to find and factor out common functionality, thus

    providing essentially the same capabilities as typical

    dictionary-based compression formats. This compression is under the

    control of a programmer, not a computer, so whether or not the result

    is actually shorter depends on how the programmer works -- but there's

    strong grounds for believing that other things being equal, shorter

    code is easier to write and maintain, so programmers will indeed tend

    to try to factor their code.

    So concatenative languages make it textually very easy to factor

    common code out; they also make it inexpensive, because function calls

    in a concatenative language are cheaper than function calls in

    applicative languages. And what's cheap will be done more often, no

    matter WHAT people may tell you about "early optimization".

    Oh, and one more reason why your second program was shorter: it's

    probably because your first program was an experiment, and you did

    part of it wrong. That one has nothing to do with concatenativity. :-)

     > flippa@...

     -Billy

## Philippa Cowderoy — 2004-11-16 20:53:32

    On Tue, 16 Nov 2004, William Tanksley, Jr wrote:

     >

    > Philippa Cowderoy <flippa@...> wrote:

    > > On Tue, 16 Nov 2004, Slava Pestov wrote:

    > > > Is this just sloppy Java coding on my part (and it WAS sloppy), or do

    > > > concatenative languages have an inherent advantage in compactness?

    >

    > > I think it's more that languages that aren't Java have an inherant

    > > advantage in compactness :-)

    >

    > Heh :-).

    >

    > Seriously, a lot of Forth programmers, myself included, believe that

    > there is indeed an advantage.

     <snip>

     > But with that said, here's my jusification: concatenative languages

    > make it easy to find and factor out common functionality, thus

    > providing essentially the same capabilities as typical

    > dictionary-based compression formats.

     Sure. Similar capabilities can be found in eg applicative languages or

    even that monster known as lisp.

     > So concatenative languages make it textually very easy to factor

    > common code out; they also make it inexpensive, because function calls

    > in a concatenative language are cheaper than function calls in

    > applicative languages. And what's cheap will be done more often, no

    > matter WHAT people may tell you about "early optimization".

    >

     And here you have why I'm showing an interest. Well, that and something

    I've been playing with from a completely different angle looks

    suspiciously like a compositional language (I don't have a good concrete

    syntax yet).

    --

    flippa@...

## William Tanksley, Jr — 2004-11-16 21:28:42

    Philippa Cowderoy <flippa@...> wrote:

     > On Tue, 16 Nov 2004, William Tanksley, Jr wrote:

    > > But with that said, here's my jusification: concatenative languages

    > > make it easy to find and factor out common functionality, thus

    > > providing essentially the same capabilities as typical

    > > dictionary-based compression formats.

    > Sure. Similar capabilities can be found in eg applicative languages or

    > even that monster known as lisp.

     No, not at all. Well, yes, okay, you can talk about factoring stuff

    out -- but you can't perform the factoring by copying text; you have

    to analyse the local variable and parameter usage. In a concatenative

    language, you perform the entire factoring by copying the code. In an

    applicative language, you have to find all the parameters and insert

    them into the function header, find all the locals and create

    declarations and initial values, and so on.

    So although all languages do support function calls, not all languages

    make factoring out code anything close to a smooth, mechanical

    process.

     > > So concatenative languages make it textually very easy to factor

    > > common code out; they also make it inexpensive, because function calls

    > > in a concatenative language are cheaper than function calls in

    > > applicative languages. And what's cheap will be done more often, no

    > > matter WHAT people may tell you about "early optimization".

    > And here you have why I'm showing an interest. Well, that and something

    > I've been playing with from a completely different angle looks

    > suspiciously like a compositional language (I don't have a good concrete

    > syntax yet).

     I'd love to hear more!

     > flippa@...

     -Billy

## Daniel Ehrenberg — 2004-11-16 22:54:23

    > But with that said, here's my jusification:

    > concatenative languages

    > make it easy to find and factor out common

    > functionality, thus

    > providing essentially the same capabilities as

    > typical

    > dictionary-based compression formats. This

    > compression is under the

    > control of a programmer, not a computer, so whether

    > or not the result

    > is actually shorter depends on how the programmer

    > works -- but there's

    > strong grounds for believing that other things being

    > equal, shorter

    > code is easier to write and maintain, so programmers

    > will indeed tend

    > to try to factor their code.

     That is an advantage, but it isn't specific to

    concatenative languages, nor is it always possible in

    concatenative languages. Rather, it is a property of

    not using named variables. In Forth, there is the word

    LOCALS|, which can make local variables. Code which

    uses this is less easily factorable than code that

    doesn't use it, yet there are some cases where it's

    much easier to write code using it. Also, in a

    language like FP, and to a limited degree in J, you

    don't have named variables and code is completely

    factorable, yet the language is not concatenative. In

    Haskell, you can use functions like . to write in a

    variable-free style and make code more factorable.

    Still, I like the concatenative approach, because

    unlike J and Haskell, you can avoid using variables in

    all cases, and FP is just creepy :)

    Daniel Ehrenberg

    __________________________________

    Do you Yahoo!?

    The all-new My Yahoo! - Get yours free!

    http://my.yahoo.com

## William Tanksley, Jr — 2004-11-17 16:34:52

    Daniel Ehrenberg <littledanehren@...> wrote:

     > > But with that said, here's my jusification:

    > > concatenative languages

    > > make it easy to find and factor out common

    > > functionality, thus

    > > providing essentially the same capabilities as

    > > typical

    > > dictionary-based compression formats. This

    > That is an advantage, but it isn't specific to

    > concatenative languages, nor is it always possible in

    > concatenative languages.

     I would say that it IS always possible in concatenative languages --

    but some things people like to add to concatenative languages destroy

    their concatenativity.

     > Rather, it is a property of

    > not using named variables.

     To phrase it in a positive way, this advantage is a property of

    languages that use explicit dataflow. And that's not entirely true --

    dataflow makes it possible, but the syntax of the language can still

    make it very difficult. Consider some of the syntactical forms in the

    J language, where the form of the dataflow is controlled not by words,

    but by the arrangement of words in the syntax.

     > In Forth, there is the word

    > LOCALS|, which can make local variables.

     Yes. This, I would say, makes code non-concatenative. The same can be

    argued for one of my personal favorite features, return stack

    manipulation.

     > much easier to write code using it. Also, in a

    > language like FP, and to a limited degree in J, you

    > don't have named variables and code is completely

    > factorable, yet the language is not concatenative. In

    > Haskell, you can use functions like . to write in a

    > variable-free style and make code more factorable.

     In all cases I know of, the power is gained through explicit control

    of dataflow.

     > Still, I like the concatenative approach, because

    > unlike J and Haskell, you can avoid using variables in

    > all cases, and FP is just creepy :)

     Grin.

     > Daniel Ehrenberg

     -Billy

## Slava Pestov — 2004-11-17 21:40:10

    William Tanksley, Jr wrote:

     > Yes. This, I would say, makes code non-concatenative. The same can be

    > argued for one of my personal favorite features, return stack

    > manipulation.

     Return stack manipulation in the 'portable' sense is concatenative. Just

    picture Forth's:

      >r .... r>

     as Joy's

    [ ... ] dip

    On the other hand, if you're using >r/r> to dick with the actual return

    addresses, its not concatenative at all, but it maybe be possible to

    reformulate in terms of continuations.

     >>Still, I like the concatenative approach, because

    >>unlike J and Haskell, you can avoid using variables in

    >>all cases, and FP is just creepy :)

     Speaking of FP, do any implementations actually exist?

    Slava

## William Tanksley, Jr — 2004-11-17 22:05:49

    Slava Pestov <slava@...> wrote:

     > William Tanksley, Jr wrote:

    > > Yes. This, I would say, makes code non-concatenative. The same can be

    > > argued for one of my personal favorite features, return stack

    > > manipulation.

    > Return stack manipulation in the 'portable' sense is concatenative. Just

    > picture Forth's:

    >  >r .... r>

    > as Joy's

    > [ ... ] dip

     Joy's "dip" combinator is quite brilliant, since it hides the

    non-concatenativity inside a quotation, thus making it irrelevant to

    the analysis of the program. The Forth >R and R> don't have the same

    advantage.

    I don't think it's fair to claim an equality between the two simply

    because the Forth _can_ be used in the same way. You might as well say

    that a language with only assembly-style BRANCH instructions was

    equivalent to a language with a structured IF, because you _can_ use

    them in the same way.

     > On the other hand, if you're using >r/r> to dick with the actual return

    > addresses, its not concatenative at all, but it maybe be possible to

    > reformulate in terms of continuations.

     Continuations themselves are not, in current theory, concatenative. I

    think that this is a problem with the theory, not with continuations;

    in fact, I believe that when the theory is completed, >R and R> will

    turn out to be perfectly valid concatenative operations.

    For this reason, I really like the "stackless" way of looking at

    concatenative languages -- you might remember the recent essay posted

    here about XY, queues, trees, and loops. This is the start of a

    complete theory of concatenative languages, and I can only hope that

    we'll be able to complete it. IMO the big step will be when we can

    come up with a textual theory, equivalent to but more precise than the

    current concatenativity test "a language is concatenative if any two

    valid programs can be concatenated to form a valid program, and any

    valid program can be split at any lexical boundary to form two valid

    programs."

     > >>Still, I like the concatenative approach, because

    > >>unlike J and Haskell, you can avoid using variables in

    > >>all cases, and FP is just creepy :)

    > Speaking of FP, do any implementations actually exist?

     I saw one a while ago, but I think it was very old and pretty much

    useless. It's a great model, I suppose, but Haskell does better. You

    don't need variables in Haskell -- in fact, you can write

    concatenative Haskell without too much difficulty, even though it

    doesn't look as good.

     > Slava

     -Billy

## stevan apter — 2004-11-17 22:20:49

    From: "William Tanksley, Jr" <wtanksleyjr@...>

     >

    > For this reason, I really like the "stackless" way of looking at

    > concatenative languages -- you might remember the recent essay posted

    > here about XY, queues, trees, and loops. This is the start of a

    > complete theory of concatenative languages, and I can only hope that

    > we'll be able to complete it. IMO the big step will be when we can

    > come up with a textual theory, equivalent to but more precise than the

    > current concatenativity test "a language is concatenative if any two

    > valid programs can be concatenated to form a valid program, and any

    > valid program can be split at any lexical boundary to form two valid

    > programs."

     yes - where /is/ chris cogan?

## phimvt@lurac.latrobe.edu.au — 2004-11-23 05:55:32

    On Wed, 17 Nov 2004, William Tanksley, Jr wrote:

     > Slava Pestov <slava@...> wrote:

    > > William Tanksley, Jr wrote:

     [..]

     > > >>Still, I like the concatenative approach, because

    > > >>unlike J and Haskell, you can avoid using variables in

    > > >>all cases, and FP is just creepy :)

    >

    > > Speaking of FP, do any implementations actually exist?

    >

    > I saw one a while ago, but I think it was very old and pretty much

    > useless.

     There was an implementation of sorts:

        google:  "Illinois functional programming"

    will give you all the papers and documentation. But it is really

    an Algolised version of FP.

    The real FP (by Backus) does look creepy at first, I admit.

    But after studying it very long and very hard, I was most

    impressed by the 1978 (?) paper "Can programming be liberated

    from the von Neumann style ...". It opened my eyes about

    high level programming (and the eyes of a lot of other people,

    to). It was my primary motivation for developing the

    precursor(s) to Joy.

    [..]

      - Manfred