Changing source code by using an unified diff format

[comby-tools]

Changing source code by using an unified diff format

[rvantonder]

Hi @elfring! I take it you're familiar with spatch [1, 2], so something like that? This is possible; there are a couple of things to think about compared to, say, spatch, and maybe you can offer your thoughts. Perhaps at the simplest level, for a patch language in comby there wouldn't be a block (delimited by @@..@@ for identifiers, and instead just use combys metasyntax (holes) directly in patch lines, like:

// some context
- foo(:[1])
+ foo(:[1])
more context

The other part to consider is the separation of the rule language, and how that would be syntactically delineated or supported. Perhaps initially this just wouldn't be supported.

Overall, as a basic or experimental feature, this should be quite easy to support.

I can think of some good reasons why having a diff-like representation would be useful, but I'm curious to hear how this would specifically help your use case?

[elfring]

I take it you're familiar with spatch …

You can see from published development activities that I am working also with the semantic patch language (Coccinelle software) for a few years.

I can think of some good reasons why having a diff-like representation would be useful,

I suggest to take another look at variants for further possible change specifications.

• Example 1:

   // some context
  -foo
  +update
   (:[1])
   more context

• Example 2:

  -foo(:[1])
   action()
  +foo(:[1])

but I'm curious to hear how this would specifically help your use case?

• You chose to use the term “rewrite template”. I would prefer the wording “generation template”.
• I propose to take more possibilities into account so that the specification of duplicate contents can be avoided in this data structure.

[rvantonder]

I am working also with the semantic patch language

Well, good to meet you :)

duplicate contents can be avoided in this data structure

Makes sense to me. So, there are a couple of things that are roughly described in the roadmap document that I'd like to prioritize. I'm happy to add the diff specification as a feature request, and it does not seem too difficult. It might be a while until I can get to work on it though. You are of course very welcome to hack on and contribute something like this.

Sound good if I put this on the ROADMAP and I'll get to it once I have some more time?

[elfring]

I am struggling with software development challenges also together with the programming language “OCaml".
So I tend to pick opportunities up for improvements in other areas.