Add a green check

[labbo-lab]

Add a built-in function to check if the given value is green or not.

greenCheck(green); //true
greenCheck("green"); //true
greenCheck("#00FF00"); //true
greenCheck("rgb(0,255,0)"); //true

greenCheck(red); //false
greenCheck(1); //false
greenCheck("blue"); //false
greenCheck("rgb(255,255,0)") //false

TODO:

• [x] List of every present and future way of describing the color green
• [ ] Truth table for every other color and it's distance from green, using false, maybe and true
• [ ] handle user colorblindness
• [x] research color spaces
• [ ] ~~remember how to code~~
• [ ] full color space list

[mitiko]

How would we handle greenCheck(blue + yellow)?

[labbo-lab]

How would we handle greenCheck(blue + yellow)?

Some sort of color mixing would need to be implemented, or just a truth table (This could get out of hand rather quickly though

[labbo-lab]

Python implementation for if #74 ever wants to implement this

(sorry if this is bad, its been a bit since i last used python so im a bit rusty, used to javascript now)

def checkGreen(i):
  if (isinstance(i, str) or callable(i)):
    if i == "green" or i == "rbg(0,255,0)" or i == "rbg(0, 255, 0)" or i == "0,255,0" or i == "0, 255, 0"  or i == "#00FF00" or i == "rbg(0,255,0)":
      return True;
    elif hasattr(i, "__name__"):
      if i.__name__ == "green" or i.__name__ == "Green":
        return True
  else:
    return False
  return False 

[MaxenceDC]

Wouldn't it make more sense as an external module/crate/library/package/whateveritscalledinthislang?

[labbo-lab]

Wouldn't it make more sense as an external module/crate/library/package/whateveritscalledinthislang?

It would be much more fitting as a built in function, since this is a rather commonly needed function

[MaxenceDC]

greenCheck(green); //true

what if I define the immutable const const const like that? :

const const const green = "rgb(255,255,0)"!

That would be rude, so I won't do that but someone else could... Also this function might aswell support HSL, RGBA and the bizillion+ different formats of color storing that exists ; so a better color interpretation algorithm might be needed instead of hard-checking the variable.

(By the way I'm not sure what the ; (not operator) stands for at the end of each line of your examples, did you intend to write ! instead?)

[MaxenceDC]

(oh and where do we draw the line between green and blue?)

[labbo-lab]

(oh and where do we draw the line between green and blue?)

Exactly on green, if the user wants to get a color close to green they would use checkApproxGreen()

[labbo-lab]

greenCheck(green); //true

what if I define the immutable const const const like that? :

const const const green = "rgb(255,255,0)"!

That would be rude, so I won't do that but someone else could... Also this function might aswell support HSL, RGBA and the bizillion+ different formats of color storing that exists ; so a better color interpretation algorithm might be needed instead of hard-checking the variable.

(By the way I'm not sure what the ; (not operator) stands for at the end of each line of your examples, did you intend to write ! instead?)

The check could go deeper, we may need to philosophically define green to avoid any edge cases

We're gonna need a large truth table, and the implementation was written in a DreamBerd competitor called "Pythom" or something so it uses a weird operator at the end of lines

[MaxenceDC]

checkApproxGreen()

Which returns a boolean being false, true or maybe based on how far it is from greenest green

[labbo-lab]

https://en.wikipedia.org/wiki/List_of_color_spaces_and_their_uses https://en.wikipedia.org/wiki/Category:Color_space

This may take a bit

[mitiko]

we should be inclusive to colorblind users, the compiler needs to check if the user is colorblind and if so only ever return maybe

However there is the rare case when a user turned colorblind in which case we must record the exact time so code executing before that would have it's regular behavior..

[MaxenceDC]

Wait, can you turn colorblind?

[labbo-lab]

we should be inclusive to colorblind users, the compiler needs to check if the user is colorblind and if so only ever return maybe

However there is the rare case when a user turned colorblind in which case we must record the exact time so code executing before that would have it's regular behavior..

todo: implement a way to interface with reality to check if user is colorblind and the exact time of the change.

[TodePond]

this is more complex than I first thought

[labbo-lab]

this is more complex than I first thought

This is just for the green specification, we still have to do all the other visible colors, along with invisible colors such as ultraviolet and infrared

[labbo-lab]

added a task list

[labbo-lab]

You know, there are times when I wish i was joking (I'm sure I missed plenty, and I still need to add all the variants for the color spaces)

greenList.csv

[k2d222]

we should be inclusive to colorblind users, the compiler needs to check if the user is colorblind and if so only ever return maybe

However there is the rare case when a user turned colorblind in which case we must record the exact time so code executing before that would have it's regular behavior..

There is definitely room for a race condition there, and very nasty compiler bugs!

Scenario: a compiler runs greenCheck: it tests user blindness, then computes function result. What if user turns blind between the test and the output?

[mitiko]

Oh, I thought we had that "atomic shield" thing that allows us to execute instructions in exactly 0 seconds:

• first the instructions are executed and the timing recorded
• next we travel back in time exactly this much time before the atomic execution is started
• we run the instructions back in time and they finish just when its result is needed - aka instantaneous

I guess that is pretty complex on its own, I shall open a new issue about it

Update: there's a wikipedia page on this: https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use

[omentic]

However there is the rare case when a user turned colorblind in which case we must record the exact time so code executing before that would have it's regular behavior..

Mmm, I think lifetime annotations can be leveraged for this purpose. The near-exclusive use of seconds always struck me as limiting. If we introduce binding to something other than static time units, ex. actual real-world life times, that would solve this problem as a result (simply bind to the retina, and write a destructor). It might introduce some other issues: undecidability? armageddon? idk

[k2d222]

Hmm that could be done but I think we are waaaayyyy too overcomplicating things here.

What I propose instead, is that we simply

• check the medical record of the user at runtime (which can easily be done through an API call),
• compute a probability of turning blind/color blind (or recovering sight/color vision, which we should not forget about),
• return maybe green in case the probability is above a threshold.