<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative">
    <title>gmane.comp.lang.concatenative</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3703"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3702"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3701"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3700"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3699"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3698"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3697"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3696"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3695"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3694"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3693"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3692"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3691"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3690"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3689"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3688"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3687"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3686"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3685"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.concatenative/3684"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3703">
    <title>[stack] SPREAD: another kid on the block</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3703</link>
    <description>&lt;pre&gt;Let me introduce a new (concatenative?) programming language called SPREAD.
SPREAD has - what I believe - many properties that might interest you.

SPREADs most exciting property is its 'retroactive' property, which means that:

1) values may keep a reference to the historical computation(s) that lead has led to themselves. Such history is called a trace.
2) traces (and traces of traces) can be rolled back, for instance when replacing 'historical' values with 'future' values.
3) a trace that is rolled back (and then slightly altered) can be re-evaluated, thus creating a new trace.

Such web of traces most likely resembles a version control system where developers create branches, do merges, etc.
In SPREAD, such version control is 'built-in'.

But SPREAD has more desirable (programming language) properties:

1) Spreadsheet-like
2) Immutable
3) Declarative
4) Incremental
5) Reversible
6) Scaleable
7) Exception-less
8) Total (non-Turing complete)
9) Appealing (syntax)

For me personally, postfix format is the m&lt;/pre&gt;</description>
    <dc:creator>Robbert van Dalen</dc:creator>
    <dc:date>2013-05-11T21:36:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3702">
    <title>[stack] New discussion group for concatenative and stack languages</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3702</link>
    <description>&lt;pre&gt;Just for the fun of it, I've created a Google+ "Community" for us. If you'd like to help me try it out, please feel free to swing on by.

https://plus.google.com/communities/102133861060475683875

-Wm


&lt;/pre&gt;</description>
    <dc:creator>William Tanksley</dc:creator>
    <dc:date>2013-01-14T22:40:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3701">
    <title>Re: [stack] Introducing the Om language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3701</link>
    <description>&lt;pre&gt;I've filled out the Om documentation to hopefully clarify how the whole thing works and explain it from a concatenative standpoint.

http://sparist.github.com/Om/


Please let me know if you still have any questions about how the language works, or any suggestions. Thanks for all the feedback.


Jason

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

&lt;/pre&gt;</description>
    <dc:creator>Jason Erb</dc:creator>
    <dc:date>2013-01-06T20:32:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3700">
    <title>Re: [stack] Introducing the Om language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3700</link>
    <description>&lt;pre&gt;Fixing formatting issues in the last message...

Some examples of valid operators:


operator

o`p`e`r`a`t`o`r

an` operator

an` operator` with` `{braces`}

an` operator` with` a`
new` line


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

&lt;/pre&gt;</description>
    <dc:creator>Jason Erb</dc:creator>
    <dc:date>2013-01-05T19:40:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3699">
    <title>Re: [stack] Introducing the Om language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3699</link>
    <description>&lt;pre&gt;William,


Thanks for the in-depth questions.  Discussions like this are extremely helpful in figuring out what I need to explain better in the documentation.


the least elementary part of the language (the escape codes) look like
the primary, and hides everything else. Do those escape codes do
anything?

I'll try to explain this better.  I think that by "escape codes" you are referring to the characters in an operator, which may be escaped.

An operator is any UTF-8 string.  However, some characters need to be escaped with a backquote - these include space, tab, and new line (because these are separator characters), curly braces (because these enclose operands), and backquotes (because this is the escape character).  Any other character can be escaped with a backquote, but this is a no-op (e.g. "`o`p`e`r`a`t`o`r" resolves to "operator"). Some examples of valid operators:
operator


A separator is any string comprised of the space, tab and/or new line characters.

An operand is any program (made of oper&lt;/pre&gt;</description>
    <dc:creator>Jason Erb</dc:creator>
    <dc:date>2013-01-05T19:39:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3698">
    <title>Re: [stack] Re: Introducing the Om language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3698</link>
    <description>&lt;pre&gt;Thanks for the good words and the addition at concatenative.org.  I hadn't realized that editing was open for all -- I've created an account and filled in the description a bit.  (I finally figured out editing in the sidebar: you have to click the Contents heading.)

About the website: I can't take a lot of credit here -- most of it is generated by Doxygen from markup in the C++ code.  I highly recommend Doxygen for this.

About the "minutes" example: you're right.  That is very confusing for someone who doesn't already know the language (i.e. everyone except me).  I've updated the website to show how that one is evaluated, step by step.  Let me know if it still isn't very well explained.

Cheers,
Jason



________________________________
 From: Ruurd &amp;lt;r.wiersma26&amp;lt; at &amp;gt;kpnplanet.nl&amp;gt;
To: concatenative&amp;lt; at &amp;gt;yahoogroups.com 
Sent: Saturday, January 5, 2013 5:06 AM
Subject: [stack] Re: Introducing the Om language
 

  
Hi,

It is nice to see some activity here. An impressive web site you have there. Makes me feel l&lt;/pre&gt;</description>
    <dc:creator>Jason Erb</dc:creator>
    <dc:date>2013-01-05T18:46:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3697">
    <title>Re: [stack] Introducing the Om language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3697</link>
    <description>&lt;pre&gt;
It looks cool and fun, and I'd like to see examples for something more
than swap and copy.

Until I see more, I'll say that it looks like a language in Backus' FP
/ FL tradition (APL, Rebol, J, K), although true to your goals it
looks like you've done some nice simplification. It might be
concatenative, I don't know.


That seems like an appropriate way to describe it :-).


It took me a long time to figure out your syntax... The graph makes
the least elementary part of the language (the escape codes) look like
the primary, and hides everything else. Do those escape codes do
anything?

Aside from that: I see that a valid program will begin with a dequoted
symbol, and everything else will be quoted. That means that
concatenating two valid programs does NOT produce a syntactically
valid program, and thus the language is not concatenative. But I'm
still confused by the syntax, so maybe I'm wrong.


An elegant left-turn.


Ah, I do that in my useless language. But like Jot and Iota and unlike
Om, my language is&lt;/pre&gt;</description>
    <dc:creator>William Tanksley, Jr</dc:creator>
    <dc:date>2013-01-05T17:05:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3696">
    <title>[stack] Re: Introducing the Om language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3696</link>
    <description>&lt;pre&gt;Hi,

It is nice to see some activity here. An impressive web site you have there. Makes me feel like an amateur. Now, about concatenative.org. I have managed to create a page for Om. After all, it is a wiki, so everybody can add or change or delete a page. But I have not been able to edit the contents page. I also do not get an error message, so I don't know why that is. Now, about the language Om. In get lost in the example of minutes. Can you show a trace of the individual steps during evaluation ?

Rw

--- In concatenative&amp;lt; at &amp;gt;yahoogroups.com, Jason Erb  wrote:

&lt;/pre&gt;</description>
    <dc:creator>Ruurd</dc:creator>
    <dc:date>2013-01-05T10:06:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3695">
    <title>[stack] Introducing the Om language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3695</link>
    <description>&lt;pre&gt;Dear Concatenativists,

I've developed a unique concatenative language that I would like to share:

http://om-language.org

The goal was to find "God's programming language": the simplest language possible (mostly so that I could actually implement it) without sacrificing power (as contrasted with languages like Iota and Jot, which are fundamentally simple but don't have basics like named functions).  This led to concatenative languages, but Om has taken a few left turns where other concatenative languages have gone right:
- An Om program has only three syntactic elements: operator, operand, and separator.
- Om uses prefix syntax rather than postfix.
- The only data type exposed by the language is a program.
- Each function takes as input the rest of the program that it is in.

There is more information on the design, and rationale, in the documentation at http://sparist.github.com/Om .  The language is in an early development stage, and the documentation is not as full as I would like yet -- there is &lt;/pre&gt;</description>
    <dc:creator>Jason Erb</dc:creator>
    <dc:date>2013-01-03T06:22:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3694">
    <title>[stack] Re: Manfred von Thun</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3694</link>
    <description>&lt;pre&gt;

--- In concatenative&amp;lt; at &amp;gt;yahoogroups.com, John Cowan &amp;lt;cowan&amp;lt; at &amp;gt;...&amp;gt; wrote: 

That's right, 2011, over a year ago. I could not, though, find that information anywhere on this forum, thought it should belong here.

-EF

&lt;/pre&gt;</description>
    <dc:creator>efliski</dc:creator>
    <dc:date>2012-12-05T08:52:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3693">
    <title>Re: [stack] Manfred von Thun</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3693</link>
    <description>&lt;pre&gt;efliski scripsit:


Note that this was 23 October 2011.

&lt;/pre&gt;</description>
    <dc:creator>John Cowan</dc:creator>
    <dc:date>2012-12-05T07:02:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3692">
    <title>[stack] Manfred von Thun</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3692</link>
    <description>&lt;pre&gt;http://hosted.verticalresponse.com/291390/14a69b5ba4/1473484945/be83724914/#news

"Vale Manfred  - the philosophical programmer

Alumni and staff will be saddened to hear of the death of Manfred von Thun on 23 October after a long illness.  Manfred was a member of the philosophy department from early 1972 until his retirement in 2003, but remained an honorary associate until 2009. Manfred specialised in logic, philosophy of science, philosophy of mind, computer programming and cybernetics. He was also renowned for developing the computer programming language, Joy. He will be sadly missed."

&lt;/pre&gt;</description>
    <dc:creator>efliski</dc:creator>
    <dc:date>2012-12-05T06:38:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3691">
    <title>[stack] (unknown)</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3691</link>
    <description>&lt;pre&gt;http://thethingsthatieat.com/wp-content/themes/sight/googlemail.html

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

&lt;/pre&gt;</description>
    <dc:creator>Irfan Azher</dc:creator>
    <dc:date>2012-06-14T01:43:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3690">
    <title>Re: [stack] peg: a lazy, non-deterministic concatenative language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3690</link>
    <description>&lt;pre&gt;

--- In concatenative&amp;lt; at &amp;gt;yahoogroups.com, Joshua Shinavier &amp;lt;parcour&amp;lt; at &amp;gt;...&amp;gt; wrote:


Peg also uses lazy evaluation, but the pureness of the language means that:

    1 2 +
    3
    7 4 -

are all equivalent and indistinguishable, whether evaluated or not, because observing them requires evaluation.

Because expressions need to terminate first in order to use the Cartesian composition rule, non-termination does not pose a problem either.

Also, in Peg, an expression will not reduce, rather than yielding no solutions, if an argument to a word is missing i.e. the expression is a partially applied function.  So,

    10 + --&amp;gt; 10 +

which is different from

    "ten" + --&amp;gt; no (no results)

&lt;/pre&gt;</description>
    <dc:creator>dustin.deweese</dc:creator>
    <dc:date>2012-04-25T11:38:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3689">
    <title>Re: [stack] peg: a lazy, non-deterministic concatenative language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3689</link>
    <description>&lt;pre&gt;

--- In concatenative&amp;lt; at &amp;gt;yahoogroups.com, eas lab &amp;lt;lab.eas&amp;lt; at &amp;gt;...&amp;gt; wrote:

This is why I prefer a pencil to a pen.

Oh well. Point and laugh.


I considered having separate stacks for each type in Peg.  Each argument to a word would be taken from the appropriate stack depending on the type required. Then, values could be wrapped in semantic types to minimize stack manipulation.

For instance a word 'greeting' could require a 'name' and a 'title', both of which are simply wrappers for strings, and the greeting would return "Hello [title] [name]!" regardless of the order of arguments. It would just use the title and name on the top of their respective stacks.

I decided against this, because it would complicate many other things.

&lt;/pre&gt;</description>
    <dc:creator>dustin.deweese</dc:creator>
    <dc:date>2012-04-25T11:12:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3688">
    <title>Re: [stack] peg: a lazy, non-deterministic concatenative language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3688</link>
    <description>&lt;pre&gt;Didn't anybody pick up this 'typo'?

Think rather in term of the 'most recent' element.

] We know concatenative languages that use an accumulator and ones that
] use a stack; we also know ones that use multiples of each (for example,
] ANS Forth can have a separate floating point stack, and Machine Forth
] uses a memory fetch register; note that the return stack in Forth does
] NOT count, since accessing that makes the program NOT concatenative).
I disagree: it's the concept of LIFO/most-recent, and not the implementation
details, that count..

Consider the following real-life-task:
papers are 'stacked' in their order of creation;
we need to present them to the emperor in their order of creation;
so we could sequentially 'pop' them to another 'pile';
and than 'pop &amp;amp; present' from that 'pile'.

NB. I distinguish between the stack and the pile;
where the pile is stack2 of pop(stack).

If some of the papers may not be handled by the 'presenter',
they could be piled on a separate/floating-point-pile.

But then &lt;/pre&gt;</description>
    <dc:creator>eas lab</dc:creator>
    <dc:date>2012-04-25T09:54:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3687">
    <title>Re: [stack] peg: a lazy, non-deterministic concatenative language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3687</link>
    <description>&lt;pre&gt;On Fri, Apr 20, 2012 at 1:21 PM, William Tanksley, Jr &amp;lt;wtanksleyjr&amp;lt; at &amp;gt;gmail.com


Present, just lazy :-)

That's an interesting property, but it's not true of Ripple, and lazy
evaluation is the reason it's not true.  Suppose we split a Ripple program
arbitrarily and evaluate the fragments, e.g.

    4 sqrt. 10 add.

to

    4 sqrt.

and

    10 add.

They're both valid programs, yet the right-hand-side program has no
solutions while the complete program has two solutions ([8] and [12], or
(8) and (12) in Ripple syntax).  Any time the right-hand-side does have a
solution, e.g. if the program had been (4 sqrt. 10), which is already fully
reduced, the left-hand-side will never be reduced in the complete program,
so it doesn't matter what its solutions are.

If Ripple used an eager evaluation strategy instead, the "cartesian
composition" rule would more or less hold.


Best,

Josh






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



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

Yahoo! Groups Links

&amp;lt;*&amp;gt; To visit y&lt;/pre&gt;</description>
    <dc:creator>Joshua Shinavier</dc:creator>
    <dc:date>2012-04-23T04:24:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3686">
    <title>Re: [stack] peg: a lazy, non-deterministic concatenative language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3686</link>
    <description>&lt;pre&gt;



--- In concatenative&amp;lt; at &amp;gt;yahoogroups.com, "William Tanksley, Jr" &amp;lt;wtanksleyjr&amp;lt; at &amp;gt;...&amp;gt; wrote:


The stack for any particular execution path has a total ordering.  You could use non-determinism to make the stack appear only partially-ordered, though, with an expression such as:

1 2 3 [] [swap] \/ $


The second rule wasn't worded very well.  I tried to make it more precise:

2. The composition of two sub-expressions is equivalent to concatenating each of the Cartesian products of the results of evaluating the sub-expressions individualy.

See this wiki page (https://github.com/HackerFoo/peg/wiki/Properties-of-Peg) for an example, as well as other information on the properties of Peg you might find interesting.

&lt;/pre&gt;</description>
    <dc:creator>dustin.deweese</dc:creator>
    <dc:date>2012-04-22T21:09:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3685">
    <title>Re: [stack] peg: a lazy, non-deterministic concatenative language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3685</link>
    <description>&lt;pre&gt;

That's a clever approach. Although I liked it at first glance, I think
it's not quite complete. We know concatenative languages that use an
accumulator and ones that use a stack; we also know ones that use
multiples of each (for example, ANS Forth can have a separate floating
point stack, and Machine Forth uses a memory fetch register; note that
the return stack in Forth does NOT count, since accessing that makes
the program NOT concatenative). The problem is that the choice between
stack and accumulator changes the language in a profound way. So if it
were possible to arrange a queue in some way instead of a stack, what
would the resulting language look like? We have no semantics for such
a language (yet).

I'm also thinking about the statement that there should be only one
unambiguous "top" element. This is essentially right, of course;
accepting that when there are two top elements they can be
disambiguated by the word that's needing the data (as with ANS Forth's
floating point vocabulary, whose words m&lt;/pre&gt;</description>
    <dc:creator>William Tanksley, Jr</dc:creator>
    <dc:date>2012-04-20T17:21:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3684">
    <title>Re: [stack] peg: a lazy, non-deterministic concatenative language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3684</link>
    <description>&lt;pre&gt;

--- In concatenative&amp;lt; at &amp;gt;yahoogroups.com, "William Tanksley, Jr" &amp;lt;wtanksleyjr&amp;lt; at &amp;gt;...&amp;gt; wrote:

The stack works essentially as a sort of caching structure.  Whichever caching strategy you choose determines the data structure.

Last in, first out = queue
Highest/lowest weighted out = priority queue
First in, first out = stack
There can be only one = a single item (accumulator)

I can't think of any other strategies that have a single unambiguous "top" element.  FIFO seems to be the only reasonable caching strategy, though.


Peg is a pure functional language, so it doesn't matter if a1 is executed if a2 yields no results; the execution of a1 has no observable effects.  The exception is if a1 performs I/O.  Unfortunately, I can't see any way to fix this, because the Peg interpreter could never perform any I/O for fear of an unseen 'False assert' being concatenated to the right.

For Peg, it is formally concatenative with some modifications:

1. The expression to the right must be fully evaluated before evaluation of &lt;/pre&gt;</description>
    <dc:creator>dustin.deweese</dc:creator>
    <dc:date>2012-04-19T08:53:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.concatenative/3683">
    <title>Re: [stack] peg: a lazy, non-deterministic concatenative language</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.concatenative/3683</link>
    <description>&lt;pre&gt;
That's a good question. You'd have to provide more structure than a
simple "graph", since a graph has no orientation. Obviously you've got
a root and at least one current position... But how do branches
happen, and how do mergers happen?


Since hackerfoo just joined the group, we may be soon receiving an
answer! I look forward to it.

-Wm
&lt;/pre&gt;</description>
    <dc:creator>William Tanksley, Jr</dc:creator>
    <dc:date>2012-04-19T05:49:57</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.concatenative">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.concatenative</link>
  </textinput>
</rdf:RDF>
