Composite types/generics

[glhrmfrts]

I just noticed that the parser currently accepts only identifiers as a hash literal key, e.g.:

{hello: "world"}

I think that when this was implemented it was meant to be temporary, but since Luna is planned to be a statically typed language I think we need to define a syntax for generic types.

[vendethiel]

please, use always-matching brackets, not c++-style c++

[glhrmfrts]

@vendethiel sorry, but can you give an example?

[vendethiel]

Sorry, i meant <>, which are not always matched... Making parsing harder.

[glhrmfrts]

Yeah I don't see much sense in that being unmatched. Anyway, this syntax is very ugly to me:

map<string, int>{
  "number": 2
}

But i can't think of anything else.

[vendethiel]

"Being unmatched" => they are when you use it as comparison operators.

map[string, int]{...} map!(string, int){...} (d-style)

[aisk]

I think if luna have a type inference, the syntax will be cool:

{"foo": "bar"}    => map<string, string>
{"foo": "bar", "alist": [1, 2, 3]}    => map<string, interable<any>>
{"foo": "bar", "truth": 42}    => map<string, any>

But I think this will be a large project 😅

[vendethiel]

very, very large indeed. And can be very surprising – see Scala.

[aisk]

@vendethiel Yes, may be this is not luna's target simple, elegant, explicit haha

[glhrmfrts]

@vendethiel Oh I see now :p But maybe <> would be easier than square brackets (because of subscript), unless it's context-dependent and we do some semantic analysis later.

[glhrmfrts]

@aisk Maybe it's possible to a large project achieve simplicity? lol

[aisk]

@glhrmfrts I think it's not just too complex to implement, but with this design luna's type system may be more complex, and make it more hard too learn and use.

[glhrmfrts]

Indeed, a more strict type system might be good for both sides.