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 input and 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]

It may be INPUT to access and use types in oper. sign. bodies.

[h3rald]

I was thinking of:

• calling it inputs (I double checked in English and it's allowed to be plural in this case)
• checking the type signature and forbid inputs as a capturing input symbol.

Even if you defined inputs elsewhere in your program, the one set inside the operator body will shadow the other definition because it's in the current scope. I'll probably seal it as well so you don't overwrite it by accident.

[ghost]

I'll probably seal it as well so you don't overwrite it by accident.

Will symbol unsealing be able also for inputs symbol?

Unsealing inputs symbol should warn us about shadowing.

[h3rald]

Sure... unsealing is always allowed, on anything... it is assumed though that if you unseal you know what you are doing! 😉 use at your own risk...

[ghost]

Sure... unsealing is always allowed, on anything... it is assumed though that if you unseal you know what you are doing! 😉 use at your own risk...

Yep! ... Documentation would help here. What do you think of introducing inputs symbol via help?

I have good feelings about that inputs symbol 👍

unsealing is always allowed, on anything...

Another question for you:

Redefining sealed symbols after unsealing them may break the code. User may want to prevent this. How could it be done?

[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 ♻️ .