(possibly) unexpected behaviors compared to the spec (from a newbie)

[PoOnesNerfect]

Hello!

I am a complete beginner interested in functional programming so my questions here may be completely ignorant, in which case you can just ignore them.

I'm currently following a tutorial Yet Another Scheme Tutorial and reading r7rs.pdf and testing by running steel interpreter locally (cargo run).

While playing around with the interactive steel interpreter, I found some behaviors that are different than expected; I understand that many behaviors are up to the implementations, so wanted to know if there were docs or clarifications for expected behaviors of steel.

Below are the examples:

1. static strings share the same memory address while integers don't

(eq? "hello" "hello")
=> #true

(define a "hello")
(define b "hello")
(eq? a b)
=> #true

(define c (string-append a " world"))
(define d (string-append a " world"))
(eq? c d)
=> #false

(eq? 1 1)
=> #false

I assume this is an intended decision for optimization, but it would be very interesting if you could explain the story behind the decision.

2. floating points are not equal

(= 1.0 1.0)
=> #false

(= 1 1.0)
=> #false

(<= 1.0 1.0)
=> #true

Although this also could be up to implementations, I think a lot of interpreters I found say that = check equality of values, even for floating points. Is there a reason why this is different?

Is it not possible to check equality of floating points using =?

Even in r7rs.pdf, they have an example showing the following case:

(when (= 1 1.0)
(display "1")
(display "2")) => unspecified
and prints 12

meaning when returning value is unspecified, but the evaluation should print 12.

Btw, this is an amazing project, being able to embed rust structs and call rust functions from scheme; thank you, and I will continue to study Scheme and implementation of Steel.

[mattwparas]

Thanks for the kind words! I think you've found some bugs 😄

For the first point, yes, static strings are interned, so they will share the same memory address. Integers that are equal? should also be eq? - I'll make a PR to correct this and link it here. Looks like I just missed this case - funny what a bunch of fresh eyes on a project can find!

Per the second point, floating point equality in Rust can be tricky, and looks like I'm not correctly handling it. I'll include this as part of the above PR as well. Thanks for finding these!

[mattwparas]

This should be fixed in #89 - thanks again for catching this!

[PoOnesNerfect]

thank you for the quick response and updates! your explanation makes total sense, and fast fixes are awesome.