I thought this might interest some concatenative people. The virtual
currency Bitcoin has a stack based scripting language built in for
creating transactions. The intent was to allow extending the types of
transactions (other than just "send money to address X") via scripting
to allow various types of contracts, escrow, etc. Some information on
the language is here: https://en.bitcoin.it/wiki/Script

Recently there has been discussion on adding an 'eval' feature that
allows popping a program off the stack and executing it. This is
similar to concatenative languages like Joy. the general proposal is
here: https://en.bitcoin.it/wiki/BIP_0012

This has raised some discussion on the bitcoin development mailing
list about whether this gives the scripting language too much power.
Can it now be used to create loops or otherwise work around some of
the existing languages constraints and subvert the bitcoin transaction
system. Discussion is on this mailing list post:
http://sourceforge.net/mailarchive/message.php?msg_id=28602033

This is an interesting example of stack based languages in real world systems.

Chris.
--
http://www.bluishcoder.co.nz

The Sieve of Eratosthenes has been mentioned earlier in this newsgroup, but I didn't see a solution in Joy. Here is mine:

(*
popen ( Q -> ) starts a new task. The stdout of the current
task is connected to the stdin of the new task.
*)
DEFINE sieve == get dup put [sieve] popen
[] [get [swap mod] [put] [pop] ifte] while.

DEFINE count == 2 [] [dup put succ] while.

[sieve] popen count.

Of course, there is no such thing as a multi-tasking version of Joy,
but maybe this example shows that it worth the trouble building such
a thing. Is it?

The Sieve has been mentioned before in this newsgroup, but I didn't see a solution in Joy. Here is my proposal.

(* popen ( Q -> )

I've updated 5th's entry on the concatenative wiki with a (very) short description of its type system for anyone who's interested:

https://concatenative.org/wiki/view/5th

No, I'm not still working on it. Has been dead for years now.

- jn

On Mon, Oct 3, 2011 at 8:34 PM, maggethun <phimvt <at> gmail.com> wrote:
> Dear Friends,
>
> my health has been going down rapidly for a while,

I am very sorry to read this, take care of yourself!

> So, Slava, this is my tribute to your work.

What generous spirit!

> Anyhow, well done.
Indeed, Slava's work is a major accomplishment.

> And what should happen to Joy?

The Joy of Joy to me was always it's startling simplicity.

It was a much needed clarion call indicating, nay DEMONSTRATING, that
the march to ever more complex languages is ill advised.

Even better, Joy demonstrated that simplicity carried deep value.

As such I hope it is always around to admonish the industry.

> Besides, I am too frail
> now and don't have the energy for any major project.

Take it easy, and many thanks for your many contributions and your
kind, gentle and ever informative replies to me and others over the years.

--
John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter <at> taitradio.com
New Zealand

--
John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter <at> taitradio.com
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================

Dear Friends,

my health has been going down rapidly for a while,
I could no longer travel to my Uni, barely coped
with looking after myself, until I decided to go
into a home where I am treated exceptionally well.
I got myself a computer, internet, email again
with username phimvt, but provided by google (gmail).
So, this is my first email to the group.

La Trobe has re-organised all its web pages according
to some templates imposed from above. That meant that
a lot, not just mine, became disconnected and resulted
in many dead links all over the web. After some quite
exhausting negotiations my own pages were reconnected
with a small change: the "philosophy" part of my
pages is no longer operative. My homepage is now
www.latrobe.edu.au/phimvt/
and the Joy pages just have "joy/" appended.

I want to use this my first email to the group to do
what I should have done years ago. Slava Pestov has
designed and implemented his Factor language over
quite some time now. The result is a most impressive
piece of work. The design goes well beyond what I
ever dreamed of for Joy, and the implementation is
professional and clearly far superior than that of Joy.
There is already a huge library for all sorts of things.
And, very importantly, there are many users who are
contributing in one way or another.

So, Slava, this is my tribute to your work. I also
want to congratulate you on your Master's. I tried
to read some early bits of your thesis, but had to
look up "direct sum of vector spaces", and shortly
after that I just gave up. Anyhow, well done.

And what should happen to Joy? With a far superior
alternative around, it would be pointless for me
to patch up the existing Joy either as the language
or in the implementation. Besides, I am too frail
now and don't have the energy for any major project.
Should somebody else design a kind of Joy2? Maybe,
but probably not. It would have to be significantly
different from Factor to make it worthwhile. But I
don't know Factor well enough to say what could be
different enough for that. However, I do think that
in the Joy libraries there are a few techniques
(especially continuations to implement backtracking)
that are useful. Maybe these should be translated
into Factor.

I hope all you members of the group are thriving.
I'll be around again!

- Manfred

... now that La Trobe has changed its URLs?

(I mean the stuff that was at:

http://www.latrobe.edu.au/philosophy/phimvt/joy.html)

If La Trobe dumped his stuff, I hope someone has a full copy of it.

If not, I have some of it, and I'd bet that others have parts of it, so it seems likely that we could reconstruct it somewhere (perhaps with a better home page).

Also, is Manfred himself still around (the last post here from him seems to have been in 2008)? I have a La Trobe e-mail address for him, but, I'm a little worried that he may not want to be bothered.

Is anyone here keeping in contact with him?

--Chris Cogan

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

Just a heads up that the Joy [1] and Cat [1] wikipedia pages have been
requested to be deleted by Christopher Monsanto [2]. If you have any
notability information now is the time to bring it up:

[1] http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Deletion_sorting/Computing#Joy_.28programming_language.29
[2] http://en.wikipedia.org/wiki/Cat_(programming_language)
[3] http://en.wikipedia.org/wiki/User:Christopher_Monsanto

Chris.
--
http://www.bluishcoder.co.nz

On Mon, Jan 31, 2011 at 6:11 PM, Justin <zallambo <at> yahoo.com> wrote:

>
>
> > What may be interesting and useful would be to return to typed variables
> > (named values variety) and something like a SQL "natural join".
>
> I don't know what you mean. Could you give an example? (I don't have a good
> mental model of databases.)
>

The truely irritating thing about both stack languages, and the more
traditional languages with named parameters, is that the order of the
parameters and the names don't really matter.

Given any program P in a stack or traditional language, you can reorder
and/or rename the parameters of every function anyway you choose... and come
up with another program that does EXACTLY the same thing, so long as you
carry through the renaming through the the body of each function and the
reordering into every invocation of the function.

In stack languages without parameter names, your program will _look_
radically different as there will be a flock of stack manipulation operators
different.

ie. In a very strong sense, parameter names and parameter order is fluff and
irrelevant to the actual computation being performed!

Thus my mathematical gut feeling is, one should be able to eliminate it
_all_ in some representation.

I could be unconstructive an give you a lmgtfy link about natural joins, but
let me rather discard the SQLish analogy and try say what I mean in a
stackish language.

Well, a lot of stack languages (Factor is a very good example) give the
stack effect for each function as something like...

fn: T1, T2, T3... -> T4, T5... where I mean fn is a function that pops
parameters of type ..., T3, T2, T1 off the stack, in that order and pushes
objects of type T4, T5, .. onto the stack in that order.

Well, lets add some names...

fn: i1 T1, i2 T2, ...-> o4 T4, o5 T5, ...

Where I am naming my input parameters i1, i2, ... and my output values as
o4, o5, ...

Now a fragment of any stack language code tends to look like....

fn1 stackOp1 stackOp2, ... fn2

where all the stackOps rearrange the stack as it was left by fn1 and it's
predecessors, so as to feed fn2 correctly.

However, it you were to look at the stack effect declarations for fn1, and
fn2, it would probably be obvious from the types alone, as which stackOps
you would need between fn1 and fn2!

And if the types alone weren't enough to tell you, the names certainly
would!

Thus in principle one could create a language where you could write a
fragment as fn1 fn2 and the compiler could infer what stackOps (or calling
parameters and their order) are required.

--
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter <at> taitradio.com
New Zealand

=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================

[Non-text portions of this message have been removed]

On Mon, Jan 31, 2011 at 1:20 PM, Justin <zallambo <at> yahoo.com> wrote:

> Hello. Is this forum still alive? I haven't shown my head here for a couple
> of years. I'm a MA/CS major with an ongoing interest in giving concatenative
> languages a firmer mathematical foundation. I have a few partial results:
> (i) an operational semantics, (ii) a concept of & application for
> homomorphisms, (iii) a type system. Is anyone else around here interested in
> this sort of research? Here's a link to my (ongoing) work,
>
> http://dl.dropbox.com/u/17328602/concat/index.html
>
>
Some small comments...

> There are no variables. I have the impression that variables are a
> difficult concept to grasp. We spend years teaching students about variables
> in math class, and even in college many students have difficulty
> understanding that (lambda x. x) and (lambda y. y) are identical. This is
> certainly a double-edged sword - variables are a powerful reasoning aid -
> but I am nonetheless interested in glimpsing a world free of variables.
>

One major problem with variables is not variables themselves, but the
existence of two entirely different concepts overloaded with the same name.

- Half the time we mean "named storage location" and the other half the
time we mean "named value". The "named storage location" notion of variables
implies a stateful system and all the attendant difficulties in analysis.
- The "named value" notion of variables is a convenience that allows us
to remove the irrelevant computational fluff of stack manipulations from our
expressions.

"Concatenative" refers to the syntactic sugar (glucose?, alcohol?) of
choosing a syntax in which function composition is represented by string
concatenation.

I invite you to contemplate what these languages are in the absence of a
string representation. (For example, at one higher level of abstraction a
concatenative language is one where functional composition is represented by
the concatenation of two lists of tokens. But I'm sure we can abstract it
well away from the representation.)

The neatness of concatenative program fragments often arises from a
carefully pre-chosen alignment of the output values of the previous function
with the input requirements of the next.

Where it doesn't align neatly, we need a bunch of stack manipulating "fluff"
that adds nothing to computation.

What may be interesting and useful would be to return to typed variables
(named values variety) and something like a SQL "natural join".

99% of the time which function result variable, needs to be bound which
input variable, is obvious and can be automatically inferred from their type
and name.

By making the rules for doing this explicit, you should be able to create a
concatenative language that doesn't involve the notion of a stack, nor are
the program fragments cluttered with irrelavent variable name references or
stack manipulation "fluff".

I would argue that any language where the function definitions are cluttered
with stack manipulations OR variable references has NOT yet met the full
promise of concatenative languages.

--
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter <at> taitradio.com
New Zealand

=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================

[Non-text portions of this message have been removed]