Gday,
This to announce the start of a new project to
enhance Lisp-like languages with dispatch on type
features. The intent is to provide programmers with
a way to formally define the grammar of their list
structures, and to add 'generic' or polymorphic
functions on lists. The main difference between Genyris and
CLOS is that the you get dispatch on type for Plain Old Lists (POLs).
It is also designed to give you ambiguous data types.
So you can enter a list at the prompt and Genyris will
tell you what types it conforms to:
>- (types-of '(2134 . 986))
(complex point rational vector cons)
Here's a familiar example:
Consider the following code fragment from Paul
Graham's implementation of John McCarthy's LISP:
(defun eval. (e a)
(cond
((atom e) (assoc. e a))
((atom (car e))
(cond
((eq (car e) 'quote) (cadr e))
((eq (car e) 'atom) (atom (eval. (cadr e) a)))
((eq (car e) 'eq) (eq (eval. (cadr e) a)
(eval. (caddr e) a)))
...
To rewrite this using Genyris, first we need to define some list
types:
(define-type atom symbol)
(define-type quote-form 'quote thing) ; e.g. '(quote fred ...)
(define-type atom-form 'atom thing) ; e.g. '(atom z)
(define-type eq-form 'eq thing) ; e.g. '(eq x y)
Then we write individual generic functions for eval.
which apply to the identified types:
(define-generic g-eval. ((atom e) (alist a))
(assoc. e a))
(define-generic g-eval. ((atom-form e) (alist a))
(atom (eval. (cadr e) a)))
(define-generic g-eval. ((quote-form e) (alist a))
(cadr e))
(define-generic g-eval. ((eq-form e) (alist a))
(eq (g-eval. (cadr e) a) (g-eval. (caddr e) a)))
With source code in this form we can add new evaluation rules to
g-eval. without needing to modify existing code. Whereas in the
traditional eval. function there is a single cond expression which
must be maintained. We can also over-ride an existing definition
with a more specific data type. The dispatcher will always call the
most specific available function. For example we could add integers
to g-eval:
(define-generic g-eval. ((fixum e) a) e)
There's more features than I can put in this post. An essay describing
the approach is available on sourceforge here:
http://prdownloads.sourceforge.net/genyris/GenyrisEssay20040826.pdf?download
Of course I will be ETERNALLY grateful to anyone who troubles
themselves to read it. A couple of Lisp people have reviewed it here
in Australia (thanks guys) so it isn't _too_ ordinary. I'm reasonably
confident that someone will point out a way to do this in CLOS or
Scheme. I looked but couldn't see it.
You can either clutter up this newsgroup in the traditional c.l.l way
or you can post criticism, comments to the sourceforge newsgroup here:
http://sourceforge.net/forum/forum.php?forum_id=396258
On a personal note I have to say how much I have appreciated help from
c.l.l.ers in the past. I'm really curious to see what your reaction to
this idea will be.
Cheers,
Bill Birch
From: Christopher C. Stacy
Subject: Re: Deep Typing for Plain Old Lists - A new kind of LISP?
Date:
Message-ID: <u8ybzosav.fsf@news.dtpq.com>
Your proposed langauge suggests that lists are appropriate for representing
general data structures, and you say that your language "gives programmers
working with lists the well-known benefits of polymorphism".
If I understand you correctly, the underlying functional point of your
proposal is to provide a way to re-program the built-in Lisp operators,
and to promote lists are the representation of all abstract structures
(To implement this, your language adds a user-defined type-tag to the
implementation of every CONS cell.)
You mention an example (in Arc) where CAR and CDR have been defined on
character strings; but since your proposal talks about list structure,
I'm not sure if you are proposing that all data objects in Lisp should
be implemented as lists. You do seem to be suggesting that all user
defined objects be lists, annotated with abstract type and grammar.
Your idea is in contrast the Common Lisp philosophy that the built-in
operators have unchangeable semantics, which is desirable so that programs
can be more easily understood. When a person sees "CAR", they never have
to wonder what it means, because its meaning can not have been changed
or extended in any way.
(That's is not strictly enforced in the face of packages, but it is
considered very extraordinary to create a namespace in which the
Common Lisp symbol names have changed meanings. Once you do that,
one would say that you are no longer programming in Common Lisp!)
Lisp eschews the conflation of abstract structures and lists,
and has CLOS instead. We also don't think that the "overloading"
kind of polymorphism is a "well-known benefit". (You also mention
performance issues and seem to imply that this is the roadblack,
but that's not really the basis of our counter philosophy.)
The Common Lisp stance is similar to that of Java in this regard.
Not all Lisp-like languages share Common Lisp's philosophy here.
For a look at a Lisp-like language that provides an abstract structure
and type system like CLOS, along with operator overloading like C++,
take a look at Dylan. Scheme allows primitive operators to be redefined
······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
> Your proposed langauge suggests that lists are appropriate for representing
> general data structures, and you say that your language "gives programmers
> working with lists the well-known benefits of polymorphism".
>
> If I understand you correctly, the underlying functional point of your
> proposal is to provide a way to re-program the built-in Lisp operators,
> and to promote lists are the representation of all abstract structures
> (To implement this, your language adds a user-defined type-tag to the
> implementation of every CONS cell.)
Yes, I hope to get away with a single integer or pointer. The user
would never see this directly though.
> You mention an example (in Arc) where CAR and CDR have been defined on
> character strings; but since your proposal talks about list structure,
> I'm not sure if you are proposing that all data objects in Lisp should
> be implemented as lists. You do seem to be suggesting that all user
> defined objects be lists, annotated with abstract type and grammar.
Yes, lists have a magic property.
>
> Your idea is in contrast the Common Lisp philosophy that the built-in
> operators have unchangeable semantics, which is desirable so that programs
> can be more easily understood. When a person sees "CAR", they never have
> to wonder what it means, because its meaning can not have been changed
> or extended in any way.
I doubt CL really has a philosophy, rather it was a result of
compromise around standardization. Certainly the references on the
history of CL paint this kind of picture. The other side (Scheme)
seemed to have a much more focussed genesis and a real philosophy.
>
> Lisp eschews the conflation of abstract structures and lists,
> and has CLOS instead. We also don't think that the "overloading"
> kind of polymorphism is a "well-known benefit". (You also mention
> performance issues and seem to imply that this is the roadblack,
> but that's not really the basis of our counter philosophy.)
> The Common Lisp stance is similar to that of Java in this regard.
Apart from the meta object protocol, how different is CLOS to Java? I
like LISP because the (read) function will read in a file containing a
language of my own invention. I don't think CLOS can do that, can it?
My intention is to use the LISP syntax for everything, and to do that
I need to be able to define classes of list structures. One way to
think of this, (read) is the lexical analyser and Genyris is the
grammar. Genyris allows me to tell the computer what my lists are for.
>
> Not all Lisp-like languages share Common Lisp's philosophy here.
> For a look at a Lisp-like language that provides an abstract structure
> and type system like CLOS, along with operator overloading like C++,
> take a look at Dylan. Scheme allows primitive operators to be redefined
Sadly Dylan has a syntax. A collegue told me that I can redefined CONS
in Scheme, is this really true? How can inbuilt compiled machine code
cope with that?
From: Joe Marshall
Subject: Re: Deep Typing for Plain Old Lists - A new kind of LISP?
Date:
Message-ID: <fz63v428.fsf@ccs.neu.edu>
······@ozemail.com.au (Bill Birch) writes:
> Apart from the meta object protocol, how different is CLOS to Java?
multiple inheritance vs. Single-inheritance + `interfaces'
generic functions vs. Method encapsulation in classes
multimethod dispatch vs. single dispatch
runtime type dispatch vs. compile-time + `virtual'
method combination vs. `patterns of design'
I'd say they are practically indistinguishable, no?
> I like LISP because the (read) function will read in a file
> containing a language of my own invention. I don't think CLOS can do
> that, can it?
Why not?
> Sadly Dylan has a syntax.
All computer languages have syntax.
> A collegue told me that I can redefined CONS in Scheme, is this
> really true?
Yes.
> How can inbuilt compiled machine code cope with that?
With difficulty.
Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> ······@ozemail.com.au (Bill Birch) writes:
>
> > Apart from the meta object protocol, how different is CLOS to Java?
>
> multiple inheritance vs. Single-inheritance + `interfaces'
> generic functions vs. Method encapsulation in classes
> multimethod dispatch vs. single dispatch
> runtime type dispatch vs. compile-time + `virtual'
> method combination vs. `patterns of design'
>
> I'd say they are practically indistinguishable, no?
>
OK, you're right. But my boss makes me use it. ;-)
> > I like LISP because the (read) function will read in a file
> > containing a language of my own invention. I don't think CLOS can do
> > that, can it?
>
> Why not?
>
Can you expand on that? Last time I used CLOS it printed out objects
as some kind of opaque format. e.g. #<person @ #x7bf826> Excluding
make-instance, is there a parser for reading in CLOS objects from
ASCII streams?
Bill Birch wrote:
> Can you expand on that? Last time I used CLOS it printed out objects
> as some kind of opaque format. e.g. #<person @ #x7bf826> Excluding
> make-instance, is there a parser for reading in CLOS objects from
> ASCII streams?
MAKE-LOAD-FORM allows you to define your own (readable) externalization
format, with MAKE-LOAD-FORM-SAVING-SLOTS providing a useful default.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Frode Vatvedt Fjeld
Subject: Re: Deep Typing for Plain Old Lists - A new kind of LISP?
Date:
Message-ID: <2hpt578vn3.fsf@vserver.cs.uit.no>
······@ozemail.com.au (Bill Birch) writes:
> I doubt CL really has a philosophy, rather it was a result of
> compromise around standardization. Certainly the references on the
> history of CL paint this kind of picture. The other side (Scheme)
> seemed to have a much more focussed genesis and a real philosophy.
Having been a student of the Common Lisp standard for about five years
now, I'm still being regularly amazed by the beautiful philosophy and
level of success of balancing pragmatic and idealistic goals that it
represents. I don't think any other programming language specification
comes close.
> Apart from the meta object protocol, how different is CLOS to Java?
> I like LISP because the (read) function will read in a file
> containing a language of my own invention. I don't think CLOS can do
> that, can it?
It appears that you are seriously confused as to what Lisp and CLOS
is. CLOS is (but) one aspect of Common Lisp, and is unrelated to
syntax.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
>
> It appears that you are seriously confused as to what Lisp and CLOS
> is. CLOS is (but) one aspect of Common Lisp, and is unrelated to
> syntax.
OK let's clarify. LISP <> Lisp. CLOS is part of Common Lisp but not
part of LISP. LISP came before Common Lisp and Scheme. CLOS not part
of Scheme either...
Bill Birch wrote:
> Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
>
>>It appears that you are seriously confused as to what Lisp and CLOS
>>is. CLOS is (but) one aspect of Common Lisp, and is unrelated to
>>syntax.
>
> OK let's clarify. LISP <> Lisp. CLOS is part of Common Lisp but not
> part of LISP. LISP came before Common Lisp and Scheme. CLOS not part
> of Scheme either...
The part-of relationship doesn't make a lot of sense in the Lisp world
because Lisp languages intentionally blur the line between language and
library. Common Lisp and Scheme have standards, so it's possible to
determine what's part of those standards and what's not. LISP doesn't
have a standard, so discussions about what belongs to LISP are pretty
useless, AFAICT. Everyone has their own private idea what belongs to a
"core" LISP, but that does'nt buy you anything.
There is an implementation of CLOS for Scheme called Tiny CLOS. The
Swindle library for Scheme has a more complete version of Tiny CLOS.
There are also other CLOSish object systems for Scheme.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Christopher C. Stacy
Subject: Re: Deep Typing for Plain Old Lists - A new kind of LISP?
Date:
Message-ID: <uacwaj6xh.fsf@news.dtpq.com>
>>>>> On 31 Aug 2004 20:43:16 -0700, Bill Birch ("Bill") writes:
Bill> OK let's clarify. LISP <> Lisp. CLOS is part of Common Lisp but not
Bill> part of LISP. LISP came before Common Lisp and Scheme.
What is this "LISP" you speak of and where can I read
the language spec download an implementation?
Christopher C. Stacy wrote:
>>>>>>On 31 Aug 2004 20:43:16 -0700, Bill Birch ("Bill") writes:
>
> Bill> OK let's clarify. LISP <> Lisp. CLOS is part of Common Lisp but not
> Bill> part of LISP. LISP came before Common Lisp and Scheme.
>
> What is this "LISP" you speak of and where can I read
> the language spec download an implementation?
>
http://www.paulgraham.com/rootsoflisp.html
LISP is a language design, not a language. There have been many
different languages which were (and are) LISP. Scheme is a LISP;
Common Lisp is a LISP; so are Oaklisp, Eulisp, Elisp, Zetalisp,
Autolisp, .... Some folks would even include languages like OPS5,
New Lisp, Haskell, and Dylan in the design space.
It began as a mathematician's attempt to create a mathematical
model of computation, based on the lambda calculus rather than
on the Turing machine. I think the original paper outlined
seven things a LISPy language needed to be complete; any language
that has those things, or facilities isomorphic to them, is a LISP,
regardless of its surface syntax. "Mainstream" languages have
been edging ever nearer to LISP as they grow more powerful; sooner
or later somebody is going to add one more thing to the latest
popular or experimental programming language and come full circle
by reinventing LISP.
LISP is traditionally implemented with a fully parenthesized prefix
syntax, macros that work on the parse tree rather than on strings
of source code, automatic memory management, a heavy reliance on
pair and list-based data structures, and dynamic typing (that is,
it's values rather than variables which have types). Different
people have different ideas about whether a language can lack any
particular combination of these and still be a LISP.
Bear
From: Matthew Danish
Subject: Re: Deep Typing for Plain Old Lists - A new kind of LISP?
Date:
Message-ID: <20040901220603.GS8087@mapcar.org>
On Wed, Sep 01, 2004 at 08:19:46PM +0000, Ray Dillinger wrote:
> It began as a mathematician's attempt to create a mathematical
> model of computation, based on the lambda calculus rather than
> on the Turing machine.
Hardly. This is a closer description of Scheme than of the original
ideas behind Lisp, which were more closely tied to AI and the notion of
performing ``symbolic computation'' than to lambda-calculus. The
lambda-notation was adopted not because Lisp was based on the
lambda-calculus, but because it was a convenient, existing notation for
functions. As you should very well know, the original LAMBDA was not
specified with proper substitution semantics; McCarthy admits in his
writings that he did not understand much of Church's paper at the time.
The lambda-calculus itself is a mathematician's attempt to create a
logical basis for mathematics. Lisp originally was a simple language
for manipulating symbols and lists that could easily implement itself,
developed by an AI researcher interested in symbolic differentiation and
similar tasks.
--
;;;; Matthew Danish -- user: mrd domain: cmu.edu
;;;; OpenPGP public key: C24B6010 on keyring.debian.org
From: Christopher C. Stacy
Subject: Re: Deep Typing for Plain Old Lists - A new kind of LISP?
Date:
Message-ID: <ubrgp8zvx.fsf@news.dtpq.com>
>>>>> On Wed, 01 Sep 2004 20:19:46 GMT, Ray Dillinger ("Ray") writes:
Ray> Christopher C. Stacy wrote:
>>>>>>> On 31 Aug 2004 20:43:16 -0700, Bill Birch ("Bill") writes:
Bill> OK let's clarify. LISP <> Lisp. CLOS is part of Common Lisp
>> but not
Bill> part of LISP. LISP came before Common Lisp and Scheme.
>> What is this "LISP" you speak of and where can I read
>> the language spec download an implementation?
>>
Ray> http://www.paulgraham.com/rootsoflisp.html
I think you have misunderstood Graham's paper.
From: ? the Platypus {aka David Formosa}
Subject: Re: Deep Typing for Plain Old Lists - A new kind of LISP?
Date:
Message-ID: <m3fz5aaupw.fsf@dformosa.zeta.org.au>
Ray Dillinger <····@sonic.net> writes:
[...]
> LISP is traditionally implemented with a fully parenthesized prefix
> syntax, macros that work on the parse tree rather than on strings
> of source code, automatic memory management, a heavy reliance on
> pair and list-based data structures, and dynamic typing (that is,
> it's values rather than variables which have types). Different
> people have different ideas about whether a language can lack any
> particular combination of these and still be a LISP.
So by that definition perl6 (from what we know of it) is a lisp?
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
? the Platypus {aka David Formosa} wrote:
> Ray Dillinger <····@sonic.net> writes:
>
> [...]
>
>
>>LISP is traditionally implemented with a fully parenthesized prefix
>>syntax, macros that work on the parse tree rather than on strings
>>of source code, automatic memory management, a heavy reliance on
>>pair and list-based data structures, and dynamic typing (that is,
>>it's values rather than variables which have types). Different
>>people have different ideas about whether a language can lack any
>>particular combination of these and still be a LISP.
>
>
> So by that definition perl6 (from what we know of it) is a lisp?
>
We'll have to wait and see; if there's a notation for source
code that also reads as data whose structure is isomorphic
to the source code's parse tree, and it has macros that work
on that form, I think I'd have to say yes.
Until someone finds a way to go further, Lisp of some kind
is what's standing at the end of every language-design journey.
Bear
"? the Platypus {aka David Formosa}" <········@zeta.org.au> wrote:
> Ray Dillinger <····@sonic.net> writes:
>
> [...]
>
> > LISP is traditionally implemented with a fully parenthesized prefix
> > syntax, macros that work on the parse tree rather than on strings
> > of source code, automatic memory management, a heavy reliance on
> > pair and list-based data structures, and dynamic typing (that is,
> > it's values rather than variables which have types). Different
> > people have different ideas about whether a language can lack any
> > particular combination of these and still be a LISP.
>
> So by that definition perl6 (from what we know of it) is a lisp?
If there's something that Perl6 *isn't*, let Larry Wall know, and he'll take
care of it. With punctuation.
Anton
Bill Birch wrote:
> Gday,
>
> This to announce the start of a new project to
> enhance Lisp-like languages with dispatch on type
> features. The intent is to provide programmers with
> a way to formally define the grammar of their list
> structures, and to add 'generic' or polymorphic
> functions on lists. The main difference between Genyris and
> CLOS is that the you get dispatch on type for Plain Old Lists (POLs).
...
> Here's a familiar example:
>
> Consider the following code fragment from Paul
> Graham's implementation of John McCarthy's LISP:
>
> (defun eval. (e a)
> (cond
> ((atom e) (assoc. e a))
> ((atom (car e))
> (cond
> ((eq (car e) 'quote) (cadr e))
> ((eq (car e) 'atom) (atom (eval. (cadr e) a)))
> ((eq (car e) 'eq) (eq (eval. (cadr e) a)
> (eval. (caddr e) a)))
> ...
>
> To rewrite this using Genyris, first we need to define some list
> types:
>
> (define-type atom symbol)
>
> (define-type quote-form 'quote thing) ; e.g. '(quote fred ...)
> (define-type atom-form 'atom thing) ; e.g. '(atom z)
> (define-type eq-form 'eq thing) ; e.g. '(eq x y)
>
> Then we write individual generic functions for eval.
> which apply to the identified types:
>
> (define-generic g-eval. ((atom e) (alist a))
> (assoc. e a))
>
> (define-generic g-eval. ((atom-form e) (alist a))
> (atom (eval. (cadr e) a)))
>
> (define-generic g-eval. ((quote-form e) (alist a))
> (cadr e))
>
> (define-generic g-eval. ((eq-form e) (alist a))
> (eq (g-eval. (cadr e) a) (g-eval. (caddr e) a)))
I haven't read your paper (yet), but I think this example can already be
tackled well with CLOS. You have to change the order of arguments and
use APPLY to achieve the same effect that you describe. Here is some
(untested) code:
(defmethod g-eval. ((a list) (e symbol))
(assoc. e a))
(defmethod g-eval. ((a list) (e list))
(apply #'g-eval-form. a e))
(defmethod g-eval-form. ((a list) (e-car (eql 'atom)) &rest e-cdr)
(atom (g-eval. a (car e-cdr))))
(defmethod g-eval-form. ((a list) (e-car (eql 'quote)) &rest e-cdr)
(car e-cdr))
(defmethod g-eval-form. ((a list) (e-car (eql 'eq)) &rest e-cdr)
(eq (g-eval. a (car e-cdr)) (g-eval. a (cadr e-cdr))))
...
(defmethod g-eval. ((a list) (e fixnum))
e)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> wrote:
+---------------
| I haven't read [Bill Birch's] paper (yet), but I think this example
| can already be tackled well with CLOS. You have to change the order
| of arguments and use APPLY to achieve the same effect that you describe.
+---------------
Why is that? The argument order (EVAL expression &OPTIONAL environment)
[where "a" in Bill's example is "environment", probably called "a" for
"alist"] has a long history in Lispy languages and tutorial interpreters
and it would be unfortunately confusing to reverse it unnecessarily.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Pascal Costanza <········@web.de> wrote:
> +---------------
> | I haven't read [Bill Birch's] paper (yet), but I think this example
> | can already be tackled well with CLOS. You have to change the order
> | of arguments and use APPLY to achieve the same effect that you describe.
> +---------------
>
> Why is that? The argument order (EVAL expression &OPTIONAL environment)
> [where "a" in Bill's example is "environment", probably called "a" for
> "alist"] has a long history in Lispy languages and tutorial interpreters
> and it would be unfortunately confusing to reverse it unnecessarily.
My code works by spreading out the form (called "e" in Bill's code) via
APPLY when it's a list, so that another generic function can pick out
its first element, and methods on that gf can define eql specializers on
that first element. This "spreading out" only works for the last
argument to APPLY, so I had to shift "e" to the last argument position.
The confusion should be avoidable by using more descriptive names, like
"env" and "form".
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
On 28 Aug 2004 05:08:39 -0700, Bill Birch <······@ozemail.com.au> wrote:
> Gday,
>
> This to announce the start of a new project to
> enhance Lisp-like languages with dispatch on type
> features. The intent is to provide programmers with
> a way to formally define the grammar of their list
> structures, and to add 'generic' or polymorphic
> functions on lists. The main difference between Genyris and
> CLOS is that the you get dispatch on type for Plain Old Lists (POLs).
>
Hi Bill and otyher Lisper's,
after reading through the proposal, I am left with a question regarding the
type of the empty list and NIL.
As I understand this proposal, it is about the types of things in a list.
But what happens if there is nothing in the list?
Would it be possible to disambiguate between the empty list and NIL?
cheers,
marc