Drasil Research Group Meeting, Wednesday July 3, 11am, ITB/225 + online

[JacquesCarette]

Thanks for your weekly updates @BilalM04 @B-rando1 @NoahCardoso . Efficiently done. If you could do the same on Friday 28th (here), that would we useful. I'll create an agenda when that becomes clearer.

[smiths]

@JacquesCarette you might want to add a discussion of creating a GitHub Organization that Drasil can be a member of. From what @BilalM04 said in #3811 this would allow contributors to create their own GitHub projects.

[B-rando1]

For my weekly summary:

Summary

I spent most of the week working on the Julia renderer. Progress is going well, and we can now generate Julia code for Projectile with most Unbundled options. As we discussed in #3811, I am hoping to have it working with Unmodular Bundled by Wednesday, so that we can take another look at classes in Julia and come to a better consensus about whether it's worthwhile.

• I also ran into some issues involving scope, and created an issue about it in Local scope in Julia #3821.

I also worked on #3809. That has been going well, and has been a fun side-project when I need a break from the main projects. I don't think there's anything there that we need to discuss.

Blockers/Discussion Points

• I'd like to discuss Design of procedural languages in GOOL #3792 some more. The team seems a bit divided over this at the moment, so I think it would be helpful to talk it out. Everyone is in favour of eventually adding struct support to GOOL and using those to generate the 'best' Julia code, but we don't have a consensus about classes. To summarize where I believe everyone is at (if I misrepresent you, feel free to correct me):

  • @balacij and @smiths have expressed that it would be nice to be able to generate as many current examples as possible in Julia, even if the code isn't perfectly idiomatic. They seem optimistic that converting classes to structs should be possible, and that the wrinkles we'll have to work out will be worth it.
  • @JacquesCarette has said that while the conversion from classes to structs seems logical, issues will continue coming up and we will end up needing too many hacks in order to make it work.
  • I definitely see both sides. I like the idea of translating classes to structs, as well as making the Julia renderer as compatible with existing Drasil as possible. I also wouldn't say I've run into anything so far that's a complete dealbreaker for making it work. At the same time, I have seen a good number of non-trivial issues spring up as I tried to make it work, such as Semantics of Constructors in GOOL #3752, Adding module name to method calls in procedural targets #3789, and Constants in Julia #3824. I'm good to keep going if that's what we want, but I also understand if we'd rather cut our losses.

  In Drasil Research Group Meeting, Monday, June 24, 3:30 pm, ITB/225 #3811 we decided that I should try to get Julia working with enough class functionality that we can generate a Bundled example. I think I should be able to have this done by our meeting, hopefully a bit before then. I'll keep you posted.

• If we have time, it may be helpful to quickly discuss Local scope in Julia #3821, particularly the implementation details involved with it. If we don't have time, we can continue discussing it asynchronously too.

Edit:

I got a version of Unmodular Bundled working in Julia. You can see generated Julia code for Unmodular Unbundled here, Modular Unbundled here, and Unmodular Bundled here. There were a few hacks I used to get it up and running, but for the most part it looks how I think it should. Do note, though, that just about any other set of Choices involving Bundled is not likely to work in Julia at this point.

[BilalM04]

Weekly Update

This week I solely focused on #3722, to get it up and running. I was able to generate mdBook SRSs for all of the examples, with working cross-file references. My work is detailed here, but I'll provide a summary below.

• Refactored how the sections are separated (more info in Generating an mdBook-based variant of the SRS - UPDATED #3823).
• Generated a SUMMARY.md file, which is used for the side panel in mdBook.
• Generated a book.toml config file, similar to how the CSS is currently generated.
• Generated a title page file (title.md)
• Separated into two new SRS formats: Markdown and mdBook (more info in Generating an mdBook-based variant of the SRS - UPDATED #3823 ).
• Got the cross-file references working for the mdBook format.
• Fixed minor issues in expression printing.
• Generated SRS for all examples. I roughly scanned over and ran all of them. They seem to all be working and rendering as desired.
• Created Generating an mdBook-based variant of the SRS - UPDATED #3823
  • Currently working on addressing @balacij's and @samm82's suggestions.

Next Steps / Agenda

The only thing left for mdBook generation is the rendering of assets. As it stands, assets must be located inside the src directory of the mdBook project. For this, I'll have to work with @balacij to figure out how to get the required assets into the src directory, then update the file paths in the generated Markdown. The next major task then becomes getting the mdBook SRSs hosted on the website.

Another topic of discussion is Markdown vs mdBook (detailed in #3823 (comment)). To summarize, I propose we have two new formats: Markdown and mdBook. The mdBook format generates a complete mdBook project. The Markdown format generates a single-page SRS that can be rendered directly in the GitHub repo.

[NoahCardoso]

For weekly update

• Fixed links in contributors guild Fix Drasil Contributor's Guide links #3819
• Created the chunk diagram in mermaid Mermaid-based Chunk Diagram #3822. As mentioned in the pr I think that mermaid would be something that we could generate but I do not think that we should replace the full draw.io diagram for a mermaid one. mermaid's interactivity is very limited (you can't zoom into the diagram in vs code which is bad for large diagrams). I do think mermaid looks cleaner and I like that it is integrated into GitHub.
• I also looked at plantuml. The syntax is basically the same as mermaid and it is more interactive.
• I cleaned up Switch some lists to Set from containers #3761 I think it should be ready to merge.
• I made a small pr for changing nomThick in glassbr.unitals for strict data Making Glassbr compatible with Strict Data #3818. I also have another change in unitals that I am going to wait to make a pr for.
• In glassbr.requirements there are a couple of bad infinite loops that I am working on for strict data.

Looking forward

• By the end of the day Jason and I will decide what to do about the uml diagrams and how we should proceed.
• I have a couple pr's open that should be good to merge regarding nomThick and sets. I would like to close them before the end of next week. I really want to close Add stan and weeder to our dev. workflow #3710.

---

[samm82]

Following up on my comment on the nomThick PR, I realized that "nominal thickness" might benefit from being defined as a data type, similarly to how I defined the element type in ChemCode:

I think that this could:

1. better define nominal thickness throughout GlassBR
2. start setting up infrastructure for ChemCode
3. potentially move us closer to our "little theories" dream? (What stood out to me is that nominal thickness is a subset of the reals, but it may not make sense to add two nominal thickness, so a theory extension of the reals might be a mistake here. However, if we define it correctly, we then have the potential to "enforce correctness"; for example in the same way that we can specify that int(2.4) = 2, we could also potentially specify something like nomThick(2.4) = 2.5).

This seems to open the can of worms that is "adding a more rigid type system to Drasil", which might be too much/not the direction we want to go at the moment, but I figured we could potentially discuss this instead of me making that decision or me wasting a whole bunch of time making a detailed issue. 😅

---

While looking through the issue tracker to see if anything related has been documented, I came across #1213 which is more about defining data structures; this could be related but doesn't really need to be done in parallel.

[smiths]

@samm82 I agree that nominal thickness is like the elements in the periodic table. The nominal thicknesses are like a label for a glass product that can be purchased. They don't make glass sheets in other thicknesses. There aren't many operations that I can think of that makes sense between two elements of this set. In GlassBR I don't think we calculate the nominal thickness, but use it as an input. I could imagine another program using the nominal thickness in the way you describe for rounding if it was part of an optimization problem finding the best thickness as a real, and then rounding to the thickness that can actually be purchased. A better approach might be to use integer programming for the optimization. 😄 I don't think a nominal thickness theory as an extension of the reals would be useful for us in GlassBR.

[B-rando1]

@smiths you were interested in our discussion on #3792, so I'll provide a summary:

• Classes in GOOL are designed to represent OO classes, and we want implementations of those classes to reflect classes in the generated languages (i.e., staying true to the semantics) instead of trying to 'hack' in a class system.
• Imperative languages have some similarities with how they structure their programs, but there are also enough differences that the conversion is less simple than it appears. As @JacquesCarette mentioned today, there are both stylistic and technical things that get in the way, and in the end it would be a lot of extra work to get the conversion working as it should. I've seen that the further we go with making structs work in procedural languages, the more of these hacks will show up. Just getting Projectile to work with a very specific set of Bundled choices required several hacks that would be quite difficult to do properly, and most sets of Choices result in problems that don't even have a hacky way of getting around.
• Instead of trying to reuse our classes and hack them in using structs and modules, we should create new patterns in drasil-code and new data-structures and procedural-language features to support those patterns in drasil-gool. This has two advantages: (1) it allows us to give GOOL all the information it needs in order to cleanly generate procedural code without any of the hacks we were looking at with translating classes; and (2) when we find cases where procedural patterns should deviate from OO patterns, drasil-code is much more suitable place to make those changes in drasil-gool.

For next steps, my plan is to get Julia working well with the current parts of GOOL that it should work with (all of the purely procedural parts), and after that start splitting up the syntax of GOOL into a Venn diagram of OO, Procedural, and both. @JacquesCarette recommended doing all of this in drasil-gool for now, and eventually refactoring it into a new directory in Drasil.

[JacquesCarette]

Note: as indicated above, I've now created DrasilOrg as an organization for Drasil. Once things settle, I can move the repo from my personal one to that org. In the meantime, I think people will already be able to create projects there.

[smiths]

@B-rando1 thank you for your summary. What you say makes sense. I can see from other discussions that you have already started the work you mentioned in the above comment.