>>23
Just provide what's used to implement the language. I'm not sure if you can call linked lists as built-in in Lisp: cons cells are provided because they're how
EVAL and macros work, but you could reimplement cons cells or build them in other ways and the implementation will still work. Defining the line between library and language is a hard thing as in some languages it's possible to implement libraries which fit right in like they were built-ins, and it's possible to reimplement built-ins from scratch yourself. The CL standard provides a type/class system, arrays(of different kinds, from which you could technically build anything, such as structures, cons cells, classes, ...), cons cells(from which lists, alists, sets, graphs, binary trees, ... can be built), structures (whose internal representation may vary a lot - it can be built as anything, but most often it's represented internally as a tagged piece of memory and a compiler can inline access to the members), classes/objects(CLOS/MOP - from which you can build anything, again), symbols(which can be built from anything, again, they could be thought of as a structure with a few fields), packages(a named collection of symbols for providing namespaces), numbers(from efficient fixnums to bignums to rationals to complex numbers, floats, ...), characters, strings(simple arrays of characters), sequences (a type encompassing arrays, lists, and some implementations may let you add your own types - functions which work on sequences work on either concrete type of data), hash tables(which tend to be implemented as structures), functions(code objects, may be closures, lambdas, compiled or interpreted...), filenames/files, streams, conditions and so on ). What I'm getting at is that the language may offer many features, but given a few basic things like a tagged type system, with at least integers ,arrays and maybe structures(however they could be built using arrays) you can build all kinds of types and they could look and behave like they were there to begin with. If types and functions/interfaces are present in the language definition, it's probably right to call them part of the language, even though they're actually library. In the case of Lisp, you only need about 10% of the language to implement the remaining 90%, and it would appear as these features were always there.