Any way to check arity of a procedure?

[aartaka]

So I tried multiple directions:

• expand is nice and is an important stage of compilation. But I’m not sure what happens after that and where to insert argument count, if anywhere.
• Bytecode inspection is a good direction (I’m ready to parse that, if necessary!)
  • However, it’s not clear how to get bytecode for a procedure.
  • Built-in procedures also have argument specs, like '1', '2', 'm', 'b' etc. so these might be fetched somehow?

Any pointers?

[dermagen]

Sorry, currently there is no way to determine procedure arity from the procedure itself. Theoretically, one could (unsafely) peek at the first instruction that normally validates argument count, but there are cases when a different instruction is there because of either a need to assemble a rest list, or the procedure is made via case-lambda that inserts its own dispatcher (multiple instructions).

Also, keep in mind that byte code is just an intermediate representation; actual procedures use threaded code representation.

[aartaka]

Theoretically, one could (unsafely) peek at the first instruction that normally validates argument count, but there are cases when a different instruction is there because of either a need to assemble a rest list, or the procedure is made via case-lambda that inserts its own dispatcher (multiple instructions).

Is there then a way to get a bytecode string from closure? That’d be extremely nice for metadata inference!

[dermagen]

Not at the moment; the plan is to recreate the bytecode string from the threaded code using the instruction table(s), where both are stored. This what disassembler would do as the first step (perhaps recreating a "core" representation later). There is a problem though that the set of instructions may depend on the Skint configuration, so only code compiled with the same configuration can be disassembled correctly.

I could store the string together with the signature, but that would just waste a lot of memory. Decisions, decisions...

[aartaka]

@dermagen yeah, I think storing the string might be the best bet, as disassembly is an inherently lossy and heuristic process. Lisps have a long tradition of object introspection, so having some of it might be consistent and useful!

[dermagen]

It is not a decision about usefulness of the feature (it is obviously useful), but about a footprint of the system. I like the fact that in its core it is currently under 15K loc, and I prefer to keep it this way -- all things like Unicode and full numerical tower are optional (and quite big, especially the tower). I'd probably include code metainformation only if 'debug' feature is defined (here's another use for it!).

By the way, recovering byte code from the threaded code is lossless by design, so maybe all introspection tricks may be defined with minimal built-in support, in a separate external (skint introspection) library.

[aartaka]

@dermagen I realize the focus of the project! However, is not adding a string to the closure structure just a couple of lines, like with integrable-code?

[dermagen]

Code change is small indeed, but why do it if you can re-create it on demand from the threaded code? It will only eat RAM, serving no real purpose.

[aartaka]

@dermagen this if fair! Still, you said it yourself: disassembling the threaded code is platform-specific, while bytecode string is platform agnostic (afaiu.) It’s also much easier to process, at least in Scheme. And how bad is its memory footprint, actually? I think that threaded code consisting of procedures carries quite a lot of memory, given the closure of environment etc. But one has to prove that somehow.

[dermagen]

I will work on the introspection later this year; immediate plans are to finalize the pretty-printing SRFI and add full numerical tower as an option. These things will likely take me well into the Fall.

[aartaka]

@dermagen sure, your call!

[aartaka]

@dermagen any help you might need with Skint so that you have less on your plate?

[dermagen]

Thanks. Here's an idea: a (skint trace) external library implementing Chez-like trace macros trace-define, trace-let, ...,together with trace and untrace procedures that wrap/unwrap existing globally defined (non-integrable) procedures. I had some in my old SXM implementation, but they are commonplace, e.g.

;; taken from https://github.com/mnieper/scheme-macros

;; A form of a named let that prints information about each recursive
;; call.
(define-syntax trace-let
(syntax-rules ()
[(trace-let name ([var expr] ...) body1 ... body2)
(let f ([depth 0] [var expr] ...)
(define name
(lambda (var ...)
(f (+ depth 1) var ...)))
(indent depth)
(display "(")
(display 'name)
(begin
(display " ")
(display var))
...
(display ")")
(newline)
(call-with-values
(lambda ()
body1 ... body2)
(lambda val*
(indent depth)
(fold-left
(lambda (sep val)
(display sep)
(display val)
" ")
"" val*)
(newline)
(apply values val*))))]))

;; Helper procedure referenced by the macro output of the macro above.
(define indent
(let ([pattern "| "])
(lambda (depth)
(do ([i 0 (+ i 1)])
((> i depth))
(display (string-ref pattern (mod i 2)))))))