Updated specification #8

pca006132 · 2021-04-11T23:41:08+08:00

pca006132 commented

2021-04-11 23:41:08 +08:00

This gathers discussion from the previous issues.

Updated details related to class instance variables.
Rewrote section about referencing host variables from kernel.
Updated limitation regarding default parameter, function pointers and integer type.
Removed section about dynamic dispatch, maybe deal with this later.
Added section about kernel only class, although not discussed anywhere.
Added a blank section about lifetime.

This gathers discussion from the previous issues. - Updated details related to class instance variables. - Rewrote section about referencing host variables from kernel. - Updated limitation regarding default parameter, function pointers and integer type. - Removed section about dynamic dispatch, maybe deal with this later. - Added section about kernel only class, although not discussed anywhere. - Added a blank section about lifetime.

pca006132 added 2 commits 2021-04-11 23:41:08 +08:00

updated according to discussions d82edd2753

- Updated details related to class instance variables.
- Rewrote section about referencing host variables from kernel.
- Updated limitation regarding default parameter, function pointers and
  integer type.
- Removed section about dynamic dispatch, maybe deal with this later.

added kernel only class 30dd6a1ac1

pca006132 commented

2021-04-11 23:43:38 +08:00

@lriesebos @sb10q: Can you have a look at this?

@LPTK: Please click the 'View File' button in the 'Files Changed' tab.

@lriesebos @sb10q: Can you have a look at this? @LPTK: Please click the 'View File' button in the 'Files Changed' tab.

lriesebos reviewed 2021-04-12 04:46:28 +08:00

lriesebos left a comment

@pca006132 , I added a few questions.

README.md

						
				@ -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

lriesebos commented

2021-04-12 04:19:36 +08:00

I am still confused what the idea is about the use of 'global'. Is this what you mean?

FOO = 0

@kernel
def correct() -> int:
    global FOO
    return FOO + 1
    
@kernel
def fail_without_global() -> int:
    return FOO + 2
    
@kernel
def fail_write() -> None:
    FOO += 1

I am still confused what the idea is about the use of 'global'. Is this what you mean? ```python FOO = 0 @kernel def correct() -> int: global FOO return FOO + 1 @kernel def fail_without_global() -> int: return FOO + 2 @kernel def fail_write() -> None: FOO += 1 ```

pca006132 commented

2021-04-12 15:24:53 +08:00

yes

pca006132 marked this conversation as resolved

README.md Outdated

						
				@ -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.

lriesebos commented

2021-04-12 04:30:45 +08:00

Would it still be possible to type host-only variables and class variables?

class Foo:
    a: int
    c: ClassVar[int]  # What will this mean?
    
    def __init__(self):
        self.a = 1  # Normal / kernel-only variable
        self.b: str = 'bar'  # Host-only variable, but still typed. Is this possible?

Would it still be possible to type host-only variables and class variables? ```python class Foo: a: int c: ClassVar[int] # What will this mean? def __init__(self): self.a = 1 # Normal / kernel-only variable self.b: str = 'bar' # Host-only variable, but still typed. Is this possible? ```

pca006132 commented

2021-04-12 15:26:24 +08:00

I did not think about that, maybe we can add some new syntax similar to ClassVar for host only variables?

sb10q commented

2021-04-12 16:09:56 +08:00

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.

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.

lriesebos commented

2021-04-12 23:34:25 +08:00

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[]

class Foo:
    a: int  # Kernel-only variable
    c: Immutable[ClassVar[int]]  # Still allows host-variable typing
    
    def __init__(self):
        self.a = 1  # Normal / kernel-only variable
        self.b: str = 'bar'  # Host-only variable typed in method

Make kernel-only variable typing special using Kernel[] and be fully compatible with regular Python typing

class Foo:
    a: Kernel[int]  # Use Kernel[] to type kernel-only variables
    c: ClassVar[int]  # Host-only typing remains vanilla
    d: str  # Also host-only
    
    def __init__(self):
        self.a = 1  # Normal / kernel-only variable
        self.b: str = 'bar'  # Host-only variable

We type practically everything in [our DAX library](https://gitlab.com/duke-artiq/dax), 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[]`** ```python class Foo: a: int # Kernel-only variable c: Immutable[ClassVar[int]] # Still allows host-variable typing def __init__(self): self.a = 1 # Normal / kernel-only variable self.b: str = 'bar' # Host-only variable typed in method ``` **Make kernel-only variable typing special using `Kernel[]` and be fully compatible with regular Python typing** ```python class Foo: a: Kernel[int] # Use Kernel[] to type kernel-only variables c: ClassVar[int] # Host-only typing remains vanilla d: str # Also host-only def __init__(self): self.a = 1 # Normal / kernel-only variable self.b: str = 'bar' # Host-only variable ```

sb10q commented

2021-04-13 08:43:52 +08:00

Make kernel-only variable typing special using Kernel[] and be fully compatible with regular Python typing

That option would be ok, but might need better names than Kernel (and Immutable).

> Make kernel-only variable typing special using Kernel[] and be fully compatible with regular Python typing That option would be ok, but might need better names than `Kernel` (and `Immutable`).

sb10q commented

2021-04-13 08:48:22 +08:00

Maybe Kernel[] / KernelImmutable[] since the two annotations are similar. And we would use "kernel" terminology in nac3core.

Maybe `Kernel[]` / `KernelImmutable[]` since the two annotations are similar. And we would use "kernel" terminology in nac3core.

lriesebos commented

2021-04-13 09:44:55 +08:00

Yes, I think Kernel[] and KernelImmutable[] is great and I like the fact that it is explicit!

Yes, I think `Kernel[]` and `KernelImmutable[]` is great and I like the fact that it is explicit!

pca006132 commented

2021-04-13 10:13:17 +08:00

Yes, it is fine for me. Did you think about the syntax I mentioned in the screenshot? Using Immutable(...) instead of Immutable[].

I'm not entirely sure if we can let IDE understand Immutable[T] == T for completion and checking, but we can do that with Immutable(T). However, one caveat is that it would be harder to let users to define the type elsewhere and use it, as the information of Immutable() would be loss. Maybe we should have a look at how typing does it for other generics.

Yes, it is fine for me. Did you think about the syntax I mentioned in the screenshot? Using `Immutable(...)` instead of `Immutable[]`. I'm not entirely sure if we can let IDE understand `Immutable[T] == T` for completion and checking, but we can do that with `Immutable(T)`. However, one caveat is that it would be harder to let users to define the type elsewhere and use it, as the information of `Immutable()` would be loss. Maybe we should have a look at how typing does it for other generics.

lriesebos commented

2021-04-13 10:36:37 +08:00

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 for Kernel[] and KernelImmutable[]. 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):

dax/modules/rtio_benchmark.py:206: error: Invalid type comment or annotation  [valid-type]
dax/modules/rtio_benchmark.py:206: note: Suggestion: use TArray[...] instead of TArray(...)

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 for `Kernel[]` and `KernelImmutable[]`. 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): ``` dax/modules/rtio_benchmark.py:206: error: Invalid type comment or annotation [valid-type] dax/modules/rtio_benchmark.py:206: note: Suggestion: use TArray[...] instead of TArray(...) ```

lriesebos commented

2021-06-07 19:33:03 +08:00

@pca006132 @sb10q did we now decide on the Kernel[] and KernelImmutable[] annotations? It is not contained in this merge request.

@pca006132 @sb10q did we now decide on the `Kernel[]` and `KernelImmutable[]` annotations? It is not contained in this merge request.

pca006132 commented

2021-06-08 09:46:02 +08:00

Sorry I forgot this one, this is two months ago :(.

I think Kernel is used for kernel only attributes, and KernelImmutable is for kernel invariants right? Can KernelImmutable be changed by the host? I think it is OK, or we can open another issue If we want further discussion about this.

Sorry I forgot this one, this is two months ago :(. I think `Kernel` is used for kernel only attributes, and `KernelImmutable` is for kernel invariants right? Can `KernelImmutable` be changed by the host? I think it is OK, or we can open another issue If we want further discussion about this.

👍 1

sb10q commented

2021-06-08 11:41:08 +08:00

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.

As per the discussion in https://git.m-labs.hk/M-Labs/nac3-spec/issues/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.

👍 1

README.md Outdated

						
				@ -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.

lriesebos commented

2021-04-12 04:22:57 +08:00

Should we use brackets instead, just like used for all other typing? KernelInvariant[T]

Should we use brackets instead, just like used for all other typing? `KernelInvariant[T]`

sb10q commented

2021-04-12 16:23:34 +08:00

I think so.

pca006132 commented

2021-04-12 18:08:13 +08:00

Yes, I would fix this later.

pca006132 marked this conversation as resolved

README.md Outdated

						
				@ -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

lriesebos commented

2021-04-12 04:40:19 +08:00

How do we expect to type function pointers, using the typing library? e.g. Call[[int32, int32], int32]

How do we expect to type function pointers, using the typing library? e.g. `Call[[int32, int32], int32]`

pca006132 commented

2021-04-12 15:26:39 +08:00

Yes

pca006132 marked this conversation as resolved

README.md Outdated

						
				@ -90,0 +93,4 @@

				* Functions are all kernel only, including constructor.

				Questions:

				* Should we also do `@portable`?

lriesebos commented

2021-04-12 04:35:18 +08:00

Does this just refer to kernel-only classes or is this a general question?

In general, @portable is a decorator we use very often, so I would like to keep that.
For kernel-only classes, portable functions sound contradicting
For portable classes (if existing), that might be useful but I do not have a use case for that right now.

Does this just refer to kernel-only classes or is this a general question? - In general, `@portable` is a decorator we use very often, so I would like to keep that. - For kernel-only classes, portable functions sound contradicting - For portable classes (if existing), that might be useful but I do not have a use case for that right now.

sb10q commented

2021-04-12 17:00:16 +08:00

Yes, we definitely want @portable.

Yes, we definitely want ``@portable``.

pca006132 commented

2021-04-12 18:07:31 +08:00

Portable would be for testing the code in the host, similar to the use case of portable functions I guess.

sb10q commented

2021-04-12 18:09:03 +08:00

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.

pca006132 commented

2021-04-12 19:13:58 +08:00

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...

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...

sb10q commented

2021-04-12 19:26:47 +08:00

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.

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](https://git.m-labs.hk/M-Labs/nac3-spec/issues/5#issuecomment-2022) to have more possibilities to implement immutability.

pca006132 commented

2021-04-12 20:01:19 +08:00

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...

lriesebos commented

2021-04-12 23:05:01 +08:00

So if I understand it correctly now, a kernel-only class is a class decorated with @kernel or @portable.

Both can be constructed inside kernels
@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 host

Regarding the kernel-only name, I am fine with that.

So if I understand it correctly now, a kernel-only class is a class decorated with `@kernel` or `@portable`. - Both can be constructed inside kernels - `@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 host Regarding the kernel-only name, I am fine with that.

sb10q commented

2021-04-13 08:25:38 +08:00

Or maybe, have a single type of "kernel-capable" class, decorated with @kernel.

Or maybe, have a single type of "kernel-capable" class, decorated with ``@kernel``.

sb10q commented

2021-04-13 08:28:32 +08:00

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.

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.

lriesebos commented

2021-04-13 09:56:49 +08:00

Ok great, then I guess I misunderstood the situation when read it and what we discussed in #5 is still valid. So to summarize:

from artiq.experiment import *

@kernel  # Register class with the compiler and more
class Foo(EnvExperiment):

    def __init__(self):
        pass
        
    def run(self) -> None:  # Host-only function
        self.kernel_fn()  # Runs a kernel
        self.rpc_fn()  # Runs function on host
        self.portable_fn()  # Runs function on host
        self.host_only_fn()  # Runs function on host
            
    @kernel
    def kernel_fn(self) -> None:  # Kernel function
        self.rpc_fn()  # RPC call
        self.portable_fn()  # Portable, so remains in kernel
        
    @rpc
    def rpc_fn(self) -> None:  # RPC function
        pass
        
    @portable
    def portable_fn(self) -> None  # Portable function
        pass
        
    def host_only_fn(self) -> None  # Host-only function
        pass

Ok great, then I guess I misunderstood the situation when read it and what we discussed in #5 is still valid. So to summarize: ```python from artiq.experiment import * @kernel # Register class with the compiler and more class Foo(EnvExperiment): def __init__(self): pass def run(self) -> None: # Host-only function self.kernel_fn() # Runs a kernel self.rpc_fn() # Runs function on host self.portable_fn() # Runs function on host self.host_only_fn() # Runs function on host @kernel def kernel_fn(self) -> None: # Kernel function self.rpc_fn() # RPC call self.portable_fn() # Portable, so remains in kernel @rpc def rpc_fn(self) -> None: # RPC function pass @portable def portable_fn(self) -> None # Portable function pass def host_only_fn(self) -> None # Host-only function pass ```

pca006132 commented

2021-04-13 10:10:00 +08:00

So if I understand it correctly now, a kernel-only class is a class decorated with @kernel or @portable.
Both can be constructed inside kernels
@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 host

This is exactly what I mean by kernel-only class.

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.

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.

> So if I understand it correctly now, a kernel-only class is a class decorated with @kernel or @portable. > > Both can be constructed inside kernels > @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 host This is exactly what I mean by kernel-only class. > 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. 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.

sb10q commented

2021-04-13 10:19:29 +08:00

What is the advantage of kernel-only classes? We'd need to support classes that mix kernel, portable, rpc, and host-only methods anyway.

lriesebos commented

2021-04-13 10:21:31 +08:00

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.

sb10q commented

2021-04-13 10:32:03 +08:00

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.

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.

pca006132 commented

2021-04-13 16:26:44 +08:00

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...

lriesebos commented

2021-06-07 19:36:14 +08:00

@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?

pca006132 commented

2021-06-08 09:48:11 +08:00

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 or kernel. And maybe we should also document the behavior for RPC when the object only exists on the kernel. What do you think?

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` or `kernel`. And maybe we should also document the behavior for RPC when the object only exists on the kernel. What do you think?

👍 1

sb10q commented

2021-06-08 11:36:08 +08:00

@pca006132 Sounds good.

README.md Outdated

						
				@ -131,48 +137,6 @@ Questions:

				* Would it be better to assert on the type variable directly instead of

				  `type(x)` for type guards?

lriesebos commented

2021-04-12 04:43:19 +08:00

Not sure what alternative you have in mind, but if type(x) == int32: is fine for me, see also #7 .

Not sure what alternative you have in mind, but `if type(x) == int32:` is fine for me, see also #7 .

pca006132 commented

2021-04-12 18:06:43 +08:00

Perhaps something like this:

from typing import TypeVar
T = Union[int, bool]

def add1(x: T) -> int:
  if T == int:
      # x is int
      return x + 1
  else:
      # x must be bool
      return 2 if x else 1

but idk if this would be valid Python code, not yet tested.

Perhaps something like this: ```python from typing import TypeVar T = Union[int, bool] def add1(x: T) -> int: if T == int: # x is int return x + 1 else: # x must be bool return 2 if x else 1 ``` but idk if this would be valid Python code, not yet tested.

sb10q commented

2021-04-12 20:14:59 +08:00

It wouldn't work in the interpreter (at least, without hacks). if type(x) == int32 is the interpreter-friendly way of doing it.

It wouldn't work in the interpreter (at least, without hacks). ``if type(x) == int32`` is the interpreter-friendly way of doing it.

pca006132 marked this conversation as resolved

sb10q reviewed 2021-04-12 16:06:03 +08:00

README.md

						
				@ -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

sb10q commented

2021-04-12 16:06:03 +08:00

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.

Ah, this would cause another problem like those in https://git.m-labs.hk/M-Labs/nac3-spec/issues/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.

pca006132 commented

2021-04-12 18:05:01 +08:00

Yes, I was thinking about this either, but it seems like there is no easy way around this.

lriesebos commented

2021-04-12 23:42:58 +08:00

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.

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.

sb10q commented

2021-04-13 00:01:08 +08:00

It cannot be enforced in the interpreter.

lriesebos commented

2021-04-13 00:14:08 +08:00

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!

pca006132 commented

2021-04-13 10:04:01 +08:00

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.

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.

sb10q commented

2021-04-13 10:16:53 +08:00

For classes there are special __getattr__ and __setattr__ methods that we can use to hack the interpreter and enforce KernelImmutable restrictions.
There is no equivalent for modules/globals.

For classes there are special ``__getattr__`` and ``__setattr__`` methods that we can use to hack the interpreter and enforce ``KernelImmutable`` restrictions. There is no equivalent for modules/globals.

lriesebos commented

2021-04-13 10:26:56 +08:00

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 it KernelImmutable[].

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 it `KernelImmutable[]`.

pca006132 added 2 commits 2021-04-12 19:59:10 +08:00

modified according to comments 284ab3324c

improved explanation for kernel only classes a034251c23

pca006132 added 1 commit 2021-04-12 20:16:54 +08:00

updated type variable description 24a85c472e

pca006132 commented

2021-04-12 20:33:33 +08:00

I've found something interesting:

I've found something interesting: ![image](/attachments/134e58e7-fd4b-442f-90c0-4bc4ea7b9049)

image.png

38 KiB

sb10q commented