Making Glassbr compatible with Strict Data

[NoahCardoso]

In glassbr.unitals the ConstrainedChunk nomThick is self-referential creating an infinite loop when used with strict data. To prevent this, I created a new function called nomThick' that gives the displayDblConstrntsAsSet function in nomThick the information it needs to properly display the nominal thickness constraints as a set.

[samm82]

Is there a specific reason this was the approach taken? displayDblConstrntsAsSet only needs a Quantity, so we shouldn't have to make a whole new ConstrainedChunk. How else does the Quantity portion of nomThick get used? Does it make sense to have a separate Quantity, or should this "helper" object be inlined?

[NoahCardoso]

I argee I think it looks better when inlined. I changed it to a QuantityDict since making it a ConstrainedChunk adds unnecessary information.

nomThick = cuc "nomThick" 
  (nounPhraseSent $ S "nominal thickness" +:+ displayDblConstrntsAsSet 
    `(mkQuant "nomThick" (nounPhraseSent $ S "nominal thickness") lT Rational Nothing Nothing)` nominalThicknesses)
  lT millimetre {-Discrete nominalThicknesses, but not implemented-} Rational 
  [{- TODO: add back constraint: enumc nominalThicknesses -}] $ exactDbl 8

[balacij]

Seeing this added here, I would imagine it should be removed from somewhere else, no? Does this result in code duplication?

[NoahCardoso]

I'm not sure what you are referring to, could you be more specific?

[samm82]

I think the underlying question is "is this information written anywhere else in our code base"?

A similar thought I had: the duplication of S "nominal thickness" and the use of the Nothings seems to suggest that this chunk could be built with a different constructor than cuc that builds it more "logically", but I'm not sure what other constructors are available.…

[samm82]

What I mean by this is that we are duplicating the arguments "nomThick", nounPhraseSent $ S "nominal thickness" +:+ x, lT, and Rational, which seems redundant. Are these defined anywhere else in the code that we could borrow from instead of redefining it (there may not be)? Looking at the constructors for ConstrainedChunk, it looks like they all require some "base" "chunk" to build off of (which is one argument for moving away from our "nested" infrastructure), so we might be stuck using cuc.

While investigating this, I noticed that the reason we have this "circular definition" is because we seem to be attempting to define it in terms of itself, instead of just actually giving it a definition, which prompted a potential agenda item for our next meeting. 👀

[JacquesCarette]

I agree that this "smells bad". Feels like the wrong constructor is being used.

[JacquesCarette]

I agree that this "smells bad". Feels like the wrong constructor is being used.

[balacij]

@NoahCardoso and I had a discussion just before 5pm on Friday, so the discussion didn't hit here yet, but we're going to look into removing the problematic part of the description entirely. Right now, the description of "t / nominal thickness" is "nominal thickness t \in {....}", which carries information about a constraint (i.e., #2655). So, it looks like we need to...

1. Add Set support to *Expr and Space
2. Add basic Set support to GOOL (@B-rando1 mentioned he can help us with this 🙂 )
3. Add back the constraint
4. Remove the constraint from the description

Then, we end up completely avoiding the issue by removing it's need for existence (i.e., ~ remembering to add in a feature).

[balacij]

Closing in favour of (new) work towards #2655.