Re: [Ur] Key-value store extension

[Ziv Scully]

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
.

On Wed, Jan 31, 2018 at 8:49 PM, Athene Noctua 
wrote:

> 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.
>
> On Wed, Jan 31, 2018 at 10:32 PM, Adam Chlipala 
> wrote:
> > 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?
> >
> >
> > On 01/29/2018 10:43 AM, Athene Noctua wrote:
> >>
> >> 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 
> >>  The value of test is {[Option.get "test" t]}.
> >>  
> >>
> >>
> >> "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
> > Ur@impredicative.com
> > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
> ___
> Ur mailing list
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Key-value store extension

[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.

On Wed, Jan 31, 2018 at 10:32 PM, Adam Chlipala  wrote:
> 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?
>
>
> On 01/29/2018 10:43 AM, Athene Noctua wrote:
>>
>> 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 
>>  The value of test is {[Option.get "test" t]}.
>>  
>>
>>
>> "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
> Ur@impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] Key-value store extension

[Adam Chlipala]

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?


On 01/29/2018 10:43 AM, Athene Noctua wrote:

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 
 The value of test is {[Option.get "test" t]}.
 
   

"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
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

[Ur] Key-value store extension

[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.

For example:

key test : string

fun set_test { Test = t } =
  storeSet test t

val main =
  t <- storeGet test;
  return 
The value of test is {[Option.get "test" t]}.

  

"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
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur