support creation of list via multiplication operator #48

New Issue

sb10q · 2021-10-03T17:19:52+08:00

sb10q commented

2021-10-03 17:19:52 +08:00

def run() -> int32:
    list_a = [1]*100
    return 0

currently fails with

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Cannot unify record[__mul__=call] with list[int32] at line 2 column 17"', nac3standalone/src/main.rs:65:35

```python def run() -> int32: list_a = [1]*100 return 0 ``` currently fails with ``` thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Cannot unify record[__mul__=call] with list[int32] at line 2 column 17"', nac3standalone/src/main.rs:65:35 ```

pca006132 commented

2021-10-03 17:50:11 +08:00

This requires modification of the type system. The current implementation separates list and objects, so lists cannot have methods. Maybe we would need to treat lists as objects.

sb10q commented

2021-10-03 17:51:49 +08:00

Poster

This is a very common way of creating large lists (is there any other way?) so we definitely need to support that.

sb10q added the

high-priority

label 2021-10-03 17:58:18 +08:00

pca006132 commented

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

Two ways to do this. We can either support this via modifying the type checking module (would break quite a lot of tests and other code...) or use a special builtin function to do it. The second option would be much simpler to implement for now.

Maybe something like this:

# a = [1] * 100
a = repeat([1], 100)

What do you think?

Two ways to do this. We can either support this via modifying the type checking module (would break quite a lot of tests and other code...) or use a special builtin function to do it. The second option would be much simpler to implement for now. Maybe something like this: ```python # a = [1] * 100 a = repeat([1], 100) ``` What do you think?

sb10q commented

2021-10-09 11:46:43 +08:00

Poster

The repeat function is fine but it should be called something more specific. Maybe new_list or similar. It could be simply called as new_list(1, 100) without the [].

For the syntactic sugar, do an AST match-pattern-and-replace pass before typechecking? That pass could also handle things like int64(round()) -> round64().

The ``repeat`` function is fine but it should be called something more specific. Maybe ``new_list`` or similar. It could be simply called as ``new_list(1, 100)`` without the ``[]``. For the syntactic sugar, do an AST match-pattern-and-replace pass before typechecking? That pass could also handle things like ``int64(round())`` -> ``round64()``.

pca006132 commented

2021-10-10 15:05:21 +08:00

The repeat function is fine but it should be called something more specific. Maybe new_list or similar. It could be simply called as new_list(1, 100) without the [].

new_list(T, int) -> [T] would not support things like [1, 2, 3] * 100, although I'm not sure if users want this feature.

For the syntactic sugar, do an AST match-pattern-and-replace pass before typechecking? That pass could also handle things like int64(round()) -> round64().

For syntactic sugar, I think the best we can do is just support thing like [...] * .... Things more complicated like

a = [1]
b = a * 100

is not supported unless we modify the type system.

> The ``repeat`` function is fine but it should be called something more specific. Maybe ``new_list`` or similar. It could be simply called as ``new_list(1, 100)`` without the ``[]``. `new_list(T, int) -> [T]` would not support things like `[1, 2, 3] * 100`, although I'm not sure if users want this feature. > For the syntactic sugar, do an AST match-pattern-and-replace pass before typechecking? That pass could also handle things like ``int64(round())`` -> ``round64()``. For syntactic sugar, I think the best we can do is just support thing like `[...] * ...`. Things more complicated like ``` a = [1] b = a * 100 ``` is not supported unless we modify the type system.

sb10q commented

2021-10-10 17:08:40 +08:00

Poster

Those restrictions are fine IMHO.

pca006132 commented

2021-10-16 22:28:51 +08:00

suddenly remember that the user should be able to use [a for _ in range(x)]. Do we still need the workaround for now?

suddenly remember that the user should be able to use `[a for _ in range(x)]`. Do we still need the workaround for now?

sb10q commented

2021-10-19 08:36:08 +08:00

Poster

I suppose only range(int32) is to be supported as iterator there.
Can this be implemented quickly and without runtime performance issues?

I suppose only ``range(int32)`` is to be supported as iterator there. Can this be implemented quickly and without runtime performance issues?

pca006132 commented

2021-10-19 12:09:01 +08:00

Can this be implemented quickly

This may need some time... I'm thinking about how to deal with range without a range type for now.

without runtime performance issues?

I think we can optimize the implementation to make it fast.

> Can this be implemented quickly This may need some time... I'm thinking about how to deal with `range` without a range type for now. > without runtime performance issues? I think we can optimize the implementation to make it fast.

pca006132 commented

2021-10-24 16:55:33 +08:00

Implemented with list comprehension.

pca006132 closed this issue

2021-10-24 16:55:33 +08:00

Sign in to join this conversation.