libera/#sicl - IRC Chatlog

9:40:09 beach Brucio-61: Aside from canonicalization, I'll just experiment and see what arguments are given to MAKE-NODE and RELATE for various situations, and I'll code accordingly.

9:41:17 Brucio-61 using 6:ARGUMENT is not set in stone but i didn't expect it to cause an issue. i can try both variants at some point

9:41:48 beach I see. It is not that important. I can always adapt later.

9:42:07 beach As I recall, there are other assumptions I have made that may need to be modified later.

9:42:50 beach But I can tell that I first need to work on type declarations and declarations with unknown type identifiers.

9:42:56 Brucio-61 i looked at the canonicalization example. the builder splits declaration nodes that contain multiple declaration specifiers and it provides a generic function 6SPLIT-DECLRATION-ARGUMENTS with an example method specialized to 6TYPE

9:43:42 Brucio-61 the generic function can be used to transform 6(type T x y) to 6(type T x) (type T y)

9:44:25 beach But it doesn't do that automatically for things like INLINE, DYNAMIC-EXTENT?

9:46:44 Brucio-61 i misread the code. it does process 6INLINE and 6DYNAMIC-EXTENT but 6TYPE needs a separate method because not all of its arguments name bindings

9:47:04 Brucio-61 here is the code followed by example output: https://plaster.tymoon.eu/view/3961

9:49:20 beach What makes you say that not all arguments to a TYPE declaration specifier are bindings?

9:50:10 beach Syntax: (TYPE <typespec> <var>*)

9:51:10 Brucio-61 i meant the typespec argument does not name a variable or function binding and should not contribute to the splitting into multiple declaration specifiers

9:51:14 beach Oh, you mean the <typespec>?

9:51:44 Brucio-61 that is 6(ignore x y) becomes 6(ignore x) (ignore y) but 6(type t x) does not become 6(type t) (type x)

9:51:47 beach Sure, but the way to split is clear, right?

9:53:05 Brucio-61 yes, in the example, the generic function 6SPLIT-DECLARATION-ARGUMENTS has two methods: one for 6TYPE and one for everything else. that's probably an oversimplification but the approach should work

9:53:42 beach Oh, I see. I took your description to mean that I would have to supply a method for TYPE. My bad.

9:54:36 Brucio-61 i wrote a method for 6TYPE but it's all just an example

9:55:09 beach So let me get this straight. To use your code, I would have to first consult the environment to turn the unknown DECLARATION-ASTs into TYPE-ASTs or something else. Then what do I do to apply your code to Iconoclast ASTs?

9:55:30 Brucio-61 anyway, what is not handled is 6(declare (integer x)) since the example does not consider any environment

9:55:47 beach But I would fix that up first and then call your code.

9:55:55 beach Or is that not possible?

9:56:11 beach I need to vanish for a few minutes.

9:56:45 Brucio-61 sure, i will have to switch to dayjob soon as well

9:59:18 Brucio-61 i think you could write a 6MAKE-NODE method specialized to your builder and 6:DECLARATION-SPECIFIER that consults the environment and turns declaration specifier of unknown kinds into 6TYPE declaration specifiers

10:00:01 Brucio-61 that approach would handle unknown declaration specifiers first, then split declarations and declaration specifiers

10:01:39 Brucio-61 alternatively, you could restrict the 6SPLIT-DECLARATION-ARGUMENTS function to only apply to known declaration specifiers so that no splitting occurs for e.g. 6(integer x y) and handle unknown declaration specifiers entirely separately

10:02:31 Brucio-61 by separately i mean by post-processing the AST after the builder is done (or possibly in 6FINISH-NODE method)

10:03:09 beach The way I have done it is to consult the environment in FINISH-NODE. I'll see whether your idea can be applied.

10:06:22 Brucio-61 i can try to combine the example with the iconoclast builder. may save time if i do it

10:07:16 beach Nah, don't worry about it. I'll figure it out. I am not that thrilled about canonicalizing at MAKE-NODE time. But I might change my mind.

10:08:24 Brucio-61 i understand. i'm also worried that some roadblock might come up but if possible, it seems like the simplest solution to me since the transformation is mostly syntactical

10:08:42 beach I see, yes.

10:12:06 Brucio-61 given a quick test, the example seems to work with the iconoclast builder. but printing the iconoclast tree fails. not sure whose "fault" it is

10:13:14 beach I think you replace the DECLARATION-ASTS with DECLARATION-SPECIFIER-ASTs, no? Could that have something to do with it?

10:13:16 Brucio-61 ok, no, there is an actual problem

10:14:07 Brucio-61 i thought i disabled the part about replacing 6:DECLARATION nodes

10:14:32 Brucio-61 i just kept it as an extension to the example

10:14:38 beach I take your word for it.

10:20:20 Brucio-61 the problem was just with iconoclast-print-tree after all. the version https://plaster.tymoon.eu/view/3961#3963 (most recent annotation of the past) builds an iconoclast ast and inspects it (since printing doesn't work)

10:20:32 Brucio-61 *of the paste

10:20:58 beach I see.

10:30:27 beach I am about to take a long-ish lunch break. Recently, I often get the feeling that I am going around in circles. I need to break that feeling or I won't get anything done.

10:32:33 Brucio-61 sorry to hear that. don't feel obligated to pursue the approach i suggested. i am probably biased by thinking the fact that the builder protocol can do such transformations independently of the "target" builder is cool

10:34:21 beach Sure. I think I'll do what I often do which is write something myself, and if and when I realize that I could use something existing, I'll change and adapt the code.

10:34:50 Brucio-61 sounds good

10:35:30 beach By the way, I think I discovered (no doubt not as the first person) an alternative way of writing a tree transformer application. As I recall, the traditional way is to have a function that takes function arguments for pre-processing and post-processing of nodes, yes?

10:36:57 beach But with CLOS, the primary method can do just the traversal, and client code (specializing to a CLIENT class) can define an :AROUND method to do whatever processing is required, before calling CALL-NEXT-METHOD, after calling it, or changing the node entirely and calling the traversal routine recursively on the changed node.

10:38:45 beach Anyway, I'm off for a while.

10:39:21 Brucio-61 right, that's a pretty flexible approach. do you generally mutate nodes or build a fresh tree for the result?

10:41:32 beach That depends on the application. For canonicalizing declarations, probably mutate.

10:41:53 beach But for turning LET* into LET, new nodes will be created.

10:42:54 beach Though I guess mutating is an option there too.

10:43:42 beach I could do CHANGE-CLASS and then make a recursive call, since I can't do CALL-NEXT-METHOD then.

10:44:11 beach Really off now.

15:05:32 beach Maybe I should work on something that does not involve type specifiers for now. I need type specifiers to turn LET* into LET, but I can turn LET into FLET without manipulating type specifiers, and I can turn FLET into LABELS and (FUNCTION (LAMBDA ...)) into FLET also without type specifiers.

15:33:31 beach Brucio-61: What is the name of the syntax that parses ((lambda ...) ...)?

16:20:53 Brucio-61 beach: 6S-EXPRESSION-SYNTAX:APPLICATION. that syntax description handles 6((lambda () ...) ...) as well as 6(FUNCTION-NAME ...)

16:21:29 beach Oh, OK. Thanks.

16:35:53 beach For what it's worth, I feel somewhat better now that I worked on some of the other AST transformations.

16:38:20 Brucio-61 that's good to hear

16:53:49 Brucio-61 beach: i pushed support for the abbreviated type declaration syntax to the 6beach branch. you should be able to simply pull the change

17:13:35 beach Perfect! Thanks!

20:28:45 bike I fixed up the virtual machine "cross" system so it can compile and eval in arbitrary first class environments again. and wrote out an example https://github.com/clasp-developers/cvm/tree/main/Cross

20:29:04 bike (despite still being in clasp-developers at the moment, this works on any implementation)