www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dLISP

reply Fredrik Olsson <peylow gmail.com> writes:
On a more serious note;

I have written a small implementation of a subset of LISP.

http://peylow.no-ip.org/~peylow/dLISP.zip

It uses pointers quite allot, as need for pointers should be minimal in 
D I want some hints on how to I could get rid of them (if I should).

The simple parser could need to be replaced worth something fancy. 

only), lists, and the standard ' and . shorthands for quote and cons.

The most tedious job is to implement the build-in forms, not hard at all 
but it takes time. So far +, -, *, /, defun, lambda, setq and eval are 
done. Adding new forms is quite easy, take a look in evalpredefs.d for 
examples. It is simply concells with function pointers added the the 
global variable array. Helper functions includes naturally.

If someone is willing to implement a set of forms, please do and send me 
a patch, and mail me first so I do not do it myself :).

If you are just curious then compile the application and try these 
inputs, with enter after each line:

(defun exp (a) (* a a))
(setq inc (lambda (a) (+ a 1)))
(inc (- (/ (exp 10) 2) (exp 3)))

The result is the answer :).

regards
	Fredrik Olsson
Oct 10 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Fredrik Olsson" <peylow gmail.com> wrote in message 
news:diecbv$ikr$1 digitaldaemon.com...

 It uses pointers quite allot, as need for pointers should be minimal in D 
 I want some hints on how to I could get rid of them (if I should).


It seems that most of your pointers are just pointers to the Cell struct. 
If you want to get rid of them, make Cell a class.  Additionally, you could 
make Cell a base class, and from it derive IntCell, FloatCell, StringCell, 
etc. and overload the equality operator for all of them, meaning that this 
function:

bool eqCell(Cell* cella, Cell* cellb) {
  // Same Cell or two nils
  if (cella == cellb) {
    return true;
  }
  // One nil
  if (!cella || !cellb) {
    return false;
  }
  // Be more forgiving of types?
  if (cella.cellType != cellb.cellType) {
    return false;
  }
  switch (cella.cellType) {
    case CellType.ctINT:
      return cella.intValue == cellb.intValue;
      break;
    case CellType.ctFLOAT:
      return cella.floatValue == cellb.floatValue;
      break;
    case CellType.ctSTR:
      return cella.strValue == cellb.strValue;
      break;
    case CellType.ctSYM, CellType.ctFORM, CellType.ctPREDEF:
      return cella.name == cellb.name;
      break;
    case CellType.ctCONS:
      return eqList(cella, cellb);
      break;
  }
}

Would become entirely unneccessary.  You'd just use the == operator instead. 
I'd imagine that there are some other areas where polymorphism would help 
with this design as well.

I've always liked making scripting engines and seeing them implemented :) 
though I've never used Lisp, and it looks pretty odd.
Oct 10 2005
parent reply Fredrik Olsson <peylow gmail.com> writes:
Jarrett Billingsley skrev:

 "Fredrik Olsson" <peylow gmail.com> wrote in message 
 news:diecbv$ikr$1 digitaldaemon.com...
 

It uses pointers quite allot, as need for pointers should be minimal in D 
I want some hints on how to I could get rid of them (if I should).


 
 
 It seems that most of your pointers are just pointers to the Cell struct. 
 If you want to get rid of them, make Cell a class.  


<snip>

 I'd imagine that there are some other areas where polymorphism would help 
 with this design as well.
 


I thought about classes as well. But decided against it as interfacing 
with it from C is one goal (Perhaps a php extension? :)). I could use 
wrapper functions but thought that would over complicate it a bit.



 I've always liked making scripting engines and seeing them implemented :) 
 though I've never used Lisp, and it looks pretty odd. 
 


Me too :). My second LISP implementation, the first one about a year ago 
and written in Object Pascal. As allot of work with LISP revolves around 
hash-tables for symbol look-ups and garbage collecting memory I kind of 
thought D would be perfect. So as can be seen, that work is complete 
left to D's build-in associative arrays, and own memory management. 
Works like a charm, my old one leaked memory quite allot :/.
http://sourceforge.net/projects/tlisp/
I would not recommend further work on it, but a good reference point for 
implementing more of the build-in forms.

regards
	Fredrik Olsson
Oct 10 2005
parent Chris Sauls <ibisbasenji gmail.com> writes:
Fredrik Olsson wrote:

 Jarrett Billingsley skrev:
 

 "Fredrik Olsson" <peylow gmail.com> wrote in message 
 news:diecbv$ikr$1 digitaldaemon.com...


 It uses pointers quite allot, as need for pointers should be minimal 
 in D I want some hints on how to I could get rid of them (if I should).




 It seems that most of your pointers are just pointers to the Cell 
 struct. If you want to get rid of them, make Cell a class.  


 
 <snip>
 

 I'd imagine that there are some other areas where polymorphism would 
 help with this design as well.


 
 I thought about classes as well. But decided against it as interfacing 
 with it from C is one goal (Perhaps a php extension? :)). I could use 
 wrapper functions but thought that would over complicate it a bit.


Or you could leave Cell a struct, and use inout parameters (which seem to be
there mostly 
for the express purpose of doing away with the need for explicit pointers in
argument lists).

-- Chris Sauls
Oct 11 2005
prev sibling parent reply Brad Anderson <brad dsource.dot.org> writes:
Fredrik Olsson wrote:

 On a more serious note;
 
 I have written a small implementation of a subset of LISP.
 
 http://peylow.no-ip.org/~peylow/dLISP.zip
 
 It uses pointers quite allot, as need for pointers should be minimal in
 D I want some hints on how to I could get rid of them (if I should).
 
 The simple parser could need to be replaced worth something fancy.

 only), lists, and the standard ' and . shorthands for quote and cons.
 
 The most tedious job is to implement the build-in forms, not hard at all
 but it takes time. So far +, -, *, /, defun, lambda, setq and eval are
 done. Adding new forms is quite easy, take a look in evalpredefs.d for
 examples. It is simply concells with function pointers added the the
 global variable array. Helper functions includes naturally.
 
 If someone is willing to implement a set of forms, please do and send me
 a patch, and mail me first so I do not do it myself :).
 
 If you are just curious then compile the application and try these
 inputs, with enter after each line:
 
 (defun exp (a) (* a a))
 (setq inc (lambda (a) (+ a 1)))
 (inc (- (/ (exp 10) 2) (exp 3)))
 
 The result is the answer :).
 
 regards
     Fredrik Olsson


Fredrik,

I'm curious as to what you're going to do with this implementation.  Are
you going to have a full-blown Lisp compiler/implementation or will it
be a scripting language for embedding into other apps?  Are you shooting
for complete ANSI compliance?  Will you implement macros, LOOP, dynamic
variables, and if so, do you have any thoughts on how to do all of that
in D?

I agree some of D's strengths will help as you listed them above.  You
are welcome to host your project at http://www.dsource.org and I will
see if I can implement some built-in forms for you.

Cheers,
Brad
Oct 11 2005
parent Fredrik Olsson <peylow gmail.com> writes:
Brad Anderson skrev:

 Fredrik Olsson wrote:
 

On a more serious note;




<snip>

 I'm curious as to what you're going to do with this implementation.  Are
 you going to have a full-blown Lisp compiler/implementation or will it
 be a scripting language for embedding into other apps?  Are you shooting
 for complete ANSI compliance?  Will you implement macros, LOOP, dynamic
 variables, and if so, do you have any thoughts on how to do all of that
 in D?
 


First goal is for embedding in applications, mostly since I see some 
need for it myself as extensions to PHP. My first Pascal implementation 
was meant to be a case study for students at my University. 
Unfortunately most of the code is for memory management, so it was hard 
to see the forest for all the trees. So a clean simple implementation 
suited for embedding.



 I agree some of D's strengths will help as you listed them above.  You
 are welcome to host your project at http://www.dsource.org and I will
 see if I can implement some built-in forms for you.
 


Did a quick check on the page, and you use subversion I see. Good that 
is what I use for my personal projects as well :). So sure that would be 
nice, I guess it belong better there than on sourceforge.net. And 
helping out the D community would be nice.

For implementing forms, a try at some of the boolean operators would be 
easy I think. Quite close the the arithmetic once that exist. Personally 
I will go for the conditionals and concell-manipulation forms next; 
badly needed to actually get useful.

Regards
	Fredrik Olsson
Oct 11 2005