Updated specification #8
Loading…
Reference in New Issue
No description provided.
Delete Branch "updated"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This gathers discussion from the previous issues.
@lriesebos @sb10q: Can you have a look at this?
@LPTK: Please click the 'View File' button in the 'Files Changed' tab.
@pca006132 , I added a few questions.
@ -12,2 +8,2 @@
calling the interpreter many times during compilation if there are many
references to host variables)
## Referencing Host Variables from Kernel
Host variable to be accessed must be declared as `global` in the kernel
I am still confused what the idea is about the use of 'global'. Is this what you mean?
yes
@ -30,2 +29,4 @@
self.b = b
```
* Three types of instance variables: (Issue #5)
* Host only variables: Do not add type annotation for it in the class.
Would it still be possible to type host-only variables and class variables?
I did not think about that, maybe we can add some new syntax similar to ClassVar for host only variables?
Sounds a bit messy and would perhaps negate the advantages of host type annotations (e.g. third-party tools may not understand
ClassVar
and complain that the type annotation is incorrect).I propose not supporting host type annotations in kernel classes; anything that is annotated goes on the device.
We type practically everything in our DAX library, and I think it would be good to still allow typing of host code. Maybe you like one of these two ideas:
Allow host-only variable typing in methods or by using
Immutable[]
Make kernel-only variable typing special using
Kernel[]
and be fully compatible with regular Python typingThat option would be ok, but might need better names than
Kernel
(andImmutable
).Maybe
Kernel[]
/KernelImmutable[]
since the two annotations are similar. And we would use "kernel" terminology in nac3core.Yes, I think
Kernel[]
andKernelImmutable[]
is great and I like the fact that it is explicit!Yes, it is fine for me. Did you think about the syntax I mentioned in the screenshot? Using
Immutable(...)
instead ofImmutable[]
.I'm not entirely sure if we can let IDE understand
Immutable[T] == T
for completion and checking, but we can do that withImmutable(T)
. However, one caveat is that it would be harder to let users to define the type elsewhere and use it, as the information ofImmutable()
would be loss. Maybe we should have a look at how typing does it for other generics.Tbh, I do not think the IDE autocomplete feature should be leading this choice. And besides, IDE's understand that
ClassVar[T] == T
, so it would not surprise me if we can also make that happen forKernel[]
andKernelImmutable[]
. Brackets are the syntax used for typing in Python, so I would prefer we stick with that.To further motivate my point of view, type checkers such as mypy go totally bad when using parenthesis. See for example this error message for
TArray()
(ARTIQ 6):@pca006132 @sb10q did we now decide on the
Kernel[]
andKernelImmutable[]
annotations? It is not contained in this merge request.Sorry I forgot this one, this is two months ago :(.
I think
Kernel
is used for kernel only attributes, andKernelImmutable
is for kernel invariants right? CanKernelImmutable
be changed by the host? I think it is OK, or we can open another issue If we want further discussion about this.As per the discussion in #5, an attribute with
KernelImmutable
can be modified by the host, but only when no kernel is running. In particular, it cannot be modified inside a RPC call, and this would be enforced in the Python interpreter via the@kernel
decorator on the class.@ -32,0 +31,4 @@
* Three types of instance variables: (Issue #5)
* Host only variables: Do not add type annotation for it in the class.
* Kernel Invariants: Immutable in the kernel and in the host while the kernel
is executing. Type: `KernelInvariant(T)`. The types must be immutable.
Should we use brackets instead, just like used for all other typing?
KernelInvariant[T]
I think so.
Yes, I would fix this later.
@ -48,2 +46,2 @@
* Should we support function pointers? What about subtyping with function
pointers, and generic types?
* Function default parameters must be immutable.
* Function pointers are supported, and lambda expression is not supported
How do we expect to type function pointers, using the typing library? e.g.
Call[[int32, int32], int32]
Yes
@ -90,0 +93,4 @@
* Functions are all kernel only, including constructor.
Questions:
* Should we also do `@portable`?
Does this just refer to kernel-only classes or is this a general question?
@portable
is a decorator we use very often, so I would like to keep that.Yes, we definitely want
@portable
.Portable would be for testing the code in the host, similar to the use case of portable functions I guess.
Not just testing. One use case is converting between SI units (e.g. a floating point number in volts) and chip control words (e.g. integer values to program into a DAC). This allows 1. caching the latter and 2. determination of quantization errors.
Perhaps we should give it another name? Kernel only seems a poor naming choice, I chose it previously because the object is created and destroyed in the kernel, the host has no access to it. Actually this is just an ordinary object.
Or maybe we should call the object of type
EnvExperiment
something like experiment object? I'm not good at naming things...Kernel-only sounds fine to me.
EnvExperiment
is not specific to the core device (you can perfectly create an ARTIQ experiment with this class, that does not use the core device and the compiler at all) and I had also suggested to use a decorator instead of inheritance to have more possibilities to implement immutability.I've updated the explanation, but still I'm not entirely sure if the name should be kernel only class... It does sound weird when we allow it to be portable...
So if I understand it correctly now, a kernel-only class is a class decorated with
@kernel
or@portable
.@kernel
classes can only be used in kernels@portable
classes can be constructed in kernels and on the host. Besides, objects can be shared between the kernel and the hostRegarding the kernel-only name, I am fine with that.
Or maybe, have a single type of "kernel-capable" class, decorated with
@kernel
.That decorator simply registers the class with the compiler, and enforces
Immutable
in the interpreter. There are no restrictions on the type of methods (kernel, portable, rpc, host-only) that it contains.Ok great, then I guess I misunderstood the situation when read it and what we discussed in #5 is still valid. So to summarize:
This is exactly what I mean by kernel-only class.
This is different, I don't expect kernel-only class to contain host-only/rpc methods, and the semantic for kernel and portable functions are different. It would not be possible to call a method of a kernel object on the host if it is not portable.
I think the kernel-only object is just a simple object in our language, that can be fully-understood by the compiler, without dealing with the complicated stuff like RPC and host functions etc.
What is the advantage of kernel-only classes? We'd need to support classes that mix kernel, portable, rpc, and host-only methods anyway.
I agree with @sb10q that "mixed" classes are a must. Kernel-only classes could be interesting to allow construction of objects inside kernels, though tbh at this moment I do not have any use-case for that.
Objects that can be constructed inside kernels could have
__init__
decorated with@portable
or@kernel
. But I'm not sure if we want to support them anyway.If the object is stored in the kernel only, RPC would have to pass the object to the host and run the method. But that probably seems fine...
@pca006132 @sb10q also, I think the proposal in this tread makes sense, which would drop "kernel-only" classes. It is not contained in the current merge request. Should we still add this?
Yes, I think we can drop this, but we should make it explicit that users can create objects in the kernel if the constructor is
portable
orkernel
. And maybe we should also document the behavior for RPC when the object only exists on the kernel. What do you think?@pca006132 Sounds good.
@ -131,48 +137,6 @@ Questions:
* Would it be better to assert on the type variable directly instead of
`type(x)` for type guards?
Not sure what alternative you have in mind, but
if type(x) == int32:
is fine for me, see also #7 .Perhaps something like this:
but idk if this would be valid Python code, not yet tested.
It wouldn't work in the interpreter (at least, without hacks).
if type(x) == int32
is the interpreter-friendly way of doing it.@ -15,1 +14,3 @@
Only primitive types and tuple/list of primitive types are allowed.
Kernel cannot modify host variables, this would be checked by the compiler.
Value that can be observed by the kernel would be frozen once the kernel has
been compiled, subsequence modification within the host would not affect the
Ah, this would cause another problem like those in #5
But deleting globals or trying to make them immutable in the interpreter sounds messy, and a global being modified in a RPC seems to be a niche case.
So I'm ok with this current proposal, the behavior simply should be documented.
Yes, I was thinking about this either, but it seems like there is no easy way around this.
Why don't we force users to type globals used in kernels as
Invariant[]
? The semantics are the same, making it clear to the user how this global variable can be used in kernels.It cannot be enforced in the interpreter.
I understand, it would just potentially make it more clear to the user that the global variable is immutable in the kernel. But I am fine with either!
I think the types that we allow are basically immutable? Int, tuples, string, etc.
Even if they are decorated with
Invariant[T]
, the user can just re-assign them, so hard to enforce.For classes there are special
__getattr__
and__setattr__
methods that we can use to hack the interpreter and enforceKernelImmutable
restrictions.There is no equivalent for modules/globals.
Yes, @sb10q showed a POC for immutable instance variables in #5, and I agree this does not work for global variables.
For me, the reasoning was to type global variables as
KernelImmutable[]
because they are per definition kernel immutable. That would align their type annotation with instance variables. Though since we can not enforce that at runtime, globals will anyway be a special case that needs documentation. So as mentioned before, I am also fine with not typing itKernelImmutable[]
.I've found something interesting:
Nitpick but I would useImmutable
instead ofKernelInvariant
to keep nac3core generic and not tied to ARTIQ concepts.so should we merge this?
Yes