Support for Embeddable Common Lisp (ecl) runner

[Kreyren]

Op has been updated with the finding from the conversation

Features Description

Support for Embeddable Common Lisp (ecl) script runner.

Describe the solution you'd like

Expecting being able to use:

[env]
MESSAGE = "something"

[tasks.kreyren]
script_runner = "@ecl"
script = [
'''
(write-line "${MESSAGE}")
'''
]

To execute embeddable common lisp code through cargo-make with the intention to be portable beyond POSIX to support as many turing complete systems as possible including legacy systems created in 1971 where POSIX shell, Bourne Again Shell, Python, etc.. is not an option and writing in Bourne Shell (not to be confused with Bourne Again Shell) is painful.

Additional info

1. ecl requires argumnet --shell to execute the file without openning an interactive session or outputing help message.
2. Command ecl (write-line "Hello, world!") opens a help message

Currently i have to provide shebang to be able to run the ecl session which is not compatible with non-standard unix systems and windows.

Solution

Implement script_runner_args

Status: being considered

As proposed in #461 (comment) this would add script_runner_args for the tasks allowing to specify arguments to the script_runner

Implement script_runner = "@ecl"

Status: Dismissed as impractical

As proposed in OP this prefers implementation alike:

[env]
MESSAGE = "something"

[tasks.kreyren]
script_runner = "@ecl"
script = [
'''
(write-line "${MESSAGE}")
'''
]

for readability reasons.

Was concluded to be not practical as lisp is a framework to create a programming language and using script_runner = "@lisp" would require a translational layer to ensure that used lisp is compatible

for example that would require us to make Embedded Common Lisp compatible with non-embedded Common Lisp which is plausible, but also require implementing things like Emacs Lisp that is not compatible with common lisp as it's redefining most of it's functions for the usage of text editor (or operating system).

[sagiegurari]

so basically what i need to do to support any such cli, like ecl, is to enable you to provide cli arguments before the script file.
so in this case, you will provide --shell
the end result would be

script_runner = "ecl"
script_runner_args = ["--shell"] # this is new thing i'm suggesting
script = [
'''
(write-line "${MESSAGE}")
'''
]

would that do?

also by the way, cargo-make has embedded duckscript runtime which provides a simple shell like language with a pretty big api.
but your use case is to use something that is already installed on the OS for your scripts, which is another valid usecase.

[Kreyren]

script_runner_args = ["--shell"] @sagiegurari

I would think that would be sufficient assuming that

MESSAGE = "something"

[tasks.kreyren]
script = [
'''
#!/usr/bin/ecl --shell
(write-line "${MESSAGE}")
'''
]

Invoked from GNU bash, version 5.0.18(1)-release (x86_64-pc-linux-gnu) on 5.8.0-10.1-liquorix-amd64 works.

but i would prefer script_runner = "@ecl", because i am concerned about readability to ideally use only:

MESSAGE = "something"

[tasks.kreyren]
script_runner = "@lisp"
script = [
'''
#!/usr/bin/ecl --shell
(write-line "${MESSAGE}")
'''
]

instead of

MESSAGE = "something"

[tasks.kreyren]
script_runner = "ecl"
script_extension = "cl"
script_runner_args = ["--shell"]
script = [
'''
#!/usr/bin/ecl --shell
(write-line "${MESSAGE}")
'''
]

aldo script_runner_args would be also welcomed in case the runtime requires -eval to parse logic to the ecl shell and other usecases alike -norc to not use /~eclrc

FILES
       ~/.ecl, ~/.eclrc
              Default initialization files loaded at startup unless the option
              --norc is provided.  (if they exist).

---

FWIW though i share: On C-based Makefile it's not creating a temporary files as cargo-make and so me with irc.freenode.net/##workingset came out with this PoC solution:

#!/bin/sh
shift
makeLisp="$(pwd)/wrappers/make.lisp"
command="$*"
escaped="$(echo "$command"|sed -e 's/\\/\\\\/g' -e 's/"/\\"/g')"
#exec ccl -Q -n -b -l "$makeLisp" -e    "(eval-make-command \"${escaped}\")" -e    '(ccl:quit)'
exec ecl -norc -eval "(load \"$makeLisp\" :verbose nil)" -eval "(eval-make-command \"${escaped}\")" -eval '(ext:quit)'
#exec ecl -norc -eval '(setf *load-verbose* nil)'� -load "$makeLisp" -eval "(eval-make-command \"${escaped}\")" -eval '(ext:quit)'

(defun exit (status)
  #+ecl (ext:quit status)
  #+ccl (ccl:quit status))

(defun eval-make-command (command)
  (let ((form (handler-case (read-from-string command)
                (error (err)
                  (format *error-output* "ERROR while reading ~S: ~A~%" command err)
                  (exit 1)))))
    (handler-case (eval form)
      (error (err)
        (format *error-output* "ERROR while evaluating ~S: ~A~%" form err)
        (exit 2)))))

[Kreyren]

also FWIW it seems that it's not expanding variables when it's invoked in a script which could also be a pebcak.

[sagiegurari]

too many messages :D

1. adding something like @ecl is fine by. I think i'll do both options. but probably name it not ecl as that exists.
2. cargo make is creating temp files for those. that is true. but that allows you to write a full script file and not an unreadable one liner. one liners are cool sometimes, but scripts can be super complex. checkout the kcov script for example.
3. scripts do not support env expansion. i'm not going to do that since that would lead to bugs. for example you wrote a bash where you define a var and than use it. if i expanded before invocation, it has the wrong value.

[Kreyren]

too many messages :D @sagiegurari

Sorry didn't know how to make it shorter, but still understandable x.x

adding something like @ECL is fine by. I think i'll do both options. but probably name it not ecl as that exists. @sagiegurari

might be worth mentioning that lisp is basically framework to make a custom programming language so it has lots of implementations alike ccl (regular common lisp), ecl (Embedded Common Lisp), Vax common Lisp, Emacs Lisp, etc.. which are in core (generally, but not always) same, but are not designed to be compatible with each other (even though some are mostly compatible).

So i guess the script_runner_args would be preferrable option over the script_runner = "@ecl" as that would probably need some complicated logic to figure out what is the system using and implement a translation layer i.e. what is currently being done for cross-platform shell which is (i think) impossible to implement assuming extensibility of lisp?

---

Point 3 noted.

[Kreyren]

Just clarifying based on peer-review in irc.freenode.net/#lisp

might be worth mentioning that lisp is basically framework to make a custom programming language so it has lots of implementations alike ccl (regular common lisp), ecl (Embedded Common Lisp), Vax common Lisp, Emacs Lisp, etc.. @Kreyren

This is looking at the issue from a lisp point of view alike comparing common-lisp to emacs lisp which are lisp, but basically different languages as emacs lisp is redefining common lisp functions to be used for the editor.

Whereas common-lisp-based languages (ecl, ccl, etc..) are generally compatible with each other.

[sagiegurari]

@Kreyren I just pushed the support for this in the dev branch 0.32.6
Basically you have now a new task level attribute called script_runner_args = [] that you can use.

I took your example, just drop the shebang.

[env]
MESSAGE = "something"

[tasks.ecl]
script_runner = "ecl"
script_extension = "cl"
script_runner_args = ["--shell"]
script = [
'''
(write-line "${MESSAGE}")
'''
]

I didn't test with ecl as i don't have that installed and didn't bother to install :)
so if you can test and provide some feedback, it would be great.

[Kreyren]

Works on my end, thanks for working on this!

[sagiegurari]

New version released to crates.io so i think we can close this one.