You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should write less and achieve more. We need some way to signal the existence of form fields to the shonkier runtime, so that field value requests can be handled. We should also be able to attach a preprocessor to a form field which eats text and emits a value or aborts; field value requests should yield the output of the preprocessor.
(One day, when our language is typed, the preprocessor will be type directed.)
We could have something like
`'foo`{.in type=text size=12}
to signal a form field bound to the atom 'foo. To access this field, invoke
'field('foo)
We might, further, write
`'bar <- parser`{.in type=text size=100}
where parser is an expression yielding a function which eats string literals.
The text was updated successfully, but these errors were encountered:
This is alive. We need to wire this up to some sort of ontological model. We also need to get some more active field manipulation happening in the javascript runtime.
Pandoc does allow us to write form elements, but only in that we're allowed to write things like
I think we should write less and achieve more. We need some way to signal the existence of form fields to the shonkier runtime, so that field value requests can be handled. We should also be able to attach a preprocessor to a form field which eats text and emits a value or aborts; field value requests should yield the output of the preprocessor.
(One day, when our language is typed, the preprocessor will be type directed.)
We could have something like
to signal a form field bound to the atom
'foo
. To access this field, invokeWe might, further, write
where
parser
is an expression yielding a function which eats string literals.The text was updated successfully, but these errors were encountered: