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
username.patch
Description: Binary data
bugfix-daemon.patch
Description: Binary data
stdlib-additions.patch
Description: Binary data
mlton-opts.patch
Description: Binary data
_______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
