[Ur] Several patches and questions

[Austin Seipp]

Hi,

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

2.) A bugfix for 'urweb daemon stop' - it would exit -1 when the
daemon successfully closed it seems, but exit 0 when there was no
daemon to start, which is a bit confusing. This patch has a side
effect of making 'daemon stop' take priority over compiling a 'daemon'
project, but maybe there's a better way to do this. :)

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. :)

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. :)

OK, I think most of these are pretty uncontroversial and simple. Maybe
the unsafeGet thing is sketchy, but it saves me having to do the exact
same thing in a source file for convenience anyway (as a bonus,
because of the elaboration passes in the compiler, it seems unsafeGet
actually fails because it can't elaborate a valid type, in several
cases where it's statically known the argument is None :)

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. This is an optimization for the user: in a lot of cases, having
to maintain an entire autoconf-based build system (or waf, or
whatever) just to detect the Ur/Web compiler and it's #include paths,
and build like 3 C files into a library is kind of lame. And a lot of
work. A lot of times, I just have a couple of C files I want to drop
into the build (e.x. scrypt is 2 C files,) that need to be compiled
with my web app. This makes deployment a lot simpler for the vast
majority of libraries (I'd say almost every Ur/Web library could
probably drop most of the autoconf stuff with this in place,) and
makes development easier: I can just drop a library in a 'libs' folder
and have a 'libs.urp' that uses 'library' directives.

This is how GHC does things, and it is a big win for the user,
especially since if they want to interface with the runtime (via
"#include "urweb.h"") then the compiler can set the proper include
path, rather than them guessing or something or having to detect it.
The compiler doesn't offer a way to get it's canonical installation
path anyway to search for this stuff, other than going off the base
name of the binary path (which isn't necessarily accurate with
autoconf, if you have both $PREFIX and $DESTDIR set differently.)

In some cases this won't be necessary, you'll just compile a few C
files and have one function you FFI expose or whatever. Overall this
is a vast simplification for users and it would make my life much
happier. :)

I have an in flight patch that almost does this. It will add 2
directives to .urp files:

'CSource file.c'

This directive just adds a file to be compiled. It has the same
relative-style include semantics as 'library' (so deeply resolved
library chains in urp files will resolve correctly.) It compiles every
C file with some of the same basic options everything needs, like
include paths and optimization/debug settings.

'COptions ...'

This adds some options to every CSource file that's compiled. Maybe
you want to set a #define or something, or your own
warnings/optimizations. This is relatively similar to the link
directive.

Is this acceptable, and uncontroversial? I would really like it and am
free to changes, but overall it's a pretty simple idea. I have this
patch mostly in place modulo to the COptions stuff, so I could post a
diff later today.

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

in an .urs file, with the accompanying declaration 'tag audio' in the
implementation file. The type would be something reminiscent of the
Basis library types.

To prevent unbounded proliferation of tags, I would suggest a new
'allow' attribute so you can control what tags you allow, by referring
to the canonicalized name. So then I could write an HTML5 library with
some extra tags if people wanted, and they would say:

library libs/html5/
allow tag Html5.progress
allow tag Html5.video

etc. Now, a library itself could just say 'allow tag *', but libraries
can also say the same thing for CSS and URLs, so the same precautions
apply.

Is this feasible? Is it reasonable? Does anybody else want this? I
would actually like a 'video' tag in this case, without having to
build a nasty FFI function to just do it for me that violates type
safety and compiler guarantees and all that other great stuff. Given
the tags I have added and the code I have seen, this could make the
compiler a lot simpler too, at the expense of a massive refactoring it
seems. :) OTOH, if there's some way to support this out-of-band for
users in a simplistic manner, that would be nice too. But tags would
be great to have as a first-class abstraction so you can create your
own.

If this cannot be supported, then I guess I just have to go the FFI
route for now, and that pretty much just makes the case for Q1 (C
compilation) that much stronger.

3.) Is there a reason the 'num' type-class is closed, other than 'it
just is'? It would be nice for example, if I could write a library for
big integer support using OpenSSL's BN API, without hacking the
compiler. This isn't a crucial need, but I'd sometimes like to avoid
the possibility of overflow if I know I'm dealing with large integers.

This would mean you'd also need a way to coerce between int types
(user gives 'int', then I want to check for overflow, so I have to
promote to integer first.) So maybe this is a bit too much of an open
design question?


If these are reasonable at all I'm interested in working on them. I
already have the C compilation stuff there mostly, but I haven't put
any effort into the other things.

Thanks.

-- 
Regards,
Austin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: username.patch
Type: application/octet-stream
Size: 1576 bytes
Desc: not available
URL: <http://www.impredicative.com/pipermail/ur/attachments/20121118/8032f639/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugfix-daemon.patch
Type: application/octet-stream
Size: 1082 bytes
Desc: not available
URL: <http://www.impredicative.com/pipermail/ur/attachments/20121118/8032f639/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stdlib-additions.patch
Type: application/octet-stream
Size: 4823 bytes
Desc: not available
URL: <http://www.impredicative.com/pipermail/ur/attachments/20121118/8032f639/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mlton-opts.patch
Type: application/octet-stream
Size: 699 bytes
Desc: not available
URL: <http://www.impredicative.com/pipermail/ur/attachments/20121118/8032f639/attachment-0003.obj>