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
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".
On 4/23/11, William Tanksley, Jr <wtanksleyjr@...> wrote:
> 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 <lab.eas@...> wrote:
> Good advice that I once got from a lawyer was "don't vague out".What on earth are you talking about?
> 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]:One of the "finds" is a demo language, so in order to do that stuff
> 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".
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
> One of the "finds" is a demo language, so in order to do that stuffThat's OK, if it examines the further attributes of the file, once
> 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.
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.