On occasion this test fails.

The test cases are invariably large so I don't have any immediate insight into what's happening.

@cloudhead is implementing CLIs that need to communicate via Values, but use other datatypes. One thought that came up in discussion is that we could have two classes:

class FromValue a where
   fromValue :: Value -> Either Text a

class ToValue a where
   toValue :: a -> Value

With generic instances.

This would simplify a lot of our codebase as well. Already it's a bit painful to convert Bindings to Value, but perhaps more significantly, all our pattern matching on primop arguments could be simpler.

instance (FromValue a, FromValue b) => FromValue (a, b) where
   fromValue (List [a,b]) = (,) <$> fromValue a <*> fromValue b
   fromValue (List xs) = Left $ "expecting list with two elements, got " <> show (length xs)
   fromValue _ = Left $ "expecting list"

-- etc.

And then we can just pattern match on what we expect with fromValue.

Right now you can't see what would be the result of evaluating an expression in a particular chain (without submitting it) since eval doesn't take an Env/Bindings/Dict as a parameter.

Add an eval that does take such a param.

• CentralChain is a centralised radicle chain (what we have now, but will be replaced by a decentralised version)
• ChainApi is a server that connects to a chain and provides a nice API to interact with it, including viewing input, viewing outputs, submitting expressions, etc.

Rather than not evaluating them itself. Otherwise it's impossible to use variable keys.

Currently:

rad> ((lambda (x) (x)))
Unknown identifier: x

Function application should instead say that arguments are missing.

Clojure:

{:a 1 :b 2}

Racket:

#hash((1 . 1) (2 . 2))

Note that in Clojure commas are whitespace, so {:a 1, :b 2} is also valid.

Example:

rad> (define my-id (lambda (ref) ref))
()
rad> (my-id 3)
ref

In particular:

• place for issues
• all branches on cgit
• mailing list

We have so far a hyperstatic environment. This is probably the right default, but it should be possible to also query the environment at the call site with a get primop. #2 does most of the work - after that, I think it's really just a question of exposing the primop.

This is how Scheme works, and allows for more power over metaprogramming (e.g., lambda syntax may be redefined).

Relatedly, there's a bug currently where (list? x) gets parsed as (list ? x) because of the the listP parser, which would be fixed by this.

Currently files that start with a comment fail to parse.

E.g. -93G.

• Informative error messages.
• Informative, well formatted stack traces.
• Ability to throw and catch exceptions.

Currently (or rather, after #30), throwing and catching exceptions is possible, but somewhat limited - they can only be handled on the basis of a label (and a special any label). It would be good to have a better story for this.

• Numbers
• +
• *
• -
• /
• <
• >
• eq?
• car
• cdr
• cons
• member?
• reduce
• lookup

Based on Bindings.

• All Values should have a JSON representation.
• Prelude should have a to-json function.

Refs now work correctly, but they're very tricky to work with, since evaluation and values are all tagged with a state thread type. This is fine for traditional use cases, but oscoin needs to run multiple chains with common prefixes and those need different state threads (and keep old states in case in the future there's a fork). So moving to a State monad might be better.

Rename:

• car to head
• cdr to tail
• deref to read-ref
• Maybe sorted-map to dict?

Add:

• string?
• list?
• dict?
• type
• apply

We wrote some eval functions for different chains. Currently, if we (send! "chain" 'my-custom-eval), that only works if the other chain knows what my-custom-eval is (and what the variables it uses are). This makes it an annoyance to send things, since you can't really abstract over the process.

If we resolved everything down to primops (plus maybe prelude), this wouldn't be a problem.

We still have a fixed eval/fold, and so the language is not reflective. This should be fixed.

(#2 changes the way state is handled, allowing definition of a get primop. This in turn allows a reflective meta-interpreter, though we still have to change the Haskell definition of eval)

With #2 the repl works by just picking the InputT monad opaquely. Instead, config.rad should be picking whether to start in repl mode or not.

Possibly the best way to do this is have subscribe-to! take an extra initialization argument.

With #69, documentation is in a ref, so documenting local functions would be a global operation. Ideally this wouldn't happen.

It'd be useful to have a basic import mechanism.

Syntax

(import <module> [<bindings>])

(module <module> <bindings> <body>)

Semantics

The imported module is evaluated in an initially empty environment.

The intersection of the imported and exported bindings is shared between environments.

Any non-static reference in the imported module is always resolved to the current version of the environment in which it was originally evaluated. (If later we want to allow variation, semantically we can conceive of each variable as implicitly statically namespaced, and can allow syntax for variation.) Static references are resolve immediately in the module environment as one would expect.

Module-like mechanisms could be used for data abstraction and information hiding, so it's worth thinking about

Add a means of signing and verifying data.

For this to be useful in the REPL, it may be that a way of dealing with the shell or with files will be needed.

Turns out that's the code path with "curious about why this would happen"!

See #75 (comment).

And likely in map:

rad> (foldr (lambda (x acc) (+ (head x) acc)) 0 (list (list 1)))
Type error: Trying to apply a non-function

(both evalArgs and $$ evaluate.)

I believe ref doesn't always work as intended. While resolving the identifier is delayed, the surrounding computation isn't. So applying a function to a ref will generally result in a type error.

The fix, I think, is simple - for any application, evaluate all arguments. If any of them is a ref, don't try evaluating the application itself. deref-all already evaluates it's argument after substitutions, so this should do the right thing.

E.g. if:@Y parses as Primop "if" rather than Atom "if:@Y" (says quickcheck). Looks like tokenization isn't being done properly.

• There should be a doc function which, given an identifier, returns the documentation for that identifier (if it exists).
• There should be a way of documenting new functions that integrates with that doc function.
• Existing primops should be documented.

I initially imagined there was good reason to have doc work only in the impure environment (since we want to maintain referential transparency). But I now realize doc can work on quoted identifiers and maintain referential transparency. (Note that quote is not a function, and in typed settings at least for subtle and profound reasons that I only half-remember, so there's no function from an unquoted value to it's documentation.)

Currently this is only possible with the y combinator.

E.g.:

In prelude:

(define inc (lambda (x) (+ x 1)))

(define modify-ref
  (lambda (r fn)
    (define temp (read-ref r))
    (write-ref r (fn temp))
    ))

Repl:

(define t (ref 0))
()
rad> (modify-ref t inc)
()
rad> (read-ref t)
0.0

The problem (I think) is that mutations to refs modify the env, and the env is restored to the original after the lambda has finished executing.

Currently only parse errors show the context (line, etc.) of the error. Other errors should too.

It would be nice to be able to read in and eval code from various sources, e.g. version-control.

Currently env state is not managed by the effects system.

A few things to consider:

• On the one hand it would be nice to unify the env modifications with the rest of the effects system
• On the other this means we need continuations to handle local gets and sets.
• Persistence will probably eventually just be a subscriber

A few things could be improved about should-be:

• Should store test results (or just test cases) in a ref, so we (a) don't have to see them printed to the console, and (b) don't have to check strings for '"succeeded"'/'"failed"'.
• Should take quoted arguments so we can print out the exact test case in case of failure and so we can selectively run them.
• Should run with a mocked send/receive
• Should take an identifier rather than string as first argument. This way we can figure out what tests are associated with a particular identifier, and can e.g. use them in documentation as examples.

((lambda () (define eval (lambda (e) #t)) 3)) should in my mind evaluate to #t, not 3. @jameshaydon do you agree?

Right now ' creates a list (and differs in behavior to quote). Either rename this to list, or add list and make it an alias for quote.

A slight annoyance here is that the Pretty instance is in another module right now, which will likely have to move.

• including instance for Arbitrary

Browser REPL for the demo/talk.

Currently a lambda has to be explicit about the arguments:

(lambda (x y) (+ x y))

Unparenthesized lambda arguments should also be allowed, in which case the lambda receives a list as argument (where the list contains all arguments actually given). This allows varargs, and kwargs.

Currently we only have arbitrary-precision decimals.

Currently autocomplete gathers identifiers only once, at the beginning of the session. This means it has nothing but primops to go on.

Like Clojure, Erlang, Ruby, etc.