Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tagged Union Syntax #13

Open
wongjiahau opened this issue Jan 1, 2020 · 3 comments
Open

Tagged Union Syntax #13

wongjiahau opened this issue Jan 1, 2020 · 3 comments
Assignees
Labels
Discussion syntax semantic or syntax inconsistency and ambiguous cases.

Comments

@wongjiahau
Copy link
Collaborator

Things do discussed:

  1. How to define a tagged union?
  2. How to construct an expression with type of tagged union?
@zypeh
Copy link
Member

zypeh commented Jan 5, 2020

type Shape
  = Circle (radius: Float)
  | Rectangle (height: Float, width: Float)
  | None

area: (shape: Shape) -> (result: Float) := {
  (shape = Circle(radius)) -> 
    radius.square.multiple(by:= pi),

  (shape = Rectangle(height, width)) ->
    height.multiple(by:= width),

  (shape = None) ->
    0
}
  1. Are we gonna make the ADT cases (alternatives) an individual constructor or a field of a type?

ps. I think we need to think the type system first. #17

@wongjiahau
Copy link
Collaborator Author

wongjiahau commented Jan 6, 2020

If we make ADT cases an individual constructor, the BAD thing is that it might be confusing for some cases, because user might not know which type does the constructor belongs to, but the GOOD thing is the code is shorter.

Example:

type Shape
  = Circle (radius: Float)
  | Rectangle (height: Float, width: Float)
  | None

area: (shape: Shape) -> Float := {
  (shape = Circle(radius)) -> 
    radius.square.multiple(by:= pi),

  (shape = Rectangle(height, width)) ->
    height.multiple(by:= width),

  (shape = None) ->
    0
}

===
If we make ADT cases a field of a type, the GOOD things are:

  1. the parent type of each cases can be understood easily,
  2. it's better for autocomplete to work, because user can just type the type name, then the list of possible cases will fall down for them to choose.
  3. It's more consistent with our syntax, because we can view Shape.Circle(radius:=3) as a function application where the function is Circle and the arguments is Shape and (radius:=3).
  4. We can prevent name clashing, for example if we have two types with some common cases:
type TrafficColor :=
  | Red
  | Green

type RainbowColor :=
  | Red
  | Green
  | Blue

TrafficColor.Red

RainbowColor.Red

If we use ADT cases as individual constructor, we need to prevent this type of clashing by using prefixes:

type TrafficColor :=
  | TrafficRed
  | TrafficGreen

type RainbowColor :=
  | RainbowRed
  | RainbowGreen
  | RainbowBlue

The BAD thing is of course the resulting code will be noisier.

Example:

type Shape
  = Circle (radius: Float)
  | Rectangle (height: Float, width: Float)
  | None

area: (shape: Shape) -> Float := {
  (shape = Shape.Circle(radius)) -> 
    radius.square.multiple(by:= pi),

  (shape = Shape.Rectangle(height, width)) ->
    height.multiple(by:= width),

  (shape = Shape.None) ->
    0
}

@zypeh
Copy link
Member

zypeh commented Jan 8, 2020

Q: Do we support pattern matching over the anonymous tagged union.

so here's how Rust does it:

let x: None | Some(i32) = Some(100)

the compiler creates an invisible enum, it's just like pattern matching against normal enums. (1)

Q: How do rec-Nat and recursion works?
We will try to understand this by reading the book "The Little Typer".

Q: Can we make the pattern matching case into the polymorphic record, so that we can compose cases.
(2), I think the pattern matching rule will be huge. 😢

References
  1. Polymorphic variants
  2. First-class case

@zypeh zypeh added Discussion syntax semantic or syntax inconsistency and ambiguous cases. labels Jan 8, 2020
@zypeh zypeh added this to the Study "The Little Typer" milestone Jan 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion syntax semantic or syntax inconsistency and ambiguous cases.
Projects
None yet
Development

No branches or pull requests

3 participants