Typeclasses in Operator Signature Bodies & Generics Incld.

[ghost]

( symbol test
  ((char|int :t) :begin ...)
  (
    begin type :str-t ; It can be only `string` & `int`

    (str-t "char" ==) ; This doesn't work because typeclasses are for constraints not for a real type usage.
    (...)
    when

    (str-t "int" ==) ; This works when integer arguments given in.
    (...)
    when
  )
) ::

So when i gave an string argument as char argument to in, then it will control its argument type for constraint but don't gives its typeclass as type.

This causes a hardened conflicting:

...
(char|specialstr :t)
...

Did you look at above. These types where are in generic, a special form of string type. However they cannot be controlled from operator body because their input type of argument is string. Thereafter,

How can you get their typeclasses from generics?

[ghost]

Maybe params and returns quot that preserves types would be used in o. s. body. Look at #89

[h3rald]

Well, one way to verify if a value belongs to a certain type class you could... execute the type:char symbol within a try operator 😉

I agree that maybe saving the input values and the matched type makes sense, so it's tested only once. I like it!

I could expose two special symbols as you said (however I'd call them just input and output) that expose additional information about each value. So we could have something like this:

( symbol test
  ((char|int :t) :begin ...)
  (
    (*input/begin/typeclass "char" ==) 
    (...)
    when

    (*input/begin/typeclass "int" ==) 
    (...)
    when
  )
) ::

So basically input (and output, although less useful) is a dictionary containing:

• A dictionary of the declared input values, each of which contains:
  • A dictionary containing details about the specific value, such as:
  • typeclass -- The type class satisfied when the signature was processed
  • value -- The value of the input value
  • type -- The primitive type of the input value (e.g. "string" -- the same as typeclass for primitive types, so you could even check if a primitive type was used if type equals typeclass 😉)

Some of this information is already accessible through the captured variables, but in this way you could process it programmatically by iterating on the keys of inputand output, which could after all be useful in some cases.

Good idea, thanks!

P.S.: Actually output would be fully populated and checked after the body is executed, so... not very useful. Right? Does it make sense to even expose it?

[ghost]

value -- The value of the input value

That seems interesting. I wonder what can we will be able to do after implementing them to Min. Maybe more complex symbols... 🌻 But you say that we can also use values without accessing them from input dict, don't you?

Good idea, thanks!

You're welcome!

Right? Does it make sense to even expose it?

I don't know. You seem right of yours. But there may be an important example of output ... or... may not , i don't know really. If output is not so heavy feature for Min, then you should add it to Min. I don't want to face with problems again ♻️ .