-
Notifications
You must be signed in to change notification settings - Fork 34
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
post about string literal types #227
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
With string literal types, you can do things like this: | ||
|
||
```reasonml | ||
[ 3 -> `Int , "3" -> `String ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest not using ->
sugar but plain poly variants for clarity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, would be a lot clearer without the ->
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is to illustrate the idea of tagging
assuming people have no background with polyvar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is tagging
?
{ NAME: "String", VAL : "3"} | ||
``` | ||
|
||
And you can also write code to process such collections: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code is the same when there are string poly variants or not. Why is this relevant to string poly variants?
The NAME
now converts to a string. But why is that helpful for interop? It seems an implementation detail that doesn't have a practical use case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is used to mix data of diffrent types in a collection in a convenient way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
## Further reading | ||
|
||
Here we only cover some basic usage of string literal types, user can refer [here](https://caml.inria.fr/pub/docs/manual-ocaml/lablexamples.html#s%3Apolymorphic-variants) for more advanced stuff. The type theory is almost the same, however, we adapt it to make sure it's compiled into string literals to match the JS runtime. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be good to explicitly note what is different compared to ocaml poly variants in the new bucklescript implementation. People might land at this blog post when running into the limitations. Even if it's just a footnote or a link to a detailed overview of the differences.
|
||
## Further reading | ||
|
||
Here we only cover some basic usage of string literal types, user can refer [here](https://caml.inria.fr/pub/docs/manual-ocaml/lablexamples.html#s%3Apolymorphic-variants) for more advanced stuff. The type theory is almost the same, however, we adapt it to make sure it's compiled into string literals to match the JS runtime. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's
-> it is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just curious, there is a difference here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In technical writing it is better to avoid contractions. It is considered informal, conversational.
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 |
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写道:
***@***.**** commented on this pull request.
------------------------------
In _blogposts/compiler/string-literal-types-in-reason.mdx
<#227 (comment)>
:
> +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
<#227 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFWMK2K7OY7EXT7NP5AEJLR52HQ3ANCNFSM4PJ7UCJA>
.
--
Regards
-- Hongbo Zhang
|
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:
You can also link to the documentation of polymorphic variants in the introduction. |
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写道:
***@***.**** commented on this pull request.
------------------------------
In _blogposts/compiler/string-literal-types-in-reason.mdx
<#227 (comment)>
:
> +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](https://www.typescriptlang.org/docs/handbook/advanced-types.html#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
<#227 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFWMK3YEVM3YQKS4MJUBXDR52ID3ANCNFSM4PJ7UCJA>
.
--
Regards
-- Hongbo Zhang
|
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:
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. |
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. |
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. |
Co-authored-by: Patrick Stapfer <ryyppy@users.noreply.github.com>
No description provided.