unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Guile User <guile-user@gnu.org>
Subject: Weird behavior or bug for imports of functions with names of built-in functions
Date: Sat, 10 Jun 2023 15:27:46 +0000	[thread overview]
Message-ID: <a724419a-d38c-6e86-e43d-e10759757a0d@posteo.de> (raw)

Hello Guile Users!

Today I came across some weird behavior or perhaps even a bug. I will describe 
it in the following.

It seems like when I define a function, that has the same name as a built-in 
function, inside a (library ...) and then import that library with a (prefix 
(lib-name) my-prefix:), and then try to use (my-prefix:my-function ...) Guile 
still tries to use the built-in function, instead of the one I defined. In my 
case it lead to a type error.

I have code at 
https://notabug.org/ZelphirKaltstahl/sicp-solutions/src/430dd7451a893d039038791f3e8fbf0b58efe0b1/exercise-2.73 
that causes the problem:

~~~~
$ guile --fresh-auto-compile -L . -l solution-2-4-2.scm
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /home/user/dev/guile/guile-sicp/exercise-2.73/solution-2-4-2.scm
;;; compiling ./custom-exceptions.scm
;;; compiled /home/user/.cache/guile/ccache/3.0-LE-8-4.6/home/user/dev/guile/guile-sicp/exercise-2.73/custom-exceptions.scm.go
;;; compiling ./rectangular.scm
;;; compiling ./tagged-data.scm
;;; compiled /home/user/.cache/guile/ccache/3.0-LE-8-4.6/home/user/dev/guile/guile-sicp/exercise-2.73/tagged-data.scm.go
;;; compiling ./math.scm
;;; compiled /home/user/.cache/guile/ccache/3.0-LE-8-4.6/home/user/dev/guile/guile-sicp/exercise-2.73/math.scm.go
;;; compiled /home/user/.cache/guile/ccache/3.0-LE-8-4.6/home/user/dev/guile/guile-sicp/exercise-2.73/rectangular.scm.go
;;; compiling ./polar.scm
;;; compiled /home/user/.cache/guile/ccache/3.0-LE-8-4.6/home/user/dev/guile/guile-sicp/exercise-2.73/polar.scm.go
;;; compiled /home/user/.cache/guile/ccache/3.0-LE-8-4.6/home/user/dev/guile/guile-sicp/exercise-2.73/solution-2-4-2.scm.go
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.



scheme@(guile-user)> (rect:real-part (contents (attach-tag 'rectangular (cons 1 2))))



in contents: datum: (rectangular 1 . 2)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure real-part: Wrong type argument in position 1: (1 . 2)

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>
~~~~

(spacing added  for easier readability)

In the REPL I found by trying thing, something weird: real-part had a doc string:

~~~~
scheme@(guile-user) [1]> ,d rect:real-part
- Scheme Procedure: real-part z
      Return the real part of the number Z.
~~~~

But how could that be? I never wrote a doc string for my function … Then I 
realized, that somehow Guile must have gotten confused and itself probably 
already has a definition for a function named "real-part". A quick check:

~~~~
$ guile
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> real-part
$1 = #<procedure real-part (_)>
scheme@(guile-user)>
~~~~

So somehow, even though I imported with a prefix "rect:" and called it as 
`rect:real-part' Guile chose to use the built-in function `real-part', instead 
of what my library `rectangle.scm' exports.

The error is of course very confusing, because a pair would be exactly the right 
thing to give to my own real-part function. I began to put in debug prints to 
sanity check my understanding and noticed, that the one from my own real-part 
does not even print. But the one from polar.scm also did not print. It took me a 
few hours of head scratching, until I tried the `,describe real-part' thingy, 
and saw a suspicious doc string appear, which made me double check my imports, 
but I cannot find a mistake.

I think either I am overlooking something too obvious, or something weird is 
going on. It is not behaving like I would expect it to, which would be to use my 
own definition of real-part, from the library defined in `rectangle.scm'.

I could of course rename real-part, but I would like not to have to rename 
things, just because the built-in function has the same name. Also Guile did not 
warn me about redefining a built-in function, but I am not sure whether it does 
that or in which cases it does that.

Is this really a bug in Guile?

Is there a way around it, without renaming my own function, that does not 
require me to restructure everything?

Regards,
Zelphir

-- 
repositories:https://notabug.org/ZelphirKaltstahl


                 reply	other threads:[~2023-06-10 15:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a724419a-d38c-6e86-e43d-e10759757a0d@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).