Arc Forumnew | comments | leaders | submitlogin
2 points by shader 2518 days ago | link | parent

"there might be a way to merge conses and symbols into a single type"

Interesting idea. This might help a lot with implementing lisp in strongly typed languages. I suppose atoms could just be cons cells with nil in their cdr slot. The only problem is then how do you get the actual value out of an atom, and what is it?



2 points by rocketnia 2518 days ago | link

This might help a lot with implementing lisp in strongly typed languages.

Don't most of them have option types or polymorphism of some kind? If you've got a really rigid one, at least you can represent every value the lisp as a structure with one element being the internal dynamic type (represented as an integer if necessary) and at least two child elements of the same structure type and one element of every built-in type you'll ever need to manipulate from the lisp (like numbers and sockets). Then you just do manual checks on the dynamic type to see what to do with the rest. :-p

The only problem is then how do you get the actual value out of an atom, and what is it?

I say the programmer never gets the actual value out of the atom. :-p It's just handled automatically by all the built-in functions. However, this does mean the cons cell representation is completely irrelevant to a high-level programmer.

-----

1 point by evanrmurphy 2518 days ago | link

> I suppose atoms could just be cons cells with nil in their cdr slot.

Could they be annotated conses with symbol in the car and value in the cdr (initialized to nil)? nil itself could then be a cons with the nil symbol in the car and nil in the cdr. This should achieve the cons-symbol duality for nil that's usually desired. (Follow-up question: annotate is an axiom, right?)

Warning: May include sloppy thinking.

-----