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

EcmaScript 4 syntax #106

Open
hydroper opened this issue Mar 16, 2023 · 1 comment
Open

EcmaScript 4 syntax #106

hydroper opened this issue Mar 16, 2023 · 1 comment

Comments

@hydroper
Copy link

hydroper commented Mar 16, 2023

Haxe has some subtle differences from TypeScript and EcmaScript 4 (inexistent) syntax.

  • For aliasing types, TypeScript choose to use the context keyword type rather than a reserved word typedef. EcmaScript 4 too was going to use type (whether in ES4 it was going to be contextual or not I don't remember, though the EcmaScript 4 reference interpreter is available in archive.org).
  • In TypeScript, you can express Array<T> as T[]. In EcmaScript 4 you would be able to express Array.<T> as [T]. To me, it seems like the EcmaScript 4 syntax for specifying array types in brackets is cryptic and readable at the same time.
    • Both TypeScript and EcmaScript 4 express tuple types with the same syntax, consisting of two or more element types.
  • In TypeScript, the dynamic type is written any. In EcmaScript 4, it's written *.

More specifically, in these languages, type is reserved when it's followed or preceded by another identifier or reserved word, so it doesn't break compatibility.

Here's a Haxe version:

var a:Array<Dynamic> = [];

typedef DoublePrecisionFloatingPoint = Float;

Here's an EcmaScript 4 version:

var a:[*] = [];

type DoublePrecisionFloatingPoint = Number;

I think it'd be interesting if Haxe supported the same ES4 syntax for clarity, considering it'd not break compatibility. It doesn't break macros, does it? After all, Haxe was inspired by ES4.

Another thing I didn't mention is that the decorator syntax of ES4 used brackets, not @:.

@back2dos
Copy link
Member

I think supporting a multitude of styles from various languages in Haxe will mostly create confusion, but more importantly create obstacles for when we do want to add new syntax with new semantics, e.g. the * for a type param could mean a whole bunch of things other than Dynamic that might have distinct use cases.

I see some value in supporting ECMAScript syntax. The advantages of using standardized syntax are quite obvious and Haxe did start out being advertised ECMAScript dialect. It diverged from its heritage for a whole bunch of good reasons, but there's been a whole lot of parallel evolution, where there's little value in Haxe having a different syntax than ES/TS do. If anything, I think a separate frontend for an ECMAScript aligned syntax would actually be relatively useful, but I don't see the work involved (especially with IDE support) paying off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants