My Polymorph Data Language is finally "ready" enough for public scrutiny π
The work took a detour - so I ended up starting with 2 more parser friendly syntaxes - which are also relatively easy to parse in parallel (for more speed when needed). I have documented the first 2 syntaxes here:
https://jenkov.com/tutorials/polymorph-data/polymorph-data-language.html
I also have a third, more humanly readable / typeable syntax, but I am not sure it should be published. It's not as fast to parse, and hard (impossible?) to parse in parallel... why would we limit ourselves that much - just for a bit of extra readability? ... a bit fewer characters? Hmm... But maybe for small scripts it would be fine ( < 1 KB ) - as the performance difference might be insignificant in some such cases (small scripts parsed less often).
Polymorph Data Language (PDL) is an alternative to JSON, YAML, XML, CSV etc. which provides more features and is this more versatile than these other languages. Features, such as compact object representations, tabular data representations, object tree representations and cyclic object graph support.
PDL can also be converted to its binary counter-part Polymorph Data Encoding (PDE), which is even faster to process, and more compact on the wire / disk. PDE uses an encoding similar to MessagePack and CBOR, but with a few changes to support all the features I wanted (such as efficient tabular data, efficient object trees and cyclic object graphs).
I have spent a looooong time scrutinizing as many aspects of PDL and PDE as I could - to make sure it has good trade-offs in its design - suitable for as many use cases as I could think of.
Now I am ready for your scrutiny too - pointing out all the things I have missed π π
#Polymorph #PolymorphDataLanguage #PolymorphDataEncoding #PDL #PDE
P.S. I learned a lot about tokenizer speeds in the process too! ... I'll write more about that too, some day π
The work took a detour - so I ended up starting with 2 more parser friendly syntaxes - which are also relatively easy to parse in parallel (for more speed when needed). I have documented the first 2 syntaxes here:
https://jenkov.com/tutorials/polymorph-data/polymorph-data-language.html
I also have a third, more humanly readable / typeable syntax, but I am not sure it should be published. It's not as fast to parse, and hard (impossible?) to parse in parallel... why would we limit ourselves that much - just for a bit of extra readability? ... a bit fewer characters? Hmm... But maybe for small scripts it would be fine ( < 1 KB ) - as the performance difference might be insignificant in some such cases (small scripts parsed less often).
Polymorph Data Language (PDL) is an alternative to JSON, YAML, XML, CSV etc. which provides more features and is this more versatile than these other languages. Features, such as compact object representations, tabular data representations, object tree representations and cyclic object graph support.
PDL can also be converted to its binary counter-part Polymorph Data Encoding (PDE), which is even faster to process, and more compact on the wire / disk. PDE uses an encoding similar to MessagePack and CBOR, but with a few changes to support all the features I wanted (such as efficient tabular data, efficient object trees and cyclic object graphs).
I have spent a looooong time scrutinizing as many aspects of PDL and PDE as I could - to make sure it has good trade-offs in its design - suitable for as many use cases as I could think of.
Now I am ready for your scrutiny too - pointing out all the things I have missed π π
#Polymorph #PolymorphDataLanguage #PolymorphDataEncoding #PDL #PDE
P.S. I learned a lot about tokenizer speeds in the process too! ... I'll write more about that too, some day π
lnkd.in
LinkedIn
This link will take you to a page thatβs not on LinkedIn