<div dir="ltr">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, <a href="https://github.com/achlipala/upo/blob/master/linearStateMachine.ur">UPO's linear state machine</a>.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 31, 2018 at 8:49 PM, Athene Noctua <span dir="ltr"><<a href="mailto:steenuil.owl@gmail.com" target="_blank">steenuil.owl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have, but in my opinion it's convenient to be able to change some<br>
less important things from within the application.<br>
<br>
For example, I have a sort of readme in the front page of my<br>
application which I don't want to put in its own table because it's<br>
the only one in the whole application, but I also don't really want to<br>
hardcode it in and have to recompile and upload a new binary every<br>
time I want to fix a typo or edit it. It's also useful if I'm not the<br>
only administrator of the website but don't want to give others access<br>
to the server.<br>
<br>
I would find it useful for a few things like that, though admittedly<br>
it wouldn't be much more than some compiler checks and some syntactic<br>
sugar over what I'm doing right now.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Jan 31, 2018 at 10:32 PM, Adam Chlipala <<a href="mailto:adamc@csail.mit.edu">adamc@csail.mit.edu</a>> wrote:<br>
> That's an interesting idea. It is not a feature that has ever occurred to<br>
> me to suggest. I prefer to settle configuration at compile time, so that<br>
> the compiler can specialize code to chosen settings. Have you considered<br>
> that path, too?<br>
><br>
><br>
> On 01/29/2018 10:43 AM, Athene Noctua wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> I find it useful to have a module for storing global configuration<br>
>> settings and the likes in my applications, using a single table with<br>
>> key and value fields and a simple get/set interface. Unfortunately<br>
>> this approach breaks the nice encapsulation properties you get with<br>
>> Ur/Web tables, as there's no way to control which module can access<br>
>> which key, and trying to generate the keys to avoid collisions would<br>
>> likely be cumbersome and break through multiple versions of the same<br>
>> application.<br>
>><br>
>> I was wondering if this was a useful enough feature to be added into<br>
>> the language, and if I should bother trying to hack it into the<br>
>> compiler, or if I should just stick with writing a functor and make a<br>
>> key-val table for each module that needs it instead.<br>
>><br>
>> For example:<br>
>><br>
>> key test : string<br>
>><br>
>> fun set_test { Test = t } =<br>
>> storeSet test t<br>
>><br>
>> val main =<br>
>> t <- storeGet test;<br>
>> return <xml><br>
>> The value of test is {[Option.get "test" t]}.<br>
>> <form><textbox{#Test}/><submit action={set_test}/></form><br>
>> </xml><br>
>><br>
>> "key" is probably not a very good name, as adding it as a keyword it<br>
>> would likely break a lot of existing code, but that's easy to change.<br>
>><br>
>> What do you think?<br>
>><br>
>> - Francesco<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Ur mailing list<br>
> <a href="mailto:Ur@impredicative.com">Ur@impredicative.com</a><br>
> <a href="http://www.impredicative.com/cgi-bin/mailman/listinfo/ur" rel="noreferrer" target="_blank">http://www.impredicative.com/<wbr>cgi-bin/mailman/listinfo/ur</a><br>
<br>
______________________________<wbr>_________________<br>
Ur mailing list<br>
<a href="mailto:Ur@impredicative.com">Ur@impredicative.com</a><br>
<a href="http://www.impredicative.com/cgi-bin/mailman/listinfo/ur" rel="noreferrer" target="_blank">http://www.impredicative.com/<wbr>cgi-bin/mailman/listinfo/ur</a><br>
</div></div></blockquote></div><br></div>