https://0hmx.com/artifacts/tscircuit function based component contracts/?draft=alpha1 is this what providers want when they what to convert datasheet rules into actual rules?
https://0hmx.com/artifacts/tscircuit-function-based-component-contracts/?draft=alpha1
is this what providers want when they what to convert datasheet rules into actual rules?
yes, but....
i can say with some confidence that it's a bad idea to introduce a DSL, working within TSX is the only way that things won't get out of hand with training data etc.
so you want to create the schema to represent 99% of the checks that manufacturers have. We don't want people defining custom functions often, and when they do, we want it to be in such a way that implementations can't differ greatly
It's tempting to introduce a DSL-function system but it would be self-sabotage. TSX is the way to go
It is actually not smarter to create generic systems- this is a trap that our competitors fall into. It is far, far harder to design an API with great terms that represent the manufacturer's intent.
e.g. `<pinrequirement requirementType="requiresEnablePin" pinRef="U1.ADC1" enablePinRef="U1.EN_ADC1" />`
Of course generic checks should be possible in userland. But there are far more variants of the function-DSL representation than the TSX representation
Seve
This is related to the bull-Bun argument. "Why should bun have a large standard library?"
Want to add to the conversation?
Reply in Discord so your notes stay connected to the source.
