Factor
Hugh Aguilar
My own opinion is that Factor is a good language for desktop
programming, and Forth is a good language for micro-controller
programming.
Is discussion of Forth-derived languages appropriate for this forum,
or only ANS-Forth? The reason that I ask is that I wouldn't want my
post to be considered non-Forth spam.
I'm considering writing a book providing a head-to-head comparison of
Factor and Forth. This would involve presenting programs written in
both Factor and Forth, and compared according to various criteria that
are presumably meaningful in the real world. It might also be
interesting to throw a non-Forth language, such as Lisp, into the
arena as well. To do this however, it would be necessary to find
somebody other than myself to be the champion of that language, as I
am only good at Forth (and Factor to a lessor extent). An example of a
Factor program would be <a href="www.rosycrew.org/
symtab.factor">symtab</a>. This book would of course only be written
for fun, and distributed for free --- it is well-known that no
computer book can get accepted by a publisher nowadays unless it has
the phrase "web-design" in the title. ;-)
Elizabeth D Rather
> Do you guys have an opinion on the Factor language?
>
> My own opinion is that Factor is a good language for desktop
> programming, and Forth is a good language for micro-controller
> programming.
>
> Is discussion of Forth-derived languages appropriate for this forum,
> or only ANS-Forth? The reason that I ask is that I wouldn't want my
> post to be considered non-Forth spam.
My very personal opinion is that all varieties of Forth are fair game
here, but a different language that lists Forth among other influences
should be discussed in its own forum.
According to Wikipedia, "Factor's main influences are Joy, Forth, Lisp
and Self." That sounds like a language with its own identity, not a
"variety of Forth".
I think Forth-Factor comparisons would be welcome, but not so much
discussions of Factor per se.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Ian Osgood
The Concatenative Language mailing list is likely to be a better forum
for this.
http://tech.groups.yahoo.com/group/concatenative/
The #concatenative IRC channel on freenode.org is also a good forum.
Ian
Anton Ertl
>Is discussion of Forth-derived languages appropriate for this forum,
>or only ANS-Forth?
Any kind of Forth is on-topic here.
Factor has been discussed several times in the past, and IIRC nobody
has complained.
You could tag any postings on Factor with "[Factor]" to make it easy
to filter it out (or in). If there is so much traffic on Factor that
it becomes a problem (which I don't expect), a separate newsgroup can
be created.
>I'm considering writing a book providing a head-to-head comparison of
>Factor and Forth. This would involve presenting programs written in
>both Factor and Forth, and compared according to various criteria that
>are presumably meaningful in the real world.
You might be interested in
http://www.complang.tuwien.ac.at/forth/programs/map-array/
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Hugh Aguilar
> I think Forth-Factor comparisons would be welcome, but not so much
> discussions of Factor per se.
That is the idea --- to compare Factor and Forth. They are similar
enough that the comparison wouldn't be totally apples/oranges (imagine
trying to compare Python and Forth) --- yet they have a different
underlying philosophy.
This is somewhat like the way that Americans who try to learn German
are initially pleased to discover that a lot of the simple words are
either the same or almost the same, and so they think that the job
will be easy, but then they run into some serious difficulty. At least
that is what I've heard anyway --- the only German I know is what I
learned from watching "Hogan's Heroes."
I'm fairly new at Factor myself. My experience has been that the
emphasis on idiomatic programming is the greatest challenge. As a
Forth programmer I consider the idea that there is virtue in doing
things the way that other people do them, to be a most peculiar
superstition. In Factor, you are supposed to care about this. In Forth
if I need something, such as a doubly-linked list structure, I just
write it myself, and that is what I would be expected to do. I did
this in Factor (www.rosycrew.org/list.factor) but my effort was
frowned upon because solutions already exist and I was supposed to
care enough to look these things up in the documentation for the sake
of being idiomatic.
A book comparing Factor and Forth might prove difficult. If I included
my list program, the reader might think that this is something he
needs to learn. That would be missing the point though, which is that
you don't have to learn anything, but you just do whatever you want to
do. There is no reason to believe that my implementation of lists is
the best, just because mine is in the book.
On the other hand, my implementation of symtab (www.rosycrew.org/
symtab/factor) is the best, because I invented the algorithm, and
there aren't any other implementations.
John Passaniti
> I'm fairly new at Factor myself. My experience has been that the
> emphasis on idiomatic programming is the greatest challenge. As a
> Forth programmer I consider the idea that there is virtue in doing
> things the way that other people do them, to be a most peculiar
> superstition.
Yes, that's just crazy! Everyone knows that if you need a _common_
data structure or algorithm, the best use of your time is to code it
yourself. Think of the many advantages. First, you get extra typing
practice. Second, you get to tell your client that no, you haven't
finished the actual application yet, but your exquisitely factored
linked list and binary search routines are perfect gems, almost
poetry. Third, it means that when other people maintain your code,
they don't have to face the boredom of routines they already know;
instead your code becomes more of an adventure with thrills around
every corner! Fourth, it gives others the ability to see how truly
brilliant you are, basking in the glow of the fresh insights you
brought to the common and mundane.
> In Factor, you are supposed to care about this. In Forth
> if I need something, such as a doubly-linked list structure, I just
> write it myself, and that is what I would be expected to do. I did
> this in Factor (www.rosycrew.org/list.factor) but my effort was
> frowned upon because solutions already exist and I was supposed to
> care enough to look these things up in the documentation for the sake
> of being idiomatic.
Idiots! Yeah, it sure is nice when a language gives you a rich and
flexible set of data structures and algorithms that are designed so
that you can quickly and easily string them together to get more
powerful, reusable designs. Nice... IF YOU'RE A FREAKIN' SOCIO-
COMMUNO-NAZI-FASCIST FREAK. Clearly the right way is to come up with
a unique code that doesn't work with the oppressive interfaces of
common man. You're John Galt! You're superman! Those Factor fools
looking on your linked list code should tremble at it's beauty. Sure,
you've just replicated functionality that was already there and
already tested. But it's yours! Your name is on it!
> A book comparing Factor and Forth might prove difficult. If I included
> my list program, the reader might think that this is something he
> needs to learn. That would be missing the point though, which is that
> you don't have to learn anything, but you just do whatever you want to
> do. There is no reason to believe that my implementation of lists is
> the best, just because mine is in the book.
I guess there would be some value in a "book" that took parallel code
examples in Forth and Factor and compared them. People like that sort
of thing to quickly get a sense of the style, verbosity, and "feel" of
a language. It isn't useful for much else, as most every language
(including Forth) has idioms, best practices, dogma, and prejudices.
So simply transliterating a particular data structure or algorithm in
the same way in different languages isn't particularly revealing.
But as I understand Factor, although Forth is an obvious influence, it
is also influenced by Lisp and Smalltalk. So a far more important and
valuable "book" would be to explore how much of an "impedance
mismatch" exists between Forth's straight-ahead procedural style and
Factor's functional and object-oriented styles. Certainly in any
hybrid language like Factor seeing how well (or badly) they bridge the
divides will give people a real sense of the strengths and weaknesses.
> On the other hand, my implementation of symtab (www.rosycrew.org/
> symtab/factor) is the best, because I invented the algorithm, and
> there aren't any other implementations.
I'm sure it's lovely. Although the idea of making data structures
that order data by how frequently they are accessed isn't new and
pretty much every book on data structures and compiler design touches
on optimizations to symbol tables. What I would be far more
interested in is why you wrote it. Was it just an exercise in
premature (or presumptive) optimization? Or did you have an
application where a traditional approach (such as a hash table) was
inadequate.
Slava Pestov
> The Concatenative Language mailing list is likely to be a better forum
> for this.
>
> http://tech.groups.yahoo.com/group/concatenative/
The concatenative mailing list is very low-volume and doesn't carry
much Factor discussion. The Factor list is better for discussing
Factor:
http://sourceforge.net/mailarchive/forum.php?forum_name=factor-talk
> The #concatenative IRC channel on freenode.org is also a good forum.
Yeah, this is a good place to ask questions and get help.
Slava
Slava Pestov
wrote:
I ran these benchmarks again.
'slava.factor' needed some minor updates:
----
USING: syntax vectors namespaces math kernel sequences ;
IN: bench
: step ( seq -- ) 0 [ + ] reduce drop ; inline
: numbers ( -- seq ) 1000 [ 1 + ] map ; inline
: bench ( -- ) numbers 100000 [ dup step ] times drop ;
bench
----
Here is the running time compared to gforth:
$ time gforth map-array.fs -e bye
real 0m2.300s
user 0m2.251s
sys 0m0.012s
$ time ./factor stupid.factor
real 0m1.527s
user 0m1.244s
sys 0m0.251s
However Factor's compiler is pretty slow to compile because it has
many passes, and there is a non-zero startup time in just loading the
VM image (I presume gforth's is almost instant). We can take startup
and compile time out of the picture by timing the execution of the
'bench' word itself -- in most real-world settings you rarely have a
program that runs for less than a second then exits (CGI is one
exception of course, and you wouldn't use Factor for that). To use
internal timing, change the last line of the file to '[ bench ] time'
and add 'tools.time' to the using list at the top:
$ time ./factor stupid.factor
== Running time ==
0.547449 seconds
Much faster!
This surprises me though because while the gforth benchmark is using
direct memory access, Factor is using dynamically typed, garbage
collected, polymorphic arrays; when you iterate over the array and sum
elements; you're doing a dynamic dispatch on every call to '+'.
Perhaps I compiled my gforth-fast wrong? I just got the version out of
MacPorts using 'sudo port install gforth'. GCC 4.0.1 here.
Slava
Slava Pestov
> $ time gforth map-array.fs -e bye
>
> real 0m2.300s
> user 0m2.251s
> sys 0m0.012s
My apologies, I meant to run 'gforth-fast' but ran 'gforth' instead.
$ time gforth-fast map-array.fs -e bye
real 0m1.804s
user 0m1.774s
sys 0m0.011s
Slava
Hugh Aguilar
> > On the other hand, my implementation of symtab (www.rosycrew.org/
> > symtab/factor) is the best, because I invented the algorithm, and
> > there aren't any other implementations.
>
> I'm sure it's lovely. Although the idea of making data structures
> that order data by how frequently they are accessed isn't new and
> pretty much every book on data structures and compiler design touches
> on optimizations to symbol tables. What I would be far more
> interested in is why you wrote it. Was it just an exercise in
> premature (or presumptive) optimization? Or did you have an
> application where a traditional approach (such as a hash table) was
> inadequate.
Hash tables work well on computers with a lot of memory (desktop
computers) because you can easily increase the speed just by
increasing the size. Desktop computers are also so fast nowadays that
efficiency isn't an issue. It makes sense to just use an off-the-shelf
solution and get on with your work --- as you so sarcastically pointed
out. In a small-memory environment however --- such as on-chip
compilation --- something like symtab would be a good idea. I have
never read any book on algorithms that discussed ordering data by
frequency of access, so I think that my algorithm is original, and the
idea behind it as well.
All of this is beside the point anyway. The purpose of a Factor/Forth
comparison is not to demonstrate algorithms such as symtab. That might
have been interesting back in the 1980s, but nobody cares about
algorithms nowadays. Inventing a new algorithm in computer science is
like inventing a new shape in geometry; it is not going to make you
famous. Any book however, is going to contain example programs that
aren't very interesting or useful (the Towers of Hanoi). Compared to
programs such as this, symtab would be more likely to keep the reader
awake, IMHO.
The point of the book --- I won't draw out the suspense --- is that
Forth would benefit by switching over to supporting quotations. That
is by far the coolest aspect of Factor. Other aspects of Factor, such
as sequences, are not very interesting. Sequences are Factor's counter-
solution to my list program. There is not particular point in Forth
adopting sequences (or adopting my list program), because things like
this are easily implemented by the programmer. This is what I meant
when I said that my list program wasn't anything special --- that
there would be no point in making this a standard feature of the
language because anybody can implement lists themselves, or they can
implement something along the lines of sequences, or they can
implement some other solution that they like better. Quotations are
different though, because they are a lot harder to implement in Forth,
and would require knowledge of the internal workings of the compiler
(I doubt that this could be done using only ANS-Forth). Also,
quotations are useful in *every* program, and pretty much in every
function. By comparison, sequences are only useful occasionally and
are as easy to ignore as symtab.
Forth is an extensible language --- read the brochure! Forth can steal
the cool features (quotations) of other languages (Factor). This is
not true of non-Forth languages. I wouldn't suggest to the C++
community that they try to borrow quotations from Factor because they
would just yawn and say: "Yeah, we'll be sure to mention your idea to
Bjarne Stroustrup the next time that we see him." By comparison, in
Forth you don't have to wait for somebody important (Charles Moore or
Elizabeth Rather) to make the big decision to accept your idea --- you
just go ahead and do it yourself. Extensibility is the ultimate cool
feature!
pliz
> The point of the book --- I won't draw out the suspense --- is that
> Forth would benefit by switching over to supporting quotations.
Yup! Quotations are great! Bigforth has them in lambda.fs and gforth's
implementation has been posted here previously but I can't find it
now. Looks like:
: :[ postpone ahead :noname ; immediate
: ]; postpone ; ] >r postpone then r> postpone literal ; immediate
In contrast to factor both implementations are for compile time.
--
Sergey
Gerry
[..]
> The point of the book --- I won't draw out the suspense --- is that
> Forth would benefit by switching over to supporting quotations. That
> is by far the coolest aspect of Factor. Other aspects of Factor, such
> as sequences, are not very interesting. Sequences are Factor's counter-
> solution to my list program. There is not particular point in Forth
> adopting sequences (or adopting my list program), because things like
> this are easily implemented by the programmer. This is what I meant
> when I said that my list program wasn't anything special --- that
> there would be no point in making this a standard feature of the
> language because anybody can implement lists themselves, or they can
> implement something along the lines of sequences, or they can
> implement some other solution that they like better. Quotations are
> different though, because they are a lot harder to implement in Forth,
> and would require knowledge of the internal workings of the compiler
> (I doubt that this could be done using only ANS-Forth).
There was a discussion on this last May, see the end of:
But I doubt if most Forthers like the technique used - still it was
in ANS Forth
[..]
Gerry
heytwo
I'm considering writing a book providing a head-to-head comparison of
> Factor and Forth.
This would involve presenting programs written in
> both Factor and Forth, and compared according to various criteria that
---------------------------------------
You dont write revu's on Forth programs , you use the program
and hope no others hear of the program ( aka WORD )
You make lots of money using the program ...
Unlike Elizabeth , who SELL SELL SELL ...
Fast Forth is to find a box with a simple fast , open
BIOS , then write 4 primatives , use these to create
the rest of the primatives , then "take" over the BIOS
with Forth ( integarte BIOS into your Forth )
DSL , a childs game box . Nintendo ..
DSL is so easy , i stopped buying EVB's from
BTW anyone know where i can get old spreadsheet ( 24 years old)
JAVELIN PLUS
John Passaniti
> Hash tables work well on computers with a lot of memory (desktop
> computers) because you can easily increase the speed just by
> increasing the size. Desktop computers are also so fast nowadays that
> efficiency isn't an issue. It makes sense to just use an off-the-shelf
> solution and get on with your work --- as you so sarcastically pointed
> out. In a small-memory environment however --- such as on-chip
> compilation --- something like symtab would be a good idea. I have
> never read any book on algorithms that discussed ordering data by
> frequency of access, so I think that my algorithm is original, and the
> idea behind it as well.
I admit to only quickly looking at your code, so I may be missing
something. But it appears you are storing symbols in a binary tree,
with the ordering in the tree based on the frequency of use. If so,
that doesn't make any sense; the utility of a binary tree is to find
items in O(log2 N) time. But you aren't finding items using the key.
You're walking the tree, searching for them, presumably in order of
frequency of access. So storing in a binary tree doesn't appear to
buy you anything. You're moving items that are more frequently
accessed closer to the root, but you still have to iterate through the
tree-- in frequency order-- to find your symbols.
Consider a pathological case: All symbols have equal frequency of
access in some corpus. How would your data structure help finding the
symbol?
Also, if your concern is resource-constrained systems, you are wasting
memory having a left and right pointer for each node. If for some
reason storing in a binary tree ordered by frequency is a good idea
(and I don't think it is), then you could use a binary heap and
eliminate the left/right pointers. The recursive calls when finding a
key also don't strike me as design consideration consistent with
resource-constrained systems.
If what you're trying to do is a linear search by frequency of access,
then there are simpler and more efficient ways. A simple array sorted
by frequency of access can be built (one form of priority queue). Or
if you still think binary trees are hot, store data in a binary heap
instead and eliminate the left/right pointers. The only advantage of
a binary tree appears to be that you don't have to move as much around
in memory when you juggle positions-- you just relink pointers. But
while that speeds up insertion and rebalancing, it probably also works
against any data cache the processor may have.
Ignoring if your data structure is a good thing or not, I don't think
it's novel. The classic implementation of a Huffman compressor works
by taking the frequency of occurrence of each symbol (typically just a
character, but word-level compression is an obvious tweak) and then
storing it in a binary heap. As a binary heap is just a binary tree
with a shape constraint, I think that specific application points to
your idea not being novel.
> All of this is beside the point anyway. The purpose of a Factor/Forth
> comparison is not to demonstrate algorithms such as symtab. That might
> have been interesting back in the 1980s, but nobody cares about
> algorithms nowadays. Inventing a new algorithm in computer science is
> like inventing a new shape in geometry; it is not going to make you
> famous. Any book however, is going to contain example programs that
> aren't very interesting or useful (the Towers of Hanoi). Compared to
> programs such as this, symtab would be more likely to keep the reader
> awake, IMHO.
I think the reader of this "book" would be distracted, wondering in
what application this particular take on symbol tables would be
useful, compared to existing alternatives. In that sense, it is no
different from any artificial benchmark.
If you want to compare languages, I think it is going to be far better
to find a complete application (not just a library routine) that
stresses both Forth and Factor, showing strengths and weaknesses of
both. Then, implement that application code in idiomatic style for
both languages.
> The point of the book --- I won't draw out the suspense --- is that
> Forth would benefit by switching over to supporting quotations.
That's not a terribly controversial statement. Forth would benefit
from supporting a wide range of things, implemented as optional
wordsets people could selectively choose from.
> Forth is an extensible language --- read the brochure! Forth can steal
> the cool features (quotations) of other languages (Factor).
Read the brochure? Wow, I should really check out this Forth language
that you speak of. It sounds fascinating.
Forth can certainly "steal" features from other languages. But at
some point there is no point. Say you want to "steal" automatic
memory management, vector-centric processing, and a concise
mathematical notation? You can certainly spend your time adding those
features to Forth-- time you won't be spending on your application--
and in the end you can turn Forth into APL. Or... you could just use
APL. Now generalize my statement. The key is knowing if you've gone
to far, trying to force a different mindset onto Forth. I don't think
quotations push Forth too far into a mindset that causes a huge mental
impedance mismatch, but that presumably would be a big part of your
"book" to prove.
> This is
> not true of non-Forth languages. I wouldn't suggest to the C++
> community that they try to borrow quotations from Factor because they
> would just yawn and say: "Yeah, we'll be sure to mention your idea to
> Bjarne Stroustrup the next time that we see him."
I have yet to find any language that can't be extended in some way.
Sometimes this is external-- C++ started out as an extension to C
implemented by a preprocessor. The Qt folk want reflection and other
services C++ doesn't adequately support. They don't have to wait for
Bjarne-- they wrote a preprocessor. Sometimes extensions are
internal. Most every scripting language offers some form of string
evaluation, allowing code to be created dynamically or transformed.
Forth makes certain classes of extensions easy and even elegant. That
doesn't mean the option of extension of the language is closed to
programmers of (most) other languages.
> By comparison, in
> Forth you don't have to wait for somebody important (Charles Moore or
> Elizabeth Rather) to make the big decision to accept your idea --- you
> just go ahead and do it yourself. Extensibility is the ultimate cool
> feature!
Forth's extensibility is (sometimes) a lot like the lie that most
parents tell their children: that they can be anything they want when
they grow up. No, the reality is that except for those who are lucky
or exceptional, the set of choices one has suffers from numerous
constraints. But that crushing reality isn't something you want to
tell a wide-eyed adolescent. In the same way, Forth can be anything
that anyone wants it to be. But in reality, when you look at the
majority of what people do with Forth's extensibility, we aren't
talking about taking the language off into new and exotic
directions.
Hugh Aguilar
> I admit to only quickly looking at your code, so I may be missing
> something. But it appears you are storing symbols in a binary tree,
> with the ordering in the tree based on the frequency of use.
Nope, that's not what symtab does at all. LOL
> If you want to compare languages, I think it is going to be far better
> to find a complete application (not just a library routine) that
> stresses both Forth and Factor, showing strengths and weaknesses of
> both. Then, implement that application code in idiomatic style for
> both languages.
I do intend to have progressively large programs. If you can't figure
out symtab though, then why are you asking for a larger program?
> > The point of the book --- I won't draw out the suspense --- is that
> > Forth would benefit by switching over to supporting quotations.
>
> That's not a terribly controversial statement. Forth would benefit
> from supporting a wide range of things, implemented as optional
> wordsets people could selectively choose from.
Quotations are a pretty fundamental aspect of Factor. To introduce
quotations into Forth would change Forth significantly. Structure
words such as IF and WHILE would need to be rewritten. Also, the use
of quotations would change the style of programming. With quotations
the programmer is much more casual about writing words that use
vectored execution (nowadays called "closures"). In Forth you
generally write a colon word, then use ['] to grab its cfa to be
passed into the word that uses it. In Factor (or Forth with
quotations), you just put the quotation in the caller as a literal.
This is much easier and more readable, especially as most of those
quotations are extremely short one-liners.
The book is based upon Hegelian philosophy. The idea is that we have a
thesis (Forth) and an antithesis (Factor), that appear to be in
conflict with each other. Eventually however (by the end of the book),
we have a synthesis (Forth with quotations) --- the book gets
conflict, suspense, and a happy ending --- just like a novel.
Hegelian philosophy has a bad reputation these days because it is
closely related to "managed conflict." The best example of this is how
during WWII we had the communist USA and Russia (the thesis) versus
the fascist Germany and Japan (the antithesis), and now we have the
synthesis (the New World Order). The conflict was completely managed
so that no matter which side you joined, you were still going to lose.
Despite the bad reputation of managed conflict (being associated with
the New World Order), I still intend to use managed conflict in my
book. There really is no better technique available for controlling
people's minds, which is what all books strive to do. :-)
> > Forth is an extensible language --- read the brochure! Forth can steal
> > the cool features (quotations) of other languages (Factor).
>
> Read the brochure? Wow, I should really check out this Forth language
> that you speak of. It sounds fascinating.
I was just being flippant when I said "read the brochure" --- in an
effort to keep the tone light. Your extreme sarcasm earlier was a lot
more personal than I felt comfortable with. I'm all about defusing
confrontational situations with flippancy. :-)
> Forth can certainly "steal" features from other languages. But at
> some point there is no point. Say you want to "steal" automatic
> memory management, vector-centric processing, and a concise
> mathematical notation? You can certainly spend your time adding those
> features to Forth-- time you won't be spending on your application--
> and in the end you can turn Forth into APL. Or... you could just use
> APL. Now generalize my statement. The key is knowing if you've gone
> to far, trying to force a different mindset onto Forth. I don't think
> quotations push Forth too far into a mindset that causes a huge mental
> impedance mismatch, but that presumably would be a big part of your
> "book" to prove.
It is certainly true that we have a wide variety of languages, most of
which are oriented toward specific applications (math for APL). I'm
not much interested in learning a dozen languages though; I would
prefer to just stick with Forth.
I think that the introduction of quotations to Forth would improve
Forth, and would not be an "impedance mismatch." On the other hand,
there are a lot of aspects of Factor that I wouldn't recommend trying
to move over to Forth. I already mentioned that sequences are a
central aspect of Factor, but I don't see them as being important
enough to introduce into Forth. This is something that could be left
to the programmer to implement (my list program is an example of such
an implementation), or could be relegated to a library that the
programmer could optionally include in those programs that need such a
data structure. Things like this can be implemented in more than one
way, and it is up to the programmer to determine which way is best for
his application.
My complaint against Factor is that it includes everything but the
kitchen sink in the language. I like Forth better because it is a
"thin" language. That is why I'm discussing quotations here on c.l.f.
rather than just forgetting about Forth and focusing on Factor.
> I have yet to find any language that can't be extended in some way.
>
> Sometimes this is external-- C++ started out as an extension to C
> implemented by a preprocessor. The Qt folk want reflection and other
> services C++ doesn't adequately support. They don't have to wait for
> Bjarne-- they wrote a preprocessor. Sometimes extensions are
> internal. Most every scripting language offers some form of string
> evaluation, allowing code to be created dynamically or transformed.
I consider writing a preprocessor for a language to be grossly kludgy.
Ugh! As for string evaluation, I already made the point (see my post,
RfD :NAME) that I consider this to be kludgy too. Nobody agreed with
me there either though. :-(
> Forth's extensibility is (sometimes) a lot like the lie that most
> parents tell their children: that they can be anything they want when
> they grow up. No, the reality is that except for those who are lucky
> or exceptional, the set of choices one has suffers from numerous
> constraints. But that crushing reality isn't something you want to
> tell a wide-eyed adolescent. In the same way, Forth can be anything
> that anyone wants it to be. But in reality, when you look at the
> majority of what people do with Forth's extensibility, we aren't
> talking about taking the language off into new and exotic
> directions.
You're kind of a depressing person, aren't you?
John Passaniti
> > I admit to only quickly looking at your code, so I may be missing
> > something. But it appears you are storing symbols in a binary tree,
> > with the ordering in the tree based on the frequency of use.
>
> Nope, that's not what symtab does at all. LOL
As I wrote, I only quickly looked at your code, and from the patterns
and comments I saw in the code, it certainly appeared that is what you
were doing. However, as I'm obviously wrong, feel free to correct me.
> > If you want to compare languages, I think it is going to be far better
> > to find a complete application (not just a library routine) that
> > stresses both Forth and Factor, showing strengths and weaknesses of
> > both. Then, implement that application code in idiomatic style for
> > both languages.
>
> I do intend to have progressively large programs. If you can't figure
> out symtab though, then why are you asking for a larger program?
Again, I'll wait for your more detailed explanation. I certainly can
figure out code. I do have a problem with unclear code and with code
that has deceptive comments, especially when I'm skimming to get the
gist.
> The book is based upon Hegelian philosophy. The idea is that we have a
> thesis (Forth) and an antithesis (Factor), that appear to be in
> conflict with each other. Eventually however (by the end of the book),
> we have a synthesis (Forth with quotations) --- the book gets
> conflict, suspense, and a happy ending --- just like a novel.
Thanks for the warning. Sounds both pretentious and tedious. Put me
in the class of people who don't need narrative forms to get the
point. Simply state your case, provide some examples to prove your
point, and you're done, ready to tackle what's next. If you need
something more subtle or compelling than that, you're probably
targeting the wrong audience. Forth programmers tend to be pragmatic,
focused on understanding and solving the problem.
> I was just being flippant when I said "read the brochure" --- in an
> effort to keep the tone light. Your extreme sarcasm earlier was a lot
> more personal than I felt comfortable with. I'm all about defusing
> confrontational situations with flippancy. :-)
You chose to take it personally. I was addressing what you wrote, not
you. I don't know you.
> I consider writing a preprocessor for a language to be grossly kludgy.
> Ugh! As for string evaluation, I already made the point (see my post,
> RfD :NAME) that I consider this to be kludgy too. Nobody agreed with
> me there either though. :-(
I didn't say preprocessors weren't kludges. I did say that they allow
people to extend their language. Forth has elegance regarding
language extension, other languages less so to varying degrees. But a
lack of elegance doesn't mean one isn't able to extend a language.
String evaluation can certainly be a kludge as well. Depends on the
context. Other language extension techniques exist-- intercepting and
modifying the token stream, intercepting and modifying ASTs, macro
facilities, pattern matching/replacement, etc.
> You're kind of a depressing person, aren't you?
I guess that depends on perspective. As I favor an embrace of reality
instead of painting a happy face on everything, what some people call
depressing, I find empowering.