unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Jacob Hrbek <kreyren@rixotstudio.cz>
To: Jean Abou Samra <jean@abou-samra.fr>
Cc: "guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: Re: Feature request: Ability to document variables like defvar in elisp
Date: Sat, 05 Nov 2022 04:19:16 +0000	[thread overview]
Message-ID: <h6msNU2cZOILgu2EQXStdZn4aAcJAbrsjH8YsRaq26l3CD6Ci9I2PDmM5JUAp_ZKnp-BdT7c3zJbi2gFYgOYCH93Hdem3uqDRMZLbNruVMI=@rixotstudio.cz> (raw)
In-Reply-To: <890c5ce4-8191-54a6-dcd3-3c4b0f846415@abou-samra.fr>

To clarify I don't want to set the docstring to the value, but to the **variable name** like elisp, defining the docstring to the value seems insane to me.

First of all can we agree that the proposed syntax is a good idea that we want implemented?:

    (define variable value docstring)
                           ^^^^^^^^^

As to me it seems as very logical and intuitive solution.

Then if we can't implement it in guile due to it's current limitations then I propose to track the expected implementation as a bug and in the meantime declare e.g. macro in srfi-X that defines the immeiate and then uses the variable name to set the docstring to the variable name through appropriate code such as the one provided by Mikael Djurfeldt to be e.g. the familiar defvar or even define*:

    (defvar variable value docstring)
    => (define variable value)
    => (set-object-property! (module-variable (current-module) 'variable) 'documentation "Documentation here")

So that the common useless comments above variable definition can be removed from guile scripts and development environments such as https://github.com/Johni0702/guile-language-server adjusted to show the popup in emacs and when guile is able to use the proposed syntax to just s#defvar#define#gm

-- Jacob "Kreyren" Hrbek

------- Original Message -------
On Wednesday, November 2nd, 2022 at 9:28 AM, Jean Abou Samra <jean@abou-samra.fr> wrote:


> Le 02/11/2022 à 02:08, Jacob Hrbek a écrit :
> 
> > The ability to document variables is critical for many projects such
> > as libfive where the variables is used to declares functional computer
> > aided design structure and other projects where variables influence
> > the workflow.
> > 
> > Thus proposing to change the 'define' behavior for variables to implement:
> > 
> > (define variable default-value docstring)
> > ^^^^^^
> > 
> > Where docstring is optional and in case it's provided to call for example:
> > 
> > (set-procedure-property! variable 'documentation docstring)
> 
> 
> 
> 
> 
> The problem is that in Scheme, you cannot attach metadata to immediate
> values. According to the Scheme standards and the Guile documentation,
> 
> 
> (define a 5)
> (define b 5)
> 
> (eq? a b) => may be #t or #f
> 
> (eq? a a) => may be #t or #f
> 
> 
> 
> So it's considerably more complicated than using an object property,
> because that would not work reliably for variables defined to immediates
> like numbers and characters. Instead you would need to attach the
> metadata to the name you're defining the variable to, like Elisp does,
> but unlike Guile does with procedures right now, and it's not as simple
> in Scheme due to lexical scoping.
> 
> Best,
> Jean



      parent reply	other threads:[~2022-11-05  4:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02  1:08 Feature request: Ability to document variables like defvar in elisp Jacob Hrbek
2022-11-02  8:28 ` Jean Abou Samra
2022-11-02 10:15   ` Mikael Djurfeldt
2022-11-04 15:10     ` Jean Abou Samra
2022-11-05  4:19   ` Jacob Hrbek [this message]

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='h6msNU2cZOILgu2EQXStdZn4aAcJAbrsjH8YsRaq26l3CD6Ci9I2PDmM5JUAp_ZKnp-BdT7c3zJbi2gFYgOYCH93Hdem3uqDRMZLbNruVMI=@rixotstudio.cz' \
    --to=kreyren@rixotstudio.cz \
    --cc=guile-devel@gnu.org \
    --cc=jean@abou-samra.fr \
    /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).