# joy-linux

## Neil A Walker <neil@quill.plus.com> — 2003-02-15 20:13:38

    I am putting together a simple Linux package for joy,

    including a syntax-highlighting mode for the Jed text editor,

    which is included in most linux distributions.

    The package attempts to set up joy library in the users home

    directory also putting a startup script into the home directory.

    A usrlib.joy that I have found useful in starting out with joy

    is used as the default usrlib.joy.

    The pack may be found here

        http://www.quill.plus.com/joylin/joy-linux-0.1.tar.gz

    any suggestions will be welcome.

    Neil

## Nick Forde — 2003-02-17 21:04:17

    Hi Neil,

    Although I'm not a Jed user your mode looks better than the hacked

    Emacs mode I previously sent to Shae. I suggest you put this in the

    concatenative group's file area.

    One observation I have is that your files aren't Linux specific. Have

    you thought about making rpms or debs available instead? These would

    perhaps lead more Linux users into trying Joy.

    About a year ago John Leuner proposed building a debian package for

    joy. John, are you still here? Did you get any further with this?

    Regards,

    Nick.

    p.s. Does anyone have a vim syntax file for joy?

    "Neil A Walker <neil@...>" <neil@...> writes:

      > I am putting together a simple Linux package for joy,

     > including a syntax-highlighting mode for the Jed text editor,

     > which is included in most linux distributions.

     > [...]

     > any suggestions will be welcome.

     >

     > Neil

## Neil A Walker <neil@quill.plus.com> — 2003-02-18 19:28:51

    --- In concatenative@yahoogroups.com, Nick Forde <nickf@s...> wrote:

     > Hi Neil,

    >

    > Although I'm not a Jed user your mode looks better than the hacked

    > Emacs mode I previously sent to Shae. I suggest you put this in the

    > concatenative group's file area.

     done.

    Thank you for your coments, It maybe could be fine tuned a little,

    though I think! all the core agglib and inilib words are now included.

     > One observation I have is that your files aren't Linux specific.

     Have

     > you thought about making rpms or debs available instead? These would

    > perhaps lead more Linux users into trying Joy.

    >

     My intention was try to overcome the problems I am having in finding

    my way into Joy. I have little knowledge of rpm/deb building though I

    do run Mandrake a rpm based Linux.

    I will have a look into what it rpm building entails and see what I

    can come up with, though being retired time is very scarce so please

    be patient :)

    Speaking as a layman I do feel that Joy would benefit from a simple

    directory structure, and some means of the joy executable knowing

    where its library files are, maybe an JOYLIBRARY environmental

    variable a user could set, or .joyrc file readable on startup.

    This would certainly make the language more accessible to first time

    users, and should still keep it unix platform independent.

    Regards

    Neil

    ... cut

## phimvt@lurac.latrobe.edu.au — 2003-02-19 05:30:19

    On Tue, 18 Feb 2003, Neil A Walker <neil@...> wrote:

    [..]

    > Speaking as a layman I do feel that Joy would benefit from a simple

    > directory structure, and some means of the joy executable knowing

    > where its library files are, maybe an JOYLIBRARY environmental

    > variable a user could set, or .joyrc file readable on startup.

    > This would certainly make the language more accessible to first time

    > users, and should still keep it unix platform independent.

    It may even be possible to do all this without any change to

    the Joy executable, but just a small change in two libraries:

    1. What you called .joyrc seems to be what is currently called

       usrlib.joy. In this file (with all the personal stuff) add

       the definition:

            JOYLIBRARY == "ourmachine%funny-disk#userlibs/joy"

       or whatever. Also, the include command towards the end

       about including the inilib.joy library should now read

            JOYLIBRARY "inilib.joy" concat include.

    2. This library contains a definition of the library loading command

       libload. That should be changed to concat the filename with

       JOYLIBRARY. All the standard libraries are still loaded by

            "agglib" libload.

       or so, which will expand this name first and then do an include.

       Of course you can always do an ordinary include:

            "ourmachine%superdisk#boss/bosslibs/joy/agglib.joy" include.

    I have not tried this out yet, but it seems to be one way of

    approaching the problem. The only disadvantage (if it is one)

    is that usrlib.joy has to be in the current directory to be

    automatically read. But of course one can do manually:

        "../otherdir/usrlib.joy" include.

    first thing.

    Any thoughts on this ?

      - Manfred

## Heiko.Kuhrt@t-online.de — 2003-02-19 08:31:04

    In my opinion the semicolon as the separating token

    between definitions should be made optional or unmade

    because there are few reasons for the use of the

    semicolon against one big disadvantage.

    For it:

        In some cases, especially when arguing about Joy

        it improves clarity.

        For instance (2) is clearly comprehensible but while

        reading (1) you may wonder if he just forgot

        something.

        In (3) and (4) this is different because of the other

        notation.

        (1) j == i 1 +

        (2) j == i 1 +;

        (3) j = i + 1

        (4) j = i + 1;

    Against it:

        In the daily work of editing you constantly have

        to take care about that f. semicolon.

        When I start to edit a single definition I first move

        the semicolon into the next line, do my editing and

        then get the semicolon back. Sometimes I forget about

        all that and get obscure errors.

        The last definition of a libra must not be finished

        with a semicolon. But while editing Joy I do cut and

        paste all the time and end up with periods in the

        mid of libri and semicolons where they are unwanted.

        Look at the scratch.joy file Neil included in his

        package. (see below)

        Or look at the workaround I'm using. (see below below)

        Both examples show there is something unjoyous with

        the syntax of Joy.

    An optional semicolon would save time of future Joy programmers

    and spare their nerves.

    Regards

    Heiko

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

    (*	Joy Scratch File.

    	Put your code into the library and then call it

    *)

    LIBRA

    	minus == -;

    	add == +  # Note a semicolon on the last line will cause an error

    . # END LIBRA

    # output starts here

    "Scratch output:\n\n" putchars.

     66 4 minus.

     66 4 add.

    newline.

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

    	["Rabbit."strong big]["rabbit"at-yahoo-files]link

    	]p

    	;

    	ENDLIBRA == id.

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

## Nick Forde — 2003-02-19 12:54:39

    Heiko.Kuhrt@... writes:

      > In my opinion the semicolon as the separating token

     > between definitions should be made optional or unmade

     > because there are few reasons for the use of the

     > semicolon against one big disadvantage.

      [...]

      > An optional semicolon would save time of future Joy programmers

     > and spare their nerves.

     Currently the semicolon makes it possible for the parser to detect the

    end of definitions. If you remove this it is necessary to replace it

    with another end-of-definition token. Alternatively using lookahead

    the parser could search for either the next "ident ==" or a library

    termination token. This should be OK as long as "==" is only ever used

    in this context.

    I agree that "." as the current library termination token is

    annoyingly easy to misplace. If ";" was removed then I'd rather

    replace "." with an alternative such as "END" or "ENDLIBRA".

    Personally I don't like optional syntax.

    Nick.

## Martin Young — 2002-08-18 12:38:57

    In Monkey I used this syntaxc:

    word == [[  <defn>  ]]

    This has the advantage of an explicit termination symbol plus any

    bracket matching editor will be able to check which definition a

    particular ']]' is closing.

    Also, I like the double bracket thing 'cause it gives the (correct,

    IMHO) impression that a definition is a strong form of list.

    It has the downside it means that the general language syntax must have

    whitespace between the closing brackets of lists.

     On Wed, 2003-02-19 at 12:54, Nick Forde wrote:

    > Heiko.Kuhrt@... writes:

    >  > In my opinion the semicolon as the separating token

    >  > between definitions should be made optional or unmade

    >  > because there are few reasons for the use of the

    >  > semicolon against one big disadvantage.

    >  [...]

    >  > An optional semicolon would save time of future Joy programmers

    >  > and spare their nerves.

    >

    > Currently the semicolon makes it possible for the parser to detect the

    > end of definitions. If you remove this it is necessary to replace it

    > with another end-of-definition token. Alternatively using lookahead

    > the parser could search for either the next "ident ==" or a library

    > termination token. This should be OK as long as "==" is only ever used

    > in this context.

    >

    > I agree that "." as the current library termination token is

    > annoyingly easy to misplace. If ";" was removed then I'd rather

    > replace "." with an alternative such as "END" or "ENDLIBRA".

    >

    > Personally I don't like optional syntax.

## Neil A Walker <neil@quill.plus.com> — 2003-02-19 19:46:20

    --- In concatenative@yahoogroups.com, phimvt@l... wrote:

     >

    > On Tue, 18 Feb 2003, Neil A Walker <neil@q...> wrote:

    >

    > [..]

    >

    > > Speaking as a layman I do feel that Joy would benefit from a

     simple

     > > directory structure, and some means of the joy executable knowing

    > > where its library files are, maybe an JOYLIBRARY environmental

    > > variable a user could set, or .joyrc file readable on startup.

    > > This would certainly make the language more accessible to first

     time

     > > users, and should still keep it unix platform independent.

    >

    > It may even be possible to do all this without any change to

    > the Joy executable, but just a small change in two libraries:

    >

    > 1. What you called .joyrc seems to be what is currently called

    >    usrlib.joy. In this file (with all the personal stuff) add

    >    the definition:

    >         JOYLIBRARY == "ourmachine%funny-disk#userlibs/joy"

    >    or whatever. Also, the include command towards the end

    >    about including the inilib.joy library should now read

    >         JOYLIBRARY "inilib.joy" concat include.

     This works fine can now find the Joy libraries wherever they are,

     >

    > 2. This library contains a definition of the library loading command

    >    libload. That should be changed to concat the filename with

    >    JOYLIBRARY. All the standard libraries are still loaded by

    >         "agglib" libload.

    >    or so, which will expand this name first and then do an include.

    >    Of course you can always do an ordinary include:

    >         "ourmachine%superdisk#boss/bosslibs/joy/agglib.joy" include.

     and modifying libload nicely takes care of the rest,

    and I learnt a little more about joy!

    so... now at at a position where the library files can be seperated

    out from the joy executable, the docs can go anywhere.

     >

    > I have not tried this out yet, but it seems to be one way of

    > approaching the problem. The only disadvantage (if it is one)

    > is that usrlib.joy has to be in the current directory to be

    > automatically read. But of course one can do manually:

    >     "../otherdir/usrlib.joy" include.

    > first thing.

    >

    > Any thoughts on this ?

    >

    >   - Manfred

     It would be nice to seperate the executable and the usrlib but for

    the time being the they both can go into a /local/bin directory.

    I have put together have a working rpm build, but need to sort out

    permissions, I also would like to put some items into the users home

    directory but not sure if this is posssible :(

    One item I would like advice on is the information that is visible to

    the outside world from within the rpm. At the moment this is as

    follows the description taken from your documentation,

    #

    # joy-linux spec file

    #

    Summary: A purely functional programming language.

    Name: joy-linux  # not sure about the name

    Version: 0.1

    Release: 1

    Copyright: ?? MIT GPL or ? needs to be one line

    Group: Application/Language

    Source: http://www.quill.plus.com/joy/joy-linux-0.1.tar.gz

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

    Packager: Neil A Walker <neil@...>

    Prefix: /usr/local

    %Description

    Joy is a high-level purely functional programming language

    which is not based on the application of functions but on the

    composition of functions. Joy differs from lambda calculus

    languages in that it has no variables and hence no abstraction.

    It differs from the combinatory calculus in that it does not

    use application. It differs from the categorical languages

    in uniformly using an untyped stack as the argument and value

    of the composed  functions. One of the datatypes is that of

    programs, and the language makes extensive use of this, more

    than other reflective languages. -- Manfred von Thun

    <cut>

    the rest of the file is concerned with the build

    Regards

    Neil

## phimvt@lurac.latrobe.edu.au — 2003-02-20 02:21:10

    On Wed, 19 Feb 2003, Nick Forde wrote:

     > Heiko.Kuhrt@... writes:

     [..]

     >  > An optional semicolon would save time of future Joy programmers

    >  > and spare their nerves.

    >

    > Currently the semicolon makes it possible for the parser to detect the

    > end of definitions. If you remove this it is necessary to replace it

    > with another end-of-definition token. Alternatively using lookahead

    > the parser could search for either the next "ident ==" or a library

    > termination token. This should be OK as long as "==" is only ever used

    > in this context.

     It is instructive to see what a general policy against separators

    in the mainstream conventional programming languages would do.

    Distinguish two versions:

       (1) "no separators at all!"

       (2) "replace separators by terminators!"

    Now apply either one to, say, the comma separator in parameter lists,

    both for formal and for actual parameters. Or apply it to various

    other places where sequences of some sort are allowed.

    A similar problem arose in the definition of statement sequences

    in Pascal. The ";" is a separator, but it is made to look like

    a terminator by the simple device of allowing null statements.

    The same device could be used in the grammar for Joy. Currently

    the grammar has the following production:

        definition  ::=

    1.           atomic-symbol

    2.        |  "HIDE" definition-sequence "IN" definition-sequence "END"

    The proposal would amount to adding a third alternative:

    3.        |  null

    The production for definition-sequence would stay, with ";" as

    separator. Whether you think of the ";" as separator or as terminator

    makes no difference now. Existing code would not be broken.

     > I agree that "." as the current library termination token is

    > annoyingly easy to misplace. If ";" was removed then I'd rather

    > replace "." with an alternative such as "END" or "ENDLIBRA".

     I have had similar thoughts too, but I cannot decide between

    just one "END" or several: "ENDLIBRA", "ENDDEFINE", "ENDHIDE"

    "ENDMODULE", "END-whatever-the-future-might-bring".

    [..]

      - Manfred

## phimvt@lurac.latrobe.edu.au — 2003-02-26 04:52:57

    On Thu, 20 Feb 2003 phimvt@... wrote:

     > On Wed, 19 Feb 2003, Nick Forde wrote:

    >

    > > Heiko.Kuhrt@... writes:

     [a propos the semicolon as definition separator]

     > A similar problem arose in the definition of statement sequences

    > in Pascal. The ";" is a separator, but it is made to look like

    > a terminator by the simple device of allowing null statements.

    >

    > The same device could be used in the grammar for Joy. Currently

    > the grammar has the following production:

    >     definition  ::=

    > 1.           atomic-symbol

    > 2.        |  "HIDE" definition-sequence "IN" definition-sequence "END"

    > The proposal would amount to adding a third alternative:

    > 3.        |  null

    > The production for definition-sequence would stay, with ";" as

    > separator. Whether you think of the ";" as separator or as terminator

    > makes no difference now. Existing code would not be broken.

     I have made this small change in the function definition()

    in the file main.c . I have also changed, in the same file,

    several matters relating to HIDE to allow HIDE within HIDE within ...

    To do that it was also necessary to change the file globals.h

    a little bit. Much of this is in preparation for MODULEs.

    So, it is probably not worth your while to update these two

    files as yet, but the updated versions are now on the web page

    if you really want them now.

      - Manfred

## Nick Forde — 2003-02-26 09:48:08

    phimvt@... writes:

      > > the grammar has the following production:

     > >     definition  ::=

     > > 1.           atomic-symbol

     > > 2.        |  "HIDE" definition-sequence "IN" definition-sequence "END"

     > > The proposal would amount to adding a third alternative:

     > > 3.        |  null

     > > The production for definition-sequence would stay, with ";" as

     > > separator. Whether you think of the ";" as separator or as terminator

     > > makes no difference now. Existing code would not be broken.

     >

     > I have made this small change in the function definition()

     > in the file main.c .

     I like this update to the syntax.

      > I have also changed, in the same file,

     > several matters relating to HIDE to allow HIDE within HIDE within ...

     > To do that it was also necessary to change the file globals.h

     > a little bit. Much of this is in preparation for MODULEs.

     > So, it is probably not worth your while to update these two

     > files as yet, but the updated versions are now on the web page

     > if you really want them now.

     Could I also suggest that "." and "END" be made synonymous? e.g.

    LIBRA

      mydef == myval;

    END

    LIBRA mydeff == myval.

    LIBRA

      HIDE

        mydef == myval;

      IN

        mynewdef == mynewval;

      END

    END

    LIBRA

      HIDE mydef == myval IN

        mynewdef == mynewval.

    END

    DEFINE mydef == myval.

    DEFINE mydef == myval END

    This would remain backwards compatible but in my opinion make library

    definitions a bit nicer.

    Nick.

## phimvt@lurac.latrobe.edu.au — 2003-02-28 03:51:10

    On Wed, 26 Feb 2003, Nick Forde wrote:

     > phimvt@... writes:

    >  > > the grammar has the following production:

    >  > >     definition  ::=

    >  > > 1.           atomic-symbol

    >  > > 2.        |  "HIDE" definition-sequence "IN" definition-sequence "END"

    >  > > The proposal would amount to adding a third alternative:

    >  > > 3.        |  null

     Ooops. Not that it matters for the present purpose, but line 1 should be:

           1.           atomic-symbol "==" term

    [.. stuff about nested HIDEs ..]

     > Could I also suggest that "." and "END" be made synonymous? e.g.

     Thank you. Indeed, and its long overdue. Or maybe "synonymous for

    the purposes in HIDE's and LIBRA's". That would still leave "."

    available for calls of module functions: "m.f".

    But see also the drastic proposal about modules in my other post.

      - Manfred

## Nick Forde — 2003-02-28 13:30:39

    phimvt@... writes:

      >

     > > Could I also suggest that "." and "END" be made synonymous? e.g.

     >

     > Thank you. Indeed, and its long overdue. Or maybe "synonymous for

     > the purposes in HIDE's and LIBRA's". That would still leave "."

     > available for calls of module functions: "m.f".

     Yes. That is what I meant to say.

    Nick.