tvm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Pollock <notificati...@github.com>
Subject [dmlc/tvm] [RFC][Relay] Text Format Part 2 (#3016)
Date Fri, 12 Apr 2019 22:12:05 GMT
The following RFC is for more bikeshedding about syntax of the Relay text format not covered
by #1782.

The guiding principles for syntax choices are
- **readability:** Syntax should be easy to read and parse visually.
- **internal consistency:** Syntax choices should be similar to each other (e.g. function
definitions and function types should have similar syntax).
- **external consistency:** We should strive to reuse existing syntax choices from other languages
so users that are familiar with those languages have less to learn. Also existing syntax choices
are _usually_ well-thought-out.

**Please provide feedback on the syntax choices below or other syntactic features you think
should be discussed that weren't already agreed on in #1782.**

## References
### RefCreate
Existing languages:
OCaml
```
ref 5
```
ReasonML
```
ref(5)
```
Relay Proposal
```
ref(5)
```
### RefRead
OCaml
```
r := v
```
ReasonML
```
r := v
```
Relay Proposal
```
r := v
```
### RefWrite
OCaml
```
!r
```
ReasonML (adopted because `!` is already used for `not`)
```
r^
```
It may be temping to use `&x`, but this implies that any expression has a reference, whereas
in ML-like languages references must be created explicitly.
Relay Proposal
```
*r
```
or
```
read(r)
```
Prefixes seem better than postfixes, but we need to avoid `!` do to ambiguity. I'm open to
other suggestions.

## ADTs
ReasonML
```
type myVariant =
  | HasNothing
  | HasSingleInt(int)
  | HasSingleTuple((int, int))
  | HasMultipleInts(int, int)
  | HasMultipleTuples((int, int), (int, int))
```
Rust
```
enum myVariant {
  HasNothing,
  HasSingleInt(int),
  HasSingleTuple((int, int)),
  HasMultipleInts(int, int),
  HasMultipleTuples((int, int), (int, int)),
}
```
Relay Proposal
```
type myVariant =
  | HasNothing
  | HasSingleInt(int)
  | HasSingleTuple((int, int))
  | HasMultipleInts(int, int)
  | HasMultipleTuples((int, int), (int, int))
```
## Pattern Matching
ReasonML
```
switch (x) {
  | HasNothing => 0
  | HasSingleInt(x) => 0
  | HasSingleTuple((x, y)) => 0
  | HasMultipleInts(x, y) => 0
  | HasMultipleTuples((x, y), (q, r)) => 0
}
```
Rust
```
match x {
  HasNothing => 0,
  HasSingleInt(x) => 0,
  HasSingleTuple((x, y)) => 0,
  HasMultipleInts(x, y) => 0,
  HasMultipleTuples((x, y), (q, r)) => 0,
}
```
Relay Proposal
```
match (x) {
  | HasNothing => 0
  | HasSingleInt(x) => 0
  | HasSingleTuple((x, y)) => 0
  | HasMultipleInts(x, y) => 0
  | HasMultipleTuples((x, y), (q, r)) => 0
}
```
`case` is also a viable alternative keyword.
## Generics (i.e. type arguments)
Rust
```
enum Option<T> {
    Some(T),
    None,
}

fn takes_anything<T>(x: T) {
    // do something with x
}
```
```
let x: Option<i32> = Some(5);
let x: Option<i64> = Some(5);
```
ReasonML
```
type Option('a) =
    | Some('a)
    | None
```
Scala
```
Some[A](a : A)
```
Python
```
Option[A] = Union[A, None]
```
Relay Proposal
```
type Option[A] =
  | Some(A)
  | None

fn takes_anything[T](%x: T) {
    // do something with %x
}

let x = Some[i32](5);
let x = Some[i64](5);
```

## TupleGetItem
ReasonML
```
("foo",2,true).0 // "foo"
```
Rust
```
("foo",2,true).0 // "foo"
```
Scala
```
("foo",2,true)._1 // "foo"
```
Python
```
("foo",2,true)[0] # "foo"
```
Relay Proposal
```
("foo",2,true).0 // "foo"
```

## Semicolons
We need to consider whether or not to use semicolons as separators in sequence operations.
The pros of using semicolons is they're easier to implement and allow us to ignore newline
characters when writing and parsing programs. The cons are they are more cumbersome and make
the text format less python-like.

## Attributes
Python
```
def foo(a, b, c=None, d=None):
```
Relay Proposal
```
@foo(%a, %b, %c=None, %d=None)
```
when the attrs type index matches the operator's attrs type index
```
@foo(%a, %b, BarAttrs={%c: None, %d: None})
```
when it doesn't.
I'm not as certain about this syntax piece, so I'm very open to suggestions here.

cc @tqchen @MarisaKirisame @jroesch @wweic @vinx13 @junrushao1994 @nhynes

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/3016
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message