Nabble - Concatenative

Pipes and filters (was Re: A Joy VM in OCaml

2009-09-24T22:19:50Z

On Tue, 22 Sep 2009, chris glur wrote:

> This forum prompted me to investigate the power of
> linux 'pipe programming',
> which is astoundingly decetive.
> It's magically easy, for small jobs, but quickly becomes unmanageable.

Hmm. It's just another tool that sort of vanishes into the background
of stuff getting done. Go digging (hard) around a major unixy project
like gcc and you'll find pipes are quietly and unobtrusively used in
many places.

It's no panacea... but it it's a nifty solution to a largish pool of
commonly occurring problems.

I once wrote, before SQL became commonly and freely available, a
largish datamining project heavily using pipes and filters.

It was very similar to "NoSql", so rather than dig out my very old
programs to show you... let me just point you at NoSql.

http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page

Most database projects get hung up on the need to do updates. In the
datamining world your data is usually dumped from one or more upstream
databases and then you just digest that static dump.

Programming with pipes and filter database like nosql is a breeze. You
build up your pipeline one element at a time inspecting the output.

You can then tie it all together by dumping intermediate results in
files and use "make" to track dependencies and update things as is
needed.

However, I'm not sure how we got on to this....

I'm not sure "pipes and filters" are quite equivalent to
"concatenative" although the similarities and differences might be
interesting to explore.

A way to explore it may be looking at NoSql filter elements and some
of the nosql example pipelines.

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@...
New Zealand

Re: A Joy VM in OCaml

2009-09-22T08:13:55Z

chris glur <crglur@...> wrote:
> This forum seems to have died.

No, it's just a slow period -- this happens from time to time. There
aren't many people carrying on active research; mine is on hiatus as
I've been working on giving a new son a start in the world.

> Perhaps others had discovered what I only now discovered:
> cat-style can be as deceptive as BASIC was in the 70s.
> You think you're programming, but you're just hacking a mess.

Unlikely. This forum is largely for research; at the present state of
the art, the research is focused on the primitives, and nobody
reasonable expects perfection from a primitive research effort. The
practical people should be hanging out in the Factor and Forth (and
possibly Postscript) groups, where they'll find pragmatic
applications.

> This forum prompted me to investigate the power of
> linux 'pipe programming',
> which is astoundingly decetive.
> It's magically easy, for small jobs, but quickly becomes unmanageable.

I suspect you were using an overly simple language, then. FP, FL,
NIAL, or Q might be a better way to carry on your experiments; they're
all based on the ideas of data pipelines, but they have strong
facilities to group, manipulate, and redirect the data, as well as the
control flow. NIAL is the only open-source one; Q (kx.com) is the only
commercially successful one. FP and FL founded not only the idea of
dataflow-centered programming, but also the entire idea of "functional
programming", which has now become a major driver of programming
languages (although not at all in the way the author intended).

> == Chris Glur.

-Wm

Re: A Joy VM in OCaml

2009-09-22T04:30:05Z

On Mon, Sep 21, 2009 at 01:47:35PM -0500, john@... wrote:

> ... go read Backus, Bird, de Moor, Meijer, Fokkinga,
> Paterson, Tatsuya, Iverson, Meertens, Gibbons, et cetera.
>

Care to complete the list?

Backus[1]. De Moor[2], Bird[3], Meijer[4], Patterson[5], Tatsuya[6],
Iverson[7], Meertens[8], Gibbons[9].

[1] http://nl.wikipedia.org/wiki/John_Backus
[2] http://www.comlab.ox.ac.uk/people/oege.demoor/
[3] http://en.wikipedia.org/wiki/Richard_Bird_%28computer_scientist%29
[4] http://lambda-the-ultimate.org/user/776
[5] http://www.soi.city.ac.uk/~ross/
[6]
[7] http://en.wikipedia.org/wiki/Kenneth_E._Iverson
[8] http://en.wikipedia.org/wiki/Lambert_Meertens
[9]

Re: A Joy VM in OCaml

2009-09-21T17:58:52Z

This forum seems to have died.
Perhaps others had discovered what I only now discovered:
cat-style can be as deceptive as BASIC was in the 70s.
You think you're programming, but you're just hacking a mess.

This forum prompted me to investigate the power of
linux 'pipe programming',
which is astoundingly decetive.
It's magically easy, for small jobs, but quickly becomes unmanageable.
== Chris Glur.

On 9/4/09, Tom Schouten <tom@...> wrote:

> On Fri, Sep 04, 2009 at 01:52:42AM +0300, chris glur wrote:
>>
>>
>> >> OTOH perhaps such "democratic committee" projects aren't feasible.
>>
>> > I believe good results require a sufficiently annoying `itch' locally
>> > applied to a single implementor / designer.
>>
>> Yes, you're talking about making fish.
>> I'm talking about making fishermen.
>>
>> Most of the value-added in computing comes from the soft: psychology
>> and human-cognition. OTOH the Hard: technology; is easier to talk
>> about.
>>
>> Eg. the only justification for music is 'emotion manipulation'.
>> But that's near impossible to quantify or describe.
>> OTOH volumes are/can-be written about the technicalities.
>>
>
> Interesting viewpoint.
>
>
>> My previous laboured example, perhaps didn't prove the conclusion:--
>>
>
>
>> The brief sequence of functions described by:
>> " pstree -p | cut -b25- | grep su ".
>> which does:
>> print the process-tree,
>> but cut-out and show only the part of the lines, from the 25th char
>> to end-line,
>> and show only lines which contain the string "su";
>>
>> shows a very cognitive economical way of achieving the goal.
>>
>> And has the very important advantage of being achieved by successive
>> refinement.
>> Which makes for increased productivity.
>>
>
> What you described is a `process' view on approaching a problem.
> The combinator-style that Joy/Factor/Forth/... promote is an
> example of this. This is also called `point-free' style.
>
> An applicative language combines this with an `object' view, where
> you name intermediate objects in addition to processes that turn
> objects into objects.
>
> From a human cognition point of view it seems to me that these
> are quite basic entities that can be used to structure the
> information transfer from one brain to another.
>
> The formal language equivalents sure have their roots in natural
> languages, with the added advantage that these languages can
> be manipulated as objects themselves.
>
> (I have the feeling I'm just stating the obvious though..)
>
>
>> But I'm still waiting for for an explanation if/why joy is good.
>> And I expect the outcome of any effort to pay-back in the future.
>> Education, knowledge of universally applicable principles is more
>> profitable
>> than aquiring *A* product.
>>
>
> `good' is relative to `purpose'.
>
> On this i can only comment from a personal angle: I think
> concatenative languages are good for the purpose of working
> with them as data on a meta-level.
> I.e. playing with evaluation order (staging & partial
> evaluation) and allowing very simple interpreters.
>
> Additionally they are interesting for anything that is
> related to arithmetic (or other problems that ``naturally
> factor'' into small processes).
>
> As a general purpose programming language however, I feel
> they are too restrictive. Some solutions seem to me to
> be more naturally expressed as object instead of process.
> More specifically: when random access of objects by name
> simplifies matters (i.e. tree-structured data translation).
>
>

Re: A Joy VM in OCaml

2009-09-21T11:47:35Z

On Mon, 21 Sep 2009 19:50:00 +0300, chris glur <crglur@...> wrote:

> This forum seems to have died.
> Perhaps others had discovered what I only now discovered:
> cat-style can be as deceptive as BASIC was in the 70s.
> You think you're programming, but you're just hacking a mess.

I think it's more likely that no one is interested in responding
to your inane questions. If you want to know what the point of
all this is, go read Backus, Bird, de Moor, Meijer, Fokkinga,
Paterson, Tatsuya, Iverson, Meertens, Gibbons, et cetera.

I'm still working on things. I've been quiet because I've been
busy, not because I've decided that this is all a waste of time.

- John

Re: A Joy VM in OCaml

2009-09-21T09:50:00Z

Re: A Joy VM in OCaml

2009-09-04T05:53:44Z

On Fri, Sep 04, 2009 at 01:52:42AM +0300, chris glur wrote:

>
>
> >> OTOH perhaps such "democratic committee" projects aren't feasible.
>
> > I believe good results require a sufficiently annoying `itch' locally
> > applied to a single implementor / designer.
>
> Yes, you're talking about making fish.
> I'm talking about making fishermen.
>
> Most of the value-added in computing comes from the soft: psychology
> and human-cognition. OTOH the Hard: technology; is easier to talk about.
>
> Eg. the only justification for music is 'emotion manipulation'.
> But that's near impossible to quantify or describe.
> OTOH volumes are/can-be written about the technicalities.
>

Interesting viewpoint.

> My previous laboured example, perhaps didn't prove the conclusion:--
>

> The brief sequence of functions described by:
> " pstree -p | cut -b25- | grep su ".
> which does:
> print the process-tree,
> but cut-out and show only the part of the lines, from the 25th char
> to end-line,
> and show only lines which contain the string "su";
>
> shows a very cognitive economical way of achieving the goal.
>
> And has the very important advantage of being achieved by successive
> refinement.
> Which makes for increased productivity.
>

What you described is a `process' view on approaching a problem.
The combinator-style that Joy/Factor/Forth/... promote is an
example of this. This is also called `point-free' style.

An applicative language combines this with an `object' view, where
you name intermediate objects in addition to processes that turn
objects into objects.

From a human cognition point of view it seems to me that these
are quite basic entities that can be used to structure the
information transfer from one brain to another.

The formal language equivalents sure have their roots in natural
languages, with the added advantage that these languages can
be manipulated as objects themselves.

(I have the feeling I'm just stating the obvious though..)

> But I'm still waiting for for an explanation if/why joy is good.
> And I expect the outcome of any effort to pay-back in the future.
> Education, knowledge of universally applicable principles is more
> profitable
> than aquiring *A* product.
>

`good' is relative to `purpose'.

On this i can only comment from a personal angle: I think
concatenative languages are good for the purpose of working
with them as data on a meta-level.
I.e. playing with evaluation order (staging & partial
evaluation) and allowing very simple interpreters.

Additionally they are interesting for anything that is
related to arithmetic (or other problems that ``naturally
factor'' into small processes).

As a general purpose programming language however, I feel
they are too restrictive. Some solutions seem to me to
be more naturally expressed as object instead of process.
More specifically: when random access of objects by name
simplifies matters (i.e. tree-structured data translation).

Re: A Joy VM in OCaml

2009-09-03T15:52:42Z

>> OTOH perhaps such "democratic committee" projects aren't feasible.

> I believe good results require a sufficiently annoying `itch' locally
> applied to a single implementor / designer.

Yes, you're talking about making fish.
I'm talking about making fishermen.

Most of the value-added in computing comes from the soft: psychology
and human-cognition. OTOH the Hard: technology; is easier to talk about.

Eg. the only justification for music is 'emotion manipulation'.
But that's near impossible to quantify or describe.
OTOH volumes are/can-be written about the technicalities.

My previous laboured example, perhaps didn't prove the conclusion:--

The brief sequence of functions described by:
" pstree -p | cut -b25- | grep su ".
which does:
print the process-tree,
but cut-out and show only the part of the lines, from the 25th char
to end-line,
and show only lines which contain the string "su";

shows a very cognitive economical way of achieving the goal.

And has the very important advantage of being achieved by successive refinement.
Which makes for increased productivity.

But I'm still waiting for for an explanation if/why joy is good.
And I expect the outcome of any effort to pay-back in the future.
Education, knowledge of universally applicable principles is more profitable
than aquiring *A* product.

== Chris Glur.

On 9/3/09, eas lab <lab.eas@...> wrote:

> .. continued fron previous post, because the mailer objected to the
> complete text.
> ------------
> Because I'm an isolated researcher, I appreciate when others expose
> the route to their results, rather than just giving the 'show-room'
> end product. Perhaps some see this as indiscreet exhibitionism ?
>
> As an example of how I'd like open-collaborative projects to be,
> I'm going to NOW try to expose how I partially achieved a nasty task
> using unix's cat-like facilities.
>
> TASK DESCRIPTION: find which [if any] Desktop, VT pair is currently 'open'
> at
> the correct directory, to process the newly arrived email, news, http
> ...etc.
>
> Think of a system from 200 years ago, where 10 to 20 sheets for 6 to 8
> categories are distributed between 4 clerks. Clerk1 may have 4 sheets for:
> vegetables, meat, clothing, meat.
> When a transaction for meat arrives, it should be directed to the clerk
> who currently has the/a 'meat' sheet.
>
> Since this is a computer and not paper-sheets, multiple clerks/processes
> can have the same sheet/directory open. And muliple copies of a
> sheet/directory
> may be open for reading/editing its files. And always allocating new
> sheets/VirtualTerminals to the new topic as they arrive would give an
> explosive
> growth of redundant sheets/VTs.
>
> If you had 20 copies of a book, all open, mostly at different pages
> and you had to switch between books to see which, if any book was open at
> the 'meat page', this would be frustrating; compared to scanning down a list
> of (book, page-topic) pairs, to find the/a 'meat' book/page.
>
> So the 1st REFINED TASK DESCRIPTION is:
> find which Desktop/VT, if any, has the directory for the newly arrived item.
>
> Then the 2nd REFINED TASK DESCRIPTION 'became':
> generate a list of the open directories for the 10 to 20 mc-tasks,
> and generate info which relates the (D,V) pair to the task-directory,
> so that by visually scanning the 2 lists the D/V which matches the mc-task
> can be found.
>
> As an example this task that I'm writing now, will be in a path/directory
> *cat* or *Cat*; and I can see that it's using desktop1, VT4; which I
> designate as D,V=1,4.
>
> But when I switch out of this D,V to some other jobs and new info arrives
> for
> the 'cat' topic, I'll have forgotten/lost D,V=1,4. In fact possibly D,V=1,4
> will have been allocated to a different topic.
>
> The 2 sets of info look like this [where I just have to remember that
> they're
> call PT & DV] :-
> --> # PT
> mc 1477 /mnt/cdrom/Inet
> mc 1549 /mnt/cdrom
> mc 1593 /mnt/cdrom/Legal/TLC/Aug09
> mc 1824 /mnt/cdrom/Legal/TLC/Aug09
> mc 2429 /mnt/cdrom/Inet/RSS
> mc 8952 /mnt/cdrom/Legal/TLC/UKdefaultJ
> mc 9837 /mnt/cdrom/Legal/TLC
> mc 13406 /mnt/cdrom/Legal/TLC/UKdefaultJ
> mc 13529 /mnt/cdrom/Legal
> mc 13570 /mnt/cdrom/Legal/TLC/PreApr09
> mc 13925 /mnt/cdrom/AI/Catamorfic
> mc 17614 /mnt/cdrom/Legal/TLC/PreApr09/CCnewJudges
> mc 24024 /mnt/cdrom/Legal/AudtrFiduc
>
> --> # DV
> |-kdeinit(1186)-+-su(1196)---bash(1271)---mc(13529)---bash(13531)
> | |-su(1199)---bash(1303)---linux.oberon.no(14102)
> | |-su(1201)---bash(9009)---mc(13570)---bash(13572)
> | `-su(1203)---bash(9805)---mc(9837)---bash(9839)
> |-kdeinit(1188)-+-su(1204)---bash(1335)---mc(1593)---bash(1595)---less.bin(19649)
> | |-su(1207)---bash(1367)---mc(1824)---bash(1826)
> | |-su(1209)---bash(1399)---linux.oberon.no(1431)
> | `-su(1211)---bash(9481)---lynx(17276)
> |-kdeinit(1189)-+-su(1213)---bash(2075)---mc(17614)---bash(17616)
> | |-su(1215)---bash(2107)---mc(2429)---bash(2431)
> | |-su(1218)---bash(2139)---mc(13406)---bash(13408)
> | |-su(1222)---bash(2171)---sob(9671)---oberon(9712)
> | `-su(1225)---bash(8919)---mc(8952)---bash(8954)
> |-kdeinit(1192)-+-su(1221)---bash(1235)---linux.oberon.no(1441)
> | |-su(1226)---bash(1445)---mc(1477)---bash(1479)
> | |-su(1265)---bash(1517)---mc(1549)---bash(1551)
> | `-su(13889)---bash(13893)---mc(13925)---bash(13927)
>
>
> This can look a bit overwhelming, but searching for the 'cat', we find
> /mnt/cdrom/AI/Catamorfic
> as the 3rd last element, and with a pid-number of: 13925.
> And the 2nd info-set has mc(13925) in the 4th/last branch of the node
> which has linux.oberon.no(1441) as it's 1st branch.
>
> Which means DV=1,4 as we already know !
> Similarly we see that the 2 'tree-branches' which are already allocated
> to "Aug09", are D,V=3,1 & D,V=3,2 , via pid=1593 and pid=1824 .
>
>
> Up till now, I've had to use the hack of puting the 'oberon' in the
> N-th VT of the Nth Desktop, in order to see which Desktop a set of
> branches represent. Obviously I'd like some kind of 'artificial
> intelligence' method to further proccess and just place the D/V pair
> next to the corresponding directory-path. Like so:-
> 1,2= /mnt/cdrom/Inet
> 1,3= /mnt/cdrom
> 1,4= /mnt/cdrom/AI/Catamorfic
> ...etc.
>
> But ! by using successive refinement, one can get the benefit of the
> partially working product and finish it later -- or never.
>
> Finally ! let's see [by exposing the details of my thought process]
> how this came from cat-style linux facilities.
>
> 1. Let's examine the minimalist cat-code to see what it does.
> 2. where is the code, to be found to examine?
> 3. since it's executable, linux's "whereis" will show us.
> 4. do: "whereis PT" gives us: "PT: /usr/local/bin/PT"
> 5. and show the contents of the script/executable-code
> ie. "cat /usr/local/bin/PT" shows the single line:-
> "lsof | grep DIR | grep mc | grep "/". | cut -b-17,67-"
>
> BTW, this is an example for windows-users of what linux does;
> and truthfully the file/script had several lines of comments
> which accumulated during its evolution which I'm excluding.
>
> If I look at the line of: code, I guess this is what it does:
> lsof : list all the open file,
> | grep DIR : but show only the lines containing "DIR"
> | grep mc : and of those show only the lines containing "mc"
> | grep "/". : and of those show only the lines containing
> "/"<some non 'bad chars'>
> {I NOW don't remember exactly which char=set "." represents}
> | cut -b-17,67- : and show only parts of the line/s, probably cutting-out
> pieces at boundries 17th char & 67th char.
>
> NB. the parts which I'm not NOW sure about should be explained in the
> script's comments. But I'm not 'sanatizing' and pretending that I know.
> -------------
> And similarly the cat-like-code for "DV" is:
> pstree -p | cut -b25- | grep su
> which apparently does:
> print the process-tree,
> but cut-out and show only part of the lines, apparently from the 25th char
> up to the end,
> and show only lines which contain the string "su".
>
> Which I guess gives the 2nd data structures above.
> BTW for 'win users':
> if you've previously typed : "cat /usr/local/bin/PT"
> it only needs 3 keystrokes to get: "cat /usr/local/bin/DV"
> although I prefer ETH-oberon which works without any keyboard, if need be.
>
> Hopefully this example shows how comfortable it can be to develop a large
> class of tasks in a cat-style language.
>
> It would be valuable for me, and possibly for others, if cat-contributors
> could refine the above down to a lower level. Ie. the implementation of
> "grep:
> and eg. "tr" in a cat-like language would be valuable. Frankly I don't even
> know how joy implements its control-structures, because I never found a
> "TOP"
> view of what joy was good for.
>
> The basis of the "hello world" approach is that a demonstrable model is
> made available as soon as possible; and then later one can see how the
> actual
> characters are printed - at a lower level ?
> The top-goal must be exposed before the implementation details.
>
> == Chris Glur.
>

Re: A Joy VM in OCaml

2009-09-03T08:47:10Z

.. continued fron previous post, because the mailer objected to the
complete text.
------------
Because I'm an isolated researcher, I appreciate when others expose
the route to their results, rather than just giving the 'show-room'
end product. Perhaps some see this as indiscreet exhibitionism ?

As an example of how I'd like open-collaborative projects to be,
I'm going to NOW try to expose how I partially achieved a nasty task
using unix's cat-like facilities.

TASK DESCRIPTION: find which [if any] Desktop, VT pair is currently 'open' at
the correct directory, to process the newly arrived email, news, http ...etc.

Think of a system from 200 years ago, where 10 to 20 sheets for 6 to 8
categories are distributed between 4 clerks. Clerk1 may have 4 sheets for:
vegetables, meat, clothing, meat.
When a transaction for meat arrives, it should be directed to the clerk
who currently has the/a 'meat' sheet.

Since this is a computer and not paper-sheets, multiple clerks/processes
can have the same sheet/directory open. And muliple copies of a sheet/directory
may be open for reading/editing its files. And always allocating new
sheets/VirtualTerminals to the new topic as they arrive would give an explosive
growth of redundant sheets/VTs.

If you had 20 copies of a book, all open, mostly at different pages
and you had to switch between books to see which, if any book was open at
the 'meat page', this would be frustrating; compared to scanning down a list
of (book, page-topic) pairs, to find the/a 'meat' book/page.

So the 1st REFINED TASK DESCRIPTION is:
find which Desktop/VT, if any, has the directory for the newly arrived item.

Then the 2nd REFINED TASK DESCRIPTION 'became':
generate a list of the open directories for the 10 to 20 mc-tasks,
and generate info which relates the (D,V) pair to the task-directory,
so that by visually scanning the 2 lists the D/V which matches the mc-task
can be found.

As an example this task that I'm writing now, will be in a path/directory
*cat* or *Cat*; and I can see that it's using desktop1, VT4; which I
designate as D,V=1,4.

But when I switch out of this D,V to some other jobs and new info arrives for
the 'cat' topic, I'll have forgotten/lost D,V=1,4. In fact possibly D,V=1,4
will have been allocated to a different topic.

The 2 sets of info look like this [where I just have to remember that they're
call PT & DV] :-
--> # PT
mc 1477 /mnt/cdrom/Inet
mc 1549 /mnt/cdrom
mc 1593 /mnt/cdrom/Legal/TLC/Aug09
mc 1824 /mnt/cdrom/Legal/TLC/Aug09
mc 2429 /mnt/cdrom/Inet/RSS
mc 8952 /mnt/cdrom/Legal/TLC/UKdefaultJ
mc 9837 /mnt/cdrom/Legal/TLC
mc 13406 /mnt/cdrom/Legal/TLC/UKdefaultJ
mc 13529 /mnt/cdrom/Legal
mc 13570 /mnt/cdrom/Legal/TLC/PreApr09
mc 13925 /mnt/cdrom/AI/Catamorfic
mc 17614 /mnt/cdrom/Legal/TLC/PreApr09/CCnewJudges
mc 24024 /mnt/cdrom/Legal/AudtrFiduc

--> # DV
|-kdeinit(1186)-+-su(1196)---bash(1271)---mc(13529)---bash(13531)
| |-su(1199)---bash(1303)---linux.oberon.no(14102)
| |-su(1201)---bash(9009)---mc(13570)---bash(13572)
| `-su(1203)---bash(9805)---mc(9837)---bash(9839)
|-kdeinit(1188)-+-su(1204)---bash(1335)---mc(1593)---bash(1595)---less.bin(19649)
| |-su(1207)---bash(1367)---mc(1824)---bash(1826)
| |-su(1209)---bash(1399)---linux.oberon.no(1431)
| `-su(1211)---bash(9481)---lynx(17276)
|-kdeinit(1189)-+-su(1213)---bash(2075)---mc(17614)---bash(17616)
| |-su(1215)---bash(2107)---mc(2429)---bash(2431)
| |-su(1218)---bash(2139)---mc(13406)---bash(13408)
| |-su(1222)---bash(2171)---sob(9671)---oberon(9712)
| `-su(1225)---bash(8919)---mc(8952)---bash(8954)
|-kdeinit(1192)-+-su(1221)---bash(1235)---linux.oberon.no(1441)
| |-su(1226)---bash(1445)---mc(1477)---bash(1479)
| |-su(1265)---bash(1517)---mc(1549)---bash(1551)
| `-su(13889)---bash(13893)---mc(13925)---bash(13927)

This can look a bit overwhelming, but searching for the 'cat', we find
/mnt/cdrom/AI/Catamorfic
as the 3rd last element, and with a pid-number of: 13925.
And the 2nd info-set has mc(13925) in the 4th/last branch of the node
which has linux.oberon.no(1441) as it's 1st branch.

Which means DV=1,4 as we already know !
Similarly we see that the 2 'tree-branches' which are already allocated
to "Aug09", are D,V=3,1 & D,V=3,2 , via pid=1593 and pid=1824 .

Up till now, I've had to use the hack of puting the 'oberon' in the
N-th VT of the Nth Desktop, in order to see which Desktop a set of
branches represent. Obviously I'd like some kind of 'artificial
intelligence' method to further proccess and just place the D/V pair
next to the corresponding directory-path. Like so:-
1,2= /mnt/cdrom/Inet
1,3= /mnt/cdrom
1,4= /mnt/cdrom/AI/Catamorfic
...etc.

But ! by using successive refinement, one can get the benefit of the
partially working product and finish it later -- or never.

Finally ! let's see [by exposing the details of my thought process]
how this came from cat-style linux facilities.

1. Let's examine the minimalist cat-code to see what it does.
2. where is the code, to be found to examine?
3. since it's executable, linux's "whereis" will show us.
4. do: "whereis PT" gives us: "PT: /usr/local/bin/PT"
5. and show the contents of the script/executable-code
ie. "cat /usr/local/bin/PT" shows the single line:-
"lsof | grep DIR | grep mc | grep "/". | cut -b-17,67-"

BTW, this is an example for windows-users of what linux does;
and truthfully the file/script had several lines of comments
which accumulated during its evolution which I'm excluding.

If I look at the line of: code, I guess this is what it does:
lsof : list all the open file,
| grep DIR : but show only the lines containing "DIR"
| grep mc : and of those show only the lines containing "mc"
| grep "/". : and of those show only the lines containing
"/"<some non 'bad chars'>
{I NOW don't remember exactly which char=set "." represents}
| cut -b-17,67- : and show only parts of the line/s, probably cutting-out
pieces at boundries 17th char & 67th char.

NB. the parts which I'm not NOW sure about should be explained in the
script's comments. But I'm not 'sanatizing' and pretending that I know.
-------------
And similarly the cat-like-code for "DV" is:
pstree -p | cut -b25- | grep su
which apparently does:
print the process-tree,
but cut-out and show only part of the lines, apparently from the 25th char
up to the end,
and show only lines which contain the string "su".

Which I guess gives the 2nd data structures above.
BTW for 'win users':
if you've previously typed : "cat /usr/local/bin/PT"
it only needs 3 keystrokes to get: "cat /usr/local/bin/DV"
although I prefer ETH-oberon which works without any keyboard, if need be.

Hopefully this example shows how comfortable it can be to develop a large
class of tasks in a cat-style language.

It would be valuable for me, and possibly for others, if cat-contributors
could refine the above down to a lower level. Ie. the implementation of "grep:
and eg. "tr" in a cat-like language would be valuable. Frankly I don't even
know how joy implements its control-structures, because I never found a "TOP"
view of what joy was good for.

The basis of the "hello world" approach is that a demonstrable model is
made available as soon as possible; and then later one can see how the actual
characters are printed - at a lower level ?
The top-goal must be exposed before the implementation details.

== Chris Glur.

Re: A Joy VM in OCaml

2009-09-03T04:10:47Z

On Wed, Sep 02, 2009 at 12:22:33AM +0300, chris glur wrote:

>
>
> > I've been pondering for a while about whether this is useful
> > to actually turn into an application: to build a unix shell
> > that _is_ a concatenative language. It's a lot of work to get
> > right though.
> >
> > However, starting with scsh this might not be so far-fetched..
> I'd like to see a collaborative project in that direction;
> which was very transparent.
> I.e. doesn't just publish the final products hand-book, but
> rather exposes all steps of the design process.
>
> OTOH perhaps such "democratic committee" projects aren't feasible.

I believe good results require a sufficiently annoying `itch' locally
applied to a single implementor / designer.

Committees are probably only useful if there are too many people with the
same itch but different ways of scratching, or if a sufficiently
annoying itch doesn't emerge spontaneously.

Considering joy vs. shell programming, I do have a couple of ideas though,
while I think it's far from trivial to do it right.

- If you can figure out how to map programs, program arguments, and
pipes to clearly defined Joy function and data objects, and figure
out how to mesh the different name spaces the job seems half way done.
The rest is the long tail of infinite refinement and bug hunting.

I.e. the shell language could be a combination of

- Joy combinators

- Programs (can they be joy combinators? how to mix function
and file system namespaces?)

- Command lines of most sufficiently complex programs behave as
`mini-DSLs'. Can they be mapped to combinators, or should they
be abstract data? Can you brush this away into a wrapper
by treating providing some kind of compiler/interpreter for
each sufficiently complex external app (a good example would
be mplayer/mencoder).

- It might be a playing field where the original highly reflective
intensional Joy approach is workable. In all other practicaly
applications of concatenative languages I see, extensional approach
seems to be better from both modularity and efficiency viewpoints
(i.e. where you want play with static code properties).

Re: A Joy VM in OCaml

2009-09-01T14:22:33Z

> I've been pondering for a while about whether this is useful
> to actually turn into an application: to build a unix shell
> that _is_ a concatenative language. It's a lot of work to get
> right though.
>
> However, starting with scsh this might not be so far-fetched..
I'd like to see a collaborative project in that direction;
which was very transparent.
I.e. doesn't just publish the final products hand-book, but
rather exposes all steps of the design process.

OTOH perhaps such "democratic committee" projects aren't feasible.
I recently read some man/info * which gave a nice example of how
the simple 'transformers' can be serially piped together to achieve
a task. I'm sorry that I didn't read this 15 years ago.
-------
.. continued if my web-crap posts this !
== Chris Glur

Re: A Joy VM in OCaml

2009-09-01T01:35:56Z

Indeed.

I've been pondering for a while about whether this is useful to
actually turn into an application: to build a unix shell that _is_
a concatenative language. It's a lot of work to get right though.

However, starting with scsh this might not be so far-fetched..

On Mon, Aug 31, 2009 at 11:01:45PM -0700, Don Groves wrote:

>
>
> I have always found stack programming and Unix shell programming
> to be very similar, the stack being a LIFO pipe connecting successive
> refinements rather than the FIFO pipe used in Unix. As with the Unix
> shell, the transformations of the stack can be verified at each step of
> the process.
> --
> don
>
> On Aug 31, 2009, at 10:02 PM, chris glur wrote:
>
> > What is this good for ?
> > The answer that I didn't get directly, but which hints led to,
> > for my previous question: "what is cat-style good for";
> > could have been "it facilitates successive refinement, which
> > aids software productivety".
> >
> > Unix shell programming, which amazingly is several decades old,
> > allows remarkable economy in effort by using the 'data view'
> > [vs. procedural or OO views], by merely passing the data through
> > multiple stages of simple filters.
> >
> > Successive-refinement applies [which allows the programmer to
> > confirm each step] because the data transformation can be confirmed
> > at the output of each serial-filter.
> >
> > == Chris Glur.
> >
> >
> > On 8/26/09, Tom Schouten <tom@...> wrote:
> >> ... and another one: extensional, non-linear Joy stack machine that
> >> works using binary tree representation of code, and a binary tree
> >> rotation in the interpreter, with again the continuation = a
> >> quotation.
> >>
> >> http://zwizwa.be/darcs/libprim/pf/seq.ml
> >>
> >>
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>

Re: A Joy VM in OCaml

2009-08-31T23:01:45Z

I have always found stack programming and Unix shell programming
to be very similar, the stack being a LIFO pipe connecting successive
refinements rather than the FIFO pipe used in Unix. As with the Unix
shell, the transformations of the stack can be verified at each step of
the process.
--
don

On Aug 31, 2009, at 10:02 PM, chris glur wrote:

> What is this good for ?
> The answer that I didn't get directly, but which hints led to,
> for my previous question: "what is cat-style good for";
> could have been "it facilitates successive refinement, which
> aids software productivety".
>
> Unix shell programming, which amazingly is several decades old,
> allows remarkable economy in effort by using the 'data view'
> [vs. procedural or OO views], by merely passing the data through
> multiple stages of simple filters.
>
> Successive-refinement applies [which allows the programmer to
> confirm each step] because the data transformation can be confirmed
> at the output of each serial-filter.
>
> == Chris Glur.
>
>
> On 8/26/09, Tom Schouten <tom@...> wrote:
>> ... and another one: extensional, non-linear Joy stack machine that
>> works using binary tree representation of code, and a binary tree
>> rotation in the interpreter, with again the continuation = a
>> quotation.
>>
>> http://zwizwa.be/darcs/libprim/pf/seq.ml
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Re: A Joy VM in OCaml

2009-08-31T22:02:29Z

What is this good for ?
The answer that I didn't get directly, but which hints led to,
for my previous question: "what is cat-style good for";
could have been "it facilitates successive refinement, which
aids software productivety".

Unix shell programming, which amazingly is several decades old,
allows remarkable economy in effort by using the 'data view'
[vs. procedural or OO views], by merely passing the data through
multiple stages of simple filters.

Successive-refinement applies [which allows the programmer to
confirm each step] because the data transformation can be confirmed
at the output of each serial-filter.

== Chris Glur.

On 8/26/09, Tom Schouten <tom@...> wrote:
> ... and another one: extensional, non-linear Joy stack machine that
> works using binary tree representation of code, and a binary tree
> rotation in the interpreter, with again the continuation = a quotation.
>
> http://zwizwa.be/darcs/libprim/pf/seq.ml
>
>

Re: A Joy VM in OCaml

2009-08-26T06:30:17Z

... and another one: extensional, non-linear Joy stack machine that
works using binary tree representation of code, and a binary tree
rotation in the interpreter, with again the continuation = a quotation.

http://zwizwa.be/darcs/libprim/pf/seq.ml

A Joy VM in OCaml

2009-08-25T00:48:51Z

Hello list,

Something I'd like to share: a small interpreter for an (intensional)
Joy dialect, that has helped me to clarify some conversation about
implementation of concatenative languages.

http://zwizwa.be/darcs/libprim/pf/joy.ml

What I found remarkable is that the continuation of such an intensional
VM _really is just an intensional quotation_.

This is mostly to contrast the PF VM, an early-bound extensional Joy dialect
with linear core memory and nonlinear code memory. I.e. it uses linear
lists for data, delimited continuations, and partial applications, and
nonlinear memory for the code graph.

I think I finally found a way to combine linearity and some form of
reflection by using a staged approach.

http://zwizwa.be/darcs/libprim/pf/pf.ml

Cheers,

Tom

Re: Compression: Huffman Coding with Joy

2009-08-20T13:23:13Z

--- In concatenative@..., "icpdesign" <taoufik.dachraoui@...> wrote:

>
> Dear,
>
> How do you implement the Huffman Coding with Joy?
>
> I would like to compare it with other languages (eg. F#)
>
> Kind regards
> Taoufik
>

Hello,

Huffman Coding seems like a nice algorithm to try my
new programming skills. Please bear in mind that this
is my first program in JOY.

http://home.kpn.nl/r.wiersma26/huffman.pdf
http://home.kpn.nl/r.wiersma26/hzip.txt
http://home.kpn.nl/r.wiersma26/hunzip.txt

Re: ANN: Concatenative Macro Processor

2009-07-04T19:35:01Z

--- In concatenative@..., eas lab <lab.eas@...> wrote:

>
> Just to keep the pipes exercised
> [I suspected that I'd been cut-off of cat-list
> [what's happening in the 1st-world/N-hemisphere
> 'for' no cat-list-traffic ?] ]
>
> I'm asking what's Minimac's minimal-syntax ?
>
> I/we don't just go off to httpS on a whim.
> ANNs should contain minimum info to justify
> further effort investment.
>
> How would it:
> remove all sequences of lines,
> starting from <string1> upto <string2> ?
>
> == TIA.

Hi,

Thanks for your questions.

Minimac has almost no syntax, basically a set of special characters that trigger behaviors (quoting, escaping, naming, compiling, etc...) and a dictionary (i.e. symbol table) of built-in macros that is extended at runtime with user macro definitions. See the draft manual for more info: http://code.google.com/p/minimac/wiki/manual

As to your second question on removing sequences of lines, minimac is a macro processor similar in purpose to m4, i.e. it expands macro directives contained in a source file, what you're describing is a job better suited for a stream editor.

Cheers,
Mark Humphries
http://freshmeat.net/projects/minimac-macro-processor

Re: ANN: Concatenative Macro Processor

2009-07-04T05:48:59Z

Just to keep the pipes exercised
[I suspected that I'd been cut-off of cat-list
[what's happening in the 1st-world/N-hemisphere
'for' no cat-list-traffic ?] ]

I'm asking what's Minimac's minimal-syntax ?

I/we don't just go off to httpS on a whim.
ANNs should contain minimum info to justify
further effort investment.

How would it:
remove all sequences of lines,
starting from <string1> upto <string2> ?

== TIA.

On 6/23/09, Mark W. Humphries <mwh@...> wrote:

> Minimac (http://freshmeat.net/projects/minimac-macro-processor) is a
> minimalist, general purpose text macro processor.
> It uses an explicit argument stack, and user functions are defined by
> concatenation.
> The software is currently in alpha release.
>
> Example: 99 bottles of beer (http://99-bottles-of-beer.net/)
>
> `drink! ( u -- ) `{continue}${#}
> this-many-bottles of beer on the wall, this-many-bottles of beer.
> Take one down and pass it around, fewer-bottles of beer on the wall.
>
> {repeat}`
>
> `oh-no! ( -- ) `No more bottles of beer on the wall, no more bottles of
> beer.`
>
> `please! ( u -- u ) `{#}
> Go to the store and buy some more, this-many-bottles of beer on the
> wall.`
>
> `this-many-bottles ( u -- u ) `[{dup} 0& ~no more bottles~& {case} 1& ~1
> bottle~& {case} {.} ~ bottles~]`
>
> `fewer-bottles ( u -- u-1 ) `{--}$this-many-bottles`
>
> 99& drink!
> oh-no!
> 99& please!
>
>
>
> Cheers,
> Mark Humphries
>
>

ANN: Concatenative Macro Processor

2009-06-22T18:09:55Z

Minimac (http://freshmeat.net/projects/minimac-macro-processor) is a
minimalist, general purpose text macro processor.
It uses an explicit argument stack, and user functions are defined by concatenation.
The software is currently in alpha release.

Example: 99 bottles of beer (http://99-bottles-of-beer.net/)

`drink! ( u -- ) `{continue}${#}
this-many-bottles of beer on the wall, this-many-bottles of beer.
Take one down and pass it around, fewer-bottles of beer on the wall.

{repeat}`

`oh-no! ( -- ) `No more bottles of beer on the wall, no more bottles of beer.`

`please! ( u -- u ) `{#}
Go to the store and buy some more, this-many-bottles of beer on the wall.`

`this-many-bottles ( u -- u ) `[{dup} 0& ~no more bottles~& {case} 1& ~1 bottle~& {case} {.} ~ bottles~]`

`fewer-bottles ( u -- u-1 ) `{--}$this-many-bottles`

99& drink!
oh-no!
99& please!

Cheers,
Mark Humphries

Re: proof/examples of productivety increase ?

2009-04-27T08:59:11Z

Nigel Galloway wrote:
> Should a language like Joy be compared to Java.

Yes and no. A language like Joy yes; Joy itself NO. Joy is an academic
prototype, not really intended for any specific use.

> For efficiency the JVM reads and 'understands' the bytecodes. It does
> not execute them slavishly as real assmbler is by a real CPU but
> intelligently optimizing the instructions.

Right.

The concatenative language "Cat" was originally designed for this
general type of use, as an intermediate language. You might want to read
up on it. It also has a fairly advanced type checker.

-Wm

Re: proof/examples of productivety increase ?

2009-04-27T04:41:54Z

Should a language like Joy be compared to Java. Java compiles into class files, which consist of bytecodes, which is assembler like code for the JVM.

Joy comes in 2 parts an iterpreter and a language. The language is more like the JVM facing Java bytecode assembler than the programmer facing Java language.

Java is interesting in this respect: its class files are compiled in such a way that closure is regularly achieved at the bytecode level by adding extra instructions. This means that the correctness and resource usage can be verified when the class is loaded. For efficiency the JVM reads and 'understands' the bytecodes. It does not execute them slavishly as real assmbler is by a real CPU but intelligently optimizing the instructions.

To be efficient at a programming level, a language designed for the type of problem is required. This should be compiled into Joy. The questions then are:

can this Joyclass be optimized using concatative algorithms into something better than the Java class or the Intel assembler?

can this be done by machine, or would it require rooms full of people hand optimizing assembler like Joy?

--- On Sun, 12/4/09, chris glur <crglur@...> wrote:

From: chris glur <crglur@...>
Subject: [stack] proof/examples of productivety increase ?
To: concatenative@...
Date: Sunday, 12 April, 2009, 4:42 PM

On cleaning out archives of
Tue, Apr 29, 2008 at 10:20 AM
where John Nowak wrote:

>Most type systems are not compositional which destroys the simple
>algebra of concatenative programs. Take these equivalencies
>for example:

> [$A] i == $A -- application
> [$A] [$B] o == [$A $B] -- composition
> $a [$B] pa == [$a $B] -- partial application
> [$A] m == [$A] $A -- self-application

>Unfortunately, all of these rules (except perhaps for partial
>application) fall apart once types are involved. This is of
>practical concern as it makes cut-and-paste refactoring
>impossible and will cause problems with many macro
>transformations.

I wondered is there a tutorial on 'algebra of concatenative
programs', preferably without another new syntax,
which shows complete examples of design and/or correctness proof ?

Some time back I did a string-utility. Something like:
remove all non-line-leading repeated spaces in all lines,
and was amazed at the complexity, with the nested loops and several
pointers needed. And I recently gave back a book which told about
the well-know Hi-priest who published about 'correctness proofs'
and later 2 guys found 2 errors and yet later someone else found
another error. Does anyone know of a link to this story ?
I think it was in the '70s ..Parnas...Hoare. .days.

Frankly, this concat-business seems pointless to me unless it can
increase productivety, which IMO is only possible by:
1. being more readable - eg. by being closer to the mental model
of the problem/S. Which I don't think it is eg. compared to
typical java or Algol-family code ..... Eiffel ?...;
2. being ameniable to formal correctness proof techniques, eg.
via transformations, by its algebra.

The newsgroup/s re. 'formal methods' only have lists of conferences.
Like snake-oil-peddlars: pay for an attendance and get a key to
the inner secrets. For decades formal methods have been the
'real soon now magic bullet'. Like epaper seems to be lately.

I want some concrete demonstrations.
Starting from 'hello world' level and extending to usefull
utilities. BTW who can demonstrate cat's benefit on a string
utility, like above or similar ?

Thanks,

== Chris Glur.

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

list about PL design

2009-04-20T09:06:23Z

Hello,

just started a mailing list about programming language design.
It's called 'PiLuD' ;-)
For anyone interested.

subscribe : pilud+subscribe@...
send mail : pilud@...
home page : http://groups.google.com/group/pilud

You'll find a list of sample topics, only intended to help the list start & live, at
http://groups.google.com/group/pilud/web/topics
Add your own center of interests.

Denis
------
la vita e estrany

proof/examples of productivety increase ?

2009-04-12T08:42:54Z

On cleaning out archives of
Tue, Apr 29, 2008 at 10:20 AM
where John Nowak wrote:

>Most type systems are not compositional which destroys the simple
>algebra of concatenative programs. Take these equivalencies
>for example:

> [$A] i == $A -- application
> [$A] [$B] o == [$A $B] -- composition
> $a [$B] pa == [$a $B] -- partial application
> [$A] m == [$A] $A -- self-application

>Unfortunately, all of these rules (except perhaps for partial
>application) fall apart once types are involved. This is of
>practical concern as it makes cut-and-paste refactoring
>impossible and will cause problems with many macro
>transformations.

I wondered is there a tutorial on 'algebra of concatenative
programs', preferably without another new syntax,
which shows complete examples of design and/or correctness proof ?

Some time back I did a string-utility. Something like:
remove all non-line-leading repeated spaces in all lines,
and was amazed at the complexity, with the nested loops and several
pointers needed. And I recently gave back a book which told about
the well-know Hi-priest who published about 'correctness proofs'
and later 2 guys found 2 errors and yet later someone else found
another error. Does anyone know of a link to this story ?
I think it was in the '70s ..Parnas...Hoare..days.

Frankly, this concat-business seems pointless to me unless it can
increase productivety, which IMO is only possible by:
1. being more readable - eg. by being closer to the mental model
of the problem/S. Which I don't think it is eg. compared to
typical java or Algol-family code ..... Eiffel ?...;
2. being ameniable to formal correctness proof techniques, eg.
via transformations, by its algebra.

The newsgroup/s re. 'formal methods' only have lists of conferences.
Like snake-oil-peddlars: pay for an attendance and get a key to
the inner secrets. For decades formal methods have been the
'real soon now magic bullet'. Like epaper seems to be lately.

I want some concrete demonstrations.
Starting from 'hello world' level and extending to usefull
utilities. BTW who can demonstrate cat's benefit on a string
utility, like above or similar ?

Thanks,

== Chris Glur.

Re: Re: Motivations to embrace undecidable type systems

2009-04-06T05:00:38Z

On Apr 5, 2009, at 5:09 AM, hallucious wrote:

> Thanks for the info and for bearing with me.
> I do want to move on to type systems that are useful for compilers.

It seems to me that some of the most interesting work in this field
(type systems for compilers) is being done by the Church Project (http://www.church-project.org
). They've already done much work on compositional analysis which may
be useful to you if you're not already familiar with it.

- John

Re: Compression: Huffman Coding with Joy

2009-04-05T05:40:24Z

Dear,

You can find the F# code for Huffman coding in

http://blogs.msdn.com/lukeh/archive/2008/05/05/huffman-coding-with-f.aspx

Kind regards
Taoufik

--- In concatenative@..., "icpdesign" <taoufik.dachraoui@...> wrote:

>
> Dear,
>
> How do you implement the Huffman Coding with Joy?
>
> I would like to compare it with other languages (eg. F#)
>
> Kind regards
> Taoufik
>

Compression: Huffman Coding with Joy

2009-04-05T05:34:56Z

Dear,

How do you implement the Huffman Coding with Joy?

I would like to compare it with other languages (eg. F#)

Kind regards
Taoufik

Re: Motivations to embrace undecidable type systems

2009-04-05T02:09:21Z

Hi John,

Thanks for the info and for bearing with me.
I do want to move on to type systems that are useful for compilers.

I shall clarify the subordinate role of this type system in the report.

Adrian

Re: Re: Motivations to embrace undecidable type systems

2009-04-04T23:27:11Z

On Apr 4, 2009, at 9:41 PM, hallucious wrote:

> If decidable type inference means that the type of quotations and
> compositions of functions can be inferred and expressed, then I
> think that type inference is decidable in this system. You are not
> forced to simplify. (I should have pointed that out.)

It's easy to infer the constraints, but type inference (I believe)
also entails checking that those constraints are satisfied and not in
contradiction to one another. For example, you may have the following
composition:

A b -> A b b Int
C String d d -> E

And you could assign it the following type:

A b -> E where A < C and b = String and b < d and d = Int

This alone is not useful because the type inferred is not valid.

- John

Re: Motivations to embrace decidable type systems

2009-04-04T23:15:21Z

On Apr 4, 2009, at 9:01 PM, hallucious wrote:

> One motivation for this work was to broaden the range of functions
> which can be investigated by looking at their type, which can be
> useful to see their effect.

You may want to look at Djinn if you haven't already:
http://lambda-the-ultimate.org/node/1178

> Another was to allow the programmer to provide additional
> constraints. I also hoped that the type would form a basis for
> proving properties of any function, using denotation provided by the
> programmer.

In my opinion, it would be more useful to add types dependent on
values rather than (or in addition to) higher rank polymorphism and
subtyping if your goal to allow programmers to prove things. There
are, as you probably know, a large number of languages that already
take this approach (Agda, Coq, Epigram, Dependent ML, ATS, etc).

> I do not expect that there is any automated (unguided) procedure to
> check, for instance, whether two type formulas are equivalent in
> this system. (Is this what decidable type inference means?)

In practice, I believe undecidable just means "not guaranteed to
terminate". For example, type inference is undecidable in a language
like Agda because certain programs will cause the type checking stage
to never finish.

- John

Re: Motivations to embrace undecidable type systems

2009-04-04T18:41:42Z

If decidable type inference means that the type of quotations and compositions of functions can be inferred and expressed, then I think that type inference is decidable in this system. You are not forced to simplify. (I should have pointed that out.)

But I do not think that type checking or type equality are decidable.

Motivations to embrace undecidable type systems

2009-04-04T18:14:17Z

One motivation for this work was to broaden the range of functions
which can be investigated by looking at their type, which can be
useful to see their effect. Another was to allow the programmer to
provide additional constraints. I also hoped that the type would form
a basis for proving properties of any function, using denotation
provided by the programmer. I did not want the type system to restrict
which functions or algorithms could be considered. We should be free
to get a function working empirically, then prove its correctness.

And another was to use inheritance polymorphism, mix in native objects
from Java or C# and type their interfaces, and investigate uniqueness
types in concatenative languages. Perhaps an undecidable type system
is not really necessary for this. But I wanted a type system for
experimental programs that might be rejected by conventional type
systems.

I do not expect that there is any automated (unguided) procedure to
check, for instance, whether two type formulas are equivalent in this
system. Is this what decidable type inference means?

Motivations to embrace decidable type systems

2009-04-04T18:01:30Z

One motivation for this work was to broaden the range of functions which can be investigated by looking at their type, which can be useful to see their effect. Another was to allow the programmer to provide additional constraints. I also hoped that the type would form a basis for proving properties of any function, using denotation provided by the programmer. I did not want the type system to restrict which functions or algorithms could be considered. We should be free to get a function working empirically, then prove its correctness.

And another was to use inheritance polymorphism, mix in native objects from Java or C# and type their interfaces, and investigate uniqueness types in concatenative languages. Perhaps an undecidable type system is not really necessary for this. But I wanted a type system for experimental programs that might be rejected by conventional type systems.

I do not expect that there is any automated (unguided) procedure to check, for instance, whether two type formulas are equivalent in this system. (Is this what decidable type inference means?)

Re: Type for row based languages

2009-04-04T16:08:32Z

One more thing I should've mentioned. You state that your type system
is compositional. I should note that you can get this quite easy by
extending HM with row types and omitting any equivalent to let
polymorphism. For example, 'dup apply' would fail to type:

A b -> A b b
C (C -> D) -> D

A (C -> D) -> A (C -> D) (C -> D)
C (C -> D) -> D

-- error: C occurs in A (C -> D)

Luckily (for some definition of "luck"), something like '[id] dup
apply' would fail as well:

A -> A (B -> B)
C d -> C d d

A -> A (B -> B)
C (B -> B) -> C (B -> B) (B -> B)

A -> A (B -> B)
A (B -> B) -> A (B -> B) (B -> B)

A -> A (B -> B) (B -> B)

A -> A (B -> B) (B -> B)
C (C -> D) -> D

A -> A (D -> D) (D -> D)
C (C -> D) -> D

A -> A (C -> C) (C -> C)
C (C -> C) -> C

-- error: C occurs in A (C -> C)

For all expressions that do yield valid types, the order in which you
infer the type does not matter.

Apologies if I'm stating the obvious.

- John

Re: Type for row based languages

2009-04-04T15:54:54Z

On Apr 4, 2009, at 5:27 PM, hallucious wrote:

> Is there pre-existing work on this?

Nothing published that I'm aware of, no. Existing work on type systems
for concatenative languages (and there isn't much) has mostly focused
on systems with decidable type inference.

> Have I made a mistake? Missed something?

Not that i can see. Do you have any application in mind for it?

I suppose my only comment is that I'm not sure if your approach is
ideal for concatenative languages. In my personal experience,
intersection types seem to be a much better match. For example, the
type of 'dup apply' in a system with intersection types can be stated
rather simply:

A (b /\ (A b -> C)) -> C

If you assume 'dup' to have the type 'A (b /\ c) -> A b c', inference
is straightforward:

A (b /\ c) -> A b c
D (D -> E) -> E

A (b /\ (D -> E)) -> A b (D -> E)
D (D -> E) -> E

A (b /\ (A b -> E)) -> A b (D -> E)
A b (D -> E) -> E

A (b /\ (A b -> E)) -> E

As for your '[id] dup' example:

A -> A (B -> B)
C (d /\ e) -> C d e

-- B free in B -> B, make fresh
A -> A ((B -> B) , (F -> F))
C (d , e ) -> C d e

A -> A ((B -> B) , (F -> F))
C ((B -> B) , e ) -> C (B -> B) e

A -> A ((B -> B) , (F -> F))
C ((B -> B) , (F -> F)) -> C (B -> B) (F -> F)

A -> A ((B -> B) , (F -> F))
A ((B -> B) , (F -> F)) -> A (B -> B) (F -> F)

A -> A (B -> B) (F -> F)

Apologies for not having anything more constructive for your system in
particular.

- John