Feature feedback from Duke #6

New Issue

lriesebos · 2021-03-10T08:35:48+08:00

lriesebos commented

2021-03-10 08:35:48 +08:00

Various language features have been discussed in other issues. I just wanted to underline some features I noticed in the context of how we use ARTIQ.

If we can provide any further insight in how we use ARTIQ in our lab, let me know!

Function default parameters

Function default parameters are not allowed, as changes to the default value would not be kept across kernel calls, which is a potential source of confusion. (maybe we can allow primitive default types?)

Function parameter defaults for kernel, portable, and rpc functions are very important for us. The limitation of only allowing immutable or primitive default types is fine.

Function pointers

Should we support function pointers? What about subtyping with function pointers, and generic types?

We do use function pointers in various ways. For example in lists or as callbacks. I don't think we pass function pointers in kernels at runtime at this moment.

Subtyping with function pointers would definitely be something we are interested in, but we can do without.

range

range (over numerical types) (not sure if this is really useful)

I am not sure what the plan is with the range buildin, but it is obviously used in loops very often. If a range by default converts to a list that is fine for us, as long this is noted in the documentation (regarding memory usage).

We do have one or two situations where we return a range object. We could change most of these situations such that we return a (kernel invariant) attribute instead assuming that is still possible.

Type guards for list types

See the following example you provided:

I = TypeVar('I', int32, list[int32])

def add(a: int32, b: I) -> int32:
    if type(b) == int32:
        return a + b
    else:
        # b must be list[int32] in this branch.
        for x in b:
            a = add(a, x)
        return a

I like the type() syntax for type guards, but we are not able to differentiate between different list types. To be honest, at this moment we do not really have usecases for generics and substitution

super

We are interested in having simple support for super() as also mentioned in #3

Various language features have been discussed in other issues. I just wanted to underline some features I noticed in the context of how we use ARTIQ. If we can provide any further insight in how we use ARTIQ in our lab, let me know! # Function default parameters > - Function default parameters are not allowed, as changes to the default value would not be kept across kernel calls, which is a potential source of confusion. (maybe we can allow primitive default types?) Function parameter defaults for kernel, portable, and rpc functions are very important for us. The limitation of only allowing immutable or primitive default types is fine. # Function pointers > - Should we support function pointers? What about subtyping with function pointers, and generic types? We do use function pointers in various ways. For example [in lists](https://gitlab.com/duke-artiq/dax/-/snippets/1966946#LC160) or [as callbacks](https://gitlab.com/duke-artiq/dax/-/blob/master/dax/modules/safety_context.py#L56). I don't think we pass function pointers in kernels at runtime at this moment. Subtyping with function pointers would definitely be something we are interested in, but we can do without. # range > - range (over numerical types) (not sure if this is really useful) I am not sure what the plan is with the `range` buildin, but it is obviously used in loops very often. If a range by default converts to a `list` that is fine for us, as long this is noted in the documentation (regarding memory usage). We do have one or two situations where we return a `range` object. We could change most of these situations such that we return a (kernel invariant) attribute instead assuming that is still possible. # Type guards for list types See the following [example you provided](https://git.m-labs.hk/M-Labs/nac3-spec/src/branch/master/toy-impl#substitution): > ```python > I = TypeVar('I', int32, list[int32]) > > def add(a: int32, b: I) -> int32: > if type(b) == int32: > return a + b > else: > # b must be list[int32] in this branch. > for x in b: > a = add(a, x) > return a > ``` I like the `type()` syntax for type guards, but we are not able to differentiate between different list types. To be honest, at this moment we do not really have usecases for generics and substitution # super We are interested in having simple support for `super()` as also mentioned in #3

lriesebos referenced this issue

2021-03-10 08:39:10 +08:00

Kernel code simulation #7

pca006132 commented

2021-03-30 09:48:27 +08:00

Yes, only allowing immutable types in function default parameter would be a good compromise.
Function pointers without dealing with subtyping or type inferencing should not be too hard.
Implementing Range type should be simple, I forgot why I put that comment there.
For generics and substitution, I was just proposing it to mitigate the new limitation of mandatory function type signature. Previously we can do generic implicitly which facilitates code reuse, and we are not sure the new changes without generic would be too much a limitation for users.

1. Yes, only allowing immutable types in function default parameter would be a good compromise. 2. Function pointers without dealing with subtyping or type inferencing should not be too hard. 3. Implementing `Range` type should be simple, I forgot why I put that comment there. 4. For generics and substitution, I was just proposing it to mitigate the new limitation of mandatory function type signature. Previously we can do generic implicitly which facilitates code reuse, and we are not sure the new changes without generic would be too much a limitation for users.

👍 1

pca006132 referenced this issue

2021-06-07 11:10:39 +08:00

Kernel code simulation #7

pca006132 referenced this issue from M-Labs/nac3

2021-11-20 14:44:14 +08:00

Constant Default Parameter Support #98

Sign in to join this conversation.