# RE: [stack] joy applications

## wtanksley@bigfoot.com — 2000-05-25 17:58:50

    From: stevan apter [mailto:apter@...]

     >i'm curious whether anyone here (or for that matter, anywhere)

    >has applied joy to a concrete problem.

     As I see it, Joy's intended purpose is teaching, explaining, and exploring

    concatenative theory.  One could use it for other purposes, but there are

    other languages better suited right now.

    I'd like it if one of the results of this group's work was a new Joy, one

    which was useful for concrete problems.  I'm more focussed on making a

    variant of Forth which is like Joy.

    -Billy

## stevan apter — 2000-05-26 01:17:08

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Thursday, May 25, 2000 1:58 PM

    Subject: RE: [stack] joy applications

    > From: stevan apter [mailto:apter@...]

    >

    > >i'm curious whether anyone here (or for that matter, anywhere)

    > >has applied joy to a concrete problem.

    >

    > As I see it, Joy's intended purpose is teaching, explaining, and exploring

    > concatenative theory.  One could use it for other purposes, but there are

    > other languages better suited right now.

    >

    > I'd like it if one of the results of this group's work was a new Joy, one

    > which was useful for concrete problems.  I'm more focussed on making a

    > variant of Forth which is like Joy.

    i haven't touched forth for 20 years, but isn't joy already the

    most joy-like forth?

    perhaps you can list what you see as the most important differences

    between the two languages.  in particular, what's missing from joy

    that keeps it from being "practical"?

    (btw, there is at least one other pure combinator language, viz.

    unlambda:  http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/

    but it is totally mad.)

    for me, the nature of a language isn't revealed until i understand

    how to write non-trivial programs with it.  having recently coded

    up the solitaire algorithm in k, i believe i see how i would go about

    it in joy, and the prospect is rather daunting!

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Old school buds here:

    > http://click.egroups.com/1/4057/6/_/_/_/959277482/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## wtanksley@bigfoot.com — 2000-05-26 17:20:29

    From: stevan apter [mailto:apter@...]

    [I said:]

     >> I'd like it if one of the results of this group's work was a

    >> new Joy, one

    >> which was useful for concrete problems.  I'm more focussed

    >> on making a variant of Forth which is like Joy.

    >i haven't touched forth for 20 years, but isn't joy already the

    >most joy-like forth?

     It's barely like Forth at all.  And if it was, it would be the most

    Forth-like Joy, not the most Joy-like Forth.  For example, I don't believe

    it's possible to make a Forth with garbage collection.  See below for why.

     >perhaps you can list what you see as the most important differences

    >between the two languages.  in particular, what's missing from joy

    >that keeps it from being "practical"?

     Keep in mind that although Forth is indisputably practical, its path to

    practicality is NOT the only possible path -- that's why I'm thinking of

    writing _two_ languages.

    The first language will follow the Forth path: pure simplicity, with

    everything completely controlled by the programmer, and no optimization

    without the programmer's command.  This pure simplicity would be hell in an

    applicative language (such as C); however, Forth demonstrates that within

    certain limits, concatenativity allows for more simplicity.  I have to find

    out what those limits are, and how Forth breaks them (if indeed it does go

    too far).

    The second language will follow the traditional functional languages path:

    every possible means taken to leave the programmer with as little to think

    about as possible.  Garbage collection, sophisticated type inferencing

    (although the Forthlike language will have at least primitive static type

    polymorphism), many primitive data types (some of which are unreasonable

    without GC), and so on.

     >(btw, there is at least one other pure combinator language, viz.

    >unlambda:  http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/

    >but it is totally mad.)

     But unlambda is applicative, not concatenative.  :-)  No, for combinator

    languages I'll stick with Joy, Forth, and J (perhaps I'll learn K someday).

     >for me, the nature of a language isn't revealed until i understand

    >how to write non-trivial programs with it.  having recently coded

    >up the solitaire algorithm in k, i believe i see how i would go about

    >it in joy, and the prospect is rather daunting!

     This makes sense.

    -Billy

## stevan apter — 2000-05-27 01:10:09

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Friday, May 26, 2000 1:20 PM

    Subject: RE: [stack] joy applications

    :

    >

    > Keep in mind that although Forth is indisputably practical, its path to

    > practicality is NOT the only possible path -- that's why I'm thinking of

    > writing _two_ languages.

    >

    > The first language will follow the Forth path: pure simplicity, with

    > everything completely controlled by the programmer, and no optimization

    > without the programmer's command.  This pure simplicity would be hell in an

    > applicative language (such as C); however, Forth demonstrates that within

    > certain limits, concatenativity allows for more simplicity.  I have to find

    > out what those limits are, and how Forth breaks them (if indeed it does go

    > too far).

    >

    > The second language will follow the traditional functional languages path:

    > every possible means taken to leave the programmer with as little to think

    > about as possible.  Garbage collection, sophisticated type inferencing

    > (although the Forthlike language will have at least primitive static type

    > polymorphism), many primitive data types (some of which are unreasonable

    > without GC), and so on.

    >

    my approach to pls is narrowly practical.  i'll work in the one

    which offers the best combination of speed, simplicity, size, and

    expressivity.  forth doesn't cut it - too slow by far.  j has

    many lovely features, but at critical points remains too closely

    tied to the boxed array tradition of APL.  (as a result, j code is

    full of encloses and discloses, sometimes explicit, sometimes

    silently shunted through operators which dart into the box,

    do some work, then dart out.)

    i evaluate and compare pls by letting them fight it out on the

    battlefield of problems (i just saw _gladiator_, so i'll be in

    martial metaphor mode for a few days).  the art of picking

    good problems is a subtle one, but there is, we can be sure,

    an inexhaustible supply of them.

## Massimo Dentico — 2000-05-27 03:16:04

    stevan apter wrote:

     > [...]

    > my approach to pls is narrowly practical.  i'll work in the one

    > which offers the best combination of speed, simplicity, size, and

    > expressivity.  forth doesn't cut it - too slow by far.

    > [...]

     What do you intend for slow? As program execution speed?

    Or as development cycle? Or what exactly? And slow regards

    to what?

    Forth's implementation techniques are various. A modern

    Forth system often produce machine code (or native code

    in Forth community) without sacrificing its extremely

    interactive nature, which help to achieve a short

    development cycle.

    But even a "traditional" implementation technique like

    threaded code [1] can produce respectable results [2]

    (this paper is about the Virtual Machine of CAML and

    Objective CAML [3], dialects of ML):

    "Abstract

    [...]

       We demonstrate that a few simple techniques make it

    possible to create highlyportable dynamic translators that

    can attain as much as 70% the performance of optimized C

    for certain numerical computations. Translators based on

    such techniques can offer respectable performance without

    sacrificing either the simplicity or portability of much

    slower ``pure'' bytecode interpreters."

    References

    [1] Anton Ertl, "Threaded Code", Forth Research at Institut für

        Computersprachen

        - http://www.complang.tuwien.ac.at/forth/threaded-code.html

    [2] I. Piumarta and F. Riccardi. "Optimizing direct threaded code

        by selective inlining". ACM SIGPLAN PLDI '98 Conference,

        pages 291-300.

        - http://citeseer.nj.nec.com/piumarta98optimizing.html

    [3] "The Caml language"

        - http://pauillac.inria.fr/caml/

    --

    Massimo Dentico

## stevan apter — 2000-05-27 15:02:38

    ----- Original Message -----

    From: Massimo Dentico <m.dentico@...>

    To: <concatenative@egroups.com>

    Sent: Friday, May 26, 2000 11:16 PM

    Subject: Re: [stack] joy applications

    > stevan apter wrote:

    > > [...]

    > > my approach to pls is narrowly practical.  i'll work in the one

    > > which offers the best combination of speed, simplicity, size, and

    > > expressivity.  forth doesn't cut it - too slow by far.

    > > [...]

    >

    > What do you intend for slow? As program execution speed?

    > Or as development cycle? Or what exactly? And slow regards

    > to what?

    both.

    i'm willing to have my mind changed, but it's going to take

    concrete examples to do so.  i'm not a computer scientist, so

    theoretical arguments don't work well on me.

    if you're a forth programmer, you can try your hand at the

    following problem.  btw, it's a "real" one -- several years

    ago, we needed something to demonstrate performance on olap-

    style calculations for one of our potential clients.

    "the rollup problem"

    you are given three (integer) inputs:

        Records

        Levels

        Nodes

    from which you must compute three outputs:

        Tree

        Trans

        Rollup

    Tree is some representation of a tree whose maximum path-length

    from the root is given by Levels.  every non-terminal node in Tree

    has 2-to-Nodes many nodes.

    Trans is a table of transactions for the leaves of Tree.  Trans has

    two fields:  leaf and value (a floating point number between 0 and 1).

    the cardinality of Trans is given by Records.  Trans depends on both

    Records and Tree.

    Rollup is a table which rolls up the transactions in Trans according

    to Tree.  Rollup contains four fields:  node, count, sum, avg.  the

    cardinality of Rollup is the number of nodes in Tree.  Rollup depends

    on Tree and Trans.

    the functional dependencies among the six objects are:

        Tree <- Levels, Nodes

        Trans <- Tree, Records

        Rollup <- Tree, Trans

    typical starting values for the parameters:

        Levels:5

        Nodes:10

        Records:1000000

    the customer wants to see the six objects displayed in a window:

        Levels: ____      Nodes: _____       Records: ________

        Tree              Trans              Rollup

         parent child      leaf value         node count sum avg

         ------ -----      ---- -----         ---- ----- --- ---

            :     :          :    :             :    :    :   :

    so e.g. when you enter a new value for Levels or Nodes, Tree

    recomputes, which causes Trans to recompute, which causes Rollup

    to recompute; and when you re-enter a new value for Records,

    Trans recomputes, which causes Rollup to recompute.

    here is what i look for in any solution:

    - how small is the code?

    - how long did it take to write?

    - what's the performance like?

    - does it scale (e.g. to 20 gig of transactions)?

    - how adaptable is the code (e.g. change the tree to a dag)?

    have fun!

## stevan apter — 2000-05-27 15:31:33

    :

     > "the rollup problem"

     :

     > here is what i look for in any solution:

    >

    > - how small is the code?

    > - how long did it take to write?

    > - what's the performance like?

    > - does it scale (e.g. to 20 gig of transactions)?

    > - how adaptable is the code (e.g. change the tree to a dag)?

    >

     let me add the following criteria:

    - starting from scratch -- a standard machine out of the

      box -- how much work to install the language software?

    arguing from purely theoretical considerations, we are

    often led to overlook the time and cost which goes into

    maintaining the environment for our solutions.

    for example, i note that the swiftforth installer, from

    forth inc, weighs in at 4.5 meg -- 4.5 meg?! -- for a

    programming language?!

## Samuel A. Falvo II — 2000-05-27 17:33:13

    > > What do you intend for slow? As program execution speed?

    > > Or as development cycle? Or what exactly? And slow regards

    > > to what?

    >

    > both.

    >

    > i'm willing to have my mind changed, but it's going to take

    > concrete examples to do so.  i'm not a computer scientist, so

    > theoretical arguments don't work well on me.

     I recommend posting this to a community of programmers who perhaps know

    Forth better than any of us on this list ever will hope to achieve --

    comp.lang.forth.  There, you have a direct interface with the likes of

    Anton Ertl(sp?), Bernd Paysan, and Neal Bridges, as well as the commercial

    Forth vendors, all of whom are very well familiar with native-code Forth

    implementations.  Hell, even Chuck Moore has been known to pop his head in

    once in a great blue moon or two.

    The results may or may not demonstrate your claims; frankly I don't care.

    But it'd be interesting to see the results nonetheless.

## Samuel A. Falvo II — 2000-05-27 17:37:57

    On Sat, 27 May 2000, stevan apter wrote:

     > for example, i note that the swiftforth installer, from

    > forth inc, weighs in at 4.5 meg -- 4.5 meg?! -- for a

    > programming language?!

     That's all?

    How about GCC/binutils?

    How about VisualBASIC?

    How about Microsoft Visual C++?

    How about Delphi?

## stevan apter — 2000-05-27 19:18:21

    ----- Original Message -----

    From: Samuel A. Falvo II <kc5tja@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, May 27, 2000 1:37 PM

    Subject: Re: [stack] joy applications

    > On Sat, 27 May 2000, stevan apter wrote:

    > > for example, i note that the swiftforth installer, from

    > > forth inc, weighs in at 4.5 meg -- 4.5 meg?! -- for a

    > > programming language?!

    >

    > That's all?

    >

    > How about GCC/binutils?

    > How about VisualBASIC?

    > How about Microsoft Visual C++?

    > How about Delphi?

    if the total pl won't fit comfortably in an email message,

    something is wrong.  i should think that the forth creed

    of minimalism would preclude this kind of bloat.

## Massimo Dentico — 2000-05-27 21:14:53

    stevan apter wrote:

     >

    > ----- Original Message -----

    > From: Massimo Dentico <m.dentico@...>

    > To: <concatenative@egroups.com>

    > Sent: Friday, May 26, 2000 11:16 PM

    > Subject: Re: [stack] joy applications

    >

    > > stevan apter wrote:

    > > > [...]

    > > > my approach to pls is narrowly practical.  i'll work in the one

    > > > which offers the best combination of speed, simplicity, size, and

    > > > expressivity.  forth doesn't cut it - too slow by far.

    > > > [...]

    > >

    > > What do you intend for slow? As program execution speed?

    > > Or as development cycle? Or what exactly? And slow regards

    > > to what?

    >

    > both.

    >

    > i'm willing to have my mind changed, but it's going to take

    > concrete examples to do so.  i'm not a computer scientist, so

    > theoretical arguments don't work well on me.

     Nor I am a computer scientist. I don't have even a degree.

    I have only a diploma, in informatics, of technical high school

    (the acronym in italian is I.T.I.S. that in English means something

    like Technical Industrial State Institute). This kind of school

    has both theoretical and pratical (even manual) teaching.

    Moreover I was an hobbyst, so my background about computers is

    quite pratical. This doesn't mean that I disdain theory.

    In any case the referenced paper is quite dense of measurements,

    with the obvious limitations of benchmarks.

     > if you're a forth programmer,

     I'm *absolutely* not an experienced Forth programmer.

    I'm completely unsatisfied from the current state of IT. My experience

    is that both actual hardware and software tools complicates solutions

    to real world problems.

    In my opinion this is caused *exactly* by the plethora of ad-hoc

    solutions, which is given by insufficient problem analysis, generalization

    and theorization. The results are well known: bloatware, scarce performances,

    long development cycles. The proposals to these problems often add

    complication to complication and they don't solve anything.

    So some time ago I'm beginning my research toward something of more

    satisfactory than the "mainstream" practice in this industry.

    I'm looking toward all the directions, in particular in the research

    field, in which is possible to find new approaches.

    It's thanks to the Tunes Project that I have rediscovered Forth.

    Previously (around 1985) I had read a bad introduction that dissuaded

    me to study it. Even if Charles Moore is a total pragmatic, or thanks

    to this, with Forth he developed a tool and a philosophy of programming

    attractive also 30 years later of going in public, more advanced than

    most tools in use today (specifically C and all C-based so-called

    "Operating Systems").

    Concepts like Open Implementation (compiler/interpreter open

    to application programmers), metaprogramming, Domain Specific

    Languages have been rediscovered or reconsidered in the research

    field during the 90's, all presents in Forth as tool for everyday

    programming, perhaps in primitive form, in the 70's.

     > you can try your hand at the following problem.  btw, it's a "real" one

    > -- several years ago, we needed something to demonstrate performance on

    > olap-style calculations for one of our potential clients.

    > [snipped the "real" problem]

    > - how small is the code?

    > - how long did it take to write?

    > - what's the performance like?

    > - does it scale (e.g. to 20 gig of transactions)?

    > - how adaptable is the code (e.g. change the tree to a dag)?

     Are you kidding? I'm no more an hobbyst nor a student and an OLAP-like

    system is not exactly a simple exercise to solve sporadically in the spare

    time, particularly with your requirements, and as I said I'm not an

    experienced Forth programmer. No one here is saying that Forth is

    "magical". I could try to think a little bit about a solution, but

    I don't promise anything.

     > let me add the following criteria:

    >

    > - starting from scratch -- a standard machine out of the

    >  box -- how much work to install the language software?

    >

    > arguing from purely theoretical considerations, we are

    > often led to overlook the time and cost which goes into

    > maintaining the environment for our solutions.

     I think a simple, little, stand-alone Forth-like system with

    a TCP/IP stack could be part of the solution: not limited by the

    host OS and at the same time open to the outer world. Something

    like COLDFIRE FORTH by Colour Vision Systems [1], but in another

    context.

     > stevan apter

    > > Samuel A. Falvo II

    > > > stevan apter

    > > > for example, i note that the swiftforth installer, from

    > > > forth inc, weighs in at 4.5 meg -- 4.5 meg?! -- for a

    > > > programming language?!

    >

    > > That's all?

    >

    > > How about GCC/binutils?

    > > How about VisualBASIC?

    > > How about Microsoft Visual C++?

    > > How about Delphi?

    >

    > if the total pl won't fit comfortably in an email message,

    > something is wrong.  i should think that the forth creed

    > of minimalism would preclude this kind of bloat.

     Exactly, bloat induced by the OS and the hardware. Forth is not

    a language in traditional sense, it's much more a whole system,

    a meta-system. Moore wrote in his seminal paper on Forth [2]:

    ----------------------------------------------------------------------------

    What is FORTH?

    [...]

    The software provided with large conmputers supplies a heirarchy of

    languages:

    - the assembler defines the language for describing the compiler and

      supervisor;

    - the supervisor the language for job control;

    - the compiler the language for application programs;

    - the application program the language for its input.

    The user may not know, or know of, all these languages; but they are

    there. They stand between him and the computer, imposing their restrictions

    on what he can do and what it will cost.

    And cost it does, for this vast heirarchy of languages reguires a huge

    investment of man and machine time to produce, and an equally large effort

    to maintain. The cost of documenting these programs and of reading the

    documentation is enormous. And after all this effort the programs are still

    full of bugs, awkward to use and satisfying to no one.

    We maintain that this multi-level nightmare is precisely that.

    We place the blame upon the lack of a suitable language. FORTH provides

    a suitable language, and by using it an order of magnitude improvement

    in the cost, effort and efficiency of providing a terminal interface.

    [...]

    ----------------------------------------------------------------------------

    His work since the 80's is to address the bloat in hardware. In a recent

    essay is explained quite well his philosophy [3], but probably you know all

    that.

    Forth for me is a starting point, a model, not an end in itself, otherwise

    I would not be here to discuss about another system. Moore himself don't

    think to Forth as a language to standardize and "freeze".

    In any case, I'm not a fanatic of "Do-It-Yourself": if I'm thinking

    to partecipate in the development of yet another system is because

    I have much troubles with the available systems, no matter how much

    time I put into the study of such monsters.

    References

    [1] "COLDFIRE FORTH Version 0.1"

        - http://forth.cx/

        - http://forth.cx/tcpippaper/tcp_ip.html

        by Color Vision Systems

    [2] Charles H. Moore e Geoffrey C. Leach, "Forth - a Language for Interactive

        Computing", 1970

        - http://www.ultratechnology.com/4th_1970.html

    [3] Jeff Fox, "Thoughtful Programming"

        - http://www.ultratechnology.com/forth.htm

    --

    Massimo Dentico

## stevan apter — 2000-05-27 22:20:38

    ----- Original Message -----

    From: Massimo Dentico <m.dentico@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, May 27, 2000 5:14 PM

    Subject: Re: [stack] joy applications

    >

    > > you can try your hand at the following problem.  btw, it's a "real" one

    > > -- several years ago, we needed something to demonstrate performance on

    > > olap-style calculations for one of our potential clients.

    > > [snipped the "real" problem]

    >

    > > - how small is the code?

    > > - how long did it take to write?

    > > - what's the performance like?

    > > - does it scale (e.g. to 20 gig of transactions)?

    > > - how adaptable is the code (e.g. change the tree to a dag)?

    >

    > Are you kidding?

    hell no!

    step 1:  go to www.kx.com, download k (k is about 150k, and

    should install instantaneously.  i'd attach the interpreter,

    but egroups would complain ;-))

    step 2:  paste the code below into a text file called ru.k

    step 3:  from a command prompt (or the equivalent), say

                k ru

    it's important to note that ru.k is built entirely from

    primitive list-oriented building blocks.  it took a few

    hours to write.  it scales to available virtual memory,

    at which point you need to modify couple of lines to allow

    generation to and retrieval from disk-based blocks, which

    is trivial.  execution involving anything up to 5 million

    records (depending on how much vm you've got, how fast

    your processor is, &c.) takes less than a second.

    comments available on request. ;-)

    ---- paste the following into ru.k (don't include this line!) ----

    Records:1000000

    Levels:5

    Nodes:10

    Tree..d:".+(`child`parent

                +{x@<x}@+{[l;n;p;c]

                           (c;p),' :[l&(~c)|()_draw l+1

                                     ,'/_f[l-1;n;c]'{x;:I+:1}'!2+()_draw n

                                     2#,!0]}[Levels;Nodes;0;I::0])"

    Trans..d:".((`leaf;c Records _draw#c:&Tree[`child]_lin Tree`parent)

                (`value;Records _draw 0))"

    Rollup..d:"

     p:i\\'!#i:Tree[`child]?/:Tree`parent

     g:Tree[`child]?/:Trans`leaf

     f:{@[x;p;y;@[x;g;y;z]]}

     s:f[(#i)#0.;+;Trans`value]

     c:f[(#i)#0;+;1]

     .((`node;Tree`child);(`sum;s);(`count;c);(`avg;s%c))"

    .k..c:`form

    .k..a:(`Levels`Nodes`Records

           `Tree`Trans`Rollup)

    `show$`.k

## Samuel A. Falvo II — 2000-05-27 22:32:35

    On Sat, 27 May 2000, stevan apter wrote:

     > if the total pl won't fit comfortably in an email message,

    > something is wrong.  i should think that the forth creed

    > of minimalism would preclude this kind of bloat.

     Well, I hate to burst your utopian bubble, but this is the real world.  Do

    not confuse the language for the supporting libraries. A basic C compiler

    can be quite tiny, but it doesn't in any way impact the size of the C

    runtime environment, which consists of the linker libraries required make

    your programs work.  Ditto for Forth, ML, and yes, even Joy.  Every

    programming language has to have some kind of run-time infrastructure.  If

    the target on which that infrastructure runs is non-trivial (as we all

    know Windows is the antithesis of all things "simple"), then you must also

    expect the run-time environment to also be non-trivial.  This is

    particularly true of the run-time environments that provide features which

    are not considered "standard." SwiftForth, after all, can be used to build

    full-blown Win32 applications.  As a result, it necessarily requires the

    Win32 run-time environment, which provides a mapping for the C-based Win32

    API to the Forth environment, including any arbitrary DLLs the user may

    want to use in his software.

    We're not dealing with CP/M or DOS anymore.

## Samuel A. Falvo II — 2000-05-27 22:59:57

    On Sat, 27 May 2000, stevan apter wrote:

     > Tree..d:".+(`child`parent

    >             +{x@<x}@+{[l;n;p;c]

    >                        (c;p),' :[l&(~c)|()_draw l+1

    >                                  ,'/_f[l-1;n;c]'{x;:I+:1}'!2+()_draw n

    >                                  2#,!0]}[Levels;Nodes;0;I::0])"

     Oh my God!  I never thought it possible!  I've actually seen a programming

    language that's harder to read than Perl!! 8)

## stevan apter — 2000-05-27 23:21:25

    ----- Original Message -----

    From: Samuel A. Falvo II <kc5tja@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, May 27, 2000 6:32 PM

    Subject: Re: [stack] joy applications

    > On Sat, 27 May 2000, stevan apter wrote:

    > > if the total pl won't fit comfortably in an email message,

    > > something is wrong.  i should think that the forth creed

    > > of minimalism would preclude this kind of bloat.

    >

    > Well, I hate to burst your utopian bubble, but this is the real world.

    [snip]

    yes, i live there too.  my firm (of which i am a principal) uses k

    to write distributed monte-carlo simulations for financial institutions

    such as banks and insurance companies.  typically, these simulations

    involves hundreds of thousands of nodes, at each of which an lp must

    be performed.  a typical simulation is spread out over several dozen

    processors and generates 20-30 gig.  it must complete in reasonable

    time (10-20 minutes) and produce a result which can be analyzed

    interactively through a customized gui.  the code is completely portable:

    it runs on windows, linux, solaris -- in fact, on any platform to which

    k has been ported (see www.kx.com for the official list).

    the application (about 100k) is written in 100% pure interpreted k and

    runs at c speeds.  k itself accounts for another 150k.  i can fit

    the interpreter, the environment (gui + ipc + native file system), and

    the application in an email message.

    >

    > We're not dealing with CP/M or DOS anymore.

    never used 'em.

    >

    >

    > ------------------------------------------------------------------------

    > CLICK HERE AND START SAVING ON LONG DISTANCE BILLS TODAY!

    > http://click.egroups.com/1/4125/6/_/_/_/959466758/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-05-27 23:22:55

    ----- Original Message -----

    From: Samuel A. Falvo II <kc5tja@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, May 27, 2000 6:59 PM

    Subject: Re: [stack] joy applications

    > On Sat, 27 May 2000, stevan apter wrote:

    > > Tree..d:".+(`child`parent

    > >             +{x@<x}@+{[l;n;p;c]

    > >                        (c;p),' :[l&(~c)|()_draw l+1

    > >                                  ,'/_f[l-1;n;c]'{x;:I+:1}'!2+()_draw n

    > >                                  2#,!0]}[Levels;Nodes;0;I::0])"

    >

    > Oh my God!  I never thought it possible!  I've actually seen a programming

    > language that's harder to read than Perl!! 8)

    gee, i've never heard that before. ;-)

    seriously though, we think k is far more readable than j!

## stevan apter — 2000-05-27 23:31:55

    ----- Original Message -----

    From: stevan apter <apter@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, May 27, 2000 7:21 PM

    Subject: Re: [stack] joy applications

    > the application (about 100k)

    a slight over-estimate on my part.  the application contains 607 lines

    of code (15209 bytes).  of course, the documentation is about 10x that.

## Samuel A. Falvo II — 2000-05-27 23:43:12

    On Sat, 27 May 2000, stevan apter wrote:

     > gee, i've never heard that before. ;-)

    > seriously though, we think k is far more readable than j!

     Oooo...I don't know.  It's a toss-up at this point.  ;)

## Massimo Dentico — 2000-05-28 00:28:39

    stevan apter wrote:

     >

    > ----- Original Message -----

    > From: Massimo Dentico <m.dentico@...>

    > To: <concatenative@egroups.com>

    > Sent: Saturday, May 27, 2000 5:14 PM

    > Subject: Re: [stack] joy applications

    >

    > >

    > > > you can try your hand at the following problem.  btw, it's a "real" one

    > > > -- several years ago, we needed something to demonstrate performance on

    > > > olap-style calculations for one of our potential clients.

    > > > [snipped the "real" problem]

    > >

    > > > - how small is the code?

    > > > - how long did it take to write?

    > > > - what's the performance like?

    > > > - does it scale (e.g. to 20 gig of transactions)?

    > > > - how adaptable is the code (e.g. change the tree to a dag)?

    > >

    > > Are you kidding?

    >

    > hell no!

    >

    > step 1:  go to www.kx.com, download k (k is about 150k, and

    > should install instantaneously.  i'd attach the interpreter,

    > but egroups would complain ;-))

    >

    > step 2:  paste the code below into a text file called ru.k

    >

    > step 3:  from a command prompt (or the equivalent), say

    >

    >             k ru

    >

    > it's important to note that ru.k is built entirely from

    > primitive list-oriented building blocks.  it took a few

    > hours to write.  it scales to available virtual memory,

    > at which point you need to modify couple of lines to allow

    > generation to and retrieval from disk-based blocks, which

    > is trivial.  execution involving anything up to 5 million

    > records (depending on how much vm you've got, how fast

    > your processor is, &c.) takes less than a second.

    >

    > comments available on request. ;-)

    >

    > ---- paste the following into ru.k (don't include this line!) ----

    > [.. snipped ..]

     Ok, my worry was about the dimension of the data-set. OLAP application

    of which I have heard to speak involves usually TBytes (T = Tera = 10 ^ 12),

    if not PBytes (P = Peta = 10 ^ 15), of data.

    Apologize me, I have misunderstood what you have written, I have

    understood the data products by 20*10^9 (giga) transactions and not 20 GBytes

    of data; estimating 1 KB of data per transaction, the data-set is 20 TB ...

    managing this amount of data in reasonable time are not peanuts.

    In any case, real advantage is the direct disk block access (implicit

    via virtual memory or explicit as you say) a characteristic that has

    Forth too. Probably, with a K-like embedded in Forth (even as syntax

    thanks to its extendibility), it could achieve the same performace/compactness

    ratio. Portability of Forth machine is trivial, the interface with other

    features of the host, like GUI or IPC, is not so trivial but feasible,

    as REBOL or K show. Probably selecting carefully a subset of these features.

    But these are only my speculations.

    Anyway, this thread originated from your statement that Forth is slow.

    Are you so sure that the implementation techniques of K and Forth

    are completely unrelated?

    --

    Massimo Dentico

## Massimo Dentico — 2000-05-28 00:56:29

    Massimo Dentico wrote:

     >

    > stevan apter wrote:

    > > let me add the following criteria:

    > >

    > > - starting from scratch -- a standard machine out of the

    > >  box -- how much work to install the language software?

    > >

    > > arguing from purely theoretical considerations, we are

    > > often led to overlook the time and cost which goes into

    > > maintaining the environment for our solutions.

    >

    > I think a simple, little, stand-alone Forth-like system with

    > a TCP/IP stack could be part of the solution: not limited by the

    > host OS and at the same time open to the outer world. Something

    > like COLDFIRE FORTH by Colour Vision Systems [1], but in another

    > context.

     ... because we all know how is simple, pratical, inexpensive to

    install and manage a box with Windows, NT, Unix or another

    fat, general purpose OS ... :o)

    A stand-alone, dedicated Forth system could run on really cheap

    machines in an efficient way (infact it is used in emebedded

    and real-time environments) ... but computer retailers would

    not be very happy.

    --

    Massimo Dentico

## stevan apter — 2000-05-28 01:08:27

    ----- Original Message -----

    From: Massimo Dentico <m.dentico@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, May 27, 2000 8:28 PM

    Subject: Re: [stack] joy applications

    > stevan apter wrote:

    > >

    > > ----- Original Message -----

    > > From: Massimo Dentico <m.dentico@...>

    > > To: <concatenative@egroups.com>

    > > Sent: Saturday, May 27, 2000 5:14 PM

    > > Subject: Re: [stack] joy applications

    > >

    > > >

    > > > > you can try your hand at the following problem.  btw, it's a "real" one

    > > > > -- several years ago, we needed something to demonstrate performance on

    > > > > olap-style calculations for one of our potential clients.

    > > > > [snipped the "real" problem]

    > > >

    > > > > - how small is the code?

    > > > > - how long did it take to write?

    > > > > - what's the performance like?

    > > > > - does it scale (e.g. to 20 gig of transactions)?

    > > > > - how adaptable is the code (e.g. change the tree to a dag)?

    > > >

    > > > Are you kidding?

    > >

    > > hell no!

    > >

    > > step 1:  go to www.kx.com, download k (k is about 150k, and

    > > should install instantaneously.  i'd attach the interpreter,

    > > but egroups would complain ;-))

    > >

    > > step 2:  paste the code below into a text file called ru.k

    > >

    > > step 3:  from a command prompt (or the equivalent), say

    > >

    > >             k ru

    > >

    > > it's important to note that ru.k is built entirely from

    > > primitive list-oriented building blocks.  it took a few

    > > hours to write.  it scales to available virtual memory,

    > > at which point you need to modify couple of lines to allow

    > > generation to and retrieval from disk-based blocks, which

    > > is trivial.  execution involving anything up to 5 million

    > > records (depending on how much vm you've got, how fast

    > > your processor is, &c.) takes less than a second.

    > >

    > > comments available on request. ;-)

    > >

    > > ---- paste the following into ru.k (don't include this line!) ----

    > > [.. snipped ..]

    >

    > Ok, my worry was about the dimension of the data-set. OLAP application

    > of which I have heard to speak involves usually TBytes (T = Tera = 10 ^ 12),

    > if not PBytes (P = Peta = 10 ^ 15), of data.

    >

    > Apologize me, I have misunderstood what you have written, I have

    > understood the data products by 20*10^9 (giga) transactions and not 20 GBytes

    > of data; estimating 1 KB of data per transaction, the data-set is 20 TB ...

    > managing this amount of data in reasonable time are not peanuts.

    agreed.  commercial olap products (arbor essbase for example) claim

    to scale to multi-terabyte data, but experience (viz. mine)

    shows the practical limits to be much lower (for example, there is a

    massive explosion of the data during the precalculation phase.)  the

    only petabyte database i know of is at cern, and i have no idea what

    they're using to analyze it.  in any case, 100 gig databases are still

    rare in the world of commerce, and that's probably for the best, since

    all the commercial rdbms products choke at well under this limit, but

    pose little difficulty for 32 bit k, and none at all for the 64 bit

    version.  ;-)

    >

    > In any case, real advantage is the direct disk block access (implicit

    > via virtual memory or explicit as you say) a characteristic that has

    > Forth too. Probably, with a K-like embedded in Forth (even as syntax

    > thanks to its extendibility), it could achieve the same performace/compactness

    > ratio. Portability of Forth machine is trivial, the interface with other

    > features of the host, like GUI or IPC, is not so trivial but feasible,

    > as REBOL or K show. Probably selecting carefully a subset of these features.

    > But these are only my speculations.

    until joy came to my attention, i had little interest in stack-oriented

    languages (at least, since 1980, when i wrote a lisp interpreter in neon).

    i still find joy somewhat cumbersome, except, as billy has said, as a

    concrete system for exploring the ideas of combinator theory (although

    i have been thinking about how to program the pontifex algorithm in

    joy, and it seems to me that the way to do it is to implement a few of

    the k list operators, such as 'cut').

    >

    > Anyway, this thread originated from your statement that Forth is slow.

    > Are you so sure that the implementation techniques of K and Forth

    > are completely unrelated?

    well, they're quite different, as far as i know.  billy is probably

    best equipped to answer here, as he's familiar with both forth and

    the vector languages of which k is one.  in any case, the question

    regarding forth which is uppermost in my mind is whether it is

    feasible to even contemplate writing something like an rdbms in

    that language.  if it is, why hasn't it been done?  is this a cultural

    thing?

    >

    > --

    > Massimo Dentico

    >

    > ------------------------------------------------------------------------

    > Missing old school friends?  Find them here:

    > http://click.egroups.com/1/4055/6/_/_/_/959473444/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-05-28 02:20:07

    ----- Original Message -----

    From: Samuel A. Falvo II <kc5tja@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, May 27, 2000 7:43 PM

    Subject: Re: [stack] joy applications

    > On Sat, 27 May 2000, stevan apter wrote:

    >

    > > gee, i've never heard that before. ;-)

    > > seriously though, we think k is far more readable than j!

    >

    > Oooo...I don't know.  It's a toss-up at this point.  ;)

    (grumble)

    the tree function has been bothering me for a while.  thinking it

    through, i believe the following is somewhat more satisfactory.

    for one thing, it involves less code.  for another, it's slightly

    faster and uses less space.  (the original tree generation function

    used recursion to sprout nodes; this version computes the tree

    structure directly, in one vector calculation.)

    the drawback is that uses a less intuitive representation of trees.

    instead of the usual relational form:

            parent    child

            ------    -----

              :         :

    i use a "parent vector".  for example, if the tree is:

    0

    -1

    --2

    --3

    -4

    --5

    ---6

    ---7

    ---8

    --9

    --10

    then the parent vector representation is a vector p:

        0 0 1 1 0 4 5 5 5 4 9

    i.e. p[i] is the parent of i (where the root 0 is self-parenting).

    bear in mind what this little bit of code is doing:  it's generating

    a random well-formed tree with 5000 nodes; from that, a table of

    a million random transactions on the leaves of the tree; and from

    those, a table of hierachical aggregations, where count, sum, and

    average are "rolled up" the tree.  that's a fair amount of logic,

    and a fair amount of computation.  we're not taking advantage of any

    non-list types or fancy oo techniques to structure the calculations.

    --

    Records:1000000

    Nodes:5000

    N..d:"!Nodes"

    P..d:"{x@<x}0,1+(_.2*Nodes)_draw-Nodes-1"

    C..d:"N _dvl P"

    Tree..d:"@[,/(-':P,Nodes)#'P;1_ P;:;-1_ P]"

    Trans..d:".((`leaf;C Records _draw#C);(`value;Records _draw 0))"

    Rollup..d:"

     p:Tree\\'N

     g:N?/:Trans`leaf

     f:{@[x;p;y;@[x;g;y;z]]}

     s:f[Nodes#0.;+;Trans`value]

     c:f[Nodes#0;+;1]

     .((`node;N);(`sum;s);(`count;c);(`avg;s%c))"

    .k..c:`form

    .k..a:(`Nodes`Records;`Tree`Trans`Rollup)

    `show$`.k

    --

    one of the things i hope to learn from joy is whether there are

    combinators which can be usefully added to k.  as you may have

    gathered, k is a "mixed" language:  we make heavy use of lambdas

    { ... }, and combine them with a couple of elementary combinators:

    composition, each, over, scan, and prior (more about these in a

    future message).  j is also a vector language, but they have

    taken a different approach:  unlike k, functions are not first

    class, but there are lots and lots of combinators.

    >

    >

    > ------------------------------------------------------------------------

    > Missing old school friends?  Find them here:

    > http://click.egroups.com/1/4055/6/_/_/_/959470996/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## Massimo Dentico — 2000-05-28 02:55:32

    stevan apter wrote:

     > [...]

    > agreed.  commercial olap products (arbor essbase for example) claim

    > to scale to multi-terabyte data, but experience (viz. mine)

    > shows the practical limits to be much lower (for example, there is a

    > massive explosion of the data during the precalculation phase.)  the

    > only petabyte database i know of is at cern, and i have no idea what

    > they're using to analyze it.  in any case, 100 gig databases are still

    > rare in the world of commerce, and that's probably for the best, since

    > all the commercial rdbms products choke at well under this limit, but

    > pose little difficulty for 32 bit k, and none at all for the 64 bit

    > version.  ;-)

     You are right, I have exaggerated with the dimensions of the

    data-set, but it's possible with this dimension beyond our common

    experience.

    I have never been directly involved in the development of an OLAP

    but from what I have read, when really large set of historical data

    are involved, they are computed off-line as regards the RDBMS,

    on a non-relational DB with dedicated data structures. Infact

    RDBMS are not suitable for massive aggregation; in such case usual

    indexes are useless.

     > > In any case, real advantage is the direct disk block access (implicit

    > > via virtual memory or explicit as you say) a characteristic that has

    > > Forth too. Probably, with a K-like embedded in Forth (even as syntax

    > > thanks to its extendibility), it could achieve the same performace/compactness

    > > ratio. Portability of Forth machine is trivial, the interface with other

    > > features of the host, like GUI or IPC, is not so trivial but feasible,

    > > as REBOL or K show. Probably selecting carefully a subset of these features.

    > > But these are only my speculations.

    >

    > until joy came to my attention, i had little interest in stack-oriented

    > languages (at least, since 1980, when i wrote a lisp interpreter in neon).

    > i still find joy somewhat cumbersome, except, as billy has said, as a

    > concrete system for exploring the ideas of combinator theory (although

    > i have been thinking about how to program the pontifex algorithm in

    > joy, and it seems to me that the way to do it is to implement a few of

    > the k list operators, such as 'cut').

     This confirm my hypothesis about embedding, but take in mind that Joy

    doesn't have the capability to absorb the syntax of another language

    as it's possible in Forth.

     > > Anyway, this thread originated from your statement that Forth is slow.

    > > Are you so sure that the implementation techniques of K and Forth

    > > are completely unrelated?

    >

    > well, they're quite different, as far as i know.  billy is probably

    > best equipped to answer here, as he's familiar with both forth and

    > the vector languages of which k is one.

     Ok, even if, for what is my knowledge, there isn't much documentation

    about K implementation: after all is a proprietary environment.

     > in any case, the question regarding forth which is uppermost in my mind

    > is whether it is feasible to even contemplate writing something like an

    > rdbms in that language.  if it is, why hasn't it been done?  is this a cultural

    > thing?

     My personal experience is negative about RDBMS: most of the time they

    are a problem, not a solution. They are proposed as a generic tool

    but often they impose an artificial rappresentation of data *and*, when

    you need performance, it's difficult to tune a RDBMS to take advantage

    of your knowledge about properties of the data-set (a colleague spoke

    to me about a manual of a RDBMS, about performance tuning, that is beyond

    1000 pages).

    The philosophy of Forth (at least the original) suggests to carefully

    select algorithms and data structures best suited for the application

    at hand. So it is against general purpose tools like RDBMS and File

    Systems. The real advantage in performance and reduced complexity is

    the possibility to construct application specfic DBs or FSs.

    The only methods that I know to reconcile in a program performance,

    generality, flexibility and manageability (reasonable dimension,

    understandable, easy maintenance) are program transformation techniques

    like partial evaluation (automatic specialization), thus again

    metaprogramming.

    For a criticism of RDBMSs see Baker:

    "Relational Databases considered harmful" Comm. of the ACM 35,

    4 (April 1992), 16,18".

    - ftp://ftp.netcom.com/pub/hb/hbaker/letters/CACM-RelationalDatabases.html

    Ok, interesting discussion, but it's too late here, I'm going to sleep.

    --

    Massimo Dentico

## Massimo Dentico — 2000-05-28 03:07:36

    Massimo Dentico wrote:

     > [...]

    > but often they impose an artificial rappresentation of data *and*, when

    > [...]

     Representation .. it's really late. :o)

    How many other errors there will be???

    --

    Massimo Dentico

## Christian Tismer — 2000-05-28 16:48:28

    "Samuel A. Falvo II" wrote:

     >

    > On Sat, 27 May 2000, stevan apter wrote:

    > > Tree..d:".+(`child`parent

    > >             +{x@<x}@+{[l;n;p;c]

    > >                        (c;p),' :[l&(~c)|()_draw l+1

    > >                                  ,'/_f[l-1;n;c]'{x;:I+:1}'!2+()_draw n

    > >                                  2#,!0]}[Levels;Nodes;0;I::0])"

    >

    > Oh my God!  I never thought it possible!  I've actually seen a programming

    > language that's harder to read than Perl!! 8)

     Then try out APL. It can for sure compete with the above

    (WOL = Write Only Language) :-)

    ciao - chris

    --

    Christian Tismer             :^)   <mailto:tismer@...>

    Applied Biometrics GmbH      :     Have a break! Take a ride on Python's

    Kaunstr. 26                  :    *Starship* http://starship.python.net

    14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net

    PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF

         where do you want to jump today?   http://www.stackless.com

## stevan apter — 2000-05-28 22:19:58

    ----- Original Message -----

    From: Christian Tismer <tismer@...>

    To: <concatenative@egroups.com>

    Sent: Sunday, May 28, 2000 12:48 PM

    Subject: Re: [stack] joy applications

    >

    >

    > "Samuel A. Falvo II" wrote:

    > >

    > > On Sat, 27 May 2000, stevan apter wrote:

    > > > Tree..d:".+(`child`parent

    > > >             +{x@<x}@+{[l;n;p;c]

    > > >                        (c;p),' :[l&(~c)|()_draw l+1

    > > >                                  ,'/_f[l-1;n;c]'{x;:I+:1}'!2+()_draw n

    > > >                                  2#,!0]}[Levels;Nodes;0;I::0])"

    > >

    > > Oh my God!  I never thought it possible!  I've actually seen a programming

    > > language that's harder to read than Perl!! 8)

    >

    > Then try out APL. It can for sure compete with the above

    > (WOL = Write Only Language) :-)

    actually, k syntax is extremely simple.

    we recognize three syntax categories:  noun, verb, and adverb.

    there are exactly 20 verbs:

        ~ ! @ # $ % ^ & * _ - + = | : < , > . ?

    each verb can be monadic, in which case it is prefixed to its

    noun:

        ^x

    or dyadic, in which case it is written infix:

        x^y

    there is no precedence.

    there are six adverbs:

        ' \ / ': /: \:

    an adverb is suffixed to its verb or noun:

        +/

        -':

        p\

    verbs take nouns to make nouns; adverbs take verbs and nouns to

    make verbs.

    the parsing rules are given in two tables.  one table gives the

    binding strengths between categories:

     n n 1

     n v 3

     n a 4

     v n 2

     v v 1

     v a 4

    the other gives the result of binding two categories:

     n n -> n        / application

     n v -> v        / curry

     n a -> v        / modify noun

     v n -> n        / monadic application

     v v -> v        / composition

     v a -> v        / modify verb

    parsing is simple:  scan from the right; when a drop in binding

    strength occurs, bind the pair at that position and replace it

    with the category of the result.

    nouns are datatypes.  in k, there are exactly 8:

        int

        float

        byte

        symbol

        dictionary

        null

        lambda

        list

    the shape of k has been strongly influenced by thousands of man-

    years spent writing applications for trading-floor environments.

    such environments are characterized by the demand for high

    productivity, large volumes of data, speed of execution, and zero

    tolerance for errors.  in such an environment, a "write only language"

    would be quickly targetted for extinction.

    >

    > ciao - chris

    >

    > --

    > Christian Tismer             :^)   <mailto:tismer@...>

    > Applied Biometrics GmbH      :     Have a break! Take a ride on Python's

    > Kaunstr. 26                  :    *Starship* http://starship.python.net

    > 14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net

    > PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF

    >      where do you want to jump today?   http://www.stackless.com

    >

    > ------------------------------------------------------------------------

    > Failed tests, classes skipped, forgotten locker combinations.

    > Remember the good 'ol days

    > http://click.egroups.com/1/4053/6/_/_/_/959532194/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## John Drake — 2000-05-29 18:39:50

    On Sat, 27 May 2000 15:18:21   stevan apter wrote:

     >

    >----- Original Message -----

    >From: Samuel A. Falvo II <kc5tja@...>

    >To: <concatenative@egroups.com>

    >Sent: Saturday, May 27, 2000 1:37 PM

    >Subject: Re: [stack] joy applications

    >

    >

    >> On Sat, 27 May 2000, stevan apter wrote:

    >> > for example, i note that the swiftforth installer, from

    >> > forth inc, weighs in at 4.5 meg -- 4.5 meg?! -- for a

    >> > programming language?!

    >>

    >> That's all?

    >>

    >> How about GCC/binutils?

    >> How about VisualBASIC?

    >> How about Microsoft Visual C++?

    >> How about Delphi?

    >

    >if the total pl won't fit comfortably in an email message,

    >something is wrong.  i should think that the forth creed

    >of minimalism would preclude this kind of bloat.

    >

     Ah, but you forget that SwiftForth is designed

    as a Windows programming language.  Anything

    geared toward Windows is going to have to have

    some kind of bloat.  ;-)  Seriously, a program

    written for Windows needs all of the "WIMP"

    (Windows Icons Menus and Pointers) stuff to

    be competitive.  It also needs access to

    databases.  The code to access all of the

    Microsoft DLLs to handle all of this stuff

    takes up space.  There are some Forths for

    windows that are much smaller, but that also

    offer a lot less functionality out of the

    box.  The Windows Forth that does the best

    job of balancing size and functionality to

    me is bigForth Bernd Paysan, (though there

    are a few such a VFX Forth from MPE that I

    haven't tried).

    --== Sent via Deja.com http://www.deja.com/ ==--

    Before you buy.

## stevan apter — 2000-05-29 19:59:05

    ----- Original Message -----

    From: John Drake <jmdrake@...>

    To: <concatenative@egroups.com>

    Sent: Monday, May 29, 2000 2:39 PM

    Subject: Re: [stack] joy applications

    :

    > >

    > >if the total pl won't fit comfortably in an email message,

    > >something is wrong.  i should think that the forth creed

    > >of minimalism would preclude this kind of bloat.

    > >

    >

    > Ah, but you forget that SwiftForth is designed

    > as a Windows programming language.  Anything

    > geared toward Windows is going to have to have

    > some kind of bloat.  ;-)  Seriously, a program

    > written for Windows needs all of the "WIMP"

    > (Windows Icons Menus and Pointers) stuff to

    > be competitive.  It also needs access to

    > databases.  The code to access all of the

    > Microsoft DLLs to handle all of this stuff

    > takes up space.

    not really, john.  the k interpreter has identical

    capabilities, but is still only 150k or so.  go take

    a look (www.kx.com) and tell me what i'm missing.

    best

    sa

    >

    >

    > --== Sent via Deja.com http://www.deja.com/ ==--

    > Before you buy.

    >

    > ------------------------------------------------------------------------

    > Was the salesman clueless? Productopia has the answers.

    > http://click.egroups.com/1/4633/6/_/_/_/959625697/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## John Drake — 2000-05-30 14:06:54

    Well maybe I'm missing something.  I just

    downloaded K.  Here's what I can't find :

    1) A decent installation program (I'm not

       crazy about software that doesn't let

       me tell it where I want it to load).

    2) The ability to make DLLs and EXEs

    3) The ability to call DLLs.  (If it's there

       I can't find it in the manual.)

    4) DDE capability

    5) Multitasking

    6) A GUI enviornment

    2, 3, 4 and 6 can add quite a bit to a

    programs size.  1 and 5 probably don't add

    that much size wise but they are nice to

    additions.  Plus, I may be wrong, but

    I think I remember the SwiftForth

    documentation being a part of the 4MB

    download.  K's documentation (an additional

    1.3 MB) is a separate download.

    While making up your mind about Forth you

    should also consider Meme.  It's a Forth

    environment for virtual reality.  The

    download for it is 2Mb and that includes

    a rendering engine from RenderWare as

    well, a network communications protocol

    and a sample virtual world.

    http://www.immersive.com/

    Also Bernd Paysan's "bigForth" is only

    1.1 Mb.  It includes a complete GUI

    builder (VB drag and drop style),

    an OpenGL interface (and an

    advanced 3D language called

    "dragon-graphics" built on top of the

    OpenGL) and an SQL interface (which

    unfortunately only works on the Linux

    version.)

    http://www.jwdt.com/~paysan/bigforth.html

    --

     On Mon, 29 May 2000 15:59:05   stevan apter wrote:

    >

    >----- Original Message -----

    >From: John Drake <jmdrake@...>

    >To: <concatenative@egroups.com>

    >Sent: Monday, May 29, 2000 2:39 PM

    >Subject: Re: [stack] joy applications

    >:

    >

    >> >

    >> >if the total pl won't fit comfortably in an email message,

    >> >something is wrong.  i should think that the forth creed

    >> >of minimalism would preclude this kind of bloat.

    >> >

    >>

    >> Ah, but you forget that SwiftForth is designed

    >> as a Windows programming language.  Anything

    >> geared toward Windows is going to have to have

    >> some kind of bloat.  ;-)  Seriously, a program

    >> written for Windows needs all of the "WIMP"

    >> (Windows Icons Menus and Pointers) stuff to

    >> be competitive.  It also needs access to

    >> databases.  The code to access all of the

    >> Microsoft DLLs to handle all of this stuff

    >> takes up space.

    >

    >not really, john.  the k interpreter has identical

    >capabilities, but is still only 150k or so.  go take

    >a look (www.kx.com) and tell me what i'm missing.

    >

    >best

    >

    >sa

    >

    >

    >>

    >>

    >> --== Sent via Deja.com http://www.deja.com/ ==--

    >> Before you buy.

    >>

    >> ------------------------------------------------------------------------

    >> Was the salesman clueless? Productopia has the answers.

    >> http://click.egroups.com/1/4633/6/_/_/_/959625697/

    >> ------------------------------------------------------------------------

    >>

    >> To unsubscribe from this group, send an email to:

    >> concatenative-unsubscribe@egroups.com

    >>

    >>

    >>

    >>

    >

    >

    >------------------------------------------------------------------------

    >Failed tests, classes skipped, forgotten locker combinations.

    >Remember the good 'ol days

    >http://click.egroups.com/1/4053/6/_/_/_/959629871/

    >------------------------------------------------------------------------

    >

    >To unsubscribe from this group, send an email to:

    >concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

    --== Sent via Deja.com http://www.deja.com/ ==--

    Before you buy.

## wtanksley@bigfoot.com — 2000-05-30 16:42:34

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >my approach to pls is narrowly practical.  i'll work in the one

    >which offers the best combination of speed, simplicity, size, and

    >expressivity.  forth doesn't cut it - too slow by far.

     I don't think you've used many Forths, and I doubt you've ever compared an

    application written by a Forth programmer -- your experience has almost

    certainly been in writing simple benchmark programs in ancient PD Forths.

    Commercial Forths generate optimised native code; most newer free Forths now

    are starting to do the same (although with weaker optimization), because

    it's so much faster and usually takes the same amount of space.

    The current trend in the minimalist camp of Forth programming is to generate

    native code with certain very simple and very consistent optimizations (such

    as tail-call optimization).

    -Billy

## wtanksley@bigfoot.com — 2000-05-30 16:54:49

    From: stevan apter [mailto:apter@...]

     >From: Massimo Dentico <m.dentico@...>

    >> What do you intend for slow? As program execution speed?

    >> Or as development cycle? Or what exactly? And slow regards

    >> to what?

    >both.

     Both!  Have you done any research?  Have you known any Forth programmers?

    Forth is just as fast or slow as C, although in Forth's history there have

    been many more slow wordcode interpreters then there have been fast native

    code compilers.  Forth's development cycle is VERY fast; that's one of the

    notable things about the language.  It's not only fast, though; it's

    profoundly _different_ from most languages.  In this group we're discussing

    one of the differences: Forth is _concatenative_, and this makes it trivial

    to _refactor_ in certain ways.  Code which can be easily refactored is

    highly amenable to coding-time design changes, which means that in the real

    world projects get finished faster (because there are ALWAYS coding-time

    design changes in a good project).

    Forth claims other advantages, but we're not here to debate those -- for

    example, Forth claims that its simplicity is a major benefit, since a

    user/programmer can comprehend everything about the system with minimal

    effort.  This has little applicability to this forum, so there's no need to

    debate it -- it would be better to take it to comp.lang.forth.

     >i'm willing to have my mind changed, but it's going to take

    >concrete examples to do so.  i'm not a computer scientist, so

    >theoretical arguments don't work well on me.

     So you lay out a theoretical programming problem?  This doesn't work very

    well.

    I can't imagine any good results coming from that, seriously.

    -Billy

    Walking on water and coding to a specification are both trivial only if both

    are frozen.

## wtanksley@bigfoot.com — 2000-05-30 17:03:19

    From: Samuel A. Falvo II [mailto:kc5tja@...]

     >On Sat, 27 May 2000, stevan apter wrote:

    >> Tree..d:".+(`child`parent

    >>             +{x@<x}@+{[l;n;p;c]

    >>                        (c;p),' :[l&(~c)|()_draw l+1

    >Oh my God!  I never thought it possible!  I've actually seen a

    >programming language that's harder to read than Perl!! 8)

     Not entirely fair, Sam (BTW, it's good to see you here).  Perl has an

    inconsistent and tortured syntax; K has a simple and consistent one.  It's

    true that K's syntax relies heavily on symbols, but in actual use this is

    handy: like almost all applicative languages, K attempts to express a tree

    structure (functions and parameters) in a stream form (ASCII text ignoring

    whitespace).

    Python, BTW, is in a sense an exception to this: Python represents its tree

    structures in an appropriately 2-dimensional form.

    -Billy

## wtanksley@bigfoot.com — 2000-05-30 17:12:07

    From: stevan apter [mailto:apter@...]

     >one of the things i hope to learn from joy is whether there are

    >combinators which can be usefully added to k.

     I hope we can help you; however, I suspect that you'll spend more time

    helping us.  Joy is an immature language, really the first language in its

    class (Forth and Postscript hardly count, and Joy borrowed too little from

    them anyhow).  K is the third generation of very sucessful languages, each

    one learning a lot from its predecessor.

    K is strongly applicative and combinative.  Joy is strongly concatenative

    and weakly combinative.  I think it would be a very wise idea to make Joy

    more combinative; I also think it would be wise to add all of K's

    fundamental capabilities.  Only instead of parsing from left to right and

    executing from right to left like J and APL (I don't know K), Joy-2 will

    parse and execute in the same direction.

    -Billy

## Samuel A. Falvo II — 2000-05-30 17:17:25

    On Tue, 30 May 2000 wtanksley@... wrote:

     > Not entirely fair, Sam (BTW, it's good to see you here).  Perl has an

    > inconsistent and tortured syntax; K has a simple and consistent one.  It's

     That doesn't change anything; Befunge and Brain**** both have simple and

    consistent syntaxes.  But you'll be hard pressed to find anyone who can

    truely and fluently read programs written in such languages.

    And besides, there was a smiley at the end of my statement.  :)

## stevan apter — 2000-05-31 01:49:58

    ----- Original Message -----

    From: John Drake <jmdrake@...>

    To: <concatenative@egroups.com>

    Sent: Tuesday, May 30, 2000 10:06 AM

    Subject: Re: [stack] joy applications

    > Well maybe I'm missing something.  I just

    > downloaded K.  Here's what I can't find :

    >

    > 1) A decent installation program (I'm not

    >    crazy about software that doesn't let

    >    me tell it where I want it to load).

    k consists of a single dll and single license file.

    >

    > 2) The ability to make DLLs and EXEs

    k is an interpreter.

    >

    > 3) The ability to call DLLs.  (If it's there

    >    I can't find it in the manual.)

    2:, 3:, or 4:

    >

    > 4) DDE capability

    i have no idea what this is.

    >

    > 5) Multitasking

    3: and 4:

    >

    > 6) A GUI enviornment

    `show$ and `hide$

    >

    > 2, 3, 4 and 6 can add quite a bit to a

    > programs size.  1 and 5 probably don't add

    > that much size wise but they are nice to

    > additions.  Plus, I may be wrong, but

    > I think I remember the SwiftForth

    > documentation being a part of the 4MB

    > download.  K's documentation (an additional

    > 1.3 MB) is a separate download.

    the complete manual for the language and environment is

    part of the interpter:

        \

## stevan apter — 2000-05-31 01:50:53

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Tuesday, May 30, 2000 12:42 PM

    Subject: RE: [stack] joy applications

    > From: stevan apter [mailto:apter@...]

    > >From: <wtanksley@...>

    >

    > >my approach to pls is narrowly practical.  i'll work in the one

    > >which offers the best combination of speed, simplicity, size, and

    > >expressivity.  forth doesn't cut it - too slow by far.

    >

    > I don't think you've used many Forths, and I doubt you've ever compared an

    > application written by a Forth programmer --

    now's your chance.

## stevan apter — 2000-05-31 02:01:00

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Tuesday, May 30, 2000 12:54 PM

    Subject: RE: [stack] joy applications

    > From: stevan apter [mailto:apter@...]

    > >From: Massimo Dentico <m.dentico@...>

    >

    > >> What do you intend for slow? As program execution speed?

    > >> Or as development cycle? Or what exactly? And slow regards

    > >> to what?

    >

    > >both.

    >

    > Both!  Have you done any research?  Have you known any Forth programmers?

    no and no, although i was (briefly) a neon programmer.

    >

    > Forth is just as fast or slow as C, although in Forth's history there have

    > been many more slow wordcode interpreters then there have been fast native

    > code compilers.  Forth's development cycle is VERY fast; that's one of the

    > notable things about the language.  It's not only fast, though; it's

    > profoundly _different_ from most languages.  In this group we're discussing

    > one of the differences: Forth is _concatenative_, and this makes it trivial

    > to _refactor_ in certain ways.  Code which can be easily refactored is

    > highly amenable to coding-time design changes, which means that in the real

    > world projects get finished faster (because there are ALWAYS coding-time

    > design changes in a good project).

    as a casual follower of comp.lang.forth, i've been hearing variations on

    this theme for years.  now, i've got lots and lots of programming problems

    which are either distilled from real-world situations (mainly, finance)

    or lifted/adapted from other sources.

    >

    > Forth claims other advantages, but we're not here to debate those -- for

    > example, Forth claims that its simplicity is a major benefit, since a

    > user/programmer can comprehend everything about the system with minimal

    > effort.  This has little applicability to this forum, so there's no need to

    > debate it -- it would be better to take it to comp.lang.forth.

    >

    > >i'm willing to have my mind changed, but it's going to take

    > >concrete examples to do so.  i'm not a computer scientist, so

    > >theoretical arguments don't work well on me.

    >

    > So you lay out a theoretical programming problem?  This doesn't work very

    > well.

    the rollup problem is not a "theoretical problem".  it was defined by

    a potential customer - "let's see if you can do this, and how long it

    takes (our oracles guys haven't been able to solve this problem in a

    year."

    >

    > I can't imagine any good results coming from that, seriously.

    i can't imagine learning anything about programming any other way -

    pick some problems, and code them up.

    >

    > -Billy

    > Walking on water and coding to a specification are both trivial only if both

    > are frozen.

    >

    > ------------------------------------------------------------------------

    > Missing old school friends?  Find them here:

    > http://click.egroups.com/1/4055/6/_/_/_/959705881/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-05-31 02:05:16

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Tuesday, May 30, 2000 1:03 PM

    Subject: RE: [stack] joy applications

    > From: Samuel A. Falvo II [mailto:kc5tja@...]

    >

    > >On Sat, 27 May 2000, stevan apter wrote:

    > >> Tree..d:".+(`child`parent

    > >>             +{x@<x}@+{[l;n;p;c]

    > >>                        (c;p),' :[l&(~c)|()_draw l+1

    >

    > >Oh my God!  I never thought it possible!  I've actually seen a

    > >programming language that's harder to read than Perl!! 8)

    >

    > Not entirely fair, Sam (BTW, it's good to see you here).  Perl has an

    > inconsistent and tortured syntax; K has a simple and consistent one.  It's

    > true that K's syntax relies heavily on symbols, but in actual use this is

    > handy: like almost all applicative languages, K attempts to express a tree

    > structure (functions and parameters) in a stream form (ASCII text ignoring

    > whitespace).

    what?  i wasn't "expressing" a tree - i was definiing a function to

    compute one.

    by the way, after all the gibes about the unreadability of that code,

    i was stimulated to rethink it.  yes, there is a faster, shorter, and

    altogether prettier way to do it.  here it is (john, take note:  here's

    the gui you couldn't find):

    ----

    Records:1000000

    Branches:10

    Depth:5

    Tree..d:".((`child;c);(`parent;,/0,{(#x)#y}':(0,+\\_ Branches^!Depth-1)_ c:!+/_ Branches^!Depth))"

    Trans..d:".((`leaf;c Records _draw#c:Tree[`child]_dvl?Tree`parent);(`value;Records _draw 0))"

    Rollup..d:"

     p:Tree[`parent]\\'!#Tree`parent

     g:Tree[`child]?/:Trans`leaf

     f:{@[x;p;y;@[x;g;y;z]]}

     s:f[(#p)#0.;+;Trans`value]

     c:f[(#p)#0;+;1]

     .((`node;Tree`child);(`sum;s);(`count;c);(`avg;s%c))"

    .k..c:`form

    .k..a:(`Depth`Branches`Records;`Tree`Trans`Rollup)

    `show$`.k

    ----

    there - the tree computation is a straight vector calculation, with no

    loops or recursion.

    >

    > Python, BTW, is in a sense an exception to this: Python represents its tree

    > structures in an appropriately 2-dimensional form.

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Missing old school friends?  Find them here:

    > http://click.egroups.com/1/4055/6/_/_/_/959706265/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-05-31 02:09:15

    >

    > > Well maybe I'm missing something.  I just

    > > downloaded K.  Here's what I can't find :

    > >

    > > 1) A decent installation program (I'm not

    > >    crazy about software that doesn't let

    > >    me tell it where I want it to load).

    >

    > k consists of a single dll and single license file.

     and an exe.  you can see how much time i spend outside of k,

    i can't even remember how many pieces there are!

## Steve Adams — 2000-05-31 05:11:56

    K?  I must have missed that part of the thread.

     ----- Original Message -----

    From: "stevan apter" <apter@...>

    To: <concatenative@egroups.com>

    Sent: Tuesday, May 30, 2000 7:09 PM

    Subject: Re: [stack] joy applications

    > >

    > > > Well maybe I'm missing something.  I just

    > > > downloaded K.  Here's what I can't find :

    > > >

    > > > 1) A decent installation program (I'm not

    > > >    crazy about software that doesn't let

    > > >    me tell it where I want it to load).

    > >

    > > k consists of a single dll and single license file.

    >

    > and an exe.  you can see how much time i spend outside of k,

    > i can't even remember how many pieces there are!

    >

    >

    >

    >

    >

    >

    > ------------------------------------------------------------------------

    > Hot off the press- summer's here!

    > School's out and it's sizzling hot. Whether you're planning a

    > graduation party, a summer brunch, or simple birthday party,

    > shop GreatEntertaining.com before your next celebration.

    > http://click.egroups.com/1/4473/6/_/_/_/959738453/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## Samuel A. Falvo II — 2000-05-31 02:11:22

    On Tue, 30 May 2000, stevan apter wrote:

     > what?  i wasn't "expressing" a tree - i was definiing a function to

    > compute one.

     I think what he's saying is that the program itself is expressed as a tree

    in applicative languages (LISP makes this the most explicit; but other

    languages like C and J do as well, but do so implicitly):

    	; LISP

    	(if (= 1 (* 2 3)) (print "I'm broken") (print "I'm good!"))

    	# Python

    	if 1 == 2*3:

    	   print "I'm broken"

    	else:

    	   print "I'm good!"

    	<<Abstract syntax tree>>

    			if

    			|

    	+---------------+---------------+

    	|		|		|

    	=	      print	      print

    	|		|		|

      +-----------+	   "I'm broken"     "I'm good!"

      |           |

      1           *

    	      |

    	+-----------+

    	|           |

    	2           3

    --

    KC5TJA/6, DM13, QRP-L #1447

    Samuel A. Falvo II

    Oceanside, CA

## stevan apter — 2000-05-31 11:32:40

    ----- Original Message -----

    From: Samuel A. Falvo II <kc5tja@...>

    To: <concatenative@egroups.com>

    Sent: Tuesday, May 30, 2000 10:11 PM

    Subject: Re: [stack] joy applications

    > On Tue, 30 May 2000, stevan apter wrote:

    >

    > > what?  i wasn't "expressing" a tree - i was definiing a function to

    > > compute one.

    >

    > I think what he's saying is that the program itself is expressed as a tree

    > in applicative languages (LISP makes this the most explicit; but other

    > languages like C and J do as well, but do so implicitly):

    ah - so he did.

    sorry - i should have read these remarks more carefully.

## stevan apter — 2000-05-31 12:53:35

    ----- Original Message -----

    From: Steve Adams <sadams3@...>

    To: <concatenative@egroups.com>

    Sent: Wednesday, May 31, 2000 1:11 AM

    Subject: Re: [stack] joy applications

    > K?  I must have missed that part of the thread.

    i see no reason why joy should not be transparently extended

    to include scalar extension, so that e.g.

        joy>[1 2 3][4 5 6]+

        joy>[5 7 9]

    in fact, my k implementation of joy does exactly this, since

    joy lists are implemented as k lists, and joy + is implemented

    as k +.

    but a further question which has been nagging at me is why

    joy should not be thought of as an applicative-combinative

    language in which all operations are applications of one-place

    combinators, and the stack argument can therefore be elided.

    that is, in fact, how i have implemented joy, where the stack

    is a local variable.

    thus, + takes the stack as a list-argument, adds the top two

    items, and returns the stack with the top two items dropped,

    and the result of addition on top:

        plus:{(,+/2#x),2_ x}

    if you escape from the read-eval-print loop of the joy

    interpreter, then you can write joy code applicatively:

        plus(1 2;3 4;5 6 7 8)

     (4 6

      5 6 7 8)

    >

    >

    > ----- Original Message -----

    > From: "stevan apter" <apter@...>

    > To: <concatenative@egroups.com>

    > Sent: Tuesday, May 30, 2000 7:09 PM

    > Subject: Re: [stack] joy applications

    >

    >

    > > >

    > > > > Well maybe I'm missing something.  I just

    > > > > downloaded K.  Here's what I can't find :

    > > > >

    > > > > 1) A decent installation program (I'm not

    > > > >    crazy about software that doesn't let

    > > > >    me tell it where I want it to load).

    > > >

    > > > k consists of a single dll and single license file.

    > >

    > > and an exe.  you can see how much time i spend outside of k,

    > > i can't even remember how many pieces there are!

    > >

    > >

    > >

    > >

    > >

    > >

    > > ------------------------------------------------------------------------

    > > Hot off the press- summer's here!

    > > School's out and it's sizzling hot. Whether you're planning a

    > > graduation party, a summer brunch, or simple birthday party,

    > > shop GreatEntertaining.com before your next celebration.

    > > http://click.egroups.com/1/4473/6/_/_/_/959738453/

    > > ------------------------------------------------------------------------

    > >

    > > To unsubscribe from this group, send an email to:

    > > concatenative-unsubscribe@egroups.com

    > >

    > >

    > >

    > >

    >

    >

    > ------------------------------------------------------------------------

    > Hot off the press- summer's here!

    > School's out and it's sizzling hot. Whether you're planning a

    > graduation party, a summer brunch, or simple birthday party,

    > shop GreatEntertaining.com before your next celebration.

    > http://click.egroups.com/1/4473/6/_/_/_/959739182/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## John Drake — 2000-05-31 14:46:08

    --

     On Tue, 30 May 2000 21:49:58   stevan apter wrote:

    >

    >----- Original Message -----

    >From: John Drake <jmdrake@...>

    >To: <concatenative@egroups.com>

    >Sent: Tuesday, May 30, 2000 10:06 AM

    >Subject: Re: [stack] joy applications

    >

    >

    >> Well maybe I'm missing something.  I just

    >> downloaded K.  Here's what I can't find :

    >>

    >> 1) A decent installation program (I'm not

    >>    crazy about software that doesn't let

    >>    me tell it where I want it to load).

    >

    >k consists of a single dll and single license file.

    Actually it is an EXE, not a DLL.  And I'd

    still prefer to tell it where to install.

    >> 2) The ability to make DLLs and EXEs

    >

    >k is an interpreter.

    SwiftForth is also an interpreter and it

    still lets you make DLLs and EXEs.

    >> 3) The ability to call DLLs.  (If it's there

    >>    I can't find it in the manual.)

    >

    >2:, 3:, or 4:

    ???? Not sure what you're trying to say here.

    >> 4) DDE capability

    >

    >i have no idea what this is.

    DDE stands for "dynamic data exchange".  It's

    the forerunner to COM.

    >> 5) Multitasking

    >

    >3: and 4:

    Again.  3: and 4: what?

    >> 6) A GUI enviornment

    >

    >`show$ and `hide$

    That does not a GUI enviornment make.

    I'm talking about the IDE here.  (intergrated

    development enviornment.)

    >> 2, 3, 4 and 6 can add quite a bit to a

    >> programs size.  1 and 5 probably don't add

    >> that much size wise but they are nice to

    >> additions.  Plus, I may be wrong, but

    >> I think I remember the SwiftForth

    >> documentation being a part of the 4MB

    >> download.  K's documentation (an additional

    >> 1.3 MB) is a separate download.

    >

    >the complete manual for the language and environment is

    >part of the interpter:

    That's an incorrect statement.  I'm not talking

    about the online help file.  I'm talking about

    the 2 PDF files that you can download from the

    K website.  SwiftForth's download includes

    the PDF file for the book "The Forth

    Programmer's Handbook".  If you're going to

    compare download size than you have to add

    in the extra 1.3 MB in the two PDF files that

    can be downloaded with K.

    I should also add that if you want a windows

    Forth that's about 178 Kb there is Aztec Forth.

    It includes a GUI based editor.

    --== Sent via Deja.com http://www.deja.com/ ==--

    Before you buy.

## wtanksley@bigfoot.com — 2000-05-31 16:29:41

    From: stevan apter [mailto:apter@...]

     >> >expressivity.  forth doesn't cut it - too slow by far.

    >> I don't think you've used many Forths, and I doubt you've

    >> ever compared an application written by a Forth programmer

    >now's your chance.

     Yours, not mine.  I've had my chance.  Go ahead, take your challenge to

    comp.lang.forth.  I dunno if it'll be well-recieved there, but it certainly

    doesn't belong here.  We're discussing and implementing concatenative

    languages here.

    -Billy

## wtanksley@bigfoot.com — 2000-05-31 16:33:59

    From: stevan apter [mailto:apter@...]

     >> Not entirely fair, Sam (BTW, it's good to see you here).  Perl has an

    >> inconsistent and tortured syntax; K has a simple and

    >> consistent one.  It's

    >> true that K's syntax relies heavily on symbols, but in

    >> actual use this is

    >> handy: like almost all applicative languages, K attempts to

    >> express a tree

    >> structure (functions and parameters) in a stream form (ASCII

    >> text ignoring whitespace).

    >what?  i wasn't "expressing" a tree - i was definiing a function to

    >compute one.

     Like all applicative languages, K expresses a tree.  The leaves of the tree

    are parameters, and the branches are function calls or curries.

     >by the way, after all the gibes about the unreadability of that code,

    >i was stimulated to rethink it.  yes, there is a faster, shorter, and

    >altogether prettier way to do it.

     I don't know K, but that looks indeed very nice.  I don't think you'll get

    much appreciation from people who can't read K, though.

    -Billy

## wtanksley@bigfoot.com — 2000-05-31 16:55:42

    From: stevan apter [mailto:apter@...]

     >i see no reason why joy should not be transparently extended

    >to include scalar extension, so that e.g.

    >    joy>[1 2 3][4 5 6]+

    >    joy>[5 7 9]

     I like that a lot.  In fact, Joy could include all of the operators K

    includes, and thereby be almost as useful on K's own territory.  (Joy would

    lack K's applicivity, but perhaps that would serve as a test of how much

    application really helps.)

     >but a further question which has been nagging at me is why

    >joy should not be thought of as an applicative-combinative

    >language in which all operations are applications of one-place

    >combinators, and the stack argument can therefore be elided.

    >that is, in fact, how i have implemented joy, where the stack

    >is a local variable.

     This is, in fact, the theory behind Joy; however, because Joy does not

    include any syntax or semantics of any kind to _control_ that application,

    it's a misnomer to call the language applicative.  It certainly is

    concatenative-combinative, though.

    -Billy

## stevan apter — 2000-05-31 23:55:36

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Wednesday, May 31, 2000 12:29 PM

    Subject: RE: [stack] joy applications

    > From: stevan apter [mailto:apter@...]

    > >> >expressivity.  forth doesn't cut it - too slow by far.

    >

    > >> I don't think you've used many Forths, and I doubt you've

    > >> ever compared an application written by a Forth programmer

    >

    > >now's your chance.

    >

    > Yours, not mine.  I've had my chance.  Go ahead, take your challenge to

    > comp.lang.forth.  I dunno if it'll be well-recieved there, but it certainly

    > doesn't belong here.  We're discussing and implementing concatenative

    > languages here.

    well then, have fun.

## wtanksley@bigfoot.com — 2000-05-31 23:50:29

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >> From: stevan apter [mailto:apter@...]

    >> >concrete examples to do so.  i'm not a computer scientist, so

    >> >theoretical arguments don't work well on me.

    >> So you lay out a theoretical programming problem?  This

    >> doesn't work very well.

    >the rollup problem is not a "theoretical problem".  it was defined by

    >a potential customer - "let's see if you can do this, and how long it

    >takes (our oracles guys haven't been able to solve this problem in a

    >year."

     You say you have a collection of problems like that.  While it's true that

    they're based on problems which were at one time real, as programming

    projects they're still utterly theoretical.  for instance, their

    specifications will never change.  There's a known correct answer.

     >> I can't imagine any good results coming from that, seriously.

    >i can't imagine learning anything about programming any other way -

    >pick some problems, and code them up.

     But the thing you asked us to do isn't a problem; it's a benchmark.  And

    you're not "picking up the problems and coding them up;" you're asking us to

    do it for you.  _We_ may indeed learn something if we did that (although if

    we did we wouldn't have been very good programmers in that language); _you_

    certainly wouldn't learn anything.

    -Billy

## stevan apter — 2000-06-01 00:16:13

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Wednesday, May 31, 2000 7:50 PM

    Subject: RE: [stack] joy applications

    > From: stevan apter [mailto:apter@...]

    > >From: <wtanksley@...>

    > >> From: stevan apter [mailto:apter@...]

    > >> >concrete examples to do so.  i'm not a computer scientist, so

    > >> >theoretical arguments don't work well on me.

    >

    > >> So you lay out a theoretical programming problem?  This

    > >> doesn't work very well.

    >

    > >the rollup problem is not a "theoretical problem".  it was defined by

    > >a potential customer - "let's see if you can do this, and how long it

    > >takes (our oracles guys haven't been able to solve this problem in a

    > >year."

    >

    > You say you have a collection of problems like that.  While it's true that

    > they're based on problems which were at one time real, as programming

    > projects they're still utterly theoretical.  for instance, their

    > specifications will never change.  There's a known correct answer.

    this is beginning to feel like one of those pointless usenet

    controversies which consume as much time and energy as you're

    willing to pour into them.  personally, i'm less interested

    in gassing about languages than in using them.  the study of

    actual code in relation to well-defined problems, across and

    within languages, is in my opinion the road to travel.

    >

    > >> I can't imagine any good results coming from that, seriously.

    >

    > >i can't imagine learning anything about programming any other way -

    > >pick some problems, and code them up.

    >

    > But the thing you asked us to do isn't a problem; it's a benchmark.  And

    > you're not "picking up the problems and coding them up;" you're asking us to

    > do it for you.  _We_ may indeed learn something if we did that (although if

    > we did we wouldn't have been very good programmers in that language); _you_

    > certainly wouldn't learn anything.

    i think i'm a good k programmer, but i learn something new about

    the langauge every day, *by writing k programs*.  how absurd to suggest

    that if one can learn something in this way, then one didn't know

    much to begin with.  what a strange belief to have.  how did you

    acquire it?

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Scrap your search engine.

    > Inforocket.com is the fast way to the right answer - guaranteed.

    > http://click.egroups.com/1/4517/6/_/_/_/959816969/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-06-01 02:16:30

    ----- Original Message -----

    From: John Drake <jmdrake@...>

    To: <concatenative@egroups.com>

    Sent: Tuesday, May 30, 2000 10:06 AM

    Subject: Re: [stack] joy applications

    > Well maybe I'm missing something.  I just

    > downloaded K.  Here's what I can't find :

    >

    > 6) A GUI enviornment

    see:

    http://www.cs.chalmers.se/~magnus/GuiFest-95/postchallenge.html

    to wit:

    GUI Fest Post Challenge: Multiple Counters

    The "Multiple Counter" program shows a counter which can be incremented manually or periodically.  The counter can at any time be

    copied, giving a new counter with its own independent state, which is copied from the old counter in the very moment of creation. A

    counter can also be linked, giving a new view to the same counter. One can think of the copying and linking as being analogous to ln

    and cp applied to files under Unix.

    A counter view looks something like this:

    +------------+

    |            |

    | +--------+ |

    | |    0   | |

    | +--------+ |

    |            |

    |            |

    | +--------+ |

    | | Manual | |

    | +--------+ |

    |            |

    | +--------+ |

    | |  Auto  | |

    | +--------+ |

    |            |

    | +--------+ |

    | |  Copy  | |

    | +--------+ |

    |            |

    | +--------+ |

    | |  Link  | |

    | +--------+ |

    +------------+

    It contains the following elements:

    an integer display of the current count.

    Manual, a button which increments this counter and all those linked with it.

    Auto, a button which sets this counter (and all its associated links) to auto-increment mode in which the count increases

    periodically until Manual is pressed. The button may visually reflect if the counter is in auto-increment mode or not.

    Copy, a button which makes a copy of this counter. The new counter starts with the same value as the counter that created it, but is

    not linked to it (ie. pressing Manual in it does not increase the count in the one that created it, and vice-versa).

    Link, a button which makes a link to this counter. The link is a new view of the same count, ie. it increases when other counters

    linked to it increase, and vice-versa.

    If possible, it should be possible to distinguish counters that are linked - eg. links have the same background colour or window

    title, copies have a different colour or title, or perhaps by layout - links placed across the screen, copies placed down the

    screen.

    --

    here is one way of solving this little problem:

    http://www.cs.chalmers.se/~magnus/GuiFest-95/fudgets/solutions.html#multiple

    here is a differnent way, which involves much less code:

        count:()

        p0[`value`auto`manual`copy`link]:(0;0;"value+:1";".k.copy _d";".k.link _d")

        p0[.;`c]:_n,`check,3#`button

        p0..l:$I:0

        copy:{`show$~@[~new[];`d`t`l;:;(".k.count ",i;".k.count[",i,";_i]:_v ._i";i:$-1+#count,:. x)]}

        link:{`show$~.[~new[];();:;.~x]}

        new:{`$".k.p",$I+:1}

        .t..t:"{if[.k.count[x;`auto];.k.count[x;`value]+:1]}'!#.k.count;"

        \t 1

        copy`.k.p0

    'count' is a list of counters.

    'p0' is the prototype counter:  it is a dictionary containing five variables:

    an integer 'value', a checkbutton 'auto', and three buttons, 'manual', 'copy',

    and 'link'.

    k assigns the time to .t every second; a trigger on .t is then executed, which

    sweeps through count and increments the value of every counter whose 'auto'

    checkbutton is 'on'.

    when the user presses the 'copy' button of counter i, a new counter i+1 is generated,

    appended to the list of counters, and mapped to the screen.

    when the user presses the 'link' button of counter i, a copy i+1 of the current counter

    is made and mapped to the screen.  linked counters are automatically in sync (e.g. turn

    'auto' on for counter i, and the 'auto' button of every counter linked to i is turned on).

    when the user presses the 'manual' button, 'value' is incremented.

    to run this, download k from www.kx.com, start a k session, and copy the code

    into the session (you can also save it as k script - e.g., counters.k - and

    start the session with

        k counters

## stevan apter — 2000-06-01 12:54:29

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Wednesday, May 31, 2000 12:55 PM

    Subject: RE: [stack] joy applications

    > From: stevan apter [mailto:apter@...]

    >

    > >i see no reason why joy should not be transparently extended

    > >to include scalar extension, so that e.g.

    > >    joy>[1 2 3][4 5 6]+

    > >    joy>[5 7 9]

    >

    > I like that a lot.  In fact, Joy could include all of the operators K

    > includes, and thereby be almost as useful on K's own territory.  (Joy would

    > lack K's applicivity, but perhaps that would serve as a test of how much

    > application really helps.)

    >

    > >but a further question which has been nagging at me is why

    > >joy should not be thought of as an applicative-combinative

    > >language in which all operations are applications of one-place

    > >combinators, and the stack argument can therefore be elided.

    > >that is, in fact, how i have implemented joy, where the stack

    > >is a local variable.

    >

    > This is, in fact, the theory behind Joy; however, because Joy does not

    > include any syntax or semantics of any kind to _control_ that application,

    > it's a misnomer to call the language applicative.  It certainly is

    > concatenative-combinative, though.

    that may well be, however i can only report that in writing

    joy programs i continue to think of each operation as a function

    of the stack:  S'<- f S.  this scales (in the cognitive sense)

    so long as i can map the solution into a train of monadic

    applications:  S'<- f g h i j S.  but it imposes an extra

    cognitive burden for solutions which involve "trees of trains".

    for example, consider

            r:f[g x;h x]

    where f takes g x and h x to produce r.  if i don't want to

    write

            x dup g swap h f

    (and i don't!) then i need to have an "apply" combinator of

    for each pattern of application:

            x g h f apply_f_to_g_and_h

    or i need extra arguments to control the pattern of a general

    apply function:

            x g h f 2 ... apply

    the control arguments get more and more complex as i consider

    all the possible application trees; e.g.

            r:f[g h x;f[h g x;g g x]]

    etc.  and that's just for the case of one argument x and two

    functions g and h!

    i have no idea how forth programmers deal with this kind of

    thing (i would like to hear from one of you).

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Hot off the press- summer's here!

    > School's out and it's sizzling hot. Whether you're planning a

    > graduation party, a summer brunch, or simple birthday party,

    > shop GreatEntertaining.com before your next celebration.

    > http://click.egroups.com/1/4473/6/_/_/_/959792084/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## John Drake — 2000-06-01 13:03:44

    Hello Steve.

    You still don't understand what I mean when

    I say "GUI enviornment".  I'm not talking about

    the ability to make a GUI, but that the

    IDE (intergrated development enviornment) is

    a GUI.  The IDE includes the editor,

    the debugger ect.  I addressed this in an

    earlier post, but it seems that it didn't

    get forwarded out of e-groups (although it

    showed up in the archive.)  So here it is

    again :

    --

     On Tue, 30 May 2000 21:49:58   stevan apter wrote:

    >

    >----- Original Message -----

    >From: John Drake <jmdrake@...>

    >To: <concatenative@egroups.com>

    >Sent: Tuesday, May 30, 2000 10:06 AM

    >Subject: Re: [stack] joy applications

    >

    >

    >> Well maybe I'm missing something.  I just

    >> downloaded K.  Here's what I can't find :

    >>

    >> 1) A decent installation program (I'm not

    >>    crazy about software that doesn't let

    >>    me tell it where I want it to load).

    >

    >k consists of a single dll and single license file.

    Actually it is an EXE, not a DLL.  And I'd

    still prefer to tell it where to install.

    >> 2) The ability to make DLLs and EXEs

    >

    >k is an interpreter.

    SwiftForth is also an interpreter and it

    still lets you make DLLs and EXEs.

    >> 3) The ability to call DLLs.  (If it's there

    >>    I can't find it in the manual.)

    >

    >2:, 3:, or 4:

    ???? Not sure what you're trying to say here.

    >> 4) DDE capability

    >

    >i have no idea what this is.

    DDE stands for "dynamic data exchange".  It's

    the forerunner to COM.

    >> 5) Multitasking

    >

    >3: and 4:

    Again.  3: and 4: what?

    >> 6) A GUI enviornment

    >

    >`show$ and `hide$

    That does not a GUI enviornment make.

    I'm talking about the IDE here.  (intergrated

    development enviornment.)

    >> 2, 3, 4 and 6 can add quite a bit to a

    >> programs size.  1 and 5 probably don't add

    >> that much size wise but they are nice to

    >> additions.  Plus, I may be wrong, but

    >> I think I remember the SwiftForth

    >> documentation being a part of the 4MB

    >> download.  K's documentation (an additional

    >> 1.3 MB) is a separate download.

    >

    >the complete manual for the language and environment is

    >part of the interpter:

    That's an incorrect statement.  I'm not talking

    about the online help file.  I'm talking about

    the 2 PDF files that you can download from the

    K website.  SwiftForth's download includes

    the PDF file for the book "The Forth

    Programmer's Handbook".  If you're going to

    compare download size than you have to add

    in the extra 1.3 MB in the two PDF files that

    can be downloaded with K.

    I should also add that if you want a windows

    Forth that's about 178 Kb there is Aztec Forth.

    It includes a GUI based editor.

    --== Sent via Deja.com http://www.deja.com/ ==--

    Before you buy.

## stevan apter — 2000-06-01 14:10:44

    hi john

     ----- Original Message -----

    From: John Drake <jmdrake@...>

    To: <concatenative@egroups.com>; <concatenative@egroups.com>

    Sent: Thursday, June 01, 2000 9:03 AM

    Subject: Re: [stack] joy applications

    > Hello Steve.

    >

    > You still don't understand what I mean when

    > I say "GUI enviornment".  I'm not talking about

    > the ability to make a GUI, but that the

    > IDE (intergrated development enviornment) is

    > a GUI.  The IDE includes the editor,

    > the debugger ect.  I addressed this in an

    > earlier post, but it seems that it didn't

    > get forwarded out of e-groups (although it

    > showed up in the archive.)  So here it is

    > again :

    i've always used 'gui' to refer to the windowing parts of an

    application.  lately, i've picked up the term 'ide' to refer

    to what you're calling 'gui'.  so now that we've coordinated our

    terminology ... ;-)

    right - k has no native ide, and no symbolic debugger.  we

    use the native command prompt for running/debugging/developing,

    and recommend that you use your favorite text editor for

    writing k scripts.  i use notepad and the EM editor, some

    folks use emacs, and others use sam.  since k applications,

    even at their largest, are rarely more than a few dozen lines,

    it's hard to imagine what else one might need.  (but of course,

    i realize that you raised this and a number of other issues

    in order to explain why swiftforth is 4.5 meg and k only 150k.)

    re-reading your list of features reinforces my original opinion

    that the only useful way to compare pls is to have at a series

    of concrete programming problems.

    thanks for your response (btw, how big is swiftforth once you

    subtract out the documentation and ide?)

## wtanksley@bigfoot.com — 2000-06-01 17:07:22

    From: stevan apter [mailto:apter@...]

     >re-reading your list of features reinforces my original opinion

    >that the only useful way to compare pls is to have at a series

    >of concrete programming problems.

     This is mostly true (inasmuch as you can ever have the same problem with two

    different languages; it's _really_ hard to arrange circumstances that way,

    because usually by the time the second language gets to the scene, the first

    one has _failed_, and the problem has stabilised).  Another way is to have a

    series of artificial problems, as with the 99 bottles of beer on the wall

    page or your problem request.  This has the advantage of being easier to

    reproduce; it has the disadvantage of being totally unlike the real world,

    and thus fails to portray the language's advantages or disadvantages to real

    development (as opposed to coding).

     >thanks for your response (btw, how big is swiftforth once you

    >subtract out the documentation and ide?)

     I've never downloaded it (I've been happy with the free Forths), so I can't

    answer your question, but keep in mind that SwiftForth has featureitis.

    It's a commercial product, and it's competing against free Forths on the

    basis of programmers used to MSVC++.  Size is not a competitive feature

    (except in generated code); bells and whistles are.

    -Billy

## stevan apter — 2000-06-01 20:58:29

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Thursday, June 01, 2000 1:07 PM

    Subject: RE: [stack] joy applications

    > From: stevan apter [mailto:apter@...]

    >

    > >re-reading your list of features reinforces my original opinion

    > >that the only useful way to compare pls is to have at a series

    > >of concrete programming problems.

    >

    > This is mostly true (inasmuch as you can ever have the same problem with two

    > different languages; it's _really_ hard to arrange circumstances that way,

    > because usually by the time the second language gets to the scene, the first

    > one has _failed_, and the problem has stabilised).  Another way is to have a

    > series of artificial problems, as with the 99 bottles of beer on the wall

    > page or your problem request.  This has the advantage of being easier to

    > reproduce; it has the disadvantage of being totally unlike the real world,

    > and thus fails to portray the language's advantages or disadvantages to real

    > development (as opposed to coding).

    i can't quite get my mind around this way of looking at things.

    "problem patterns" have always been an essential item in my toolkit,

    no matter what language i work in.  a problem pattern is just an

    ordinary inductive generalization from experience.  e.g. having

    encountered the rollup problem in (superficially) diverse forms,

    try to formulate it in general, but not overly general, form.

    if you refuse to generalize from experience, then every problem

    will be wholly and utterly novel - but of course, you can't help

    but generalize, and part of comprehending a new problem is just

    finding similarities between it and other problems which you've

    solved in the past.

    i've described the problems i'm interested in comparing across

    languaes as "small, rich, and interesting".  99 bottles is small,

    but neither rich nor interesting.  8 queens is small and interesting,

    but not rich.  (a problem is rich if it has lots of connections

    with real-world programming, and if it contains parameters which

    can be easily modified to make those connections salient.  a problem

    can be interesting for any of a variety of reasons, and i won't

    attempt an enumeration.)

    are you claiming that there are no such problems?

    i think the following qualifies:

        spreadsheet execution order

        ---------------------------

        you aee given a list of assignment statements

                a : [ b c d ... ]

        where [ b c d ... ] is a functional expression

        involving variables b c d ... .

        the list is not in execution order.

        write a function which takes such a list and

        re-orders it so it can be executed one assignment

        at a time.

        sample list:

            d:c+b

            c:-b

            e:d*a

            b:10

            a:20

        reordered:

            b:10

            c:-b

            a:20

            d:c+b

            e:d*a

    contrary to your assertion, this problem is language independent.

    it has also been solved many times (e.g. excel solves it), but

    that doesn't make it *uninteresting*.

    >

    > >thanks for your response (btw, how big is swiftforth once you

    > >subtract out the documentation and ide?)

    >

    > I've never downloaded it (I've been happy with the free Forths), so I can't

    > answer your question, but keep in mind that SwiftForth has featureitis.

    > It's a commercial product, and it's competing against free Forths on the

    > basis of programmers used to MSVC++.  Size is not a competitive feature

    > (except in generated code); bells and whistles are.

    have you read david gelernter's _machine beauty_?

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > $60 in FREE Long Distance!  Click Here to join beMANY! today.

    > http://click.egroups.com/1/4126/6/_/_/_/959879186/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## John Drake — 2000-06-02 15:02:57

    Well it's been a while since I downloaded

    SwiftForth and my "90 day eval" has long

    since run out.  I would guess that the

    PDF file is at least 2 meg, but I'm not

    sure.

    Just for experimental purposes I stripped

    down my copy of bigForth to as small as

    I could make it and still have it do

    anything interesting.  That was a minimum

    of 4 files, 485Kb uncompressed, 250Kb

    compressed.  I can still build a GUI with

    it, but all of the IDE is gone (including

    the point and click GUI builder).  Of

    course the OpenGL is gone also.  As I also

    already mentioned the Aztec Forth for

    Windows starts out pretty small.  And if

    you take out the full screen editor and

    the assembly language support is shrinks

    to 130Kb.

    Judging program examples is tough because

    different languages do better in different

    areas.  Forth is a general purpose language.

    K seems strong in vector processing, but

    say if I wanted to write my own BMP viewer

    in K?  Or if I wanted to access OpenGL?

    Would I be able to do that within K?  Or

    would I have to wait for someone else to

    implement this in C and then link it into

    K?  You can implement a BNF recursive

    descent parser generator in 14 lines of

    Forth, but then again REBOL has a parser

    generator built in.

    http://www.jwdt.com/~paysan/screenful.html

    --

     On Thu, 1 Jun 2000 10:10:44    stevan apter wrote:

    >hi john

    >

    >----- Original Message -----

    >From: John Drake <jmdrake@...>

    >To: <concatenative@egroups.com>; <concatenative@egroups.com>

    >Sent: Thursday, June 01, 2000 9:03 AM

    >Subject: Re: [stack] joy applications

    >

    >

    >> Hello Steve.

    >>

    >> You still don't understand what I mean when

    >> I say "GUI enviornment".  I'm not talking about

    >> the ability to make a GUI, but that the

    >> IDE (intergrated development enviornment) is

    >> a GUI.  The IDE includes the editor,

    >> the debugger ect.  I addressed this in an

    >> earlier post, but it seems that it didn't

    >> get forwarded out of e-groups (although it

    >> showed up in the archive.)  So here it is

    >> again :

    >

    >i've always used 'gui' to refer to the windowing parts of an

    >application.  lately, i've picked up the term 'ide' to refer

    >to what you're calling 'gui'.  so now that we've coordinated our

    >terminology ... ;-)

    >

    >right - k has no native ide, and no symbolic debugger.  we

    >use the native command prompt for running/debugging/developing,

    >and recommend that you use your favorite text editor for

    >writing k scripts.  i use notepad and the EM editor, some

    >folks use emacs, and others use sam.  since k applications,

    >even at their largest, are rarely more than a few dozen lines,

    >it's hard to imagine what else one might need.  (but of course,

    >i realize that you raised this and a number of other issues

    >in order to explain why swiftforth is 4.5 meg and k only 150k.)

    >

    >re-reading your list of features reinforces my original opinion

    >that the only useful way to compare pls is to have at a series

    >of concrete programming problems.

    >

    >thanks for your response (btw, how big is swiftforth once you

    >subtract out the documentation and ide?)

    >

    >

    >

    >

    >

    >------------------------------------------------------------------------

    >Accurate impartial advice on everything from laptops to table saws.

    >http://click.egroups.com/1/4634/6/_/_/_/959868126/

    >------------------------------------------------------------------------

    >

    >To unsubscribe from this group, send an email to:

    >concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

    --== Sent via Deja.com http://www.deja.com/ ==--

    Before you buy.

## stevan apter — 2000-06-03 01:19:03

    ----- Original Message -----

    From: John Drake <jmdrake@...>

    To: <concatenative@egroups.com>

    Sent: Friday, June 02, 2000 11:02 AM

    Subject: Re: [stack] joy applications

    these are good questions.  i wish i had

    good answers.  ;)

    "k as a systems langauage" is a hot topic

    among a certain subset of the community.

    the consensus is:  wait till next year

    (the release of k4 - a substantially

    different language).

    there is a set of OpenGL covers, although i

    haven't used them.

    [:]

    >

    > Judging program examples is tough because

    > different languages do better in different

    > areas.  Forth is a general purpose language.

    > K seems strong in vector processing, but

    > say if I wanted to write my own BMP viewer

    > in K?  Or if I wanted to access OpenGL?

    >

    > Would I be able to do that within K?  Or

    > would I have to wait for someone else to

    > implement this in C and then link it into

    > K?  You can implement a BNF recursive

    > descent parser generator in 14 lines of

    > Forth, but then again REBOL has a parser

    > generator built in.

    >

    > http://www.jwdt.com/~paysan/screenful.html

    >

    >

    >

    >

    >

    > --

    >

    > On Thu, 1 Jun 2000 10:10:44    stevan apter wrote:

    > >hi john

    > >

    > >----- Original Message -----

    > >From: John Drake <jmdrake@...>

    > >To: <concatenative@egroups.com>; <concatenative@egroups.com>

    > >Sent: Thursday, June 01, 2000 9:03 AM

    > >Subject: Re: [stack] joy applications

    > >

    > >

    > >> Hello Steve.

    > >>

    > >> You still don't understand what I mean when

    > >> I say "GUI enviornment".  I'm not talking about

    > >> the ability to make a GUI, but that the

    > >> IDE (intergrated development enviornment) is

    > >> a GUI.  The IDE includes the editor,

    > >> the debugger ect.  I addressed this in an

    > >> earlier post, but it seems that it didn't

    > >> get forwarded out of e-groups (although it

    > >> showed up in the archive.)  So here it is

    > >> again :

    > >

    > >i've always used 'gui' to refer to the windowing parts of an

    > >application.  lately, i've picked up the term 'ide' to refer

    > >to what you're calling 'gui'.  so now that we've coordinated our

    > >terminology ... ;-)

    > >

    > >right - k has no native ide, and no symbolic debugger.  we

    > >use the native command prompt for running/debugging/developing,

    > >and recommend that you use your favorite text editor for

    > >writing k scripts.  i use notepad and the EM editor, some

    > >folks use emacs, and others use sam.  since k applications,

    > >even at their largest, are rarely more than a few dozen lines,

    > >it's hard to imagine what else one might need.  (but of course,

    > >i realize that you raised this and a number of other issues

    > >in order to explain why swiftforth is 4.5 meg and k only 150k.)

    > >

    > >re-reading your list of features reinforces my original opinion

    > >that the only useful way to compare pls is to have at a series

    > >of concrete programming problems.

    > >

    > >thanks for your response (btw, how big is swiftforth once you

    > >subtract out the documentation and ide?)

    > >

    > >

    > >

    > >

    > >

    > >------------------------------------------------------------------------

    > >Accurate impartial advice on everything from laptops to table saws.

    > >http://click.egroups.com/1/4634/6/_/_/_/959868126/

    > >------------------------------------------------------------------------

    > >

    > >To unsubscribe from this group, send an email to:

    > >concatenative-unsubscribe@egroups.com

    > >

    > >

    > >

    > >

    >

    >

    > --== Sent via Deja.com http://www.deja.com/ ==--

    > Before you buy.

    >

    > ------------------------------------------------------------------------

    > Best friends, most artistic, class clown Find 'em here:

    > http://click.egroups.com/1/4054/6/_/_/_/959958195/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## Christian Tismer — 2000-06-03 17:54:29

    stevan apter wrote:

     >

    > ----- Original Message -----

    > From: Christian Tismer <tismer@...>

    > To: <concatenative@egroups.com>

    > Sent: Sunday, May 28, 2000 12:48 PM

    > Subject: Re: [stack] joy applications

    >

    > >

    > >

    > > "Samuel A. Falvo II" wrote:

    > > >

    > > > On Sat, 27 May 2000, stevan apter wrote:

    > > > > Tree..d:".+(`child`parent

    > > > >             +{x@<x}@+{[l;n;p;c]

    > > > >                        (c;p),' :[l&(~c)|()_draw l+1

    > > > >                                  ,'/_f[l-1;n;c]'{x;:I+:1}'!2+()_draw n

    > > > >                                  2#,!0]}[Levels;Nodes;0;I::0])"

    > > >

    > > > Oh my God!  I never thought it possible!  I've actually seen a programming

    > > > language that's harder to read than Perl!! 8)

    > >

    > > Then try out APL. It can for sure compete with the above

    > > (WOL = Write Only Language) :-)

    >

    > actually, k syntax is extremely simple.

     Thank you for the excellent explanation!

    But that cannot make me find this "flee dirt" any nicer.

    Makes my eyes hurt. I'm used to write in Python, and

    I like to show some simple code to the customer.

    At least they get an idea what's going on, without

    knowing programming at all.

    What would they say when I threw a bunch of ASCII at them :-)

    ciao - chris   (probably on the wrong list)

    --

    Christian Tismer             :^)   <mailto:tismer@...>

    Applied Biometrics GmbH      :     Have a break! Take a ride on Python's

    Kaunstr. 26                  :    *Starship* http://starship.python.net

    14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net

    PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF

         where do you want to jump today?   http://www.stackless.com

## srenner@mail.ru — 2000-06-03 20:18:36

    --- In concatenative@egroups.com, Christian Tismer <tismer@t...>

    wrote:

    ...

     > > > "Samuel A. Falvo II" wrote:

     ...

    ...

     >

    > What would they say when I threw a bunch of ASCII at them :-)

    >

    > ciao - chris   (probably on the wrong list)

    >

     Christian: Allow the Moderator to disagree. Please remain on the list

    as one of its valued citizens. It happens that Mr. Falvo II was the

    one who was on the wrong list, but this matter has been resolved.

    The Moderator

## stevan apter — 2000-06-04 14:05:40

    ----- Original Message -----

    From: Christian Tismer <tismer@...>

    To: <concatenative@egroups.com>

    Sent: Saturday, June 03, 2000 1:54 PM

    Subject: Re: [stack] joy applications

    >

    >

    > stevan apter wrote:

    > >

    > > ----- Original Message -----

    > > From: Christian Tismer <tismer@...>

    > > To: <concatenative@egroups.com>

    > > Sent: Sunday, May 28, 2000 12:48 PM

    > > Subject: Re: [stack] joy applications

    > >

    > > >

    > > >

    > > > "Samuel A. Falvo II" wrote:

    > > > >

    > > > > On Sat, 27 May 2000, stevan apter wrote:

    > > > > > Tree..d:".+(`child`parent

    > > > > >             +{x@<x}@+{[l;n;p;c]

    > > > > >                        (c;p),' :[l&(~c)|()_draw l+1

    > > > > >                                  ,'/_f[l-1;n;c]'{x;:I+:1}'!2+()_draw n

    > > > > >                                  2#,!0]}[Levels;Nodes;0;I::0])"

    > > > >

    > > > > Oh my God!  I never thought it possible!  I've actually seen a programming

    > > > > language that's harder to read than Perl!! 8)

    > > >

    > > > Then try out APL. It can for sure compete with the above

    > > > (WOL = Write Only Language) :-)

    > >

    > > actually, k syntax is extremely simple.

    >

    > Thank you for the excellent explanation!

    >

    > But that cannot make me find this "flee dirt" any nicer.

    > Makes my eyes hurt. I'm used to write in Python, and

    > I like to show some simple code to the customer.

    > At least they get an idea what's going on, without

    > knowing programming at all.

    i have only myself to blame for sending the dr. moreau creation

    above into the world as a spokesman for k.  after all this time,

    i should have absorbed the fact that symbolic notation puts the

    fear of god into programmers of mainstream languages.  (whenever

    we want to reassure ourselves that k is readable, we go look at

    some j code. ;-))

    perhaps it will be a useful datapoint to add that i find non-

    symbolic languages vastly more intimidating.  how can anyone

    manage to remember all those keywords, all the rules for special

    statement and expression forms, the precedence hierarchies, the

    (in python) rules for when to indent and when not.  how can

    anyone keep track of the volumes of code, the libraries to

    import.  everytime i am forced to write a loop, i get the

    counter logic wrong.  nested loops give my headaches headaches.

    different languages develop different muscles.  forth programmers

    will testify that their dreams have stacks.  oo-programmers

    find inheritance hierarchies in restaurant menus.  lisp programmers

    speak with lots of subordinate clauses.  k programmers are drawn

    to arid desert landscapes where each cactus is its own species.

    >

    > What would they say when I threw a bunch of ASCII at them :-)

    ours say, "very nice, but where's the *code*?".

    a good resource is www.kx.com/technical/contribus/euguge/kidioms.html.

    >

    > ciao - chris   (probably on the wrong list)

    no no.  you have to answer my question about continuations in

    joy.

    best

    sa

    >

    > --

    > Christian Tismer             :^)   <mailto:tismer@...>

    > Applied Biometrics GmbH      :     Have a break! Take a ride on Python's

    > Kaunstr. 26                  :    *Starship* http://starship.python.net

    > 14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net

    > PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF

    >      where do you want to jump today?   http://www.stackless.com

    >

    > ------------------------------------------------------------------------

    > Failed tests, classes skipped, forgotten locker combinations.

    > Remember the good 'ol days

    > http://click.egroups.com/1/4053/6/_/_/_/960054468/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## stevan apter — 2000-06-04 14:12:31

    > a good resource is www.kx.com/technical/contribus/euguge/kidioms.html.

     www.kx.com/technical/contribs/eugene/kidioms.html

## wtanksley@bigfoot.com — 2000-06-06 22:23:09

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >> From: stevan apter [mailto:apter@...]

    >> >but a further question which has been nagging at me is why

    >> >joy should not be thought of as an applicative-combinative

    >> >language in which all operations are applications of one-place

    >> >combinators, and the stack argument can therefore be elided.

    >> >that is, in fact, how i have implemented joy, where the stack

    >> >is a local variable.

    >> This is, in fact, the theory behind Joy; however, because

    >> Joy does not

    >> include any syntax or semantics of any kind to _control_

    >> that application,

    >> it's a misnomer to call the language applicative.  It certainly is

    >> concatenative-combinative, though.

    >that may well be, however i can only report that in writing

    >joy programs i continue to think of each operation as a function

    >of the stack:  S'<- f S.  this scales (in the cognitive sense)

    >so long as i can map the solution into a train of monadic

    >applications:  S'<- f g h i j S.  but it imposes an extra

    >cognitive burden for solutions which involve "trees of trains".

     This is just the problem.  It's definitely good to be able to think of

    concatenative languages using functional terms, but it's also good to be

    able to think of them as simple RPN (so to speak).

     >for example, consider

    >        r:f[g x;h x]

    >where f takes g x and h x to produce r.

     Okay...  I think.

     >if i don't want to write

    >        x dup g swap h f

    >(and i don't!)

     ...which seems to be a problem.

     >then i need to have an "apply" combinator of

    >for each pattern of application:

    >        x g h f apply_f_to_g_and_h

     That won't work -- try

    x [g] [h] [f] apply_f_to_g_and_h

    (Or something related.)

     >i have no idea how forth programmers deal with this kind of

    >thing (i would like to hear from one of you).

     Well, we often go to the root of the problem, and learn to enjoy writing

    things like "x dup g swap h f".  Alternately, we can factor such that the

    stack noise becomes an obvious part of the solution instead of just looking

    like noise.  It depends how much time we're willing to put in, and how

    clearly we understand the problem (in this case there's nothing I can do,

    since g, f, and h have no obvious meaning).

    -Billy

## stevan apter — 2000-06-07 01:27:47

    ----- Original Message -----

    From: <wtanksley@...>

    To: <concatenative@egroups.com>

    Sent: Tuesday, June 06, 2000 6:23 PM

    Subject: RE: [stack] joy applications

    > From: stevan apter [mailto:apter@...]

    > >From: <wtanksley@...>

    > >> From: stevan apter [mailto:apter@...]

    >

    > >> >but a further question which has been nagging at me is why

    > >> >joy should not be thought of as an applicative-combinative

    > >> >language in which all operations are applications of one-place

    > >> >combinators, and the stack argument can therefore be elided.

    > >> >that is, in fact, how i have implemented joy, where the stack

    > >> >is a local variable.

    >

    > >> This is, in fact, the theory behind Joy; however, because

    > >> Joy does not

    > >> include any syntax or semantics of any kind to _control_

    > >> that application,

    > >> it's a misnomer to call the language applicative.  It certainly is

    > >> concatenative-combinative, though.

    ok - i think i've absorbed this point in the interim

    >

    > >that may well be, however i can only report that in writing

    > >joy programs i continue to think of each operation as a function

    > >of the stack:  S'<- f S.  this scales (in the cognitive sense)

    > >so long as i can map the solution into a train of monadic

    > >applications:  S'<- f g h i j S.  but it imposes an extra

    > >cognitive burden for solutions which involve "trees of trains".

    >

    > This is just the problem.  It's definitely good to be able to think of

    > concatenative languages using functional terms, but it's also good to be

    > able to think of them as simple RPN (so to speak).

    yes, i think this is right.

    >

    > >for example, consider

    > >        r:f[g x;h x]

    > >where f takes g x and h x to produce r.

    >

    > Okay...  I think.

    f takes two arguments:  g of x, and h of x.

    >

    > >if i don't want to write

    > >        x dup g swap h f

    > >(and i don't!)

    >

    > ...which seems to be a problem.

    does an acculturated forth programmer "see" x dup g swap h f

    as f[g x;h x]?  i would expect the answer to be yes.

    >

    > >then i need to have an "apply" combinator of

    > >for each pattern of application:

    > >        x g h f apply_f_to_g_and_h

    >

    > That won't work -- try

    >

    > x [g] [h] [f] apply_f_to_g_and_h

    right.

    >

    > (Or something related.)

    >

    > >i have no idea how forth programmers deal with this kind of

    > >thing (i would like to hear from one of you).

    >

    > Well, we often go to the root of the problem, and learn to enjoy writing

    > things like "x dup g swap h f".  Alternately, we can factor such that the

    > stack noise becomes an obvious part of the solution instead of just looking

    > like noise.

    this is intriguing.  i have to think about this.

    > It depends how much time we're willing to put in, and how

    > clearly we understand the problem (in this case there's nothing I can do,

    > since g, f, and h have no obvious meaning).

    and this.

    >

    > -Billy

    >

    > ------------------------------------------------------------------------

    > Buy Long Distance with your GROUP and SAVE!!!

    > http://click.egroups.com/1/4123/6/_/_/_/960330133/

    > ------------------------------------------------------------------------

    >

    > To unsubscribe from this group, send an email to:

    > concatenative-unsubscribe@egroups.com

    >

    >

    >

    >

## wtanksley@bigfoot.com — 2000-06-07 17:36:51

    From: stevan apter [mailto:apter@...]

     >From: <wtanksley@...>

    >> From: stevan apter [mailto:apter@...]

    >> >From: <wtanksley@...>

    >> >> From: stevan apter [mailto:apter@...]

    >> >if i don't want to write

    >> >        x dup g swap h f

    >> >(and i don't!)

    >> ...which seems to be a problem.

    >does an acculturated forth programmer "see" x dup g swap h f

    >as f[g x;h x]?  i would expect the answer to be yes.

     Well...  Let me ask a parallel question.

    Does a native Greek speaker "see" 'naus' as 'boat'?

    The answer is "yes and no".  The native Greek speaker doesn't translate to

    English before he understands the words of Greek; however, when he sees

    'naus' he may get a picture in his head which looks very much like the

    picture I get in my head after seeing 'boat'.

    In the same way, a competent Forth programmer doesn't translate to k or

    anything like it; as long as you're still translating, you're not yet a

    "native speaker."  However, in the sense that the same basic concept is

    being communicated, the Forth programmer sees the same thing in "x dup g

    swap h f" as the k programmer sees in "f[g x;h x]".

    Of course, the concepts being communicated are not exactly equal, as in all

    real languages.  The language itself applies some definitions to one phrase

    which are not in the other.

     >> >i have no idea how forth programmers deal with this kind of

    >> >thing (i would like to hear from one of you).

    >> Well, we often go to the root of the problem, and learn to

    >> enjoy writing

    >> things like "x dup g swap h f".  Alternately, we can factor

    >> such that the

    >> stack noise becomes an obvious part of the solution instead

    >> of just looking

    >> like noise.

    >this is intriguing.  i have to think about this.

     I assume you're talking about the second part, the one about "factoring".

    Yes, it is an intriguing part of Forth.

    While I was developing the [dip] proof (which turned out to be wrong), I

    built some preliminary words which had a lot more stack noise.  In the

    process of undertsanding the problem better I managed to reduce the stack

    noise down to almost nothing.  This is typical.

    Also typical is moving stack noise into a word, and at the same time

    changing the name of the word.  As an example, I had the word "cons", but I

    had the phrase "[] cons cons".  This is list noise, not stack noise, but the

    idea is the same; I disliked the echoed "cons", so I moved "[] cons" into a

    new word of its own, and the following cons into the definition of the word

    following it.

    The nice thing is that with concatentive languages this is always guaranteed

    to work: there are no variables to rename, so shuffling words around (so

    long as you don't change their order of execution) never changes the

    behavior of a program.  This doesn't work with applicative languages; read

    the book "Refactoring: Improving the design of existing code" to see what

    you have to do instead (I highly, highly recommend that book!).

     >> It depends how much time we're willing to put in, and how

    >> clearly we understand the problem (in this case there's

    >> nothing I can do, since g, f, and h have no obvious

    >> meaning).

    >and this.

     Let me give you an example of a refactoring done _without_ understanding of

    the real meaning of the words.

    In the Joy papers there's a lot of times where "swap cons" occurs.  The

    author noted that, but rather than analysing the individual words and

    inventing a name which was appropriate for each case, he chose the generic

    word "swons".

    This would be like me renaming "g" as "dgs" and removing the "dup" and

    "swap" from around it.  It works; it simplifies the final statement of the

    solution -- but it doesn't clarify the solution.  Suppose, on the other

    hand, the problem's name for 'g' was "derivative".  A Forth programmer might

    name his solution word "prime", and define it as "dup g"; this is the same

    as the definition of "dgs", but now the word's name expresses something in

    the problem space.

      x prime swap h f

    This is not exactly a good example either -- I came up with it on the fly.

    The worst aspect of it is that the word 'prime' says nothing to connote that

    it's preserving the value of x on the stack.  It's said that a good Forth

    programmer keeps a thesaurus and dictionary on the desk next to him.  This

    is true.  I don't have either next to me.

    This, as Musashi would say, requires some thought.

    -Billy

## srenner@mail.ru — 2000-06-07 17:55:09

    --- In concatenative@egroups.com, wtanksley@b... wrote:

     >

    > Does a native Greek speaker "see" 'naus' as 'boat'?

    >

    > The answer is "yes and no".  The native Greek speaker doesn't

     translate to

     > English before he understands the words of Greek; however, when he

     sees

     > 'naus' he may get a picture in his head which looks very much like

     ...

    The idea that words have their meanings by virtue of pictures in the

    head is wrong. How do we know there are pictures? How do we know that

    they are in the head? How does the picture correspond to the thing

    denoted by the word? How could a picture which we can't see look like

    anything? This is irrelevant to the list topic, but I felt that I had

    to say something.

## iepos@tunes.org — 2000-06-07 19:06:30

    One thing I thought I'd chime in on ...

     > >does an acculturated forth programmer "see" x dup g swap h f

    > >as f[g x;h x]?  i would expect the answer to be yes.

    >

    > [...]

    >

    > In the same way, a competent Forth programmer doesn't translate to k or

    > anything like it; as long as you're still translating, you're not yet a

    > "native speaker."  However, in the sense that the same basic concept is

    > being communicated, the Forth programmer sees the same thing in "x dup g

    > swap h f" as the k programmer sees in "f[g x;h x]".

     You both are speaking as if "x dup g swap h f" were the Forth analogue

    of the k "f[g x;h x]" ... If I understand the k, it seems like

    the equivalent Forth would just be:

      x h x g f

    There is no need to bring combinators like "dup" and "swap" into this

    unless it is necessary to abstract out the "x". If "f", "g", "h", and "x"

    are all specific objects (not variables) such as number literals and

    operators like "+" and "square", then it seems like you could

    just write it as that.

    But then, if the "x" is not a specific object, but is taken from the stack

    at runtime, then we would need to try something else. If Forth used

    lambdas, then we'd do something like

      x\ x h x g f

    Where the "x\" is my made-up lambda word, read as "pop the top item

    off the stack and call it 'x'". Of course, using lambdas would probably

    not be consistent with the spirit of Forth. So, instead we'd probably

    want to use combinators; as you've already suggested, "dup g swap h f"

    would probably work. Here's an alternative that seems simpler to me:

      [g] sip h f

    "g" would be ran with the "x" on the stack, but an extra copy of "x"

    would be preserved by "sip" for "h".

    - "iepos" (Brent Kerby)

## wtanksley@bigfoot.com — 2000-06-07 19:18:47

    From: iepos@... [mailto:iepos@...]

     >> >does an acculturated forth programmer "see" x dup g swap h f

    >> >as f[g x;h x]?  i would expect the answer to be yes.

    >> [...]

    >> In the same way, a competent Forth programmer doesn't

    >> translate to k or

    >> anything like it; as long as you're still translating,

    >> you're not yet a

    >> "native speaker."  However, in the sense that the same basic

    >> concept is

    >> being communicated, the Forth programmer sees the same thing

    >> in "x dup g

    >> swap h f" as the k programmer sees in "f[g x;h x]".

    >You both are speaking as if "x dup g swap h f" were the Forth analogue

    >of the k "f[g x;h x]" ...

     No, I'm not.  I not only weasel-worded by saying "in the sense that the same

    basic concept is being communicated...", but I also mentioned that the two

    languages give entirely different meanings to isolated scraps of text.  The

    meaning of that text can be drastically changed by what appears before and

    after it, and the two languages do that differently.

     >If I understand the k, it seems like

    >the equivalent Forth would just be:

    >  x h x g f

     That's closer than the original translation, but it's still not exact.

    Your point is accurate, though, at least that far.

     >- "iepos" (Brent Kerby)

     -Billy