aldld / hasp Goto Github PK
View Code? Open in Web Editor NEWAn interpreter for a variant of Lisp written in Haskell.
License: BSD 3-Clause "New" or "Revised" License
An interpreter for a variant of Lisp written in Haskell.
License: BSD 3-Clause "New" or "Revised" License
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:
evalExpr
to Either Error (Maybe HData, Env)
. This will require careful planning to avoid adding yet another layer of complexity wherever expressions are evaluated.define
in the UI.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:
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:
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:
HData
variables) either into the source code, or somehow inject them into the default global Env
at compile time.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.
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.