Drasil icon indicating copy to clipboard operation
Drasil copied to clipboard

GOOL Specification/Documentation

Open B-rando1 opened this issue 9 months ago • 2 comments

As I'll need to write GOOL code at some point for testing the new back end implementations I'm working on, I was wondering, do we have a specification/documentation for writing GOOL code? So far all I've been able to find is a list of keywords in this paper (page 3), and the class definitions in ClassInterface.hs.

That will probably be enough to go on, but proper documentation would also be helpful. I know that the language is a work in progress so it might make sense to leave the documentation until the language is where we want it to be, but it seems like a good long-term goal at least.

Or maybe there is documentation, and I just haven't looked hard enough 😄. If so, please let me know where I can find it!

B-rando1 avatar May 14 '24 14:05 B-rando1

Brooks' thesis might be helpful. Other than these, I'm not aware of anything else (or at least not remembering anything else right now).

balacij avatar May 14 '24 16:05 balacij

I'm not aware of any other documentation either, but another resource is the example GOOL programs in code/drasil-code/test. . I think I made an effort to cover most of GOOL's available syntax with the tests that I originally wrote, and I see more tests have been added since.

P.S. Happy to see someone working on GOOL, @B-rando1! My memory for it isn't what it once was, but I'm excited to see the updates, and I'll try to follow along and chime in on questions where I might have insight.

bmaclach avatar May 15 '24 03:05 bmaclach

Thanks @bmaclach! I found those tests yesterday afternoon, and they've already been super helpful 👍

@balacij should I leave this issue open as a reminder to add documentation when the time is right, or should I close it for now?

B-rando1 avatar May 15 '24 13:05 B-rando1

@B-rando1 the specific issue that you posted has been dealt with, so we can close this issue. We have a long history (unfortunately) of leaving issues open. Ideally issues should be something that can be closed in a short amount of time. Some of our issues are too vague and too large of a scope. We won't forget that we eventually need documentation for GOOL. When we are ready to do this task, hopefully we can decompose it into smaller tasks. :smile:

smiths avatar May 16 '24 03:05 smiths

Thanks for the clarification @smiths! I'll try to keep that in mind in the future.

B-rando1 avatar May 16 '24 13:05 B-rando1