Structs in drasil-gool/GProc

[B-rando1]

We had talked about adding structs to GProc, to enable it to have better Choices parity with GOOL. I think now might be a good time to start work on it. I'm running low on major issues to work on, and it seems like splitting up drasil-code should be easier to do once GProc is more fully-featured.

Design Decisions

• Our main definition of structs can be pretty simple. Structs need a name and a list of variables.
• We could think about building in a constructor, since a good number of languages support constructors for structs.
  • This might be a trap, though - even for languages that support constructors, the semantics are likely quite different, and we'd need to decide how to translate constructors for languages that don't support them. It likely wouldn't be as bad as our troubles converting class constructors to struct constructors, but it would still be tricky.
• Since structs don't have methods, we'd need to declare separate functions, which would not be tied to the structs themselves.
• In a lot of languages, structs are immutable, at least by default. My thinking is that we can start out assuming that they are immutable, and if that assumption is too strict, we can revisit it later.
• I think it makes the most sense to make structs GProc-only, and leave them out of GOOL. Not all OO languages have structs, and for those that do, it would mostly overcomplicate things to use them here.

Implementing Structs in drasil-gool shouldn't be too bad. We can take a lot of inspiration from classes, and I've worked with Julia's structs a lot already. From there, we can start integrating them into drasil-code. This will likely be a bigger challenge, but it will bring us a lot closer to being able to generate most of our examples in Julia.

[B-rando1]

I did a bit of a trial run, just to see what a good general direction would be for when it's the right time to continue on this. I got it to the point of generating struct definitions, but no further than that (instantiating, using, etc. wasn't implemented). My implementations were pretty rushed, but the types should mostly be on the right track so I'll share them here. Just note that there will be things that I don't see coming, so take this with a grain of salt.

CodeType.hs

• Add a StructName type to mirror ClassName
• Add Struct StructName to CodeType

InterfaceProc.hs

Here we need to add a lot of Struct-related typeclasses to mirror the Class-related typeclasses in InterfaceGOOL.hs. They'd need to be added to ProcProg. I did my best to remove/change things from the OO versions so that they make sense for structs. Here they are:

type SStruct a = FS (a (Struct a))

class (StateVarSym r) => StructSym r where
  type Struct r
  -- | Main external method for creating a struct.
  --   Input: variables
  buildStruct :: [SStateVar r] -> SStruct r
  -- | Creates an extra class.
  --   Inputs: struct name, the rest are the same as buildClass.
  extraStruct :: Label -> [SStateVar r] -> SStruct r

  docStruct :: String -> SStruct r -> SStruct r

type SStateVar a = FS (a (StateVar a))

class (VariableSym r) => StateVarSym r where
  type StateVar r
  stateVar :: SVariable r -> SStateVar r

class (TypeSym r) => ProcTypeSym r where
  struct :: StructName -> VSType r

class (ValueSym r, ProcTypeSym r) => ProcValueSym r

class (VariableSym r, ProcTypeSym r) => ProcVariableSym r where
  structVar       :: SVariable r -> SVariable r -> SVariable r

($->) :: (ProcVariableSym r) => SVariable r -> SVariable r -> SVariable r
infixl 9 $->
($->) = structVar

class (VariableValue r, ProcVariableSym r) => ProcVariableValue r

class (DeclStatement r, ProcVariableSym r) => ProcDeclStatement r where
  structDecDef    :: SVariable r -> r (Scope r) -> SValue r -> MSStatement r
  structDecNew    :: SVariable r -> r (Scope r) -> [SValue r] -> MSStatement r
  extStructDecNew :: Library -> SVariable r -> r (Scope r) -> [SValue r]
    -> MSStatement r

convTypeProc :: (ProcTypeSym r) => CodeType -> VSType r
convTypeProc (Struct n) = struct n
convTypeProc t = convType t

Notes:

• buildModule needs to take an extra argument: [SStruct r]. It's a list of structs included in the module.
  • A thought I just had - we could make it [(SStruct r, [SMethod r])] instead. This would allow us to interleave structs with functions that act on them, rather than having all the structs appear before all the functions.
• Currently structs are in FS, rather than a new StrS which would mirror CS. The reason for this is that none of the reasons for CS's existence seem to apply to structs.
• I'm not sure if we actually want the buildStruct function, which mirroring buildClass creates a struct with the same name as the module. The issue with that is that in Julia, structs cannot have the same name as the module they're in. So maybe it makes sense to have all structs require a name, which is what the extraStruct function does.

RendererClassesProc.hs

This also has a few typeclasses that we need. They'd need to be added to ProcRenderSym. Here are what I believe they should be:

class StateVarElim r where  
  stateVar :: r (IP.StateVar r) -> Doc

class (BlockCommentSym r) => RenderStruct r where
  intStruct :: Label -> [IP.SStateVar r] -> IP.SStruct r

  commentedStruct :: FS (r (BlockComment r)) -> IP.SStruct r -> IP.SStruct r

class StructElim r where
  struct' :: r (IP.Struct r) -> Doc

Hopefully this is still relevant when it's the time to start implementing structs 😅. Whether it's someone else who picks this up or if I get a chance to come back to it, I'd just encourage you to take your time. Try adding one typeclass at a time to ProcProg, and only add typeclasses to ProcRenderSym as is necessary. There'll be design decisions that come up, and don't be afraid to ask for input when they do.

[JacquesCarette]

Great experiment, thanks. Is there a branch on the repo that corresponds to this?

[B-rando1]

Actually there isn't one. My implementation was a bit rushed and not quite of the quality we would want in the real thing, and I figured that with no one maintaining it the branch would likely fall behind, so I discarded my changes. In hindsight maybe I should have kept that branch around...