# 0hmx - https://0hmx.com/artifacts/tscircuit-fun...

Channel: #contributor
Source: https://discord.com/channels/1233487248129921135/1552041627294367784
Started: 2026-09-22T19:39:20.355000+00:00
Last activity: 2026-09-22T21:09:27.852000+00:00

## 0hmx — 2026-09-22T19:39:19.486000+00:00

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?
Attachment: image.png — https://community.tscircuit.com/media/1552041625272844389

## Seve — 2026-09-22T20:08:13.312000+00:00

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 — 2026-09-22T20:09:14.186000+00:00

This is related to the bull-Bun argument. "Why should bun have a large standard library?"

## 0hmx — 2026-09-22T21:04:08.744000+00:00

> e.g. <pinrequirement requirementType="requiresEnablePin" pinRef="U1.ADC1" enablePinRef="U1.EN_ADC1" />

I think I get the idea!

But chip-level DRC could be difficult, especially for cases like the example in the blog.

It could also extend the existing `<drccheck />` tag. I didn’t know we already had this tag; otherwise, I probably would have designed the API differently.

but do you think the 2 example that we picked is a real case to handel?

## 0hmx — 2026-09-22T21:05:47.637000+00:00

The big idea I have in mind is to convert these datasheet rules into component-level DRCs. Since tscircuit is so easy to share, I think this could become something really unique to us.

## Seve — 2026-09-22T21:06:31.491000+00:00

I mean the AM3552 is probably going to be something we play with for a while

## Seve — 2026-09-22T21:06:44.682000+00:00

it has a massive list, i think i scrolled through it in the last meeting recording

## Seve — 2026-09-22T21:07:09.291000+00:00

i will get you a link

## Seve — 2026-09-22T21:07:55.808000+00:00

yea i think basically when we ship a chip re-usable module, we include <drccheck /> or other elements

## Seve — 2026-09-22T21:08:54.996000+00:00

keeping the representation minimal and extremely explicit is how we'll be able to represent the most rules. Typescript functions are crazy flexible, and we should support them, but the same way we compress and standardize footprints we should apply for DRC rules

## Seve — 2026-09-22T21:09:27.852000+00:00

it's also just a lot easier to ask an AI to identify all the pinrequirements for a pin then have a super testable TSX outcome