mattwparas / steel

An embedded scheme interpreter in Rust
Apache License 2.0
1.1k stars 49 forks source link

Feasibility as frameworking language for Nix? #259

Open Kreyren opened 1 month ago

Kreyren commented 1 month ago

Referencing: https://github.com/NiXium-org/NiXium/issues/131

Hey, i am considering to use steel as the frameworking language for Nix to be a de-facto alternative to nixpkgs.

Could you please elaborate on the state of the steel project, it's integration with IDE and documentation management? As those are the major roadblock on the GNU Guile candidate and i am hoping that steel would be a better integration there.

Ideally i am looking for an integration comparable to the rust in vscode/ium and elisp in emacs so basically the ability to add docstrings to the used methods and have the editor be helpful during development to do linting, formatting, etc..

implementation wise the code is expected to have a bunch of functions that evaluate into packages from given arguments that ideally should be something like keyword arguments in guile (https://www.gnu.org/software/guile/manual/html_node/Why-Use-Keywords_003f.html) so that they can be interpreted in the scope of the function e.g.:

(define (define-package . args)
  (let-keywords args #f ((version  "")
                         (src     "")
                         (hash  "sha256-AAAA..."))
    ...))

(define-package (rustc #:version "1.0.0" #:src "github.com/owner/repo")
  "docstring"
  ;; Expecting to have variables `version` and `src` available in this scope, if they are unset they should have a default value
  ...) 

So that the function could return the package based on provided arguments and in a way that is not more complex than it has to be and at sane evaluation time and resources used.

Thanks for anything relevant! <3

mattwparas commented 1 month ago

Steel is under active development, as I'm pretty much consistently working on it :smile:

There is a language server specifically for steel - it is rather primitive but will propagate doc strings and go to definitions. Doc strings are provided with an @doc annotation in the comment, which is something I'm going to keep around. There will probably be other ways to provide doc strings as continue to improve the implementation, but this seems to work well enough for now.

Undoubtedly there are bugs and things that don't work (and occasionally the language server will crash), but I daily drive with it and largely don't run into major issues. Part of fixing those issues would be getting more adoption to collect more bug reports.

For example:

;; example.scm
(provide foo)

;;@doc
;; Hello world!
(define (foo #:bar [bar 10])
  (+ bar 10))
image

It also supports go to definition from there as well.

The example I provided also shows how steel supports default arguments and keyword args - keywords are provided with the #: syntax plus the variable name and the default provided after that.