Add text primitives in DAML 1.dev for experiments.
See original GitHub issueThe idea is to add LF primitives for:
toUpper/toLower
replicate/fill
break/breakOn/stripInfix
… and other missingList
counterpartscontainsOnlyAlphabet: Text -> Text -> Bool
(useful forisDigital, isAlpha, isWhitespace, isAscii
and similar functions)split/join
Issue Analytics
- State:
- Created 4 years ago
- Comments:25 (13 by maintainers)
Top Results From Across the Web
Reference: Built-in Functions — Daml SDK 2.4.2 documentation
Daml has these built-in functions for working with text: <> operator: concatenates two Text values. show converts a value of the primitive types...
Read more >Release of Daml Connect 1.10.0 - Digital Asset Blog
Set allowing maps and sets with arbitrary serializable types as keys/members. This supersedes the TextMap type and standard library modules DA.
Read more >Great introduction to Daml by Andreas given as Guest Lecture ...
Get started with Daml : https://bit.ly/tryDaml Learn more about Daml Smart Contracts: https://bit.ly/learn_daml Check out our blogs: ...
Read more >JavaScript Client Libraries — Daml SDK 0.0.0 documentation
The @daml/types library contains TypeScript data types corresponding to primitive Daml data types, such as Party or Text . It is used by...
Read more >daml/daml-lf-1.rst at main · digital-asset/daml - GitHub
Contribute to digital-asset/daml development by creating an account on GitHub. ... add BigNumeric primitive type - add RoundingMode primitive type and ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@cocreature pointed out that
take
anddrop
aren’t primitive, so I’m adding those.I took a brief look at the unicode standard, in particular, section 4 in https://www.unicode.org/versions/Unicode12.0.0/ch04.pdf paragraph “Case Mapping”. It looks like a nice option might be to use the data from
UnicodeData.txt
which is not dependent on weird things but not useSpecialCasing.txt
because nobody likes special cases and that is context dependent.However, I have no clue how easy it is to do that on the JVM or anywhere else so while this seems easy to specify and less restrictive than nly allowing ASCII, I’m not sure it is actually a reasonable option.
I don’t really like A2 and it seems to go against the spirit of those primitives which are all about performance and I agree that A3 is not a very nice specification even though it probably does what you want™ in basically all cases. So I’m leaning towards A1, what do you think @remyhaemmerle-da? @filmackay Would ASCII be sufficient for your usecases?