Handling form-type of compiler-macro-functions

[digikar99]

Would it be possible to handle more diverse form-types? One particular one I'm interested in is when the car is bound to a compiler-macro-function.

@commander-trashdin, thanks for several others! You might want to issue a PR for commander-trashdin@12cba3c

[commander-trashdin]

I haven't really done anything and stuff I tried to add didn't really work afair?

But yeah, this whole lib is kinda necessary for what I am trying to achieve rn. Like, spec store doesn't do much if you pass in something that is not a variable.

[Bike]

commander trashdin's changes were discussed as #6

As I said there, I've grown skeptical that what I was going for here is doable, but I don't mind merging valid changes if they help with whatever you're doing. I might have been too dismissive earlier. Looking at this commit, the progn, prog1, prog2, locally, tagbody, and if inferrers look correct to me (though with the last, the (if else ...) could more simply be (form-type else env), since else defaults to nil and (form-type nil env) should be (eql nil) if I hooked up constants correctly).

What would happen with compiler macro forms? Do you mean that they should be expanded? I would have thought the function could just have a type declared for it.

[digikar99]

I see. I see. I see. Checked the discussion.

So, we either need a full-type inferencing system, or users need to explicitly declare types using the?

Yeah, I wanted compiler-macros to be expanded.

I, as well as commander trashdin, were trying to implement a type-based dispatching version of generic-cl. I got a half-baked typed-functions done based, but upon trying to use it to implement a typed-cl/cl-overload, yesterday and today, ran into various issues pertaining to the final generated code.

And the mentioned discussion here neatly explains the point. The point of SICL. The point of Coalton. I just had a discussion with Marco Heisig; with a mention of these two.

This really needs a write-up, and the write-up should be included on all the relevant projects; is there one already?

[commander-trashdin]

The more I fiddle with cl-overload, the more I realize that what we want is like, a second compiler, or rather, a compiler mode, something like https://en.wikipedia.org/wiki/Stalin_(Scheme_implementation) but for CL, something that pg describes here, I guess http://www.paulgraham.com/thist.html

[Bike]

This really needs a write-up, and the write-up should be included on all the relevant projects; is there one already?

I, at least, haven't written one.

Since #6 Cleavir has been spun out into its own project, s-expressionists/Cleavir - part of the SICL meta-project, as it were. Karlosz and I are working on compiler optimizations. You can see some of our (mostly his) plans on the wiki.

We're not as far as devising any kind of language extension, but that could be a longer term project. We would like something like sbcl's deftransform, but for the moment we're intending for it to be used by implementations themselves. You can get some tricky safety questions with user code.

[digikar99]

For SBCL itself, I think I'll stick to sb-c:deftransform - found a really neat introduction at https://stackoverflow.com/questions/44342104/using-deftransform-defknown-in-sbcl-internals-to-get-the-compiler-to-transform-u

[commander-trashdin]

I've seen the discussion and even tried to contact the person who answered

Is your plan to just put deftransforms under #+sbcl in dispatch code?

[digikar99]

Yeah, that way; added last night; pushed. Perhaps, something similar can be done for other implementations; but I'll stick with this and SBCL for the time being.

PS; Perhaps rest of the discussion belongs elsewhere; just thought of dropping the link here in case someone passes by this discussion, though google has that stackoverflow discussion indexed.