luthersystems / elps Goto Github PK

The elps executable should contain a fmt command which basically has a subset of the go fmt options.

The parser should be adapted so that it can keep comments and produce an AST that allows it to distinguish whether block comments are attached to an expression or not. That is the following code pieces should not modified and are not equivalent

;; hello

(world)

;; hello
(world)

When working with a list of unquoted symbols (e.g. '(a b c)) the select and reject functions evaluate the list elements which causes an "unbound symbol" error. Such lists are not common but can come up when writing macros.

The map function works properly with such lists.

elps> (map 'list to-string '(1 'a b))
'("1" "a" "b")

This list will cause errors when passed to select and reject, even when given no-op predicates.

elps> (select 'list (lambda (x) true) '(1 'a b))
stdin:1: lisp:select: unbound symbol: b
Stack Trace [1 frames -- entrypoint last]:
  height 0: stdin:1: lisp:select
elps> (reject 'list (lambda (x) true) '(1 'a b))
stdin:1: lisp:reject: unbound symbol: b
Stack Trace [1 frames -- entrypoint last]:
  height 0: stdin:1: lisp:reject

Reproduction steps:

• Evaluate (zip 'list '() '(1))
  Length of the second argument is not important. (Length of the 2nd arg being zero but first one not being zero is handled)

Reproduction steps: evaluation of (make-sequence 0 1 0) won't terminate

The encoding/json package escapes html-unsafe characters & < and > by default and the recent changes to json encoding in v1.14.0 no longer escape these characters. Regardless of security ramifications this is a bug because json encoding is supposed to be deterministic and checksum-able.

Stack traces after macro expansion (perhaps traces which occur while evaluating expanded code) can look very misleading. We need some concreate, small test cases.

The elps command should implement a linter that can be used directly or used as a reference for implementing linters specific to the application domain elps is being embedded into.

There is one proposed use case for a linter, with docstrings in #46. Other examples would be guarding against direct use of set or using set! when there is no matching variable in scope (though the latter may be better implemented in the long term as a 'compile time' check -- which doesn't exist currently as an elps concept). Another valid concern is attempts to use the in-package operator when not in the package's top-level.

Certainly there are other gotchas which could be detected without too much effort. But the ones discussed here probably merit including a default linter implementation with the project.

We lose stack traces using the current pattern of rethrowing errors in handler-bind, e.g.:

                      (handler-bind ([condition ; catch any error
                                     (lambda (c &rest args)
                                       (log-metrics)
                                       (apply error c args))]) ; re-throw the error

We would like the ability to "re-throw" the error within this handler-bind.

staticcheck ./... results in a number of errors, which we should either i) fix, ii) add ignore annotations.

Common-lisp style (aka python style) docstrings are technically a breaking change but also seem drastically easier to implement. Perhaps if docstrings are used then a hypothetical "linter" could catch cases where a "constant function" is ambiguous about whether its intent is to return a constant string or a nil value.

Of course, go-style doc comments have significant benefits. Beyond being backwards compatible it becomes possible to document arbitrary symbols within a package.

Implementations have to consider how function documentation works after symbols have been "imported" to the user's package (i.e. via use-package). If a user in a repl imports regexp-match? from the regexp package and then tries to evaluate a hypothetical (help regexp-match) expression then how does that resolve to the original documentation for that function?

Even the implementation of such a repl-based doc lookup is not a certainty.

There are two aspects to file io in elps. It should be possible to read IO from files in the runtime SourceLibrary (writing to the source library does not need to be permitted). It should also be possible to read and write files in the host operating system. Perhaps reading from the SourceLibrary could be allowed by default and file io would be an optional library or something?

If a macro wants to produce a quoted version of its argument that does not seem possible.

elps> (defmacro m (x) (quasiquote (list '(unquote x))))
()
elps> (macroexpand '(m mysymbol))
'(list mysymbol)

The above macro expanded to (list mysymbol) instead of (list 'mysymbol) as it should have. Of course trying to use the macro as things are currently produces an error because mysymbol is not bound to a value.

elps> (m mysymbol)
stdin:1: unbound symbol: mysymbol
Stack Trace [0 frames -- entrypoint last]:

The value produced should have been '('mysymbol).

Other attempts to quote the value like the following don't work either.

elps> (let* ([lis '(a b c)][x (first lis)]) (quasiquote (unquote x)))
a

And this example illustrates another issue with quasiquote because it doesn't introduce an additional level of quoting in this case, which is inconsistent with how quasiquote behaves without using unquote

elps> (quasiquote a)
'a

Finally, quasiquote doesn't handle multiple levels of quotes. It does not traverse them and produces values which may have lingering unquote directives.

elps> (quasiquote (list ''(unquote 'b)))
'(list ''(unquote 'b))

The value produced should have been '(list '''b).

Fixing this will break some tests because the tests themselves aren't really sound or realistic. I don't think there are any real macros that would break because of this fix, in some sense a lot of the ones that would break probably already have bugs. Instead of risking breakage we could introduce some quasiquote2 alternative to the old quasiquote behavior but that is a bit lame.