better meta values?
31 views
Skip to first unread message
Matthew Butterick
May 29, 2019, 6:28:57 PM5/29/19
to Pollen
tl;dr
1) Would it be useful to allow meta values to be expressions, not merely datums?
2) Is anyone using identifiers or lists as meta values? Mostly my impression is that they're usually strings, numbers, or booleans (whose meaning wouldn't change with this upgrade).
I was thinking that it would be easy to make meta values expressions rather than datums, so that something like this:
◊(define-meta foo (* 6 7))
Means that the `foo` meta is 42.
You could, in theory, run anything you wanted there:
◊(define meta bar (let () (local-require every/module) (do-a-zillion-things))
This isn't quite backward-compatible. Datums that are self-quoting, like strings, numbers, and booleans, are the same under either system.
But things that look like evaluatable expressions — especially naked identifiers and lists — would be different.
◊(define-meta id bar)
Today, this results in a meta value of `'bar`. But if meta values are treated as expressions, it would just be `bar`, and trigger an unbound-identifier error.
Or again consider:
◊(define-meta foo (* 6 7))
Today, this results in a value of `'(* 6 7)`, but it would not under the new system.
I can't really tell, however, whether the theoretical benefits outweigh the theoretical costs.
1) Would it be useful to allow meta values to be expressions, not merely datums?
2) Is anyone using identifiers or lists as meta values? Mostly my impression is that they're usually strings, numbers, or booleans (whose meaning wouldn't change with this upgrade).
I was thinking that it would be easy to make meta values expressions rather than datums, so that something like this:
◊(define-meta foo (* 6 7))
Means that the `foo` meta is 42.
You could, in theory, run anything you wanted there:
◊(define meta bar (let () (local-require every/module) (do-a-zillion-things))
This isn't quite backward-compatible. Datums that are self-quoting, like strings, numbers, and booleans, are the same under either system.
But things that look like evaluatable expressions — especially naked identifiers and lists — would be different.
◊(define-meta id bar)
Today, this results in a meta value of `'bar`. But if meta values are treated as expressions, it would just be `bar`, and trigger an unbound-identifier error.
Or again consider:
◊(define-meta foo (* 6 7))
Today, this results in a value of `'(* 6 7)`, but it would not under the new system.
I can't really tell, however, whether the theoretical benefits outweigh the theoretical costs.
Joel McCracken
May 30, 2019, 12:43:28 AM5/30/19
to Matthew Butterick, Pollen
Well, I for one have a list of aliases for a page name, so that it might have multiple.
Sent from my iPhone
> --
> You received this message because you are subscribed to the Google Groups "Pollen" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pollenpub+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pollenpub/F1382F41-83DC-4864-8DEA-2D919DA7976F%40mbtype.com.
> For more options, visit https://groups.google.com/d/optout.
Sent from my iPhone
> You received this message because you are subscribed to the Google Groups "Pollen" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pollenpub+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pollenpub/F1382F41-83DC-4864-8DEA-2D919DA7976F%40mbtype.com.
> For more options, visit https://groups.google.com/d/optout.
Matthew Butterick
May 31, 2019, 2:07:04 PM5/31/19
to Pollen
Maybe the whole syntax of `define-meta` is idiosyncratic and we could add (without breaking any compatibility):
◊(meta-set! 'key (* 6 7))
Since `metas` is a hash, `meta-set!` would echo `hash-set!`. And as with `hash-set!`, the key and value would be expressions.
◊(meta-set! 'key (* 6 7))
Since `metas` is a hash, `meta-set!` would echo `hash-set!`. And as with `hash-set!`, the key and value would be expressions.
Joel McCracken
May 31, 2019, 2:29:23 PM5/31/19
to Matthew Butterick, Pollen
This would be fine by me!
--
You received this message because you are subscribed to the Google Groups "Pollen" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pollenpub+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pollenpub/E38816E6-5D29-4916-8EC3-40F14B3188E0%40mbtype.com.
Cole Lyman
Jun 6, 2019, 2:09:03 PM6/6/19
to Pollen
I think that this would be a useful update. It would solve a problem that I am currently running into where I am trying to store the
date struct from gregor in the metas table, but it isn't working because the meta values are not evaluated.Thanks,
Cole
Reply all
Reply to author
Forward
0 new messages