Quantcast

Renaming "tag" and "log_err"

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Patrick Walton
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Marijn Haverbeke
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

David Rajchenbach-Teller
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"

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Brendan Eich
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Sebastian Sylvan
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Patrick Walton
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Peter Hull
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

David Rajchenbach-Teller
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Patrick Walton
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Marijn Haverbeke
> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Brendan Eich
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

austin seipp
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

David Rajchenbach-Teller
-----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-----

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Patrick Walton
> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Marijn Haverbeke
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.)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Graydon Hoare
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Graydon Hoare
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Patrick Walton
> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Graydon Hoare
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Renaming "tag" and "log_err"

Patrick Walton
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

12
Loading...