chore: split NadaType and NadaValue / refactoring

[Jmgr]

Fixes #
Design discussion issue (if applicable) #

Changes

Please provide a brief description of the changes here.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Backwards compatibility analysis completed (if applicable). "Will this change require recompilation and upload of user programs?"

[pablojhl]

I was taking a look at the PR and I'm confused. What is a NadaValue at the compiling level exactly? IMO NadaValue should exist only at the runtime level, right?

[Jmgr]

I was taking a look at the PR and I'm confused. What is a NadaValue at the compiling level exactly? IMO NadaValue should exist only at the runtime level, right?

In this context a NadaValue is what you would pass to Tuple.new for instance: PublicInteger or Array. A NadaType would be PublicIntegerType or ArrayType. The two are currently mixed in the code, which creates some confusion.

[pablojhl]

I was taking a look at the PR and I'm confused. What is a NadaValue at the compiling level exactly? IMO NadaValue should exist only at the runtime level, right?

In this context a NadaValue is what you would pass to Tuple.new for instance: PublicInteger or Array. A NadaType would be PublicIntegerType or ArrayType. The two are currently mixed in the code, which creates some confusion.

Maybe I am wrong, but IMO in this context you are not using a NadaValue. PublicInteger and Array are the types for the future values you will assign in the runtime and PublicIntegerType and ArrayType are the type definitions something like a metatype and they only live in Python because we need to get the type properties.

[pablojhl]

I was taking a look at the PR and I'm confused. What is a NadaValue at the compiling level exactly? IMO NadaValue should exist only at the runtime level, right?

In this context a NadaValue is what you would pass to Tuple.new for instance: PublicInteger or Array. A NadaType would be PublicIntegerType or ArrayType. The two are currently mixed in the code, which creates some confusion.

Maybe I am wrong, but IMO in this context you are not using a NadaValue. PublicInteger and Array are the types for the future values you will assign in the runtime and PublicIntegerType and ArrayType are the type definitions something like a metatype and they only live in Python because we need to get the type properties.

To clarify my worries. I worry that we introduce the term NadaValue in the dsl and that provokes a dependency between the MIR model and NadaValue in the future. In the end, we are introducing a soft dependency between the DSL and NadaValue. I would like to avoid any problems because of this in the future.

[Jmgr]

We can name them FutureNadaValue maybe, but it's a bit long. Yes we don't have the numerical value yet, but they still represent a value for me, compared to a type. In any case this is a draft and a WIP, so we might change the naming before putting the PR into review.

[Jmgr]

https://github.com/NillionNetwork/nillion/pull/2403 will need to be merged first.

[navasvarela]

This doesn't stop me from using this as a decorator, @create_nada_fn.

[Jmgr]

Is there a way to prevent that?