• Continue writing and updating the list of tools and frameworks.
• Add a section about the Language Server Protocol to the list of tools and frameworks.
• Implement a small LSP server. Also implement either a client, or try to use an existing editor as client.
• Possibly look at IntelliJ/Atom to implement in instead, but this would mean leaving Spoofax.
  • In this context, maybe look at Eclipse Epsilon?
• Read Generating Diagram Editors with DiaGen by Mark Minas.
• Look at Flexmi from Eclipse Epsilon.
• Look compiler compilers support for unicode.
• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc.
• Try and get a concrete definition of island grammars and related terms, with references to papers.
• Try the same for code completion, and other points of comparison. This to make our classification more specific.
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself.

• Add maintenance criteria for tool (Snyk.io advisor for example)

Preparation

• To fill in on 30-04-2021

Scheduled

• Nothing yet

Things to mention/ask

• None yet

Actionable information

• In the future!

Extra information

• In the future!

Preparation

• Continue writing grammars for examples in variability document.
• Expand on Unicode in variability document.

Things to mention/ask

• Missing: "Comparison of compiler-compilers with Python support" by Jelle Slowack (2012)

Actionable information

• In the future!

Extra information

• In the future!

Preparation

• Continue writing grammars for examples in variability document.
• Expand on Unicode in variability document. [DEFERRED]

Actionable information

• Read "Human-Usable Textual Notation for ArkM3"
• Check if lexerless parsers can support indentation aware languages.

Extra information

• In the future!

Preparation

• Write grammars for examples in variability document.
• Expand on Unicode in variability document. [DEFERRED]

Actionable information

• Verify difference between lexer="dynamic" and lexer="dynamic_complete" in Lark. [DONE]

Preparation

• Continue writing document detailing each variability point. [DONE]
• Continue looking at various languages to classify them in our variability model. [DONE]
• Look at Clafer to visualize the variability model, and to look at where it falls within this model itself. [DEFERRED]

Actionable information

• Fix examples for section "Comment styles" being referred to as being Java examples, should be JavaScript examples. [DONE]
• Under "Section based": replace INI with nesting example to use relative syntax rather than absolute ([...[ ... ]...] to <<& ... >>) [DONE]
• Try and split document into smaller pieces. [DONE]
• Go to next step: writing grammars for each example.

Extra information

• Data flow vs. control flow: depends on granularity. At around 08:00 into meeting.

Preparation

• Continue writing document detailing each variability point.
• Continue looking at various languages to classify them in our variability model.
• Look at Clafer to visualize the variability model, and to look at where it falls within this model itself. [DEFERRED]

Actionable information

• Unicode: add more background information on what Unicode is (with citations)
• Add to bibtex file.
• Make variability document compile with pdflatex instead of xelatex. [DONE]

Extra information

• 3 levels of variability: language, grammar families, parser generators (simplified overview)

Preparation

• Continue writing document detailing each variability point.
• Continue looking at various languages to classify them in our variability model.
• Look at Clafer to visualize the variability model, and to look at where it falls within this model itself. [DEFERRED]

Actionable information

• Meeting notes: shorten "preparation" section and split "meeting" sections into "actionable information" and "extra information"
• Reminder of tasks:
  1. Complete report on language variability model including everything we've discussed.
  2. For each example we've written down, look at the grammar for the example. Try and combine 2 language grammars with a 3^rd bridge grammar (manually).
  3. Look at how we can make this more modular, or how we would combine these 3 grammars together dynamically

Extra information

• Possibility of moving meetings to Mondays

Preparation

• Contact Mariska Hendrickx about study programme. [DONE]
• Continue writing document detailing each variability point.
• Look at Clafer to visualize the variability model, and to look at where it falls within this model itself. [DEFERRED]
• Continue looking at various languages to classify them in our variability model.
• Look compiler compilers support for unicode. [DEFERRED]
• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc. [DEFERRED]
• Try and get a concrete definition of island grammars and related terms, with references to papers. [DEFERRED]
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Things to mention/ask

• None yet

Actionable information

• Unicode: operators, separators and whitespace can also be used by some languages (adding to keywords, identifiers and strings).

Extra information

• Unicode: Table of characters in "Separators, Space" category: link
• Unicode: File containing unicode properties (latest revision): link

Preparation

• Continue writing document detailing each variability point.
• Look at Clafer to visualize the variability model, and to look at where it falls within this model itself. [DEFERRED]
• Continue looking at various languages to classify them in our variability model.
• Look compiler compilers support for unicode. [DEFERRED]
• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc. [DEFERRED]
• Try and get a concrete definition of island grammars and related terms, with references to papers. [DEFERRED]
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Meeting

• Meeting recap scheduled
• Tasks from this meeting:
  • Try and think of 2 grammars that are different enough that when parsing there is no doubt it is one or the other (with a combined grammar)
  • Try and rework images for token stream

Preparation

• Continue writing document detailing each variability point.
• Look at Clafer to visualize the variability model, and to look at where it falls within this model itself. [DEFERRED]
• Look at various languages to classify them in our variability model.
• Look compiler compilers support for unicode. [DEFERRED]
• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc. [DEFERRED]
• Try and get a concrete definition of island grammars and related terms, with references to papers. [DEFERRED]
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Things to mention/ask

• Prompto platform: Designed for usage in the cloud, has its own programming language that can be written in 3 different dialects

Meeting

• Meeting recap scheduled

Preparation

• Begin writing document detailing each variability point.
• Look at Clafer to visualize the variability model, and to look at where it falls within this model itself.
• Look at various languages to classify them in our variability model.
• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc. [DEFERRED]
• Try and get a concrete definition of island grammars and related terms, with references to papers. [DEFERRED]
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Meeting

• Meeting recap scheduled

Preparation

• Refine and extend variability model and write examples.
• Create feature diagram.
• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc. [DEFERRED]
• Try and get a concrete definition of island grammars and related terms, with references to papers. [DEFERRED]
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Meeting

• [0:00:00] Intro: Progress update
• [0:03:40] [H] Caution for progress speed.
• [0:04:00] [H] Study progress monitoring.
• [0:07:57] [H] [@] Need to contact Mariska before next meeting about study progress.
• [0:09:02] [H] Talk about planning in Google Calendar & meeting notes.
• [0:12:59] [M] Progress: Detailed meeting notes from last meeting.
  • [0:14:25] [H] Important to filter these into background information & actionable information ([@]) that leads to further work.
  • [0:17:19] [H] [@] Go through last meeting notes and highlight the actionable information there as well
  • [0:19:11] [H] Example of background information from last week's update on the Modelverse
• [0:21:42] [H] Progress on/changes to variations
  • [0:22:18] [M] Comparison with PHP: No changes and still not very clear how to define this
  • [0:26:04] [H] [@] Try to write each variation down in a LaTeX report, including examples and all thoughts related to them. -> Start of the final report
• [0:27:51] [M] Variations need proper categorisation.
  • [0:28:41] [H] Similar to feature models.
  • [0:29:20] [H] Clafer
  • [0:29:34] [H] Different approaches to looking at feature models. Tree based models are usually for toy or small feature models.
  • [0:31:32] [H] Feature matrix
  • [0:32:29] [H] Feature tree problems: unusable for big trees, some constraints are not modelled visually
  • [0:35:27] [H] Semantics of a feature model is a product family (collection of products) (extension) that satisfy the constraint definition (intension)
  • [0:36:10] [H] Historically product families grew from configuration options in software like the Linux kernel
  • [0:37:28] [H] Clafer can generate feature matrixes from a model specification
  • [0:37:53] [H] Could make feature matrixes manually, but this could turn into a very big collection
  • [0:39:07] [H] Joeri: Used Clafer for his thesis on statecharts -> 52 million possible combinations -> Needed more constraints to filter nonsensical combinations
  • [0:39:54] [H] Simon: also did this for his doctorate
  • [0:40:00] [H] Useful to think back to feature models if you need to think of or pick a set of options
  • [0:40:19] [H] Classification of language features in Simon's PhD thesis
  • [0:44:38] [H] [@] Look at Clafer to create a feature model
• [0:49:34] [M] Overview of changes to variations
  • [0:49:48] [M] Replaced some examples with custom/simpler languages: only indentation & braces so far.
  • [0:51:25] [H] [@] Can look at existing languages and attempt to fill them into the feature model to see where they fit in.
  • [0:52:28] [H] [@] When combining features, make own languages as examples.
  • [0:52:53] [H] Important: Clearly state in report the examples of individual features, of combinations, and reason which combinations can and which cannot exist -> End up with a feature model of all possible meaningful combinations.
  • [0:54:00] [H] Simon looked at features of each language, and at how those languages get processed.
  • [0:54:21] [H] Here we have the same: TODO: Need clarification: "eenerzijds: hoe zit het in elkaar in die taal? Anderzijds (wat de definitie is): hoe wordt de parser beschreven?"
  • [0:54:46] [H] Can use Simon's feature models as inspiration (figure 4.2, page 72)
  • [0:55:05] [H] "Eating your own dogfood": Use Clafer to describe feature model, and then try to look at where Clafer ends up in that feature model.
• [0:56:39] [M] Continue overview of changes
  • [0:56:39] [M] Slightly modified python example for statement ends by EOL
  • [0:57:10] [M] Comment styles based on paper by Dennie Van Tassel
  • [0:58:34] [M] XML mega comments are "marked sections"
  • [0:59:57] [M] XML declarations <! conflict with example syntax used here
  • [1:00:28] [M] Suggestion to use « guillemets »
  • [1:01:21] [H] Try to be unicode compatible, but try to stay backwards compatible with 7-bit ASCII for languages that only support 7-bit ASCII
  • [1:05:04] [H] Guillemets aren't part of 7-bit ASCII, will try to stay within that range
  • [1:05:15] [H] [@] Possible design criteria: supports 7-bit ASCII, 8-bit ASCII, or full unicode. Problem is mostly about fragment change characters
  • [1:06:38] [H] [@] Example language 1 that is 7-bit ASCII, language 2 that is 7-bit ASCII -> Can our language change character be full unicode?
  • [1:07:11] [M] [@] Difference between supported character encodings & supported characters? Need to decide on whether to split this up into 2 variability points
  • [1:12:53] [H] BOM = Byte Order Mark
• [1:18:34] [M] Rough feature model specification for inputting into Clafer.
• [1:19:25] [H] [@] Repeat: start with writing report.
• [1:20:07] [M] Overview of meeting notes for this meeting.
• [1:23:20] [H] "Eat your own dogfood": "Practice what you preach"
  • [1:25:47] [H] MetaEdit+ is not bootstrapped: written in code only -> Not dogfooding

Preparation

• Refine and extend variability model and write examples.
• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc. [DEFERRED]
• Try and get a concrete definition of island grammars and related terms, with references to papers. [DEFERRED]
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Meeting

• [0:00:25] [M] Intro: overview of new variations added/changed
  • [0:01:03] [M] Renamed 3' to 4 (and shifted the ones following by 1)
  • [0:03:01] [M] PEGs do not have a lexer step
  • [0:05:13] [M] Indentation important vs braces
  • [0:07:15] [M] Section based (vs indentation & braces)
  • [0:08:25] [H] Link to Language Server Protocol -> Start looking at LSP again soon
• [0:10:45] [H] Update on the Modelverse
  • [0:11:23] [H] Aposteriori typing: No longer instantiating models based on a meta-model, but making arbitrary models and then checking conformance instead.
  • [0:12:43] [H] Andrei: finished their research internship, rewrote (part of) the Modelverse Kernel
  • [0:13:02] [H] Joeri Exelmans: working with draw.io to make a visual editor
  • [0:13:24] [H] Andrei: implemented aposteriori type-checking, conformance checking, meta-modelling, graph transformations
  • [0:13:40] [H] Neutral Action Language
  • [0:14:04] [H] Modelverse currently allows multiple clients, but isn't really built for this
  • [0:14:31] [H] Joeri next step: making Modelverse multi-view (2021-02-12 H: multi-view means having multiple views/windows on the same model, some with visual syntax, some with textual syntax = poor man's approach to blended textual-visual modelling)
• [0:15:29] [M] Continue overview of variations added/changed
  • [0:15:38] [M] Statement ends
  • [0:17:16] [M] Python: compound statements (list of statements separated by semicolon, treated as one block)
  • [0:20:22] [M] Fragment ordering/scope binding
  • [0:21:25] [H] Scope of variables Java vs. C
  • [0:24:18] [H] [@] MSL-USER: Sequence of statements vs. collection of "statements"/equations (linear system)
  • [0:26:05] [H] [@] Distinction between scope width & sequential vs "set"
  • [0:27:30] [M] Question: does the grammar definition have to come before usage, or can it come afterwards? -> Due to unknown island syntax the answer to this right now is: yes it has to come first.
  • [0:30:40] [H] Given a declaration & specification of a grammar, where is it visible and where can we use it? -> From moment of specification until end of scope, or in the whole scope it is defined in?
  • [0:31:55] [H] For grammars this isn't as easy, because fragment syntax definitions (grammar change tokens) are important for parsing a fragment.
  • [0:35:52] [M] Old idea: allow specifying the start and end token ahead of time.
  • [0:39:34] [M] Comparison of parsing to something "pipeline"-ish -> not pipeline, but multi-step approach
  • [0:51:53] [M] Comparision with PHP which has islands of code, but was hard to describe -> skipped
  • [0:53:44] [M] Parser options (indentation, ...): allow mid-parse change?
  • [0:54:53] [H] [@] High-level requirement: try to be as non-intrusive as possible -> try to change the grammar of a language as little as possible (or not at all!)
  • [0:56:25] [H] When glueing languages together, we don't count this is changing the grammar of a language for the purpose of trying to change as little as possible
  • [0:57:21] [H] Comparison of science vs. engineering: What are the high-level requirements?
  • [0:57:44] [H] Comments in programming languages: least intrusive way, but most languages do not support nested comments, which gives problems with nested fragments.
  • [1:08:22] [H] [@] For each article and webpage, keep a copy & a biblatex reference & a short abstract.
• [1:10:23] [H] End of meeting
  • [1:10:30] [M] Also worked on abstract syntax, but still work in progress so skipped for now
  • [1:10:52] [H] [@] Next steps: complete features, make feature diagram, write parser for each example, try to combine parsers

Preparation

• Look at notational variance of languages and try to get a variability model.
• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc. [DEFERRED]
• Try and get a concrete definition of island grammars and related terms, with references to papers. [DEFERRED]
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Meeting

• Meeting recap scheduled

Preparation

• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc. [DEFERRED]
• Try and get a concrete definition of island grammars and related terms, with references to papers. [DEFERRED]
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Things to mention/ask

• Zope: outdated, causing consistent rendering issues (though may be partially hardware related)
• Preference: PEG or LR? Discuss advantages/drawbacks

Meeting

• Meeting recap scheduled

Preparation

• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc.
• Try and get a concrete definition of island grammars and related terms, with references to papers.
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Things to mention/ask

• Possibly interesting paper: Practical scope recovery using bridge parsing by Nilsson-Nyman et al. Paper itself is not available online for free, but presentation is.
• Possibly interesting book: Semantic Structures by Jackendoff. Not available online for free

Meeting

• Meeting recap scheduled

Preparation

• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc.
• Try and get a concrete definition of island grammars and related terms, with references to papers.
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Create textual example from meeting of 27-11-2020 whiteboard drawing.
• Create graphical abstract syntax definition of what the parsed languages would potentially look like (PlantUML?)
• Read "MontiCore: a framework for compositional development of domain specific languages" and try out MontiCore itself. [DEFERRED]

Things to mention/ask

• None yet

Meeting

• [0:01:00] [M] Intro: Created partial textual version of diagram from 2020-11-27 (without grammar definition (2))
  • [0:01:27] [H] MontiCore: Comparison with diagram -> MontiCore is more limited with languages.
  • [0:01:58] [H] MontiCore has a syntax for defining class diagrams with state charts. Our goal is to have state charts being a separate formalism from class diagrams.
  • [0:02:28] [H] Explanation of wanting to combine 2 formalisms, needs combining of concrete syntax (parses to abstract syntax), abstract syntax (gets pretty printed to concrete syntax), and semantics (semantic mapping: operational or denotational).
  • [0:03:29] [H] First combine abstract syntax, then conrete syntax and relations between conrete syntax (semantics are out of scope for this project).
  • [0:03:48] [H] Based off of grammar of language 1 & language 2, get combined language grammar.
  • [0:04:06] [H] Many possible combinations: weave 2 grammars into a big one; parse 1 grammar, then switch to another, and then to another; etc. -> Operational question: relates to incrementality.
  • [0:05:57] [H] Purpose of diagram: show an example of a model (not grammar) that is made up of pieces of other languages, and then try to describe the grammar for this model. Can we make this modular?
  • [0:06:29] [H] -> Bottom up approach: start from concrete example of mixed language model.
• [0:07:00] [M] First thing I did: look at combined abstract syntax of combination of automaton, action language and causal block diagrams.
  • [0:07:53] [M] Automaton transition guard vs. action: guard semantically needs to determine if a transition is allowed or not, while an action can arbitrarily do anything. -> Expression vs. statement (list).
  • [0:09:41] [H] Workflow: at the meta level describe what constructs you want, then build some examples which you learn from, and so on.
  • [0:10:10] [M] Symbols for indicating start and end of islands: $$$CBD$ ... $$. Brainstorming: <![CDATA[ ... ]]>; <?php ... ?>; <html> ... </html>; <!CBD> ... <!/CBD>
  • [0:12:58] [H] Whatever syntax you use, there will always be some context where our syntax for changing languages already has a meaning in some language.
  • [0:14:12] [M] Need to be careful of nested islands, end tag may be recognized sooner than is intended.
  • [0:14:42] [H] Nested scopes/name binding: referring to names from outer scopes. Important for semantics, not for parsing. (2021-01-25 M: may be important for dynamically selecting a grammar in a nested island.)
  • [0:19:10] [H] Further work on example, then try to make a parser for it.
• [0:19:20] [M] Pre meeting notes.
• [0:19:35] [M] Syntax for attaching automaton to class: 2 examples (attachment vs containment)
  • [0:20:53] [H] Class diagrams (classes, attributes, associations) vs object diagrams (class instances, slots for each attribute with value, links). Object diagram needs to comform to class diagram.
  • [0:21:51] [H] Drawing indicates that for each instance of class C has an instance of the automaton attached to it.
  • [0:22:26] [M] How to decide the on the concrete syntax for this relation between class C and the automaton? For visual language this is easier than a textual language.
  • [0:23:15] [H] Textual language is linear/sequential, rather than a graph. Need a notion of labels.
  • [0:23:39] [H] Piggyback on class diagram association: add special association that connects a class to an automaton. -> Very specific to the class diagrams formalism, requires changing the meta-model of class diagrams.
  • [0:24:39] [H] Question: how to specify association between class C and class D in this example?
  • [0:25:12] [M] Look at UMPLE syntax: uses isA for inheritance; for other relations use 1 -- * for example.
  • [0:30:09] [H] UMPLE syntax: unexpected that associations are only declared on one side of the association. Target of association doesn't know it is connected to the source via an association. -> Use more verbose notation.
  • [0:31:26] [H] Navigability: from division get employees, but can't get division from employee -> one-way navigability.
  • [0:31:46] [H] Put navigability information and other information in association: less readable and further from programming, but more declarative.
• [0:34:45] [M] Special syntax for comments
  • [0:35:19] [H] Do not ignore or trash comments, simply connect to object.
  • [0:36:20] [H] Could for example have an automaton as a comment.
• [0:38:15] [H] Don't think too much about usability for future work. This is an iterative process and can be built on or reworked. Our goal is to specify the abstract syntax (and in the future semantics), concrete syntax is for domain experts.
• [0:41:49] [H] Question about example text document: why start with $$$ and end with $$?
  • [0:41:53] [M] Reasoning is to prevent reading a start when wanting an end if they used the same character sequence.
• [0:44:16] [H] Insideness/containment: lexical scope, referencing symbols in outer scope?
• [0:46:45] [H] We want a way to describe connections within each scope of any language with its own language. This may not necessarily be in a unique way, and as such each grammar may need this to be added. There may not be a single syntax for connectivity.
• [0:49:12] [H] Need 3 concepts for each formalism:
  1. Need to be able to say there is a nested language.
  2. We need to be able to label anything.
  3. We need to be able to add connections between labels (either normal labels (e.g. automaton states) or on islands.
• [0:51:00] [M] Question: Is the goal to support any language? Answer: Yes
  • [0:54:00] [H] Treat it more like RAMification. Take existing language and instead augment its grammar to support our 3 concepts without interferring with other parts. e.g. CBD -> CBD++.
  • [0:56:30] [H] Given a language that is not under our control and has their own grammar, we would need to invent the augmented ++ version that does not conflict with the original grammar to implement these 3 concepts. This for each language we want to use.
  • [1:01:09] [H] Possible problem: Automaton guards already had a syntax (or maybe didn't exist at all!), and we needed to add or modify it to support islands.
  • [1:03:55] [H] Afterwards ask Vadim Zaytsev about his opinion on what we're doing afterwards.
• [1:08:14] [H] Return to original problem: classification of tools, based on the example we've written with multiple grammars.
• [1:08:58] [H] Language Server Protocol: how would this work with it?

Preparation

• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc.
• Try and get a concrete definition of island grammars and related terms, with references to papers.
• Try the same for code completion, and other points of comparison. This to make our classification more specific. [DEFERRED]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Continue writing and updating the list of tools and frameworks.
• Create textual example from previous meeting whiteboard drawing. [DEFERRED]

Meeting

• Look at hybrid languages and the definition of abstract and concrete syntax, and of the semantics (which is out of scope for this).

Preparation

• Read up on island grammars and terms associated with them: lakes, reefs, bridges, etc.
• Try and get a concrete definition of island grammars and related terms, with references to papers.
• Try the same for code completion, and other points of comparison. This to make our classification more specific.
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Continue writing and updating the list of tools and frameworks.

Scheduled

• Talk about modular language engineering & hybrid languages. For example state machines, etc.
  • Reason for this is question about semantics of islands in models.

Meeting

• Idea: Make a drawing to show the distinction between land and water, or islands and lakes
• Make a small example text file based on the whiteboard drawing showing a visual model. (See also UMPLE syntax)
• Write the grammar for this example.
• This is only for syntactical purposes, semantics are out of scope.

Preparation

• Await helpdesk reply for recording meetings. [DONE 16-11-2020: Recording should be available]
• Contact Mariska Hendrickx about study programme. [DEFERRED]
• Migrate thesis notes repository from GitHub to Gogs. [DONE 16-11-2020]
• Continue writing and updating the list of tools and frameworks.

Meeting

• Using Google Calendar for scheduling tasks: seems to be improving productivity
• Meeting recordings: video is encoded with the H264 codec at 1920x1080. When screen sharing is turned off the whole screen shows just both participants.
• Reminder to use unique terminology for each concept.
• Store a glossary of used terminology in each paper. An online version is now available here.
• For each paper I consult or read, do the following:
  • Save the paper with usable filename (for example date, author, title, contents, etc.)
  • Make a BibTeX reference and check if it renders correctly in LaTeX.
  • Save where I found the paper.
  • Make a short synopsis of the paper. Could be the abstract of the paper. Should contain the important pieces of information: important techniques, pitfalls, related work, etc.

Preparation

• Contact Helpdesk to activate recording meetings. [SENT 06-11-2020: Awaiting reply]
• Continue writing and updating the text detailing everything I've tried. (reference)

Meeting

• Suggestions:
  • Prepare tasks: write what I should do to perform
  • After each task, also write down the steps I took to do them
  • Make a schedule using Google Calendar or Google Tasks

Preparation

• Continue writing and updating the text detailing everything I've tried. (reference) [PROGRESSED SLIGHTLY]
• Further implement Option A. (reference) [DONE: Connects to Modelverse, but does not detect changes as this capability is missing from the Modelverse itself]
• Implement a small LSP server. Also implement either a client, or try to use an existing editor as client. [DEFERRED]
• Possibly look at IntelliJ/Atom to implement in instead, but this would mean leaving Spoofax. [DEFERRED]
  • In this context, maybe look at Eclipse Epsilon?
• Read Generating Diagram Editors with DiaGen by Mark Minas. [DEFERRED]
• Look at Flexmi from Eclipse Epsilon. [DEFERRED]

Things to mention/ask

• How would we get back what was changed from the Modelverse? What messages would be sent, and what would be sent with them?
  For example in a Simple Class Diagrams model, a process (either a program in the Modelverse itself, or an editor on a different system/from another user) makes a change to this model. A list of examples (corresponding to CRUD operations, without R):
  • A new instance of Class is added with/without a name, and with/without inheritance
  • A Class instance gets a new Attribute added
  • A Class instance gets renamed
  • An Attribute instance gets renamed
  • A Class instance gets removed
  • An Attribute instance gets removed
  It is also important that these changes are returned in order, as it would make no sense for the receiver to add an attribute to a class that hasn't been declared yet, or has already been removed.
  RESPONSE: Currently not possible, put this part on the backburner for now and focus on other areas. More in-depth: Currently the Modelverse is not autonomous and does not change models of its own accord, and it doesn't have to be (but can be). However it should be multi-view, allowing multiple users to access it and modify concurrently, and users should be able to see if any changes were done.
• Feedback on DSL tool requirements/cases: what criteria could be added or would be important?

Meeting

• Put Modelverse pushing notifications to clients on the backburner.
• Island Grammar criterion:
  • Must not be just a blob of text, islands need to be verified if they are grammatically correct with respect to the island grammar.
  • Island could be decided either implicitly (for example $$ ..fragment.. $$) by the parser based on the context, or explicitly (for example $$class_diagram$ ..fragment.. $$)
  • Make distinction of explicit grammar by specifying it at parse time (for example $$class_diagram$) or at runtime (for example $$#languageId$, $$#"class_diagram"$)
    • This is related to incremental parsing, but is not the same. Deciding the language at runtime requires partially executing or processing the containing model.
• Some criteria are fuzzy. Having "yes/no" questions are preferable because they are more exact. We want to avoid writing "we think that this is good" or "we think that this is bad" as it turns into preference/opinion rather than facts.
• Some extra criteria to look at:
  • How well documented is the tool? Are there many examples available?
  • What is the learning curve of the tool? How long did it take me to implement my system? This requires keeping track of how much time I spend.
  • How easy is it to install?
  • Is support available/what support is available? Can you go somewhere to ask questions if you have problems?
  • Is the tool still actively developed? Is it "done"? Or is it abandoned?
  • Does it support syntax highlighting? Tab completion?
  • Does it support transforming a model? What sort of transformations does it support? Graph, tree, or string replacement?
  • Does it support custom error messages, or informative error messages while parsing?
• When thinking about research/thesis, write down my thoughts so I don't forget them!

Preparation

• Attempt to contact Eelco Visser (reference) [CONTACTED: Invited to public Slack group]
• Continue writing and updating the text detailing everything I've tried. (reference) [PROGRESSED SLIGHTLY]
• Further implement Option A. (reference) [DEFERRED]
• Implement a small LSP server. Also implement either a client, or try to use an existing editor as client. [DEFERRED]
• Possibly look at IntelliJ/Atom to implement in instead, but this would mean leaving Spoofax. [DEFERRED]
  • In this context, maybe look at Eclipse Epsilon?
• Read Generating Diagram Editors with DiaGen by Mark Minas. [DEFERRED]
• Look at Flexmi from Eclipse Epsilon. [DEFERRED]

Meeting

• Small progress update

Preparation

• Contact Spoofax developers to see if Option B can be implemented or if they have something similarly implemented already. [IN PROGRESS: contact details dead, attempting to contact via github issues]
• Otherwise, try to make an application that implements Option A instead. [PARTIAL DONE: Connects to Modelverse and displays a GUI, but does not detect changes yet]
• Possibly look at IntelliJ/Atom to implement in instead, but this would mean leaving Spoofax. [DEFERRED]
  • In this context, maybe look at Eclipse Epsilon?
• Read Generating Diagram Editors with DiaGen by Mark Minas. [DEFERRED]
• Continue writing and updating the text detailing everything I've tried. (reference)
• Read An LSP infrastructure to build EMF language servers for Web-deployable model editors. [DONE]
  • Paper is recent, but more recently it appears the different initiatives already trying to implement a graphical LSP have been merged (or have parts taken from each other) and condensed into Eclipse GLSP
  • A more in-depth version of the paper can be found here (archive link)
• Look at Flexmi from Eclipse Epsilon. [DEFERRED]

Meeting

• Clarification on how to get changes to models in the Modelverse back to Spoofax:
  To keep language models consistent with their specification, transformations should be used on the Spoofax side. However this leaves the problem on how to determine what transformations Spoofax should perform on its local representation of a model, if an arbitrary transformation has happened in the Modelverse.
  
  The solution (as I understood it) is to require that we specify each operation on the Modelverse and the equivalent operation in Spoofax (think CRUD operations). This is however not trivial to do, and the Modelverse currently does not support this.
  
  Eventually, the Modelverse will need to be adapted to accommodate for this use case, but each editor talking with the Modelverse will need to be adapted for this as well.

Preparation

• Contact Spoofax developers to see if Option B can be implemented or if they have something similarly implemented already. [DEFERRED]
• Otherwise, try to make an application that implements Option A instead. [DEFERRED]
• Possibly look at IntelliJ/Atom to implement in instead, but this would mean leaving Spoofax. [DEFERRED]
  • In this context, maybe look at Eclipse Epsilon?
• Prepare some text containing everything tried so far, the issues with implementing it with each tool
• Put meeting notes online (hello!) [DONE]
• Read Generating Diagram Editors with DiaGen by Mark Minas. [DEFERRED]

Things to mention

• Language Server Protocol is a protocol supported/implemented by Xtext, with a plugin for Atom and IntelliJ IDEA. It allows for reusing features by different IDEs to prevent each of them having to implement it themselves.

Meeting

• Note to be careful about wording of positive vs. negative, and to make sure opinion doesn't sneak in.
• When writing something, it needs to be supported by evidence.

• Discussion on how to get changes to a model added via Spoofax to the Modelverse back to Spoofax. This would work using the observer pattern, with Spoofax being an observer and the Modelverse being the subject.
  • Option A: Using a separate application as observer, which will then display a message to the user telling them to get updates. This would be used if the IDE does not support an integrated approach (option B).
  • Option B: The IDE itself becomes the observer and updates the displayed model when the model changes.
• Try to look at existing IDEs that allow adding plugins and see if it's possible to extend them instead. For example IntelliJ IDEA, Atom.

Meeting

• Mostly a reminder about the previous meeting due to lost notes.