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