[stack] Canonical LLVM starter language is concatenative...

[William Tanksley, Jr]

http://llvm.org/releases/1.1/docs/Stacker.html

I just found this... As of 1.1, LLVM includes as one of its primary
examples a "Forth-like" language that might possibly serve as the
foundation for a more complete concatenative language. It's very
Forthlike, I'd say.

Just in case anyone wants to start a new project :-).

Personally, I'm a little busy learning the J language, which isn't
concatentive but is from a remarkably different genre of languages
than the conventional ones. I'm starting this now because I just found
that JSoftware released it completely as free software (licensed under
GPL 3), so at last I can learn a complete APL and know that I'll be
able to use it effectively in my job if I want. (As a side note,
someone also recently released an open source reimplementation of the
related "K" language, named "Kona"; I'd start with that, but it's
currently much less complete.)

-Wm

[eas lab]

Good advice that I once got from a lawyer was "don't vague out".
I.e. don't talk in 'hints'. Give the reader/listener something concrete.
Add value. BTW if N readers all add value independantly, that's like
a compositional N-stage data-transformation.

Can your new find/s, compositionally [i.e. serially data-transforming like]:
find all the files in dir-tree:T |
which are less than D days old |
and which have fileName *Name* |
and which have a line which _starts_ with "Subject:" |
and where _that_ line has "dog" and has "cat"
OR where _the Subject: line_ has "fish" AND "cow".

Post by William Tanksley, Jr
http://llvm.org/releases/1.1/docs/Stacker.html
I just found this... As of 1.1, LLVM includes as one of its primary
examples a "Forth-like" language that might possibly serve as the
foundation for a more complete concatenative language. It's very
Forthlike, I'd say.
Just in case anyone wants to start a new project :-).
Personally, I'm a little busy learning the J language, which isn't
concatentive but is from a remarkably different genre of languages
than the conventional ones. I'm starting this now because I just found
that JSoftware released it completely as free software (licensed under
GPL 3), so at last I can learn a complete APL and know that I'll be
able to use it effectively in my job if I want. (As a side note,
someone also recently released an open source reimplementation of the
related "K" language, named "Kona"; I'd start with that, but it's
currently much less complete.)
-Wm

[William Tanksley, Jr]

Post by eas lab
Good advice that I once got from a lawyer was "don't vague out".
I.e. don't talk in 'hints'. Give the reader/listener something concrete.
Add value. BTW if N readers all add value independantly, that's like
a compositional N-stage data-transformation.

What on earth are you talking about?

Post by eas lab
 find all the files in dir-tree:T |
 which are less than D days old |
 and which have fileName *Name* |
 and which have a line which _starts_ with "Subject:" |
 and where _that_ line has "dog" and has "cat"
 OR where _the Subject: line_ has "fish" AND "cow".

One of the "finds" is a demo language, so in order to do that stuff
you'd have to add support for that to the language's library -- not
worth your time, if that's the only programming task you have to do
(which it clearly is). The other two (Kona and J) can definitely do
all that, trivially; except for the minor point that they don't work
serially, but rather in parallel.

I haven't learned either one (and BTW, I'm not recommending them, but
rather pointing them out), so I can't help there. If you want to know
more, go to comp.lang.apl and ask (or go to one of their mailing
lists).

-Wm

[chris glur]

Post by William Tanksley, Jr
One of the "finds" is a demo language, so in order to do that stuff
you'd have to add support for that to the language's library -- not
worth your time, if that's the only programming task you have to do
(which it clearly is). The other two (Kona and J) can definitely do
all that, trivially; except for the minor point that they don't work
serially, but rather in parallel.

That's OK, if it examines the further attributes of the file, once
it's found that the 1st one is satisfied. But the *conceptually* serial
is AFAIK fundamewntal to compositional - or ?
Depth-first or breadth-first search could both probably do it.

The power [ie. economy of human effort] comes from the ability to
'string/pipe proven functions together'. And the clean incremental
development possiblity, by the fact that while developing satge N-1,
you don't need to worry/know how the previous N stages work.

And that is essentially serially CONCEPTUALLY.

Oh, and the next stage of this task, is to:
print out the <Subject: field> and the <location field> of the lines
that 'match'.

This is just a scheme that I dreamed up to:
be able to locate my paper docos which are dispersed over several locations,
filing cabinets, ...etc.

What made me so enthusiatic was the realisation that 'physical location'
maps PERFECTLY to the [*nix] file directory tree.
So if I move docoN from /roomR/shelfS/concertinaFile/pocketP to
/roomR2/FilingCabinet3/Drawer2/............
I just need to move the sub-tree. Which is one operation.
And with mc [my constant tool], I can *SEE* it move to its new location.
-----------------
That was wrong, but leaving the 'true log' adds value. Literate programming.
A doco is a node of the tree; which is less spectacular to move.
It's moving a parent node [sub tree] that impresses me.
Eg. moving the whole <S pocket> of the concertina file.
Which is an unlikely/senseless move.
Hey, I'm designing this while I'm writing - NOW.
Thanks for the opportunity to help solve this BIG problem.

How would you do it?

BTW *nix officionados write such one-liners all the time.

== Chris Glur.