Are there any plans to simplify the language?

[artsiommiksiuk]

As an emitter writter I'd like it to be as simple as possible to write it. This requires as simple language as possible. While I understand that language expressivness requiers some complexity, I think current iterration of TSP is too complex to write emitters effortlessly. Meaning parsing all possible syntatic constructions is quite a burden atm.

1. Separate alias and is kewords instead of just type X = Y, or TypeScript like ADTs.
2. Separate rules with templates definition, which can also be put simpler into type X<T> = T. Same construction with additional parameter.
3. Probably in this case whole language can be reduced down to:
   types - as means to model serialazable data points. Here goed standard typescript types capabilitied with just added possibilty to apply decorators onto them.
   operations - as the means for communication, or simple message passing entrypoint.
   packaging - namespaces (I don't like it much and prefer js/ts way of importing exporting stuff) and files.
   [hierarchy modeling] - necessary for more OO style, which is why models as a separate keword probably fine, but I'd probably then stick to type A extends B = C.

Point being, language surface is too large (relative to proposed idea) already to be considered easy enough to write emitters left and right.

I understand that development of such things is not an easy process, that's why I hope that language core wouldn't grow, and better - shrink instead. I've decided to write this because saw another discussion about composing decorators and there where new keyword and syntax proposed, which got me worried even more.

[timotheeguerin]

Hey @artsiommiksiuk can you explain a little more on how the syntax affect you as an emitter? The emitter do not see(shouldn't) the AST but the rendered type graph. In there templates, aliases are resolved to a common type as if they were written directly.

See this playground showcasing 3 ways to construct a model with a stirng prop, in the type graph they all resolve to a very similar model type

model Test1 {
  name: string;
}

model Template<T> {
  name: T;
}

model Test2 is Template<string>;

alias strAlias = string;
model Test3 {
  name: strAlias;
}

• Test1

• Test2

• Test3

[artsiommiksiuk]

Hm, maybe I then misunderstood the way I should be working with TypeSpec. I mean, I'm not parsing AST myself, that's true, but then comparing it to TypeScript syntax and to the TypeScript AST workflow I find a lot of syntax odd and alien in comparison, and I can't get the feeling with TypeSpec of "what you see is what you get" when traversing the tree in emitter code.

Maybe this connection to TypeScript is a bit harmful here, because expectation and mental model is not that suitable as I thought it would, the constructs are just different in the end. Or maybe it is that TypeSpec is just in so early stage that it lacks big portion of documentation, descriptions, how tos, and basic DX stuff that makes up this feeling rn. Idk.

This is my 3d attempt to work with it and make an emitters for TS backend framework (different wires), for client sdks, for custom rendering configs, and seems like mental model is just not there yet.

It would probably help if there were a little bit of high level resource on modeling or approaching this.
Rn I have two conceptual ways: operations centric and models centric approach, where your main focus is operations or models as an entry points. Models are for json-schema or protobuf only outputs, while operations centric for everything which implements behaviour (server implementations, sdks). Such kind of pretty fundamental things would help a lot.