[Ur] Several patches and questions

[Austin Seipp]

On Wed, Nov 28, 2012 at 10:58 AM, Adam Chlipala <adamc at csail.mit.edu> wrote:
> Sorry for the delayed response; I won't try to give more of an excuse than
> "I've been busy." :-)  I'm very glad to have your contributions, and I'd
> also be interested in hearing more about any Ur/Web projects you're working
> on.

It's totally fine. I have an idea that I might take a stab at,
although right now it's mostly for prototyping a personal project and
a few little stumbles I hit. I will keep you in the loop, however :)

> Also, the patches you sent are missing username information.  Is that
> intentional?  I like to give credit to the right people in version control
> history, and usernames in patches make that easiest.

That's odd, I could have sworn I just regularly 'hg export'd them as I
did for prior patches. This was on a new machine though, so at the
time I crafted them I might have forgot my hgrc username. Looking at
it, it's there, but yes, it's strange. I'll be sure this is fixed in
the future. :)

> On 11/18/2012 06:08 PM, Austin Seipp wrote:
>>
>> Attached are some patches. In order:
>>
>> 1.) Add a 'username' tag, mostly to match 'password'. I wanted to have
>> a nice bootstrap-style login, but it wants the type attribute to be
>> 'text' for the login and 'password' for the pass, and there's no way
>> to specify the type for the attribute (you could theme this with CSS
>> or something, but this is just the out of the box config for bootstrap
>> it seems.) So this just specifies type="text" - This patch also adds
>> 'placeholder' attributes to 'username' and 'password' to match
>> 'textbox.'
>>
>
> What would you think about instead making the compiler include 'type="text"'
> with every <textbox> tag?  For this one especially, I'm interested in
> others' opinions, too.

I have no particular opinion here, although it sounds completely
sensible to me. Definitely up for outside thoughts.

>> 2.) A bugfix for 'urweb daemon stop'
>>
> I agree it was a bug.  Patch applied.
>

Sweet, thanks!

>> 3.) Standard library additions - add 'Basis.exp' for nums and
>> 'Option.unsafeGet' for mild convenience. I'm using these both in an
>> scrypt binding. I didn't bother to add any changes to the grammar to
>> support exponents, but that could be nice. :)
>>
>
>
> Patch applied, and then followed up with a cosmetic change of my own: I like
> [pow] better than [exp] for exponentiation, since the latter makes me think
> "expression" first, so I changed it.
>
> I think I'll skip changing the grammar for now.
>

That's fine, I don't really need the grammar change that much either
(and I didn't know what operator might be preferred anyway, which
would have its own ramifications.)

>> 4.) Enable MLton options in the 'Makefile', including DEBUG, PROFILE,
>> and I added VERBOSE. I like to see what the compiler is doing
>> sometimes while sipping my drink, and I don't see any reason why they
>> should be turned off. :)
>>
>
>
> Unfortunately, I had those parts of Makefile.am commented out because I
> couldn't figure out how to get them to work with Automake.  Presumably they
> work for you, but from the version in Debian stable, I get error messages
> like:
>     Makefile.am:52: endif without if
> I'd be happy to accept a patch for this functionality if it doesn't require
> super-new Autotools.

Yeah, I actually realized this the other day whenever I tried a clean
rebuild after submitting these. I probably made the change to
Makefile.am and then regenerated it from ./configure - but if you
completely regenerate your autoconf setup, then automake gets very mad
because it can't understand GNU-make 'ifeq' statements. It doesn't
seem like any autoconf version fixes this.

There could alternatively be an 'MLTON_OPTIONS' flag or something, but
at the moment I'm content with just tweaking the generated Makefile,
so I wouldn't worry about it too much. You can just drop this for now.

>
>> As for the questions, here are some things I might hack on if they are
>> deemed OK:
>>
>> 1.) I would like to be able to have the Ur/Web compiler build basic .c
>> files.
>
> Sounds completely reasonable, as it's an easy feature to ignore if unwanted.
>
>> I have an in flight patch that almost does this. It will add 2
>> directives to .urp files:
>>
>> 'CSource file.c'
>>
>> [...]
>>
>> 'COptions ...'
>>
>
>
> Sounds reasonable, except that I'd prefer lowercase directive names, to
> match the convention already in use for .urp files.

Awesome. I'll change the name to lowercase and try and get it emailed
in tonight. This is also the time for further bikeshedding over the
name of the option itself (coptions/csources,) before I submit the
patch. :)

>
>> 2.) Is it reasonable to support ad-hoc tags in the compiler, defined
>> by the user? Previously I proposed some tags as compiler patches, but
>> I realize this is inflexible. Instead, I would like to be able to
>> write a syntactic form similar to the basis library. Say:
>>
>>     tag audio : ...
>>
>
>
> I can support this easily with a small patch to allow tags to be defined in
> FFI modules beside [Basis].  The core tags don't have actual implementations
> anywhere, and it's easy to enable the same possibilities for tags in further
> FFI modules.  I.e., no need to define a C function returning a string.  (The
> identifier is used to figure out the tag name.)
>
> Sound good?

This would be really great, and would make it easy to ship something
like a small library with HTML5 tags + full attribute support.

One extra request if it's not too much of a burden: in the default
case, I think using the identifier to infer the tag name is correct.
However, would it be too much to ask if I could also somehow specify
via FFI opts what the identifier desugars to?

My use-case here is that things like Bootstrap (or your own CSS) can
use things like data-* attributes on tags for e.g. plugin events to
fire. I really prefer using this as opposing to bind tiny amounts of
JS just to set up my bootstrap plugin on some element (especially
since I then have to plumb the id around.)

But you don't necessarily want to write a tag trying to take into
account every possible data attribute, especially when people may have
their own attributes they want to add for their own styles/JS later.
And if the identifier *always* defines the resulting tag, then when
you have conflicts you may have to begin fully resolving the names to
remove ambiguity (i.e you may have two audio tags with slightly
different custom attributes, but you cannot have two 'audio's in
scope.)

It'd be nice if instead I could just say 'val customTag : ...' and
then say customTag=audio in my urp file or something, and when I say:

<customTag attr1={...} .../>

I get:

<audio attr1="..." .../>

in the result.

In fact, I don't even know if you can refer to a tag by it's qualified
name when using XML syntactic sugar, so if this wasn't the case, you'd
not only have to fully qualify, you couldn't use the sugar.

>> 3.) Is there a reason the 'num' type-class is closed, other than 'it
>> just is'?
>
>
> No one asked for it be open yet, so I didn't implement that. :)  I'd be glad
> to have a patch opening it.

OK. Opening 'num' is a bit more deep compiler internals than what I've
hacked on before, so I'll give it a shot. :)

FYI, I have at least 1 other patch I'll throw up tonight when I get
home (which adds OpenSSL-powered base64 encoding/decoding to Basis.)

-- 
Regards,
Austin