René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"auxiliary functions","articleBody":"Just some thoughts, since Denis mentioned that arrays used a lot of auxiliary functions.\n\nI noticed this issue for some time, auxiliary functions are actually written and designed in abstract syntax, technically, they should also be working on concrete syntax. But there are issues that are not nice:\n1. Unlike the klabel attribute mapping between concrete and abstract syntax, after some one direction rules are executed, (like we do with KListWrap), the paramenters presented in auxiliary functions are no longer valid (it doesn't recognize the new syntax). Sometimes this even affect the implementation of that auxiliary function.\n2. Even after I made changes and got them work as before, they don't look nice. It is not any easier to read auxiliary functions with concrete form parameters than abstract form parameters, if not the other round. It is natural, because as I said before, these functions were born considering the abstract form, and instead of the labeled parameters, I plugged in pieces of java code: little pieces of a normal java sentence, which could be even less recognizable than labels. \n\nIt's a dilemma here. If I don't think deep, just trying to plug concrete syntax into aux functions and then debug, the semantics could end up ugly (in many places) even after this substantial change of syntax. However, I don't think it is wise for me to greatly change aux functions. Even now, simply plugging already involves many changes, because of the first reason I mentioned.\n","author":{"url":"https://github.com/laurayuwen","@type":"Person","name":"laurayuwen"},"datePublished":"2014-10-08T04:48:28.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/8/java-semantics/issues/8"}