5.7 KiB
5.7 KiB
type:: REVIEWS
tags::
year:: 2023
venue:: TOSEM
full-title:: CONCORD: Towards a DSL for Configurable Graph Code Representation
date-start:: 15-11-2023 - 22:21
date-submitted:: 12-01-2024
external-links::
status:: DONE
deadline-submission:: 15-12-2023
file:: 
- [[Highlights]]
- #+BEGIN_IMPORTANT
((65981816-5aa6-4360-85f4-46ce5a5a69cb))
((659bcafc-05cf-4452-88d5-b8ca73ab1d6c))
((65981831-d2ba-45e9-829e-3aba0f53bbff))
#+END_IMPORTANT
-
- ((659819a2-98ea-4fc3-83a1-9d87caa5923e))
- This needs to be checked in the paper.
- ((6599056a-6c94-48c2-82dd-c738d80f0557))
- This is interesting and related to our paper [[PAPERS/SOSYM-Vallecillo]]
- ((659bcb29-167c-4364-af82-49714fa63d8a))
- This cannot be claimed in absolute terms. It depends on the task to be executed, isn't it?
- ((659bcb6b-d444-4a68-9eeb-934f7b00a3cd))
- compared to what?
- ((659bcba9-fb02-4cca-b635-7adb03216bdc))
- Is there any specificity related to the support of the approach for GNN? What-if other types of neural networks have to be employed?
- ((659bcc40-1711-42c5-9a97-41ee9bc89003))
- ((659bccb1-a488-4830-a2f0-df30d314c0a3))
- This might be related to [[PAPERS/LEV4REC]] and the work that can be of interest to [[people/claudio]]
- ((659bccf0-1a77-4ea0-864c-8c75a095c58a))
- ((659bcdcd-0f74-41be-8b38-896468422a12))
- DONE [[Omnivore/08-01-2024/Towards a DSL for AI Engineering Process Modeling - SpringerLink]]
-
- ((659bd1f9-7c70-4639-ae9c-66f93c51d7ca)) (related to code graphs construction)
- ((659bd206-fa95-46e8-8de9-bd3f2fbefd24))
- ((659bd212-ed12-4e55-91fc-c105a56197ce))
- ((659bd231-75fd-4845-9e0a-f62457347012))
- ((659bd3ea-511f-4a92-852b-3d2ef2022150)) [[AI/Attention]]
- ((659bd500-4f92-4ed3-83e9-b1471c4521ae)) (related to source core reduction)
- Is this also addressed by CONCORD? TO BE CHECKED
- ((659bd64a-a3e1-471b-82a8-f9673e6a2cb1))
- To what extend graph representations can address such a limitation?
- ((659bd67e-cf52-44c1-828c-4d7009f6e376))
- How *CONCORD specifications* are linked/related with the *Case Specific Task* component of the DL pipeline at hand?
- ((659bd96b-a2e3-4eae-a82e-d7da151c4a80))
- This reinforce the fact that the approach is for GNN models!!!
- ((659bda02-94d9-48aa-9557-153458217366))
- When are tasks executed?
- ((659bdbfc-81cc-4f69-b85f-7d849579f6a3))
- To make clear the discussion, each phase of the graph generation process should be described, by referring to the motivating example shown in Listing 1.
- ((659bdc69-49f6-4e3e-a729-f78a729f9520))
- This activity should be part of the generation process presented in Section 3.2. I understand it requires more elaboration, however, I would include it in the list given in Section 3.2.
- It seems that Node Removal refers to the Statelement Delection phase. Thus, if it is the case, I suggest to rename section 3.3 as the same third activity in sec 3.2, otherwise it seems we are talking about different things, but it is not the case.
- ((659bdf08-9037-43e1-a49d-c87be7c53814))
- Why is the removal of simple assignment relevant in the whole graph generation process? What is the goal to be achieved? Please, clarify.
- ((659bdf77-e9b2-43d5-a2be-0b3916021171))
- Similarly to Section 3.3, it is not clear when this activity and how is performed with respect to the process overviewed in Section 3.2.
- ((659fe5ba-f3af-42c0-ba05-7a3e3650faae))
- You to motivate the selection of the used characteristics.
- ((65a01a5a-a15f-42f6-a44e-ed8860605b0d))
- Is it for representing Edges? Why not using E instead of P?
- ((65a01c58-9ec9-4df7-8cd3-b3ee111ee962))
- Can this equation be defined with the CONCORD DSL?
- ((65a01c99-3061-4a1f-a818-6eaa31f62c18))
- Why 12? Maybe I'm missing something
- ((65a01cfa-d6fa-4492-b41c-776dbf40fa58))
- Even though this research question permit to investigate to what extent the computational operations change with respect to size complexity of code representation, it does not permit to investigate any aspects related to the inner characteristics of CONCORD, including the expressiveness of the language, the kinds of datasets it can mine / support, etc. The answered research question is hortognal to CONCORD and could be answered even without CONCORD.
- Following my previous comment, I don't see a consequent link of the obtained results with the following part of Key Observation 1:
- ((65a01e93-c534-432f-97fb-075c24556185))
- Even key observations 2, 3, 4 are not directly linked with the exprssiveness of the CONCORD DSL and related supporting tools. The observations could be achieved by investigating the datasets even without CONCORD. Then, the interesting question would be how difficult wold be preparing the required datasets without the proposed language.
- In other words, the paper is about an interesting and relevant problem. My main concerns are about the performed evaluation, which focuses on aspects that are not directly linked to the proposed CONCORD technology. The authors presents the approach as a " ((65a01f88-6864-44cb-b7e5-eee10e22a809)) ". Unfortunately, the performed evaluation does not permit to assess the configurability and customizability strenghts of the approach. The evaluation permits to see results that could be achieved even without CONCORD (maybe with additional efforts). It is interesting to see how difficult would be to do that!
- [[Comments]]
- [[REVIEWS/Notes]]
- The paper can be considered to support the management of "data encoding" in [[PAPERS/LEV4REC]] [[Ideas]] [[BRAINSTORMING]]
-