m2ym/trivial-types is archived

[digikar99]

https://github.com/m2ym/trivial-types has been archived.

In case no one more experienced comes forward, I'd be glad to maintain it at https://github.com/digikar99/trivial-types - quicklisp could fetch the future versions of trivial-types from the master branch here.

PS: Putting it well before the next quicklisp release for any potential discussions.

[quicklisp]

Does your version differ from the original somehow?

[digikar99]

Yes, it differs in the sense it builds over the m2ym/trivial-types. My version is essentially a fork.

Recent changes include not ignoring element-type in proper-list, the addition of a few more types (in accordance with CLHS), dependence on fiveam. (See the commits - or the Network.)

The additional types are used in trivial-coerce; both of which (trivial-coerce and additional types in trivial-types) will potentially be dependencies of some other libraries I'm planning to add in a couple of months.

[quicklisp]

This breaks a bunch of stuff. http://report.quicklisp.org/2021-02-28/failure-report.html has the fallout. Is there a quick fix?

[phoe]

Core breakage is at https://github.com/m2ym/cl-syntax/blob/03f0c329bbd55b8622c37161e6278366525e2ccc/src/operators.lisp#L38 - this seems to fail due to declare type. SBCL likely attempts to call the function TRIVIAL-TYPES/PROPER-LIST::|LIST OF SYNTAX-DESIGNATOR| that is undefined at load-time.

(Also, found a bug: SYNTAX-DESIGNATOR should have a package prefix printed in the symbol name. foo:symbol-designator and bar:symbol-designator name distinct types, but the new trivial-types:proper-list type is going to erroneously conflate them.)

[digikar99]

I... don't see a quick fix unless the function generation (https://github.com/digikar99/trivial-types/blob/83b1207d1d27cfdfb90ac36570f46ffe41228366/src/lists.lisp#L63) can be triggered after the compilation and fasl-dump in SBCL. As a side effect, I suppose doing that could also enable better reporting of type errors, since the type symbol would be available for action by describe.

I could revert those changes - or try getting into SBCL, that latter feels better in the longer run. Perhaps, if I don't find a quick fix in the next 4 or so hours, keep the URL pointed at m2ym/trivial-types. at least until the next quicklisp dist.

[quicklisp]

If I go back to the old trivial-types, can you update trivial-coerce?

…

On Sun, Feb 28, 2021 at 9:19 AM Shubhamkar Ayare ***@***.***> wrote: I... don't see a quick fix unless the function generation ( https://github.com/digikar99/trivial-types/blob/83b1207d1d27cfdfb90ac36570f46ffe41228366/src/lists.lisp#L63) can be triggered *after* the compilation and fasl-dump in SBCL. As a side effect, I suppose doing that could also enable better reporting of type errors, since the type symbol would be available for action by describe. I could revert those changes - or try getting into SBCL, that latter feels better in the longer run. Perhaps, if I don't find a quick fix in the next 4 or so hours, keep the URL pointed at m2ym/trivial-types. at least until the next quicklisp dist. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1983 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACPNLPFFREQ5AT2UJWBVCDTBJGHXANCNFSM4XLGU63Q> .

[digikar99]

Curious; how does this work? This and trivial-coerce were added; yet, the blog post does not mention the update to trivial-types or the addition of trivial-coerce; the non-updates are as per the discussions here. Doesn't a commit to this repository directly affect quicklisp? There also are projects added in the commits after the commit that closed this that appear in the new dist version, yet it seems trivial-types is kept pointed at the m2ym/trivial-types for this version of quicklisp dist.