Discussion:
[Ur] Key-value store extension
Athene Noctua
2018-01-29 15:43:10 UTC
Permalink
Hi all,

I find it useful to have a module for storing global configuration
settings and the likes in my applications, using a single table with
key and value fields and a simple get/set interface. Unfortunately
this approach breaks the nice encapsulation properties you get with
Ur/Web tables, as there's no way to control which module can access
which key, and trying to generate the keys to avoid collisions would
likely be cumbersome and break through multiple versions of the same
application.

I was wondering if this was a useful enough feature to be added into
the language, and if I should bother trying to hack it into the
compiler, or if I should just stick with writing a functor and make a
key-val table for each module that needs it instead.

For example:

key test : string

fun set_test { Test = t } =
storeSet test t

val main =
t <- storeGet test;
return <xml>
The value of test is {[Option.get "test" t]}.
<form><textbox{#Test}/><submit action={set_test}/></form>
</xml>

"key" is probably not a very good name, as adding it as a keyword it
would likely break a lot of existing code, but that's easy to change.

What do you think?

- Francesco
Adam Chlipala
2018-01-31 21:32:40 UTC
Permalink
That's an interesting idea.  It is not a feature that has ever occurred
to me to suggest.  I prefer to settle configuration at compile time, so
that the compiler can specialize code to chosen settings.  Have you
considered that path, too?
Post by Athene Noctua
Hi all,
I find it useful to have a module for storing global configuration
settings and the likes in my applications, using a single table with
key and value fields and a simple get/set interface. Unfortunately
this approach breaks the nice encapsulation properties you get with
Ur/Web tables, as there's no way to control which module can access
which key, and trying to generate the keys to avoid collisions would
likely be cumbersome and break through multiple versions of the same
application.
I was wondering if this was a useful enough feature to be added into
the language, and if I should bother trying to hack it into the
compiler, or if I should just stick with writing a functor and make a
key-val table for each module that needs it instead.
key test : string
fun set_test { Test = t } =
storeSet test t
val main =
t <- storeGet test;
return <xml>
The value of test is {[Option.get "test" t]}.
<form><textbox{#Test}/><submit action={set_test}/></form>
</xml>
"key" is probably not a very good name, as adding it as a keyword it
would likely break a lot of existing code, but that's easy to change.
What do you think?
- Francesco
Athene Noctua
2018-02-01 01:49:43 UTC
Permalink
I have, but in my opinion it's convenient to be able to change some
less important things from within the application.

For example, I have a sort of readme in the front page of my
application which I don't want to put in its own table because it's
the only one in the whole application, but I also don't really want to
hardcode it in and have to recompile and upload a new binary every
time I want to fix a typo or edit it. It's also useful if I'm not the
only administrator of the website but don't want to give others access
to the server.

I would find it useful for a few things like that, though admittedly
it wouldn't be much more than some compiler checks and some syntactic
sugar over what I'm doing right now.
That's an interesting idea. It is not a feature that has ever occurred to
me to suggest. I prefer to settle configuration at compile time, so that
the compiler can specialize code to chosen settings. Have you considered
that path, too?
Post by Athene Noctua
Hi all,
I find it useful to have a module for storing global configuration
settings and the likes in my applications, using a single table with
key and value fields and a simple get/set interface. Unfortunately
this approach breaks the nice encapsulation properties you get with
Ur/Web tables, as there's no way to control which module can access
which key, and trying to generate the keys to avoid collisions would
likely be cumbersome and break through multiple versions of the same
application.
I was wondering if this was a useful enough feature to be added into
the language, and if I should bother trying to hack it into the
compiler, or if I should just stick with writing a functor and make a
key-val table for each module that needs it instead.
key test : string
fun set_test { Test = t } =
storeSet test t
val main =
t <- storeGet test;
return <xml>
The value of test is {[Option.get "test" t]}.
<form><textbox{#Test}/><submit action={set_test}/></form>
</xml>
"key" is probably not a very good name, as adding it as a keyword it
would likely break a lot of existing code, but that's easy to change.
What do you think?
- Francesco
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
Ziv Scully
2018-02-01 05:28:05 UTC
Permalink
It seems like it should be simple to implement a Functor that has the same
semantics (if not number-of-tables efficiency) as the proposed keyword.
This approach is taken in, for instance, UPO's linear state machine
<https://github.com/achlipala/upo/blob/master/linearStateMachine.ur>.
Post by Athene Noctua
I have, but in my opinion it's convenient to be able to change some
less important things from within the application.
For example, I have a sort of readme in the front page of my
application which I don't want to put in its own table because it's
the only one in the whole application, but I also don't really want to
hardcode it in and have to recompile and upload a new binary every
time I want to fix a typo or edit it. It's also useful if I'm not the
only administrator of the website but don't want to give others access
to the server.
I would find it useful for a few things like that, though admittedly
it wouldn't be much more than some compiler checks and some syntactic
sugar over what I'm doing right now.
That's an interesting idea. It is not a feature that has ever occurred
to
me to suggest. I prefer to settle configuration at compile time, so that
the compiler can specialize code to chosen settings. Have you considered
that path, too?
Post by Athene Noctua
Hi all,
I find it useful to have a module for storing global configuration
settings and the likes in my applications, using a single table with
key and value fields and a simple get/set interface. Unfortunately
this approach breaks the nice encapsulation properties you get with
Ur/Web tables, as there's no way to control which module can access
which key, and trying to generate the keys to avoid collisions would
likely be cumbersome and break through multiple versions of the same
application.
I was wondering if this was a useful enough feature to be added into
the language, and if I should bother trying to hack it into the
compiler, or if I should just stick with writing a functor and make a
key-val table for each module that needs it instead.
key test : string
fun set_test { Test = t } =
storeSet test t
val main =
t <- storeGet test;
return <xml>
The value of test is {[Option.get "test" t]}.
<form><textbox{#Test}/><submit action={set_test}/></form>
</xml>
"key" is probably not a very good name, as adding it as a keyword it
would likely break a lot of existing code, but that's easy to change.
What do you think?
- Francesco
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
Loading...