post about string literal types

[jfrolich]

One thing that might be confusing is that the examples are now using reason syntax instead of the new Bucklescript syntax. Perhaps it makes sense to have both syntaxes in the blog post and people can select which syntax they'd like to see?

[bobzhang]

One thing that might be confusing is that the examples are now using reason syntax instead of the new Bucklescript syntax. Perhaps it makes sense to have both syntaxes in the blog post and people can select which syntax they'd like to see?

yeah, we will use the new syntax in the future, it's not settled yet

[bobzhang]

it’s a generalization to string literal types. This post is written to people who have background in typescript

Jaap Frolich notifications@github.com于2020年7月28日 周二下午4:59写道：

@jfrolich commented on this pull request.

In _blogposts/compiler/string-literal-types-in-reason.mdx https://github.com/reason-association/reasonml.org/pull/227#discussion_r461427670 :

+The deep reason is that if the compiler allows you to do such things, after you box different types of data in a single collection, it is hard to give such collection a type and process it later. + +With string literal types, you can do things like this: + +reasonml +[ 3 -> `Int , "3" -> `String ] + + +Note the generated code for 3 -> `Int`, "3"-> `String would be: + +js +{ NAME: "Int", VAL : 3} +{ NAME: "String", VAL : "3"} + + +And you can also write code to process such collections:

I know, but that was always possible with polyvars right? So I don't know how this relates with to the announcement that they now convert to strings in some cases.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/reason-association/reasonml.org/pull/227#discussion_r461427670, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFWMK2K7OY7EXT7NP5AEJLR52HQ3ANCNFSM4PJ7UCJA .

-- Regards -- Hongbo Zhang

[jfrolich]

it’s a generalization to string literal types. This post is written to people who have background in typescript

I would suggest to say that Polymorphic Variants correspond to string literals in typescript in the introduction, and then continue talking about Polymorphic Variants to not confuse anyone (and now it's clear for people coming from typescript). String literal are a less powerful construct in typescript.

Maybe have a more explicit introduction for typescript people. Something like this:

If you are coming from TypeScript you might be familiar with the string literal type. This allows you to enforce certain string values by the type checker. This functionality is now also available in BuckleScript. Polymorphic Variants without a constructor now compile to strings in JavaScript.

You can also link to the documentation of polymorphic variants in the introduction.

[bobzhang]

Let’s agree to disagree. String literal types is a well known feature in typescript. The purpose of this project is to make some academic ideas more accessible to average users. Jaap Frolich notifications@github.com于2020年7月28日 周二下午5:05写道：

@jfrolich commented on this pull request.

In _blogposts/compiler/string-literal-types-in-reason.mdx https://github.com/reason-association/reasonml.org/pull/227#discussion_r461430676 :

+title: Introducing string literal types in BuckleScript version 8.2 +description: |

• Highlights of our newest changes to the internal representation
• and how they will benefit our users. +---

• +---

• +## String literal types in BuckleScript

• +String literal types was introduced by TypeScript to model +JavaScript behavior, it's a relatively new concept since most type systems are runtime encoding agnostic. However, to smooth the user experience when writing +bindings to existing JS API, we are introducing string literal types which is unique in several behaviors compared with TypeScript: it supports type inference, +pattern match and can be attached to data.

• +## Vanilla string literal types

Variants and Polymorphic Variants are the main building block of the language. So they should be called out and explained. This is just very confusing, both for newcomers and for people familiar with the language because now things are suddenly called something different.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/reason-association/reasonml.org/pull/227#discussion_r461430676, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFWMK3YEVM3YQKS4MJUBXDR52ID3ANCNFSM4PJ7UCJA .

-- Regards -- Hongbo Zhang

[jfrolich]

Let’s agree to disagree. String literal types is a well known feature in typescript. The purpose of this project is to make some academic ideas more accessible to average users.

I get the goal you are trying to achieve. But if you'd like to achieve this, communication is important. There are a few things structurally wrong here. If you think that the term polymorphic variant is too hard to understand for beginners, it makes sense to rename these concepts. BUT this should be done deliberately, and everywhere. If you refer to the same concept with different terms in different places, this makes it objectively harder to understand for beginners. So using a different term just in a blog post off-hand is not making things clearer at all.

Also even if we would update all documentation to use this different term I don't think string literal is the best term to replace polymorphic variants for the following reason:

• A poly variant can have a constructor, a "string literal" with a constructor doesn't make much sense

• We should also rename variant. And what do we do when variants will also compile to strings?

If the naming of language primitives are changed this is a major thing and the transition should be communicated clearly. Honestly, I can name more than 10 different things that make it hard for beginners to get started on BuckleScript, and they are all more important than what specific language primitives are called in the language.

I would strongly suggest discussing these things with more people. Because they might seem to make things more understandable for you, confusing communication can be very frustrating for new users and even existing users. I think this is an amazing project but there have been a number of occasions where confusing communication has been driving away users. I love to help with this. And there are a number of strong communicators in the community who can also help with this.

[jfrolich]

Aside from this, I think it's better to link to ReasonML documentation for polymorphic variants than linking to OCaml. The people who already understand Reason + OCaml would not need the link and it would be confusing for people that start out with ReasonML.

[bobzhang]

hi @jfrolich your feedback is appreciated. I did have lots of communications (both online and offline), almost half my time is spent in communications -- I really hope not. At the end of day, we need make decisions.