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