Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #16938

Re: Rust (was: Optimization by programmers)

Cross-posted to 2 groups.

Show all headers | View raw

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <2026Oct10.161800@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
[Anton Ertl:]
>I do not know what you are referring to when you write, the
>"fact that you did not find it"; did you not notice that I gave
>you _two_ programs, one of which was pretty much the same as the
>C program you gave?  What, exactly, are you referring to?

I was referring to your safe Rust solution.  However, I did not look
at it closely enough, especially at your insert, to realize that what
you had done is to turn search into lookup, and that you do not call
search from insert, like the C version does.

I just saw that there is a similar match in your insert as in search
(and the non-recursive Java version would also have that) and set out
to refine an existing linked-list implementation with insertion at the
end into a tree insertion that does not repeat the match, and I used
your match code from search for the parts that the linked-list
implementation does not do.

The list variant has the walk to the end separated from the actual
insertion, and the C tree variant also does it that way, and I wanted
the Rust version to do the same, but could not get it past the Rust
compiler.  The insertion code did not look particularly nice, either,
checking for something that is alreadu known in the search code.  so
to work around the compiler problem, I eventually decided to inline
the search code into insert, and I could get that to compile.

For testing I then added a lookup, which was derived from the search
part of insert, without mut stuff, so it's full circle back at your
search.

Anyway, yes, your insert does not work the Java version, but like the
C version with search() inlined into insert(), and like the insert I
finally arrived at.

Which leads to the question?  Can an experienced Rust programmer do a
search that works like the C search(), and an insert that calls
search() and then uses the reference to either update a node or insert
a new one?

>>Like your code and Java code, this has a separate type Tree with a
>>field root and with its own new function, while in C a "struct tree *"
>>variable can serve as root pointer; and this leads to an additional
>>line each in insert and lookup.  Can we do without most of that
>>(havibf a constructor is useful) and just use Subtree instead of Tree?
>
>Sure.  I do not think it is an interesting exercise, though.

I tried it for a while, and did not get anything but more and more
compiler errors.

>>The integration of search in insert led to a duplication of most of
>>the search code in lookup.  However, requiring a mutable reference is
>>not necessary for the lookup code, so a search that takes a mutable
>>reference and returns a mutable reference is too restrictive for
>>lookup.  But maybe a more experienced Rust programmer can write a
>>generic search that takes an &mut tree for insert, and a & for lookup.
>
>If it offends you that much, you could use a macro.

Good to know that there is this option.

>By analogy, in your C, how would it affect things if you wanted
>to `const` qualify the tree pointer for lookups?

C works perfectly fine without "const", so why would I want to do that?

By contrast, Rust is picky about "mut".  If I add it everywhere where
the syntax allows it (which might be the analogon of leaving "const"
away), the borrow checker will complain about programs that it
accepted before adding all the "mut"s.

>>I think that, in order to be the rightful heir, safe Rust should be
>>able to do everything one can do in the other language that's not
>>inherently unsafe, and do it without needing to duplicate code of
>>other nastyness.
>
>I think that criteria is both silly and arbitrary, and has no
>basis in actual practice.  You are asserting that an arbitrary
>implementation detail of this one program is a useful yardstick
>by which to measure a language's applicability to an entire
>problem domain,

Not one detail, the collection of all the details.  This is one.

>>You may wonder about "inherently unsafe": I have no
>>definition for that yet, but I would not kno why inserting a node into
>>a search tree would ever fall into that category,
>
>Actually, I think perhaps it's the other way around: you do not
>seem to know what "unsafe" means in a Rust context.  It is
>merely a statement that the compiler cannot infer that the
>"unsafe" code meets the language's memory safety criteria, and
>that the programmer is asserting that it does; 

I understand that.

>that is exactly
>the same as every line in a C program.

The decisive difference is that in a C program there is no end to an
unsafe block, where I have to satisfy safety criteria that are beyond
my experience level.

>I'm afraid that sounds like a problem for you to deal with, not
>a problem with Rust.

Sure, and the way I deal with that is to not use unsafe Rust.

>>What I mean is the automatic dropping, and the fact that the Box stuff
>>only occurs in the type declarations, but is automatically
>>dereferenced or otherwise automatically handled; "let x = ..."
>>produces a type automatically (but I guess you could put a type
>>declaration there, though).
>
>Drop and box as a smart pointer is simply "RAII", which has been
>in C++ since the 1980s.  Hindley and Milner created the type
>inference rules you are referring to here in the 1970s.

And?

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 18:29 +0000
  Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-10 14:18 +0000
    Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 17:31 +0000
      Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-11 15:40 +0000
        Re: Rust Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-11 14:26 -0400
          Re: Rust cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:14 +0000
          Re: Rust Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-12 21:15 +0000
        Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:13 +0000

csiph-web