A little bikeshedding:
Tags ---- In my experience "tag" has been confusing for newcomers to the language. It's consistent in that it's the only way to define a nominal type, but nominal types are more of a compiler writer's construct than a construct users of the language are used to thinking about. So I suggest instead that we change the keyword for variant-typed tags to "variant", and in the documentation, change the previous usages of "variant" to "case". The word "variant" suggests what the type actually means, and a lot of potential users of Rust will be coming from languages like C++, in which sum types don't exist. It's a lot easier to explain to newcomers "a variant value is one of several cases" than to say "a tag value is one of several variants". Additionally, "variant" and "case" match OCaml. Unfortunately, "variant" is 7 letters, which breaks our 5-character limit for keywords, but I think "var" would be even more confusing. Note that this means that will want a "newtype" keyword for the newtype syntax, and it could well just be "newtype" like Haskell. Logging ------- "log_err" is a bit unsightly, and I'm worried about releasing 0.1 without a nice-looking "hello world" program. So I propose renaming it to "print". Other suggestions welcome. This way our "hello world" program will look like: fn main() { print "Hello world!"; } Thoughts? Patrick |
It might be relevant that (for the same "hello world should be simple"
reason) recently added `std::io::print` and `std::io::println` to the stdlib. |
As a newbie, I confirm that both "tag" and "log_err" are quite
confusing. I confirm that "print" will be much better. If you want something shorter than "variant", here are a few, well, variants: - "sum" - "cases" - "choice" - "tags" (it's a plural) - "tagged" - "enum" (Java-style, not C++ style) - "family" - "alt" - "either" |
On Oct 28, 2011, at 3:25 PM, David Rajchenbach-Teller wrote:
> As a newbie, I confirm that both "tag" and "log_err" are quite > confusing. > > I confirm that "print" will be much better. +1 > If you want something shorter than "variant", here are a few, well, > variants: > - "sum" > - "cases" > - "choice" > - "tags" (it's a plural) > - "tagged" > - "enum" (Java-style, not C++ style) > - "family" > - "alt" > - "either" Thanks, good suggestions (although alt is taken and either is binary). I like "sum" first, "enum" second. /be |
In reply to this post by David Rajchenbach-Teller
On Fri, Oct 28, 2011 at 3:25 PM, David Rajchenbach-Teller
<dteller at mozilla.com> wrote: > If you want something shorter than "variant", here are a few, well, > variants: > - "sum" > - "cases" > - "choice" > - "tags" (it's a plural) > - "tagged" > - "enum" (Java-style, not C++ style) > - "family" > - "alt" > - "either" > How about "union"? C/C++ programmers will instantly get the gist of it, while probably suspecting that it'll be a safer version of the union construct they're familiar with. -- Sebastian Sylvan |
On 10/28/11 4:39 PM, Sebastian Sylvan wrote:
> How about "union"? C/C++ programmers will instantly get the gist of > it, while probably suspecting that it'll be a safer version of the > union construct they're familiar with. There was a concern that C/C++ programmers would mistake it for the unsafe version. Note that we guarantee C ABI compatibility for records, but we don't for unions. Additionally, using "union" for enums might look weird... Patrick |
In reply to this post by David Rajchenbach-Teller
On Fri, Oct 28, 2011 at 11:25 PM, David Rajchenbach-Teller
<dteller at mozilla.com> wrote: > As a newbie, I confirm that both "tag" and "log_err" are quite > confusing. > > I confirm that "print" will be much better. I disagree. I would expect print to be something that writes to stdout. As I understand it, log is a specialised debug/trace facility which is built-in and configurable. For example if you write log "hello world" it won't print anything unless RUST_LOG is set. I don't think it would be too mind blowing to introduce std::io::stdout() in the Hello World program. > > If you want something shorter than "variant", here are a few, well, > variants: I would have gone for union, for exactly the same reasons as Sebastian Sylvan. Pete |
On Sat Oct 29 09:55:13 2011, Peter Hull wrote:
> On Fri, Oct 28, 2011 at 11:25 PM, David Rajchenbach-Teller > <dteller at mozilla.com> wrote: >> As a newbie, I confirm that both "tag" and "log_err" are quite >> confusing. >> >> I confirm that "print" will be much better. > I disagree. I would expect print to be something that writes to > stdout. As I understand it, log is a specialised debug/trace facility > which is built-in and configurable. For example if you write log > "hello world" it won't print anything unless RUST_LOG is set. I don't > think it would be too mind blowing to introduce std::io::stdout() in > the Hello World program. Why not a "print" that (unconditionally) prints to stdout? >> If you want something shorter than "variant", here are a few, well, >> variants: > I would have gone for union, for exactly the same reasons as Sebastian Sylvan. Between "enum" and "union", I tend to favor "enum", for a simple reason: - attempting to use a variant as a C-style or Java-style enum will work flawlessly; - by opposition, attempting to use a variant as a C-style union will fail for reasons that will be very unclear for C programmers. Cheers, David |
On 10/29/2011 05:06 AM, David Rajchenbach-Teller wrote:
>> I disagree. I would expect print to be something that writes to >> stdout. As I understand it, log is a specialised debug/trace facility >> which is built-in and configurable. For example if you write log >> "hello world" it won't print anything unless RUST_LOG is set. I don't >> think it would be too mind blowing to introduce std::io::stdout() in >> the Hello World program. > > Why not a "print" that (unconditionally) prints to stdout? In my experience "log_err" is for quick and dirty "printf debugging", so stderr seems appropriate to me. It's not intended to be the main way for command-line programs to get stuff on the screen. It's not ideal for that purpose anyway, since it's polymorphic and you typically don't want to show the equivalent of toSource() output to end users. Perhaps "show" would be a better name, to make it clear that it's a debugging tool? Given what I just said above, maybe our hello world shouldn't encourage poor practices and should import the print function from the standard library. I'm a little concerned from a developer ergonomics/marketing perspective that we require an import statement for hello world (note that not even Java requires this), but I suppose it can't be helped unless we really want to have a std::pervasives module that's imported by default. > Between "enum" and "union", I tend to favor "enum", for a simple > reason: > - attempting to use a variant as a C-style or Java-style enum will work > flawlessly; > - by opposition, attempting to use a variant as a C-style union will > fail for reasons that will be very unclear for C programmers. I'd prefer to not use either, because variants are really a combination of enums and unions in the C/C++ sense. If we use "enum", the "union" aspect of variants will look weird to C folks; if we use "union", the "enum" aspect will likewise look weird. Patrick |
> but I suppose it can't be helped unless we really want to
> have a std::pervasives module that's imported by default. I've been thinking that something like the Haskell standard prelude (small, guaranteed to always be available) might be nice. It could hold some stuff like the std::option datatype, a print-to-stdout function, and a few other things that are really common in tiny programs. |
This seems like it will pay off for many, and rarely or never bite back. Have to keep it small, of course.
/be On Oct 29, 2011, at 10:11 AM, Marijn Haverbeke wrote: >> but I suppose it can't be helped unless we really want to >> have a std::pervasives module that's imported by default. > > I've been thinking that something like the Haskell standard prelude > (small, guaranteed to always be available) might be nice. It could > hold some stuff like the std::option datatype, a print-to-stdout > function, and a few other things that are really common in tiny > programs. > _______________________________________________ > Rust-dev mailing list > Rust-dev at mozilla.org > https://mail.mozilla.org/listinfo/rust-dev |
In reply to this post by Patrick Walton
On Sat, Oct 29, 2011 at 10:17 AM, Patrick Walton <pwalton at mozilla.com> wrote:
> In my experience "log_err" is for quick and dirty "printf debugging", so > stderr seems appropriate to me. It's not intended to be the main way for > command-line programs to get stuff on the screen. It's not ideal for that > purpose anyway, since it's polymorphic and you typically don't want to show > the equivalent of toSource() output to end users. > > Perhaps "show" would be a better name, to make it clear that it's a > debugging tool? > > Given what I just said above, maybe our hello world shouldn't encourage poor > practices and should import the print function from the standard library. > I'm a little concerned from a developer ergonomics/marketing perspective > that we require an import statement for hello world (note that not even Java > requires this), but I suppose it can't be helped unless we really want to > have a std::pervasives module that's imported by default. > As someone who's been writing Rust I agree that an introductory 'Hello World' should show probably the traditional means of printing directly to stdout (via std::io::println.) It's the direct analog to something like 'std::cout' or System.out.println after all for C++/Java, and 'log' as well as 'log_err' are both diagnostics facilities from my view. Just consider what it looks like right now between 'std::io::println' and 'log_err': $ cat hi1.rs use std; fn main() { std::io::println("Hello World!"); } $ ./hi1 Hello World! And log_err: $ cat hi2.rs use std; fn main() { log_err "Hello World!"; } $ ./hi2 rt: --- rt: 4259:main:main: "Hello World!" Personally I think this would be rather surprising at a first glance. I feel log/log_err should definitely be explained in their own right (or even just a small dedicated blurb) to explain their purpose as well as e.g. RUST_LOG. I see the manual has been catching up on this note. As for renaming them, given that I think they're mostly diagnostic utilities, I'm quite OK with just log/log_err as the names. In Haskell there's a 'Debug.Trace' module for printing things in pure code, with just a 'trace' function. So maybe just 'trace' for the log_err case? It does print to stdout in any case. But maybe that's not explanatory enough. I am also +1 for a Prelude-ish module to avert the import but I don't mind it much either way. std::option and perhaps some of the println things from std::io would probably be sufficient for it. -- Regards, Austin |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 As a newbie, I do not mind either way between importing std::io or having the function baked in a Pervasives/Prelude module. However, I concur that "log" is probably not the right tool for "Hello world". I also concur that names "log"/"log_err" do not accurately represent their behavior. What about renaming "log_err" to "dump" and "log" to "dump_log" or something such? Cheers, David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOrGbPAAoJED+FkPgNe9W+G9wH/2pBx09nGHb6/URZSvSbZK3W xXPLxYnisyQ/7CRgoes9T/sdzO8/PVV7QtLvIdhR6pCjdx/mORFv+VSvHbp/AbRS wjjTjCxC9RDgzcAvAnCqB6aGT3TTZSWMmfJvrvDxjeDTmXy66ctdcn4/sUa2mbp1 50BNTa+O6PC2YXdgxv8yL+Yyxxogg6A5Nu99zMgrdDX5rchoQa+w01s7ztXCS0lg iUkK9Q5erjTyXr+63yU3Jz8Ejs9OvRhfSjiU1bkrJzj2HVWNWlePibnJw2q9aZc7 1Qgc//hPw67UW1NAw8S+3JotFWtn2IFxWLbMHvEjCSa+QrDSPlT88vmpx1OELlk= =xq4n -----END PGP SIGNATURE----- |
> As a newbie, I do not mind either way between importing std::io or
> having the function baked in a Pervasives/Prelude module. However, I > concur that "log" is probably not the right tool for "Hello world". Looks like it's decided. Filed a bug to get us a Pervasives module: https://github.com/graydon/rust/issues/1096 > I also concur that names "log"/"log_err" do not accurately represent > their behavior. What about renaming "log_err" to "dump" and "log" to > "dump_log" or something such? Looks like we have "echo", "show", and "dump" as the three contenders, all equally short. Anyone have strong preferences? I'm inclined toward "show" if there's no consensus. Patrick |
Also relevant here: log_err was originally added as a stopgap
temporary solution, with the idea being that logging eventually would be a more primitive operation where you specified both a log level and a message, and there would be a macro that'd help you do this in a more nice-looking way. We have four log levels, but are only using two of them at the moment. Making log polymorphic has removed one reason for making it a macro (the idea was to integrate #fmt), but proper support for more log levels would still be nice. (Tangentially, the standard prelude, if such a thing materializes, would be the ideal spot for such a logging macro.) |
In reply to this post by David Rajchenbach-Teller
On 29/10/2011 5:06 AM, David Rajchenbach-Teller wrote:
> Between "enum" and "union", I tend to favor "enum", for a simple > reason: > - attempting to use a variant as a C-style or Java-style enum will work > flawlessly; > - by opposition, attempting to use a variant as a C-style union will > fail for reasons that will be very unclear for C programmers. If we have to rename it, I'd go with enum as well. Also for mapping C libs into rust-ese, it'll be nice to support providing-the-numbers style, as in: "enum x { foo=2; bar=16; }", which we currently don't support, but should. I'm not sure it's *that* weird for "enum" to be overloaded to mean "newtype" as well. People regularly use enum-in-C++ for just that reason: to make a type-disjoint int-like-thing. Let's try just renaming it and see how it goes. -Graydon |
In reply to this post by Marijn Haverbeke
On 31/10/2011 2:39 AM, Marijn Haverbeke wrote:
> Also relevant here: log_err was originally added as a stopgap > temporary solution, with the idea being that logging eventually would > be a more primitive operation where you specified both a log level > and a message, and there would be a macro that'd help you do this in a > more nice-looking way. We have four log levels, but are only using two > of them at the moment. Making log polymorphic has removed one reason > for making it a macro (the idea was to integrate #fmt), but proper > support for more log levels would still be nice. I agree. log_err was a kludge and I'd prefer to un-kludge it before shipping rather than adding another keyword. Multiple log-levels is the way to go. Macro if there's something relatively easy, or just keep 'log' as compiler-supported, but extend the syntax and include a bunch of log-level numeric constant names in the prelude (err, warn, info, debug, say?) > (Tangentially, the standard prelude, if such a thing materializes, > would be the ideal spot for such a logging macro.) Yes. Or just the constants, as above. -Graydon |
> I agree. log_err was a kludge and I'd prefer to un-kludge it before
> shipping rather than adding another keyword. Multiple log-levels is the > way to go. Macro if there's something relatively easy, or just keep > 'log' as compiler-supported, but extend the syntax and include a bunch > of log-level numeric constant names in the prelude (err, warn, info, > debug, say?) By the way, `alert` was suggested in a bug as a replacement for log_err (and as a synonym for log(err, ...)), which Marijn and I like. Has a cute JavaScripty feel to it. Patrick |
In reply to this post by Brendan Eich
On 29/10/2011 1:34 PM, Brendan Eich wrote:
> This seems like it will pay off for many, and rarely or never bite back. Have to keep it small, of course. Likely yes. Though we should offer a compiler flag / crate attribute to disable the auto-import of it. -Graydon |
On 11/8/11 9:41 AM, Graydon Hoare wrote:
> Likely yes. Though we should offer a compiler flag / crate attribute to > disable the auto-import of it. In fact, we'll have to, in order to bootstrap. Patrick |
Free forum by Nabble | Edit this page |