Clarification for term "AST"

I'm not 100% sure what your question is :slight_smile:

So, we are doing ongoing refactoring work based on the ast matchers - and
when I say refactorings, I really mean "code transformations".

About the "semantic patch language". To some degree we have a semantic
patch language. It just happens to be written as C++ code. Now, I'm aware
that for simple problems that not optimal, and I'd be curious to see
projects that try to address this, but we have put a lot of thought into it
and think that a project like that would have a lot of risk - so it'd
better fit into a research org.

Cheers,
/Manuel

About the "semantic patch language". To some degree we have a semantic patch language. It just happens to be written as C++ code.

Will any further fine-tuning be performed for a domain-specific language about easier source code transformations?

... - so it'd better fit into a research org.

Would you like to reuse and integrate any results that were achieved by computer scientists for "Coccinelle"?

Regards,
Markus

We actually looked into coccinelle before staring the ast matchers. We did
not find that coccinelle matched what we needed, but a lot of it might be
related to "effort of implementation". It's definitely not something we're
going to do :slight_smile:

Cheers,
/Manuel

We did not find that coccinelle matched what we needed, but a lot of it might be related to "effort of implementation".

I find that the Coccinelle technology is a promising approach. It works for patches on C programming language files.

I assume that you imagine a different data structure for the specification of consistent source code transformations across translation units.

It's definitely not something we're going to do :slight_smile:

It is a pity. - I hope that some results from knowledge areas like Smalltalk, Java or OCaml can be better reused in the near future.
Would you like to avoid to reinvent a "coding wheel"?

Regards,
Markus

We did not find that coccinelle matched what we needed, but a lot of it

might be related to "effort of implementation".

I find that the Coccinelle technology is a promising approach. It works
for patches on C programming language files.

It's most definitely interesting.

I think the main downside of a pattern based matching language is that C++
is this huge beast of a language, where lots of implicit stuff happens.
It's comparatively easy to express matches on C code as "patterns", but
it's really hard to do the same for C++.

I assume that you imagine a different data structure for the specification
of consistent source code transformations across translation units.

It's definitely not something we're going to do :slight_smile:

It is a pity. - I hope that some results from knowledge areas like
Smalltalk, Java or OCaml can be better reused in the near future.
Would you like to avoid to reinvent a "coding wheel"?

There's nothing I'm trying to avoid. I find many of those approaches
interesting, but I don't see that it would give us the kind of pay-off for
the effort I estimate and thus we put priority on other things...

Cheers,
/Manuel

I think the main downside of a pattern based matching language is that C++ is this huge beast of a language, where lots of implicit stuff happens. It's comparatively easy to express matches on C code as "patterns", but it's really hard to do the same for C++.

The interesting patterns will not be specified by ordinary regular expressions. Can the meta-variables from the Coccinelle technology be mapped to "ASG" matchers for the desired higher level source code transformations?

Regards,
Markus

To some degree we have a semantic patch language. It just happens to be written as C++ code.

Which approaches do you prefer to specify dependencies between nodes in a control flow graph of a function implementation for example?

Would you like to reuse anything from the technology "CTL-VW" (computation tree logic with variables and witnesses) and related knowledge areas from computer science for improved source code transformations?

Do you find information from the document "A Foundation for Flow-Based Program Matching Using Temporal Logic and Model Checking" useful for your class library?
http://coccinelle.lip6.fr/papers/popl09.pdf
http://doi.acm.org/10.1145/1480881.1480897

Regards,
Markus

To some degree we have a semantic patch language. It just happens to be

written as C++ code.

Which approaches do you prefer to specify dependencies between nodes in a
control flow graph of a function implementation for example?

We don't do control flow (yet).

Would you like to reuse anything from the technology "CTL-VW" (computation
tree logic with variables and witnesses) and related knowledge areas from
computer science for improved source code transformations?

Do you find information from the document "A Foundation for Flow-Based
Program Matching Using Temporal Logic and Model Checking" useful for your
class library?
http://coccinelle.lip6.fr/**papers/popl09.pdf<http://coccinelle.lip6.fr/papers/popl09.pdf>
http://doi.acm.org/10.1145/**1480881.1480897<http://doi.acm.org/10.1145/1480881.1480897>

At a glance, this all looks super-theoretical :slight_smile: The big question for us
is: how can we make it simpler to use.

Cheers,
/Manuel

We don't do control flow (yet).

Would you like to change this design aspect?

    http://coccinelle.lip6.fr/papers/popl09.pdf

At a glance, this all looks super-theoretical :slight_smile:

I agree to this view also from my knowledge background. I hope that the technology "CTL-VW" (computation tree logic with variables and witnesses) will be reused for further software development besides the programming language "OCaml".

The big question for us is: how can we make it simpler to use.

I find that the application of "SmPL" is relatively easy after I became used to it. Corresponding extensions might be interesting for the involved class libraries.

Regards,
Markus

We don't do control flow (yet).

Would you like to change this design aspect?

Yes. But that will require getting the lowest level up first, which is to
hook the static analyzer into the tooling framework. We're planning to
spend some work there later this year...

Cheers,
/Manuel

To some degree we have a semantic patch language. It just happens
to be written as C++ code.

Do you know any utility classes which help to generate patch hunks?
http://en.wikipedia.org/wiki/Diff
http://linux.yyz.us/patch-format.html

Regards,
Markus