Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cond and struct — where in the chain? #1

Open
1 task
badlydrawnrob opened this issue Aug 15, 2019 · 1 comment
Open
1 task

Cond and struct — where in the chain? #1

badlydrawnrob opened this issue Aug 15, 2019 · 1 comment

Comments

@badlydrawnrob
Copy link
Owner

badlydrawnrob commented Aug 15, 2019

This problem is visually complex. I can't understand it at a glance without getting back into the original HTDP lesson and problem. It's probably simple if looked at in a different way?

  • Sketching in different ways (like a tree diagram) page 169
; A VAnimal is either
; – a VCat
; – a VCham

Struggling a bit on best practice with conditional ... understand the goal is to reduce repetition, but each route seems to have it's pros/cons:

  1. My attempt (below)
    • For each (cond ...) pass to a separate function
    • Each condition has it's own conditionals, per Type (VCat/VCham)
  2. Another guys answer here
    • Create a (cond ..) expression once for each enumeration
    • Create an object instance (make-struct ...) once and only once for VCat/VCham

Both methods pass only raw data values to auxiliary functions.

; VAnimal KeyEvent -> VAnimal
; pet, or feed a VCat
; feed a VCham, change color
(define (commands a ke)
  (cond
    [(vcat? a) (vcat-commands a ke)]
    [(vcham? a) (vcham-commands a ke)]))                                  

; VCat KeyEvent -> VCat
; Check the key events
(define (vcat-commands c ke)
  (cond
    [(key=? ke "up")
     (make-vcat (vcat-pos c)
                (make-happy (vcat-happy c)))]   ; pet
    [(key=? ke "down")
     (make-vcat (vcat-pos c)
                (make-happy (vcat-happy c)))]   ; feed
    [else c]))                                  ; #!

; VCham KeyEvent -> VCham
; Check the key events
(define (vcham-commands c ke)
  (cond
    [(key=? ke "down")                          ; feed
     (make-vcham (vcham-pos c)
                 (make-happy (vcham-happy c))
                 (vcham-color c))] 
    [(key=? ke "r") (change-color c RED)]
    [(key=? ke "b") (change-color c BLUE)]
    [(key=? ke "g") (change-color c GREEN)]
    [else c]))                                  ; #!

A sketch of each "tree":

IMG_20190815_162932

More detail:

IMG_20190815_162917

@badlydrawnrob badlydrawnrob added the question Further information is requested label Aug 15, 2019
@badlydrawnrob
Copy link
Owner Author

badlydrawnrob commented Aug 18, 2019

State -> Auxiliary function(s) -> KeyEvent conditions -> smaller (raw data) functions

After watching this talk on simple made easy I'd hazard a guess that tree #v2 (or v1 in the mini-diagram) is the simpler route ...

  1. You're starting with the main state conditions
  2. You're creating the new struct once and only once
  3. All other functions are based on raw values (not calling struct attributes)
  4. The keyEvent conditions are split up as needed
  5. Extra auxiliary functions created as needed

Maybe I was thinking of it backwards (creating the key events, rather than the states first)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant