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.