On Mon, Feb 17, 2020 at 10:11 PM Rick Hudson <r...@golang.org> wrote:
> > type Treenode struct {
> > left *Treenode
> > right *Treenode
> > }
>
> One could of course design a language where Treenode is called cons and
> left is called car and right is called cdr and (car nil) is nil and (cdr
> nil) is nil. You could implement such a language by putting 2 words of 0
> at location 0 and add a write barrier or page protection to enforce nil
> immutable.
>
>
Roughly also what happens in e.g., OCaml. If you define
type 'a tree = Leaf | Node of 'a * 'a tree * 'a tree
then the variant is represented with leaf being the integer 0 and node
being a box with integer tag 1. If we follow that up with
type x = Foo | Bar
then Foo has tag 0 and Bar has tag 1, reusing the tag counters. The type
system ensures we cannot accidentally use something of type x in lieu of 'a
tree and vice versa.
The important part is that the representation is somewhat hidden from us as
programmers. The system decides upon one, and uses it consistently. It is
one of the defining characteristics of Go that this won't happen in the
language (where representations are often quite explicit and chosen by the
programmer. This comes with certain advantages in that the memory layout is
known).
As for hash tables in OCaml, they have no "nil" representation and are
plain old structs. I guess this leans much the same way as the Go
representation.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiW0RuO3oUSOd41HzGHB5kQzAu29d-7AngbGNEsjCs4DaQ%40mail.gmail.com.
