Lambda list in function description #442

mmontone · 2022-08-28T14:58:26Z

Can we have the lambda-list of functions as part of their descriptions.?
It is useful to have them for tools also.

Description of function after this:

JSCL/ILT> (describe #'format)
#<FUNCTION !FORMAT>
Class: #<builtin-in-class FUNCTION>
Name:!FORMAT
Lambda list:(DESTINATION FMT &REST ARGS)

vlad-km · 2022-09-01T09:07:06Z

Is it possible to add correct handling of anonymous functions?

CL-USER> (setq kik (lambda (x &optional y) nil))
#<FUNCTION>
CL-USER> (describe 'kik)
KIK
Class: #<builtin-in-class SYMBOL>
:INTERNAL in package CL-USER
Print name: "KIK"
KIK names a special variable
Value: #<FUNCTION>
#<FUNCTION>
Class: #<builtin-in-class FUNCTION>
Name:anonimous
Lambda list:NIL
CL-USER> (defun kek (x &optional y) (cons x y))
KEK
CL-USER> (describe 'kek)
KEK
Class: #<builtin-in-class SYMBOL>
:INTERNAL in package CL-USER
Print name: "KEK"
KEK names a function
#<FUNCTION KEK>
Class: #<builtin-in-class FUNCTION>
Name:KEK
Lambda list:(X &OPTIONAL Y)

davazp · 2022-09-01T09:30:28Z

Can we expose this under a function-lambda-list function (inside the jscl package)?

I wonder also if it'd be a good idea to make this pluggable somehow. We could define a (defvar *collect-lambda-lists* ...) variable or something.

That way there is no need to pay the price for the extra bundle if desired. That would allow to change it dynamically too.

Thoughts?

mmontone · 2022-09-01T12:56:42Z

Can we expose this under a function-lambda-list function (inside the jscl package)?

I don't understand what you want here ...

I wonder also if it'd be a good idea to make this pluggable somehow. We could define a (defvar *collect-lambda-lists* ...) variable or something.

I've no problem with that. I would set it to true by default. I've no problem with not making it optional either; CL implementations usually come with this, with no optionality.

That way there is no need to pay the price for the extra bundle if desired. That would allow to change it dynamically too.

Thoughts?

mmontone · 2022-09-01T12:57:23Z

Is it possible to add correct handling of anonymous functions?

I don't know yet.. but I can have a look.

mmontone · 2022-09-01T13:29:58Z

Can we expose this under a function-lambda-list function (inside the jscl package)?

I don't understand what you want here ...

Ah. You just want a function that returns the lambda-list. Of course!.

mmontone · 2022-09-01T15:38:21Z

Would also be nice to attach lambdalists to generic functions and methods. Not done atm.

mmontone · 2022-09-01T15:46:53Z

I'm including a custom writer for functions that show lambda-lists.

Looks like this:

CL-USER> #'prin1-to-string
#<FUNCTION PRIN1-TO-STRING (FORM)>
CL-USER> #'prin1-to-string
#<FUNCTION PRIN1-TO-STRING (FORM)>
CL-USER> #'prin1
#<FUNCTION PRIN1 (FORM &OPTIONAL STREAM)>

mmontone · 2022-09-01T16:23:33Z

Would also be nice to attach lambdalists to generic functions and methods. Not done atm.

I was wrong. This is already being done:

(describe (find-generic-function 'print-object))
A CLOS object
             Printed representation: #<standard-generic-function PRINT-OBJECT>
             Class: #<standard-class STANDARD-GENERIC-FUNCTION>
             Structure 
             JSCL::NAME <- [PRINT-OBJECT]
             JSCL::LAMBDA-LIST <- [(JSCL::INSTANCE &OPTIONAL STREAM)]
             JSCL::METHODS <- [(#<standard-method PRINT-OBJECT((CONDITION JSCL::BAD-DSD-SLOT-DESC) &OPTIONAL (STREAM *STANDARD-OUTPUT*))> #<standard-method PRINT-OBJECT((CONDITION TYPE-ERROR) &OPTIONAL (STREAM *STANDARD-OUTPUT*))> #<standard-method PRINT-OBJECT((METHOD STANDARD-METHOD) &OPTIONAL (STREAM *STANDARD-OUTPUT*))> #<standard-method PRINT-OBJECT((JSCL::GF STANDARD-GENERIC-FUNCTION) &OPTIONAL (STREAM *STANDARD-OUTPUT*))> #<standard-method PRINT-OBJECT((CLASS STANDARD-CLASS) &OPTIONAL (STREAM *STANDARD-OUTPUT*))> #<standard-method PRINT-OBJECT((JSCL::INSTANCE STANDARD-OBJECT) &OPTIONAL (STREAM *STANDARD-OUTPUT*))>)]
             JSCL::METHOD-CLASS <- [#<standard-class STANDARD-METHOD>]
             JSCL::DISCRIMINATING-FUNCTION <- [#<FUNCTION  ()>]
             JSCL::CLASSES-TO-EMF-TABLE <- [#<hash-table :test equal :count 0>]

mmontone · 2022-09-01T17:09:16Z

Is it possible to add correct handling of anonymous functions?

I've implemented it:

CL-USER> (lambda (x y) x)
#<FUNCTION  (X Y)>
CL-USER> (lambda (x y) x)
#<FUNCTION  (X Y)>
CL-USER> (lambda (x y &optional z) z) 
#<FUNCTION  (X Y &OPTIONAL Z)>
CL-USER> (describe *)
#<FUNCTION  (X Y &OPTIONAL Z)>
Class: #<builtin-in-class FUNCTION>
Name:anonimous
Lambda list:(X Y &OPTIONAL Z)
CL-USER> (setq kik (lambda (x &optional y) nil))
#<FUNCTION  (X &OPTIONAL Y)>
CL-USER> (describe 'kik)
KIK
Class: #<builtin-in-class SYMBOL>
:INTERNAL in package CL-USER
Print name: "KIK"
KIK names a special variable
Value: #<FUNCTION  (X &OPTIONAL Y)>
#<FUNCTION  (X &OPTIONAL Y)>
Class: #<builtin-in-class FUNCTION>
Name:anonimous
Lambda list:(X &OPTIONAL Y)

vlad-km

May be

(defun function-object-printer (form stream)
  (let ((res)
	      (fname (oget form "fname"))
        (ll-form (function-lambda-list form)))
    (setq res (concat (if fname "#<FUNCTION " "#<LAMBDA ")
		                        (if fname 
                                            fname 
                                            "")
		                        (if ll-form
			                    (princ-to-string ll-form)
                                            "()")
		             ">"))
    (simple-format stream res)))

Mmm?

vlad-km

(defun function-lambda-list (function)
  "Return the lambda-list of FUNCTION."
      (read-from-string (oget (fdefinition function) "lambdalist") nil))

Mmm?

davazp · 2022-09-02T06:45:28Z

src/documentation.lisp

+  "Return the lambda-list of FUNCTION."
+  (let ((lambda-list (oget (fdefinition function) "lambdalist")))
+    (when lambda-list
+      (read-from-string lambda-list))))


As mentioned in the comments, this feels a bit weird.
We could just dump the lambda-list with literal from the compiler I guess so there is no need to re-read it?

Ok. I dumped it as a string. I'm not expert on the compiler internals.

src/clos/describe.lisp

mmontone · 2022-09-02T10:58:11Z

May be

(defun function-object-printer (form stream)
  (let ((res)
	      (fname (oget form "fname"))
        (ll-form (function-lambda-list form)))
    (setq res (concat (if fname "#<FUNCTION " "#<LAMBDA ")
		                        (if fname 
                                            fname 
                                            "")
		                        (if ll-form
			                    (princ-to-string ll-form)
                                            "()")
		             ">"))
    (simple-format stream res)))

Mmm?

I should revert that. I was playing a bit with the printing of lambda expressions. In SBCL for example, the lambda list is printed: #<FUNCTION (LAMBDA (X Y)) {5400B62B}>

kchanqvq · 2025-12-26T07:30:52Z

I took a shot bringing this patch up to date, there is indeed a somewhat significant bundle increase. Using the original serialization (prin1-to-string when dumping), it goes from 2.69MB -> 2.89MB. I also tried using literal instead of prin1-to-string which sounds cleaner, and it goes from 2.69MB -> 3.07MB (!!).

Maybe that means we need better dumping code, but I'm not sure how to do that. Arguably I'm responsible for making the matter worse -- in bfa0180 I changed the dumping code to create a variable for every seen literal objects, but this is to make it correctly follow CLHS 3.2.4.4. Without this, the same literal object might be dump into different (non-EQ) literal objects. To do it really correctly and compactly we might need two pass, the first for reference count and the second for actually dumping, and these have to be done over the unit of files. That doesn't sound easy.

kchanqvq · 2026-01-03T06:18:54Z

A few more thing to discuss:

Just saving the string saves space because it (can) lose the package information. For information purpose we don't typically need to package information anyway, but we do need them for accurate FUNCTION-LAMBDA-LIST. Do we really need them?
If answer to 1 is yes, then I think we should change the fname property to store symbol with package information as well. Currently it's just the symbol name string.

@davazp @vlad-km ?

davazp · 2026-01-03T16:49:58Z

I would store it as a s-form, even if the package information is not that important always. But it could be if some of the arguments is a special symbol for example!

Would it be possible to make this feature optional? Adding an option to decide during bootstrap if collect or discard the function lambda lists.

An idea: would it work if we use a global hash tables *docstrings* and *function-lambda-lists* instead of storing it in a property of the function? That way we can just reset the symbol before dumping. Or we can just do the conditional on the function definitions as well.

vlad-km · 2026-01-03T19:54:38Z

Why, and for what purpose?

vlad-km · 2026-01-03T20:00:27Z

Give me statistics on the use of docstring :)

vlad-km reviewed Sep 2, 2022

View reviewed changes

davazp reviewed Sep 2, 2022

View reviewed changes

src/clos/describe.lisp Show resolved Hide resolved

mmontone force-pushed the master branch from 14ae1b6 to 08e6709 Compare September 8, 2022 15:15

mmontone added 4 commits September 8, 2022 12:16

Lambda list in function description

d31c48f

function-lambda-list

7e94721

Fix function-lambda-list

a9dbec7

Assign lambda-lists to anonymous lambdas

2514864

mmontone force-pushed the master branch from 08e6709 to 2514864 Compare September 8, 2022 15:16

kchanqvq mentioned this pull request Jan 4, 2026

Dumper does not handle cyclic object at all #550

Open

Lambda list in function description #442

Are you sure you want to change the base?

Lambda list in function description #442

Uh oh!

Conversation

mmontone commented Aug 28, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vlad-km commented Sep 1, 2022

Uh oh!

davazp commented Sep 1, 2022

Uh oh!

mmontone commented Sep 1, 2022

Uh oh!

mmontone commented Sep 1, 2022

Uh oh!

mmontone commented Sep 1, 2022

Uh oh!

mmontone commented Sep 1, 2022

Uh oh!

mmontone commented Sep 1, 2022

Uh oh!

mmontone commented Sep 1, 2022

Uh oh!

mmontone commented Sep 1, 2022

Uh oh!

vlad-km left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vlad-km left a comment

Choose a reason for hiding this comment

Uh oh!

davazp Sep 2, 2022

Choose a reason for hiding this comment

Uh oh!

mmontone Sep 2, 2022

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mmontone commented Sep 2, 2022

Uh oh!

kchanqvq commented Dec 26, 2025

Uh oh!

kchanqvq commented Jan 3, 2026

Uh oh!

davazp commented Jan 3, 2026

Uh oh!

vlad-km commented Jan 3, 2026

Uh oh!

vlad-km commented Jan 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mmontone commented Aug 28, 2022 •

edited

Loading

vlad-km left a comment •

edited

Loading