arturo-lang / arturo

Simple, expressive & portable programming language for efficient scripting
http://arturo-lang.io
MIT License
713 stars 32 forks source link

[VM/values/comparison] how should we handle Dictionary values? #1153

Open github-actions[bot] opened 1 year ago

github-actions[bot] commented 1 year ago

[VM/values/comparison] how should we handle Dictionary values? right now, both < and > simply return false but is it even a normal idea to compare a Dictionary with something else, or another dictionary for that matter? How do other languages (e.g. Ruby, Python) handle this? If the final decision is to not support this, then we should throw an appropriate error message (e.g. "cannot compare Dictionary values"), along with an appropriate (new) error template at VM/errors see also: https://github.com/arturo-lang/arturo/pull/1139

https://github.com/arturo-lang/arturo/blob/269a723e23971f7c5ba310f6c3539852a6f016e3/src/vm/values/comparison.nim#L222

#  currently, `=` is supported but not `<` and `>`!
#  Since Complex values encapsulate a VComplex object (from values/custom/vcomplex)
#  the ideal implementation would be done there (adding a `>` and `<` operator to VComplex)
#  and then link the method here :-)
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: critical,bug,values,easy

# TODO(VM/values/comparison) add `<`/`>` support for Attribute values
#  currently, `=` is supported but not `<` and `>`!
#  the logic should be the same as with normal strings/words/etc
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: bug,values,easy

# TODO(VM/values/comparison) add `<`/`>` support for AttributeLabel values
#  currently, `=` is supported but not `<` and `>`!
#  the logic should be the same as with normal strings/words/etc
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: bug,values,easy

# TODO(VM/values/comparison) how should we handle Dictionary values?
#  right now, both `<` and `>` simply return false
#  but is it even a normal idea to compare a Dictionary with something else, or
#  another dictionary for that matter?
#  How do other languages (e.g. Ruby, Python) handle this?
#  If the final decision is to not support this, then we should throw an appropriate
#  error message (e.g. "cannot compare Dictionary values"), along with an appropriate
#  (new) error template at VM/errors
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: enhancement,values,error handling,open discussion

# TODO(VM/values/comparison) how should we handle Object values?
#  right now, Object make feature a custom `compare` method which is called an used
#  for the comparison. However, if there is no such method, we end up having the exact
#  same issues we have with Dictionaries. So, how is that to be dealt with?
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: enhancement,values,error handling,open discussion

# TODO(VM/values/comparison) add `<`/`>` support for Path values?
#  currently, `=` is supported but not `<` and `>`!
#  the logic should be the same as with blocks, as it's - internally -
#  technically the exact same thing.
#  But then again, it seems a bit weird as a notion. Any ideas?
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: bug,values,open discussion

# TODO(VM/values/comparison) add `<`/`>` support for PathLabel values?
#  currently, `=` is supported but not `<` and `>`!
#  the logic should be the same as with blocks, as it's - internally -
#  technically the exact same thing.
#  But then again, it seems a bit weird as a notion. Any ideas?
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: bug,values,open discussion

# TODO(VM/values/comparison) add `<`/`>` support for Regex values?
#  currently, `=` is supported but not `<` and `>`!
#  Another tricky one: the logic should be either the same as with strings,
#  or disallow comparison altogether and throw an error.
#  In the first case, since Regex values encapsulate a VRegex object (from values/custom/vregex)
#  the ideal implementation would be done there (adding a `>` and `<` operator to VRegex)
#  and then link the method here :-)
#  labels: bug,values,open discussion

# TODO(VM/values/comparison) add `<`/`>` support for Binary values
#  currently, `=` is supported but not `<` and `>`!
#  Preferrably, the implementation should go to values/custom/vbinary
#  and then integrate it here.
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: bug,values,easy

# TODO(VM/values/comparison) add `<`/`>` support for Range values
#  currently, `=` is supported but not `<` and `>`!
#  Preferrably, the implementation should go to values/custom/vrange
#  and then integrate it here.
#  The question is: when is range A smaller than range B? How do other
#  languages handle this?
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: bug,values,open discussion

# TODO(VM/values/comparison) add `<`/`>` support for Inline values?
#  currently, `=` is supported but not `<` and `>`!
#  since Inline values are pretty much identical to Block values - internally -
#  comparison operators should work for them in an identical fashion.
#  The question is: when is Inline A smaller than Inline B? How do other
#  languages handle this?
#  see also: https://github.com/arturo-lang/arturo/pull/1139
#  labels: bug,values,open discussion

# TODO(VM/values/comparison) Re-visit/test handling of Block comparisons
#  How do other languages (e.g. Python, Ruby, etc) handle comparisons between blocks/arrays?
#  Do they even support it? If so, how?
#  labels: enhancement,values,open discussion,unit-test

proc `<`*(x: Value, y: Value): bool {.inline.}=
    if x.kind in {Integer, Floating, Rational} and y.kind in {Integer, Floating, Rational}:
        if x.kind==Integer:

a654873c383e685c8b18a8652379468ee6f70901

stale[bot] commented 10 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 1 month ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.