aldld / hasp Goto Github PK

The following code should result in an error:

hasp $ stack exec hasp
Welome to hasp!
λ> (define f (lambda (x) (+ x y)))
()
λ> (define g (lambda (y) (f y)))
()
λ> (g 2)
4
λ>

The issue is that the variable y in g shadows the (unbound) variable y in f, which should not happen.

This is fairly simple. Right now all hasp code is executed via the interactive REPL. It is also important to be able to read input from a file, display any output, and either terminate the program, or run the program then start a REPL session.

Currently, every hasp expression evaluated, if it does not fail, must return some value of type HData. However this does not really make much sense for define, so its return value (if successful) is set to simply be the empty list (), which gets displayed by the REPL. Ideally there should be no output when define is successful. This can be addressed in one of (at least) three ways:

• Allow hasp expressions to return nothing, e.g. by changing the return value of evalExpr to Either Error (Maybe HData, Env). This will require careful planning to avoid adding yet another layer of complexity wherever expressions are evaluated.
• Suppressing the output of successful calls to define in the UI.
• Adding a new data type to HData to essentially represent "nothing". Need to be careful to either ensure that it can only be used when necessary, or take care to make it an actual feature of the language.

Macros are an important feature for any lisp dialect, and will be useful for defining standard library functions. Some decisions will need to be made, including:

• Syntax for macro definition
• Storing macros internally, i.e. creating AST transformers
• Macro expansion
• Support for hygienic macros

The tokenizer and parser modules both process source code via a single pass from left to right, appending partial results to an accumulator list. However, in Haskell, appending to a list is slow compared to inserting at the start of a list.

Look into using Data.Sequence instead of a list for accumulators where results are appended to the end of the accumulator.

Currently a limited set of standard library functions are provided by the hasp interpreter. These are functions that can only feasibly be implemented in Haskell. This depends on:

• Support for macros (#3)
• Running hasp code from a file (#6)
• Support for modules (#7)

This would most likely be in the form of a library written in hasp that will be called whenever the hasp interpreter is started up. There are a few ways to achieve this, from (IMO) best to worst:

• Evaluate the function definitions, and insert the resulting functions (as Haskell HData variables) either into the source code, or somehow inject them into the default global Env at compile time.
• Compile the hasp source code into the interpreter binary as a string, and tokenize, parse and execute it when the interpreter is loaded.
• When the interpreter is started, load the source code for the standard library from an external file and then execute it.

Some library functions to implement:

• map
• filter
• apply
• foldl, foldr
• curry
• let, let*, letrec
• not

So far most of the code written seems to work, however it has not been thoroughly tested, and is likely riddled with bugs. It would be helpful to create a test suite in order to provide some verification that it does work correctly, as well as to avoid introducing new bugs.

Calling functions that may fail follows a general pattern of capturing the return value of such a function in a case statement; if the computation is successful then make the result available to the rest of the computation, otherwise propagate the error. It should be possible to do this in a much more elegant way. Moreover, existing error messages often provide limited information and were thrown together in an ad hoc manner. They should be cleaned up, changed to provide more information, and presented in a coherent and consistent way.

• Refactor existing error handling code to use a more idiomatic Haskell style
• Improve existing error messages
• Create more helpful error messages

The last point can be addressed in a number of ways, such as adding line number info and code snippets, as well as a stack trace.

When creating an anonymous function via lambda, currently the entire environment in which lambda was called is stored as a closure. This is wasteful, since we only really need to store those name binding that are mentioned within the body of the lambda expression (except for those that are shadowed by function arguments).

After support for file input is added (#6), there should be a system in place to define functions in external files and import them. Some things to consider:

• Optional namespaces, to prevent name collisions
• Detecting circular dependencies