Practically empty.
Creating the runtime system, bottom-up. BIG COMMIT

.gitignore

    Expanded to ignore Vim's *.swp and *.swo files. For the unaware --
    they store autosaved versions of files.

pic/runtime/exit.go

    A small module providing exit handling, and replacements for
    os.Exit, log.Fatal, log.Fatalf and log.Fatalln that respect it.

    It's used at least by the symbol manager.

pic/runtime/reader.go

    Module for parsing s-expressions. Unfortunately -- the most
    important functions aren't usable at all yet.

    RawRead(string) (interface{}, error)

        Returns the default empty values of the output variables.

    ReadSExpr([]string) (*Cons, int, error)

        Does something. Only the CPU knows what.

pic/runtime/symbol_manager.go

    Symbol managment system.

    The big thing about LISP symbols is -- they are basically strings
    with comparison of O(1) complexity. This is achieved by assigning
    each symbol a number and comparing the numbers, and not the string
    form.

    For this to work the relationship between a symbol's string and
    number must be such that:

    * two symbols with the same string cannot have different numbers,

    * two symbols with the same number cannot have different strings.

    Thus I introduce a goroutine, launched at import, to manage
    symbols. Symbols aren't intended to be created by hand -- the
    package contains exported functions (which communicate and
    sychronize with the goroutine by a couple of global channels) to
    create them.

    This has some implications:

    * Symbol creation and conversion to strings are thread-safe. This
    means symbols won't introduce issues with leveraging Go's goroutines
    to provide better support for concurrency in the language.

    * If many interpreters will be run by a single process -- they will
    share the symbol tables. This saves some memory, though it's rather
    a side-effect.

    * Numbers are assigned to newly created symbols in an ascending
    order. Whether this has any actuall use (except maybe for some toy
    programs) is yet to be seen.

    And though these are all nice properties -- the symbol manager
    was designed this way mainly for the sake of conceptual simplicity.

pic/runtiem/types.go

    The types to represent Pic value's in Go. It contains 8 basic types:

    * Symbols -- strings with restricted content and O(1) equality
    comparison.

    * Integers -- 8 bytes long and signed.

    * Byte -- integers in the range of [0, 255]. Intended for use in
    bytestrings.

    * Blob -- Go slices of bytes. Intended for storage of arbitrary
    binary data in the spirit of Lua's userdata.

    * Cons -- a pair of values, basic container type.

    * Env -- a scope. Contains a map from symbols to Go's empty
    interfaces, and a pointer to another scope -- a `parent` one.

    * Fn -- a function. Contains a closure (the scope in which it was
    defined) and multiple body forms.

        * BodyForm -- doesn't corespond to any value in term's of Pic.
        Used to store an argument list and a body for a function.
        Functions will be able to have multiple body forms to better
        leverage the planned pattern-matching facility. Theese will
        probably play some role in macros, but that's distant future.

    * Annotated -- an annotated value. Consists of the value, a symbol
    representing the conceptual type, and a pointer to a function. This
    one's in the spirit of Paul Graham's Arc. In Arc you can annotate
    value's with symbols, and they end up being considered values of a
    different type by type predicates. Also Arc uses a call-like syntax
    for accessing element's of data structures -- that's what the
    function pointer is for. I believe those two concepts aren't so
    closely tied in Arc as they are in Pic.

    It is far from complete and bound to change.

    First, it doesn't have any facility to represent functions
    implemented in Go (blobs won't work for them, neither will fns).

    Second, it has only one numeric type -- a fixed size integer.
    Floating points, fractions, decimals, bignums and complex numbers
    are possible future types. Details of implementation are, of course,
    yet undecided.

    Characters are most likely to be represented as annotated blobs
    holding unicode values. String are most likely to be lists of
    characters.

    Since I mentioned lists -- they might be annotated to. That wouldn't
    mean you couldn't use (1 . (2 . (3 . nil))) as a sequence, but that
    lists would be a separate type with some extra goodies and,
    possibly, a different internal structure.

    Errors are likely candidate's for annotated conses too -- with the
    head being either nil or some value allowing to better inspect the
    error and the tail being an error message string.

    Annotations might also pay a role in the way macros work in the
    future, and how built-in forms (like if) are distinguished from
    simple Go-defined function. If Pic was ever to get fexprs/vau they
    would probably also play a role there.

    Annotations would also probably have more mundane uses -- like
    allowing object orientation to be expressed more easily in Pic.
Minor stylistic change in a comment.
Modified the s-expression parser. Other minor changes.

pic/runtime/exit.go -> pkg/pic/runtime/exit.go
pic/runtime/reader.go -> pkg/pic/runtime/reader.go
pic/runtime/symbol_manager.go -> pkg/pic/runtime/

    Moved the file's around a bit. Trying to mimic Go's own project
    structure -- with a pkg directory for library packages and cmd for
    packages that produce executables.

pkg/pic/runtime/reader.go

    The s-expression parser (ReadSExpr) seems to work now, though it's
    tests weren't extensive. The base source parser (RawRead) remains
    a stub though it's proper implementation is likely to be trivial.

    Also modified IsSymbolName, so now valid integer literals won't be
    allowed to become symbols too.

pkg/pic/runtime/symbol_manager.go

    Ensured the creation of a few basic symbols:

    * nil, which is used by the s-expr parser and thus must be present
    before any calls to it.

    * symbol, int, byte, blob, cons, fn, env -- which represent the
    built-in types. The language might grow to expect them to have a
    well-defined order or even certain values. It doesn't hurt to have
    them beforehand. If they prove unnecessary that can always be
    changed.

examples/split_tokens.go
examples/split_tokens.out

    First example included with the project. It presents the output of
    the tokenizer when beeing fed a string.

    The proper output of the example is also presented as a simple
    facility for testing (diff-ing the file ant the actual output of the
    example should show no differences). I should probably take a deeper
    look onto the Go testing package though.

examples/read_tokens.go
examples/read_tokens.out

    Second example so far. It presents the output of the s-expr parser
    fed a slice of tokens.
Added a README file.
Some code restructuring

pkg/pic/types/types.go

    "pic/types" is the new type system package. It is independent of the
    other packages, and they are supposed to import it.

pkg/pic/reader/types.go

    "pic/reader" is a separate package from building concurrent readers.
    The file contains definitions of the types for token producers,
    token stream filters and parsers, as well as tokens and abstract
    syntax trees.

pkg/pic/reader/reader.go

    Contains the function NewReader that constructs a Reader given a
    TokenProducer, a slice of TokenFilters and a Parser. All the
    components run concurrently.

pkg/pic/reader/reader_cleanup.go

    Contains an unexported helper function which ensures no unnecessary
    goroutines will be left running after . The function assumes that
    the TokenProducer, TokenFilters and Parser behave appropriately.
Minor redesign in the pic/reader package.

pkg/pic/reader/types.go
pkg/pic/reader/reader.go

    A Reader now takes an io.Reader and a string as it's arguments, and
    returns an interface{} and error. The function NewReader which
    constructs Readers makes them utilise information from the returned
    AST value to enhance the error before returning.

    A TokenProducer takes an input channel of io.Readers. It returns a
    output channel of Tokens over which it will send and an input
    channel of bools over which it expects to information whether to
    stop reading from the Reader already -- either because the Parser
    has already had enough or because an error has occured in the Parser
    or one ov the TokenFilters.

    A TokenFilter takes the same types a TokenProducer returns and
    also return the same types -- thus they are trivial to compose
    together by hand (if anyone would feel the need to do so).

    Finally a Parser takes in the same types as a TokenFilter (ie the
    same types either a TokenProducer or TokenFilter returns) and
    returns a channel of AST structures.
Merge github.com:szabba/Pic and a minor type fix

.gitignore
README.md

    Conflict fixed.

pkg/pic/reader/types.go

    A minor fix in a type signature.