Error on AllegroCL 10.1

[digikar99]

Depending on if I'm using mlisp or alisp, the errors are different; for alisp, it is:

Function position must contain a symbol or lambda expression:
(TYPE SYMBOL)
   [Condition of type PARSE-ERROR]

Restarts:
 0: [NIL] retry the compilation of /home/user/quicklisp/local-projects/cl-environments/src/other/allegro.lisp
 1: [NIL] continue compiling /home/user/quicklisp/local-projects/cl-environments/src/other/allegro.lisp but generate no output file
 2: [RETRY] Retry compiling #<CL-SOURCE-FILE "cl-environments" "src" "other/allegro">.
 3: [ACCEPT] Continue, treating compiling #<CL-SOURCE-FILE "cl-environments" "src" "other/allegro"> as having been successful.
 4: [RETRY] Retry ASDF operation.
 5: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
 --more--

Backtrace:
  0: (ERROR PARSE-ERROR :FORMAT-CONTROL "~?~@[~a~]" :FORMAT-ARGUMENTS ("~1@<Function position must contain a symbol or lambda expression: ~S~:@>" ((TYPE SYMBOL)) NIL))
  1: (COMPILER::COMPILER-ERROR "Function position must contain a symbol or lambda expression: ~S" (TYPE SYMBOL))

While on mlisp, the error is:

cl-user> (ql:quickload "cl-environments")
To load "cl-environments":
  Load 1 ASDF system:
    cl-environments
; Loading "cl-environments"

Attempt to take the value of the unbound variable
`cl-environments.util::g!test'.
   [Condition of type unbound-variable]

Restarts:
 0: [try-again] Try evaluating cl-environments.util::g!test again.
 1: [store-value] Set the symbol-value of cl-environments.util::g!test and use its value.
 2: [use-value] Use a value without setting cl-environments.util::g!test.
 3: [nil] retry the compilation of /home/user/quicklisp/local-projects/cl-environments/src/common/macro-util.lisp
 4: [nil] continue compiling /home/user/quicklisp/local-projects/cl-environments/src/common/macro-util.lisp but generate no output file
 5: [retry] Retry compiling #<cl-source-file "cl-environments" "src" "common" "macro-util">.
 --more--

Backtrace:
  0: (error #<unbound-variable @ #x20fdbdea>)
  1: (cl-environments.util:let-if ..)
  2: (funcall #<Macro Function let-if @ #x20d4870a> ..)

[Yehouda]

The same error as for Allegro occurs in LispWorks. It is caused by the symbol MATCH not recognized as a macro. In sbcl.lisp, th epackage cl-envrioenments-cltl uses the apckage OPTIMA, wher it gets the symbol MATCH. In allegro.lispa nd lispworks.lisp it doesn't. Either qualify the symbol optimia:match, or use the package like in sbcl.lisp

[alex-gutev]

Should be fixed in the latest commit.

[digikar99]

It does load now; but a few things:

1.

https://github.com/alex-gutev/cl-environments/blob/118f1916f131da58494fd13faab4c05b2b9c4327/src/other/allegro.lisp#L33

This should perhaps also include :declaration-information. (See point 3.)

https://github.com/alex-gutev/cl-environments/blob/118f1916f131da58494fd13faab4c05b2b9c4327/src/other/allegro.lisp#L125-L130

define-declaration could also declare arg-var as ignorable

3. Running the following on SBCL vs ACL produces different results:

(in-package :cl-environments.cltl2)

(defmacro var-info (var &environment env)
  (print (multiple-value-list (variable-information var env)))
  nil)

(let ((a "hello"))
  (declare (type string a))
  (var-info a)
  a)

On SBCL, the printed information is (:LEXICAL T ((TYPE . STRING))) while on ACL, it is (:LEXICAL T ((TYPE (ARRAY CHARACTER (*))))); so perhaps, the output of sys:variable-information needs to be processed to produce the required alist instead of the list; similar seems to be the case with sys:function-information and sys:declaration-information

[alex-gutev]

Regarding point 2. I suppose so. I will add it. As for point 3. CLTL2 allows the implementation to store a different type specifier in the environment, from the specifier in the type declaration. From the documentation for variable-information at https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html:

The value is a type specifier associated with the variable by a type declaration or an abbreviated declaration such as (fixnum variable). If no explicit association exists, either by proclaim or declare, then the type specifier is t. It is permissible for implementations to use a type specifier that is equivalent to or a supertype of the one appearing in the original declaration. If the value is t, the pair might be omitted.

I don't know whether in this case the type returned by variable-information is a supertype of string or not. However I'd prefer not to be modifying the results returned by the native *-information functions, where they are provided by the implementation, other than to add support for custom declarations. To solve this issue I'd either have to come up with some canonical representation for types, or add the full code walker to every implementation, including those which support CLTL2, in order to guarantee that the type returned is identical to the declared type. Neither solution is ideal and it's beyond the scope of this project.

[digikar99]

Ah, I wanted to refer to it being the list ((TYPE (ARRAY CHARACTER (*)))) on ACL and not an alist ((TYPE ARRAY CHARACTER (*))) like ((TYPE . STRING)) on SBCL

[alex-gutev]

Oh, in that case, that's something I can do. I will probably have to make the change for all standard declarations, dynamic-extent, etc.

[melisgl]

Not sure whether this needs a separate issue. Lots of tests fail on AllegroCL (alisp):

 Did 142 checks.
    Pass: 55 (38%)
    Skip: 0 ( 0%)
    Fail: 87 (61%)

I believe AllegroCL's implementation is very different as evidenced by the (broken) special casing in trivial-cltl2.

[LEHunter]

I'm having this problem again with Allegro CL 11.0

International Allegro CL Enterprise Edition 11.0 [64-bit macOS (Apple Silicon)] Copyright (C) 1985-2023, Franz Inc., Lafayette, CA, USA. All Rights Reserved.

This development copy of Allegro CL is licensed to: [TC22861]

Note: Allegro CL will expire in 70 days, on June 30, 2024. ; Loading /Users/hunter/quicklisp/setup.lisp ; Fast loading ; /Applications/AllegroCL64.app/Contents/Resources/code/asdf.001 ;;; Installing asdf patch, version 1. ; Autoloading for class synonym-stream: ; Fast loading from bundle code/streamc.fasl. ; Fast loading from bundle code/efft-utf-8s-base.fasl. ; Fast loading from bundle code/efft-utf8-base.fasl. ; Fast loading from bundle code/efft-void.fasl. ; Fast loading from bundle code/efft-latin1-base.fasl. ; Autoloading for package "excl.osi": ; Fast loading ; /Applications/AllegroCL64.app/Contents/Resources/code/osi.fasl ; Fast loading from bundle code/fileutil.fasl. ; Fast loading from bundle code/acldns.fasl. ; Fast loading from bundle code/iodefs.fasl. ; Fast loading from bundle code/iordefs.fasl. ; Fast loading from bundle code/efmacs.fasl. ;; Optimization settings: safety 1, space 1, speed 1, debug 2, ;; compilation-speed 1. ;; For a complete description of all compiler switches given the ;; current optimization settings evaluate (explain-compiler-settings). ;;--- ;; Current reader case mode: :case-sensitive-lower cl-user(1): (ql:quickload "cl-environments") To load "cl-environments": Load 1 ASDF system: cl-environments ; Loading "cl-environments" ; While file-compiling #'match-state in

P"/Users/hunter/quicklisp/dists/quicklisp/software/cl-environments-20211020-git/src/common/macro-util.lisp"

; starting at file character position 1226: Error: Attempt to take the value of the unbound variable `g!test'. [condition type: unbound-variable] Problem detected when processing (let-if ((start (second states) ...) (body (cddr states) ...)) ...) inside <...> inside (labels ...) inside (let ...) inside (progn (let ((next (intern #)) (from-state (intern #))) ...)) inside <...> inside (let nil ...) inside (let ...) inside (let nil ...) inside (block match-state ...) inside (comp::named-function-1 ...) inside (excl:compiler-let ...) inside (the excl::known-function ...) inside (excl:named-function match-state ...) inside (let* ...)

Restart actions (select using :continue): 0: Try evaluating g!test again. 1: Set the symbol-value of g!test and use its value. 2: Use a value without setting g!test. 3: retry the compilation of /Users/hunter/quicklisp/dists/quicklisp/software/cl-environments-20211020-git/src/common/macro-util.lisp 4: continue compiling /Users/hunter/quicklisp/dists/quicklisp/software/cl-environments-20211020-git/src/common/macro-util.lisp but generate no output file 5: Retry compiling

<cl-source-file "cl-environments" "src" "common" "macro-util">.

6: Continue, treating compiling

<cl-source-file "cl-environments" "src" "common" "macro-util"> as

 having been successful.

7: Retry ASDF operation. 8: Retry ASDF operation after resetting the configuration. 9: Give up on "cl-environments" 10: Register local projects and try again. 11: Return to Top Level (an "abort" restart). 12: Abort entirely from this (lisp) process.

[changing package from "common-lisp-user" to "cl-environments.util"] [1] cl-environments.util(2):

[LEHunter]

It's not about finding match, though:

(describe 'match) match is a tenured symbol. It is unbound. It is external in the optima package and accessible in the cl-environments.util, common-lisp-user, and optima.extra packages. Its function binding is #<macro match @ #x301088f02> which macro takes arguments (arg &body clauses) ...

[alex-gutev]

It seems to be a problem with the defmacro! macro from let-over-lambda. I will take a look at it.