"t and nil are now boolean types, not symbols. Sorry. It's hard to reason about them with the newfangled type-based methods if they're symbol types instead of booleans."
It's a bit hard for me to understand the consequences of this, and as you seem to be sorry about the change, I assume there are some consequences worth noting. Could you elaborate?
(def car (x)
(err "can't apply 'car to object" x))
(defm car ((t x cons))
...some scheme-side code....)
(defm car ((t x bool))
(if x
(err "attempt to scan t")
nil))
Of course we could probably still retain t and nil as symbols. However the user might want to define iterating over symbols for some arcane purpose (exploratory, exploratory...). If 'nil is a symbol, the user has to specifically check for the nil symbol when overloading 'car for symbols.
The reason I'm sorry is really because I'm not 100% sure it's the Right Thing (TM), and because I really had to go on with Arc-F instead of dithering over 'nil.
Ah ah ah.... no! The cute thing is that a 'bool presents the "scanner abstraction". Basically, a scanner is anything that overloads the functions 'car, 'cdr, 'scanner, and 'unscan. Thus, you don't have to check for the type of an object: you just need to pass it through 'scanner. If 'scanner throws, it's not a "list". If 'scanner returns a value, you can be sure that it returns a value that will be legitimately passed to 'car and 'cdr.
From this point of view, a "list" is anything that happens to be a scanner.
So nil is a list. So are 'cons cells. So are anything that overloads 'scanner, 'unscan, 'car, and 'cdr.
Try:
(using <lazy-scanner>v1)
...then play around with (lazy-scanner a d)
Or for a bit of ease of use generate an infinite list of positive integers (after doing the 'using thing):
(generate [+ _ 1] 1)
Edit: to summarize: a list is not a cons cell. A cons cell is a list. ^^
Ah...but...what if you want to define a generic function that operates differently on lists and bools (i.e. not a scanner, but a general generic function). I haven't had a close look at Arc-3F yet, so maybe I need to play around a bit more to uderstand what you're saying :)
Well, a "list" is a "scanner". So your "not a scanner" doesn't make sense, at least from the point of view of Arc-F.
However if you mean "list" as in sequence of cons cells:
(def works-on-cons-cells-and-bools (x)
(err "this works only on cons cells and bools!"))
(defm works-on-cons-cells-and-bools ((t x cons))
(work-on-cons-cells x))
(defm works-on-cons-cells-and-bools ((t x bool))
(work-on-bool x))
Note that you can even define a unifying "type class" function which ensures that the given data is a cons cell or a bool, or is convertible to one (i.e. an analog to 'scanner). For example, you might want a "hooper" type class:
(def hooper (x)
(err "Not convertible to a bool or cons cell" x))
(defm hooper ((t x cons))
x)
(defm hooper ((t x bool))
x)
Then you can convert works-on-cons-cells-and-bools with the type class:
Then, someone can make a type which supports the "hooper" type class by either overloading hooper (and returning a true hooper), or overloading hooper and works-on-cons-cells-and-bools:
choice one:
(defm hooper ((t x my-type))
(convert-my-type-to-cons x))
choice two:
(defm hooper ((t x my-type))
x)
(defm works-on-cons-cells-and-bools ((t x my-type))
(work-on-my-type x))
in reply to the summary: nice.. some day I'll have to look into the bellow of the beast. Arc3F no longer has lists build up from cons?, or lists are build from cons which are a special kind of lists.
Well, I prefer to think of cons-as-lists as one implementation of lists. It's possible to define alternative implementations of lists; all that is necessary is to define the overloads for 'car, 'cdr, 'scanner, and 'unscan. With generic functions in Arc-F, that is enough to iterate, cut, search, filter, join, map, and more on any list, regardless of whether it's made of 'cons cells or 'lazy-scanner objects.
