Re: master b72f885: Make dlet work like let, not let*

Re: master b72f885: Make dlet work like let, not let*

[Eli Zaretskii]

> branch: master
> commit b72f88518b89560accf740a4548368863e6238e0
> Author: Mattias Engdegård <mattiase@acm.org>
> Commit: Mattias Engdegård <mattiase@acm.org>
> 
>     Make dlet work like let, not let*
>     
>     Change `dlet` so that it has binding semantics like `let` because that
>     is what a user would expect and it allows a corresponding `dlet*` to
>     be added later should the need arise.  Fortunately the change has no
>     effect where it is currently used.
>     
>     * lisp/subr.el (dlet): Work like let.
>     * lisp/calendar/cal-bahai.el (calendar-bahai-date-string):
>     * lisp/calendar/cal-coptic.el (calendar-coptic-date-string):
>     * lisp/calendar/cal-dst.el (calendar-time-zone-daylight-rules)
>     (calendar-dst-starts, dst-in-effect):
>     * lisp/calendar/cal-persia.el (calendar-persian-date-string):
>     * lisp/calendar/calendar.el (calendar-dlet, calendar-generate-month)
>     (calendar-update-mode-line, calendar-date-string):
>     * lisp/calendar/diary-lib.el (diary-list-entries-2)
>     (diary-list-entries, diary-mark-entries-1, diary-sexp-entry)
>     (diary-remind, diary-font-lock-date-forms, diary-fancy-date-pattern):
>     * lisp/calendar/holidays.el (holiday-sexp):
>     * lisp/calendar/icalendar.el (icalendar--convert-float-to-ical):
>     * lisp/calendar/solar.el (solar-time-string):
>     * lisp/calendar/todo-mode.el (todo-date-pattern)
>     (todo-edit-item--header, todo-convert-legacy-date-time)
>     (todo-read-date):
>     Rename `calendar-dlet*` to `calendar-dlet` since it uses `dlet`.

Why is this change a good idea?  We had 'dlet' since more than a year
ago, so the ship has sailed quite some time ago, I'd say.

Re: master b72f885: Make dlet work like let, not let*

[Mattias Engdegård]

1 aug. 2021 kl. 18.10 skrev Eli Zaretskii <eliz@gnu.org>:

> We had 'dlet' since more than a year
> ago, so the ship has sailed quite some time ago, I'd say.

`dlet` is new in Emacs 28. There is no compatibility problem.

Re: master b72f885: Make dlet work like let, not let*

[Eli Zaretskii]

> Feedback-ID:mattiase@acm.or
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Tue, 3 Aug 2021 15:03:25 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>         emacs-devel <emacs-devel@gnu.org>
> 
> 1 aug. 2021 kl. 18.10 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > We had 'dlet' since more than a year
> > ago, so the ship has sailed quite some time ago, I'd say.
> 
> `dlet` is new in Emacs 28. There is no compatibility problem.

People out there use Emacs 28 for a long time, so of course there is a
compatibility problem, albeit a smaller one than if we have already
had released Emacs with dlet.

Could you please tell what were the reasons that led you to make this
change?  Because I don't really understand the motivation.  Is it just
the name that lacks the '*' part, or is it something else?

Re: master b72f885: Make dlet work like let, not let*

[Mattias Engdegård]

3 aug. 2021 kl. 15.33 skrev Eli Zaretskii <eliz@gnu.org>:

> People out there use Emacs 28 for a long time, so of course there is a
> compatibility problem, albeit a smaller one than if we have already
> had released Emacs with dlet.

Of course, but that's not really a compatibility promise but merely being nice, which we of course try to be but I'm quite sure that our esteemed Emacs 28 users understand that we didn't give them an iron-clad guarantee.

The change itself is also low-risk: it's an esoteric function and I've found no use of it anywhere outside the Emacs tree -- I did search. Furthermore, even inside Emacs all uses were found to be insensitive to the let/let* binding semantics.

However you do raise a good point. For incompatible changes in official releases we have etc/NEWS, but nothing really like it for things that we just broke on master. Perhaps it would be useful to have a document tracking these things so that everyone doesn't have to read every git diff to understand what is going on? `etc/NEWS.development`, say?

> Could you please tell what were the reasons that led you to make this
> change?  Because I don't really understand the motivation.  Is it just
> the name that lacks the '*' part, or is it something else?

Well sort of: if someones finds out about a construct named `dlet`, it's just natural to assume that it binds like `let`, not like `let*`. (Supporting evidence: two local macros on the pattern `something-dlet*` were in use. One of the has now been renamed.)

There is also the possibility of someone finding it useful to have a version with `let`-like binding (which is a more fundamental operation, after all). What would such a macro be called? `dlet*` would be terrible.

Furthermore, the subtle difference in semantics can lead to even subtler bugs: a dependency that is overlooked may not actually cause trouble until much later. Consider

(dlet ((case-fold-search t)
       (my-dynamic-variable EXPR)
  ...something that requires both bindings above...)

If the programmer thought in `let` terms and didn't consider the effects of case-fold-search on EXPR, he wouldn't have thought to test it with input that would exercise such a dependency.

Re: master b72f885: Make dlet work like let, not let*

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Tue, 3 Aug 2021 17:21:14 +0200
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> 3 aug. 2021 kl. 15.33 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > People out there use Emacs 28 for a long time, so of course there is a
> > compatibility problem, albeit a smaller one than if we have already
> > had released Emacs with dlet.
> 
> Of course, but that's not really a compatibility promise but merely being nice, which we of course try to be but I'm quite sure that our esteemed Emacs 28 users understand that we didn't give them an iron-clad guarantee.

It isn't iron-clad, but we should try to keep that promise unless
there are very good reasons to break it.  Which is why I asked about
the reasons for the change.

> The change itself is also low-risk

Risk of bugs is not relevant.  Risk of breaking someone's code cannot
be estimated at all.  And again, we just should try not to make such
changes after so many moods without a good reason, no matter what are
the other downsides.

> However you do raise a good point. For incompatible changes in official releases we have etc/NEWS, but nothing really like it for things that we just broke on master. Perhaps it would be useful to have a document tracking these things so that everyone doesn't have to read every git diff to understand what is going on? `etc/NEWS.development`, say?

Sounds like a maintenance burden with very little gains.

> > Could you please tell what were the reasons that led you to make this
> > change?  Because I don't really understand the motivation.  Is it just
> > the name that lacks the '*' part, or is it something else?
> 
> Well sort of: if someones finds out about a construct named `dlet`, it's just natural to assume that it binds like `let`, not like `let*`. (Supporting evidence: two local macros on the pattern `something-dlet*` were in use. One of the has now been renamed.)

If it's just the name, how about adding the "good" name and making the "bad"
name an obsolete alias?  That would at least avoid breaking any code
out there that could be using it.

Stefan, any comments?  Why did you name it "dlet" without the '*'?

Re: master b72f885: Make dlet work like let, not let*

[Stefan Monnier]

> If it's just the name, how about adding the "good" name and making the "bad"
> name an obsolete alias?  That would at least avoid breaking any code
> out there that could be using it.

I don't think it's worth the trouble.

> Stefan, any comments?  Why did you name it "dlet" without the '*'?

Because the * is unsightly ;-)


        Stefan

Re: master b72f885: Make dlet work like let, not let*

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Mattias Engdegård <mattiase@acm.org>,
>   emacs-devel@gnu.org
> Date: Tue, 03 Aug 2021 13:19:40 -0400
> 
> > If it's just the name, how about adding the "good" name and making the "bad"
> > name an obsolete alias?  That would at least avoid breaking any code
> > out there that could be using it.
> 
> I don't think it's worth the trouble.
> 
> > Stefan, any comments?  Why did you name it "dlet" without the '*'?
> 
> Because the * is unsightly ;-)

So what are your suggestions regarding this issue?  Leave it as it is
now, go back to what we had before, something else?

Re: master b72f885: Make dlet work like let, not let*

[Stefan Monnier]

>> Because the * is unsightly ;-)
> So what are your suggestions regarding this issue?
> Leave it as it is now, go back to what we had before, something else?

I'm OK with leaving it the was it is now.


        Stefan

Re: master b72f885: Make dlet work like let, not let*

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> So what are your suggestions regarding this issue?  Leave it as it is
> now, go back to what we had before, something else?

If you want another opinion: I find the name mildly confusing too.  It
has the potential that people write broken code (vs. we brake code
because of this change now).

And I think this is that kind of thing that tends to be discussed again
and again.

But it is definitely an extremely rarely used macro.  FWIW, I can't
remember the name for other reasons, I always search for something named
"fluid-let" (Scheme) or "dynamical-let" (vs. "lexical-let" we had
in the past) - but that may be only me.

Michael.

Re: master b72f885: Make dlet work like let, not let*

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mattiase@acm.org,  emacs-devel@gnu.org
> Date: Tue, 03 Aug 2021 14:50:10 -0400
> 
> >> Because the * is unsightly ;-)
> > So what are your suggestions regarding this issue?
> > Leave it as it is now, go back to what we had before, something else?
> 
> I'm OK with leaving it the was it is now.

Fine, but if someone complains about it, we will revert.

And Mattias, please in the future start a discussion about such
changes, instead of making them silently.

Re: master b72f885: Make dlet work like let, not let*

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Because the * is unsightly ;-)
>> > So what are your suggestions regarding this issue?
>> > Leave it as it is now, go back to what we had before, something else?
>> 
>> I'm OK with leaving it the was it is now.
>
> Fine, but if someone complains about it, we will revert.

I don't really have an opinion here, but I'll just note that if we're
calling this dlet* to have a consistent naming scheme for all let
macros, that ship sailed a long time ago when `when-let' was added
(which has more let*-ish semantics).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master b72f885: Make dlet work like let, not let*

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Wed, 04 Aug 2021 05:09:57 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So what are your suggestions regarding this issue?  Leave it as it is
> > now, go back to what we had before, something else?
> 
> If you want another opinion: I find the name mildly confusing too.  It
> has the potential that people write broken code (vs. we brake code
> because of this change now).
> 
> And I think this is that kind of thing that tends to be discussed again
> and again.

This is not the issue which bothered me, not at all.  What bothers me
is that we discuss the name of a macro that has been in our sources
for more than a year, and people and packages might depend on it.
Discussions about names should have been held a year ago, not now.
Now this is at most a minor issue that unfortunately slipped through
the cracks, and we shouldn't waste energy on arguing about it, same as
we do with typos or omissions in Git commit log messages: water under
the bridge.

> But it is definitely an extremely rarely used macro.  FWIW, I can't
> remember the name for other reasons, I always search for something named
> "fluid-let" (Scheme) or "dynamical-let" (vs. "lexical-let" we had
> in the past) - but that may be only me.

If I learned something during my 30+ years of using and developing
Emacs it's that usage patterns differ wildly between people.  What
looks rare and unimportant to me and you could be someone's bread and
butter.

Re: master b72f885: Make dlet work like let, not let*

[Mattias Engdegård]

4 aug. 2021 kl. 13.35 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> if we're
> calling this dlet* to have a consistent naming scheme for all let
> macros, that ship sailed a long time ago when `when-let' was added
> (which has more let*-ish semantics).

That's a good point, although with the counterpoint that we shouldn't let past mistakes prevent us from doing the right thing in the future.

Re: master b72f885: Make dlet work like let, not let*

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  mattiase@acm.org,
>   emacs-devel@gnu.org
> Date: Wed, 04 Aug 2021 13:35:59 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> I don't really have an opinion here, but I'll just note that if we're
> calling this dlet* to have a consistent naming scheme for all let
> macros, that ship sailed a long time ago when `when-let' was added
> (which has more let*-ish semantics).

I agree.  But it sounds like these arguments are not convincing
enough around here.

Re: master b72f885: Make dlet work like let, not let*

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 4 Aug 2021 13:46:02 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>,
>         emacs-devel@gnu.org
> 
> 4 aug. 2021 kl. 13.35 skrev Lars Ingebrigtsen <larsi@gnus.org>:
> 
> > if we're
> > calling this dlet* to have a consistent naming scheme for all let
> > macros, that ship sailed a long time ago when `when-let' was added
> > (which has more let*-ish semantics).
> 
> That's a good point, although with the counterpoint that we shouldn't let past mistakes prevent us from doing the right thing in the future.

No disagreement here, but in the case of dlet, the future ended a year
ago.

Re: master b72f885: Make dlet work like let, not let*

[Mattias Engdegård]

4 aug. 2021 kl. 14.16 skrev Eli Zaretskii <eliz@gnu.org>:

> No disagreement here, but in the case of dlet, the future ended a year
> ago.

We seem to disagree about that then.

Re: master b72f885: Make dlet work like let, not let*

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-08-01 19:11]:
> > branch: master
> > commit b72f88518b89560accf740a4548368863e6238e0
> > Author: Mattias Engdegård <mattiase@acm.org>
> > Commit: Mattias Engdegård <mattiase@acm.org>
> > 
> >     Make dlet work like let, not let*
> >     
> >     Change `dlet` so that it has binding semantics like `let` because that
> >     is what a user would expect and it allows a corresponding `dlet*` to
> >     be added later should the need arise.  Fortunately the change has no
> >     effect where it is currently used.

I am user and I do not expect it to work as `let' because `dlet' is
supposed to make temporarily global variables. Now it doesn't work:

(dlet ((wrs::variables (make-hash-table :test 'equal))
       (wrs::_ (puthash "areas_name" "Hyperscope" wrs::variables)))
  )

error: let: Symbol’s value as variable is void: wrs::variables

That is IMHO wrong, as it is supposed to bind variables
dynamically:

,----
| -- Special Form: dlet (bindings...) forms...
|     This special form is like ‘let’, but it binds all variables
|     dynamically.  This is rarely useful—you usually want to bind normal
|     variables lexically, and special variables (i.e., variables that
|     are defined with ‘defvar’) dynamically, and this is what ‘let’
|     does.
`----

My understanding is that `wrs::variables' should be available in the
second line but it is not. This broke my code and I am kindly
requesting to think about it and revert it back so that it does work.

This is full code below, and it is broken since this change, kindly
reconsider it as to the meaning of `dlet' as described in the Elisp
manual as `dlet' should bind variables dynamically thus make them also
available to all subsequent lines.

	(if template
	    (progn
	      (dlet ((wrs::variables (make-hash-table :test 'equal))
		     (wrs::_ (puthash "areas_name" "Hyperscope" wrs::variables))
		     (wrs::title title)
		     (wrs::keywords (string-join (split-string (hlink-tags id)) ", "))
		     (wrs::description description)
		     (wrs::_ (puthash "pages_content" (rcd-markdown text) wrs::variables))
		     (wrs::template (rcd-db-get-entry "templates" "templates_content" template hs-db))
		     (wrs::html (rcd-template-eval wrs::template '("⟦" "⟧") wrs::variables)))
		wrs::html))
	(rcd-mkd2html text title author date))))))


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: master b72f885: Make dlet work like let, not let*

[Jean Louis]

* Mattias Engdegård <mattiase@acm.org> [2021-08-03 18:22]:
> The change itself is also low-risk: it's an esoteric function and
> I've found no use of it anywhere outside the Emacs tree -- I did
> search. Furthermore, even inside Emacs all uses were found to be
> insensitive to the let/let* binding semantics.

If you don't use it, I do and it is one important function to my work,
I use it few times in few files related to variables interpolation in
templates and dynamic code fetching and re-use. And I have not ever
considered it `esoteric'.

grep --color=auto -nH -e dlet *.el
rcd-cf.el:6870:  (dlet ((wrs-text text))
rcd-cf.el:6889:  (dlet ((wrs::page (rcd-db-table-id-hash "pages" page-id cf-db))
rcd-cf.el:6919:    (dlet ((wrs::text (rcd-template-eval (gethash "pages_content" wrs::page "") '("⟦" "⟧") wrs::variables))
rcd-cf.el:6922:      (dlet ((wrs::template (gethash "templates_content" wrs::template))
rcd-utilities.el:1480:  (dlet ((wrs-processor "asciidoctor"))

> Well sort of: if someones finds out about a construct named `dlet`,
> it's just natural to assume that it binds like `let`, not like
> `let*`. (Supporting evidence: two local macros on the pattern
> `something-dlet*` were in use. One of the has now been renamed.)

For me it is not natural. `dlet' is supposed to bind variables
dynamically and with this change it doesn't. Basically the function is
ruined how I see it.

Your proposal is not logical and that you just changed it without
deeper analysis is very suprising.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: master b72f885: Make dlet work like let, not let*

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-08-04 14:41]:
> If I learned something during my 30+ years of using and developing
> Emacs it's that usage patterns differ wildly between people.  What
> looks rare and unimportant to me and you could be someone's bread and
> butter.

One big thank you for that.
---------------------------

I did not publish anything since before 1st August 2021 when this
change was introduced, and today I have discovered I cannot publish
anything more due to that change.

Thus all the Website Revision System stopped working for multiple
websites.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: master b72f885: Make dlet work like let, not let*

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

> I am user and I do not expect it to work as `let' because `dlet' is
> supposed to make temporarily global variables. Now it doesn't work:
>
> (dlet ((wrs::variables (make-hash-table :test 'equal))
>        (wrs::_ (puthash "areas_name" "Hyperscope" wrs::variables)))
>   )
>
> error: let: Symbol’s value as variable is void: wrs::variables
>
> That is IMHO wrong, as it is supposed to bind variables
> dynamically:

Being able to refer to variables earlier in the same binding form has
nothing do with dynamic binding.  `let' and `dlet' don't support that,
`let*' does, and as Mattias said, there could be a `dlet*' if someone
needs it.

What dlet allows you is to bind variables dynamically which are no
special variable (are not declared with defvar).  For example:

--8<---------------cut here---------------start------------->8---
(defun foo ()
  some-var)

(foo) ;; Lisp error: (void-variable some-var)

(dlet ((some-var 17))
  (foo)) ;=> 17
--8<---------------cut here---------------end--------------->8---

But instead of dlet you could just as well defvar some-var and use a
normal `let' instead.

Why can't you defvar wrs::variables?  Or maybe it already is?  In that
case, you could just replace `dlet' with `let*'.

Bye,
Tassilo

Re: master b72f885: Make dlet work like let, not let*

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2021-09-20 22:31]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > I am user and I do not expect it to work as `let' because `dlet' is
> > supposed to make temporarily global variables. Now it doesn't work:
> >
> > (dlet ((wrs::variables (make-hash-table :test 'equal))
> >        (wrs::_ (puthash "areas_name" "Hyperscope" wrs::variables)))
> >   )
> >
> > error: let: Symbol’s value as variable is void: wrs::variables
> >
> > That is IMHO wrong, as it is supposed to bind variables
> > dynamically:
> 
> Being able to refer to variables earlier in the same binding form has
> nothing do with dynamic binding.  `let' and `dlet' don't support that,
> `let*' does, and as Mattias said, there could be a `dlet*' if someone
> needs it.
> 
> What dlet allows you is to bind variables dynamically which are no
> special variable (are not declared with defvar).  For example:
> 
> --8<---------------cut here---------------start------------->8---
> (defun foo ()
>   some-var)
> 
> (foo) ;; Lisp error: (void-variable some-var)
> 
> (dlet ((some-var 17))
>   (foo)) ;=> 17
> --8<---------------cut here---------------end--------------->8---

> 
> But instead of dlet you could just as well defvar some-var and use a
> normal `let' instead.
> 
> Why can't you defvar wrs::variables?  Or maybe it already is?  In that
> case, you could just replace `dlet' with `let*'.

Thanks Tassilo for the tip, though I have tried to use `defvar' and
`let*' and that does not work in my case. I cannot technically explain
it why. Practically, lexical binding script is calling in my case
dynamical binding function.

By using `defvar' and subsequently `let*' I can avoid the first error.

I cannot however get the variables to pass over to the function in
dynamical binding script `rcd-template-eval' that is supposed to work
with variables.

This worked with `dlet' before, not it does not work.

Developer changed `dlet' to fit whatever programming habits, but
deleted the functionality of `dlet*'


I really need it.



rcd-template-eval: `eval' error: (void-variable languages_extension)
for match: 'languages_extension'rcd-template-eval: `eval' error:
(void-variable areas_id) for match: 'areas_id'rcd-template-eval:
`eval' error: (void-variable pages_categories) for match:
'pages_categories'rcd-template-eval: `eval' error: (void-variable
pages_id) for match: 'pages_id'rcd-template-eval: `eval' error:
(void-variable pages_copypage) for match:
'pages_copypage'rcd-template-eval: `eval' error: (void-variable
areas_company) for match: 'areas_company'rcd-template-eval: `eval'
error: (void-variable areas_url) for match:
'areas_url'rcd-template-eval: `eval' error: (void-variable
wrs::keywords) for match: '(xml-escape
wrs::keywords)'rcd-template-eval: `eval' error: (void-variable
wrs::description) for match: '(xml-escape
wrs::description)'rcd-template-eval: `eval' error: (void-variable
wrs::description) for match: '(xml-escape
wrs::description)'rcd-template-eval: `eval' error: (void-variable
open-graph-type) for match: 'open-graph-type'rcd-template-eval: `eval'
error: (void-variable areas_url) for match:
'areas_url'rcd-template-eval: `eval' error: (void-variable
wrs::description) for match: '(xml-escape
wrs::description)'rcd-template-eval: `eval' error: (void-variable
headerstuff) for match: 'headerstuff'rcd-template-eval: `eval' error:
(void-variable after_content) for match:
'after_content'rcd-template-eval: `eval' error: (void-variable
inquiry) for match: 'inquiry'rcd-template-eval: `eval' error:
(void-variable footerstuff) for match: 'footerstuff'Invalid face
reference: mail-double-quoted-text-face




Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: master b72f885: Make dlet work like let, not let*

[Tassilo Horn]

Hi Jean,

>> Why can't you defvar wrs::variables?  Or maybe it already is?  In
>> that case, you could just replace `dlet' with `let*'.
>
> Thanks Tassilo for the tip, though I have tried to use `defvar' and
> `let*' and that does not work in my case. I cannot technically explain
> it why. Practically, lexical binding script is calling in my case
> dynamical binding function.
>
> By using `defvar' and subsequently `let*' I can avoid the first error.
>
> I cannot however get the variables to pass over to the function in
> dynamical binding script `rcd-template-eval' that is supposed to work
> with variables.
>
> This worked with `dlet' before, not it does not work.
>
> Developer changed `dlet' to fit whatever programming habits, but
> deleted the functionality of `dlet*'
>
> I really need it.
>
> rcd-template-eval: `eval' error: (void-variable languages_extension)
> for match: 'languages_extension'rcd-template-eval: `eval' error:
> (void-variable areas_id) for match: 'areas_id'rcd-template-eval:

From that error, I assume you now have code like this:

(let* ((wrs::variables ...)
       (languages_extension (gethash "languages_extension" wrs::variables))
       (area_id (gethash "area_id" wrs::variables)))
  (do-stuff))

where the binding of languages_extension and area_id can access the new
value of the defvar wrs::variables (because of let*) but
languages_extension and area_id are only bound lexically (because they
are not defvar-ed and should not because of their missing prefix)
meaning they are bound only in the body of this `let*' (lexically!) but
not in `do-stuff' when it is called in this `let*'s body.  So for those,
you really need dlet.  Assuming that area_id never depends on the value
of languages_extension etc, you probably can use

(defvar wrs::variables nil)

(let ((wrs::variables ...))
  (dlet ((languages_extension (gethash "languages_extension" wrs::variables))
         (area_id (gethash "area_id" wrs::variables)))
    (do-stuff)))

Bye,
Tassilo

Re: master b72f885: Make dlet work like let, not let*

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2021-09-21 09:42]:
> where the binding of languages_extension and area_id can access the new
> value of the defvar wrs::variables (because of let*) but
> languages_extension and area_id are only bound lexically (because they
> are not defvar-ed and should not because of their missing prefix)
> meaning they are bound only in the body of this `let*' (lexically!) but
> not in `do-stuff' when it is called in this `let*'s body.  So for those,
> you really need dlet.  Assuming that area_id never depends on the value
> of languages_extension etc, you probably can use
> 
> (defvar wrs::variables nil)
> 
> (let ((wrs::variables ...))
>   (dlet ((languages_extension (gethash "languages_extension" wrs::variables))
>          (area_id (gethash "area_id" wrs::variables)))
>     (do-stuff)))

Thanks, those are good pointers. 

Though I did not explain everything. `dlet' is (was) used on my side
to interpolate bunch of information. Variables are also fetched from
the database and interpolated. In general there are too many issues
that I would need to refactor and think about it now, which is not
necessary. This gave me enough time waste.

My temporary personal solution is simply to bring it back how it was
and rename the macro to my own.

(defmacro rcd-dlet (binders &rest body)
  "Like `let*' but using dynamic scoping."
  (declare (indent 1) (debug let))
  ;; (defvar FOO) only affects the current scope, but in order for
  ;; this not to affect code after the main `let' we need to create a new scope,
  ;; which is what the surrounding `let' is for.
  ;; FIXME: (let () ...) currently doesn't actually create a new scope,
  ;; which is why we use (let (_) ...).
  `(let (_)
     ,@(mapcar (lambda (binder)
                 `(defvar ,(if (consp binder) (car binder) binder)))
               binders)
     (let* ,binders ,@body)))

As a side note, the advise for variables to be first `defvar-ed' if
they are to be used in `let*' is not practical. It increases work, it
does not lessen the work. 

You know when you start creating `let*' variables you don't want to
think much, just do it. Now I am supposed to make 50-100 `defvar-ed'
variables.

Instead I will just use the modified macro for myself, which does what
`dlet' was doing before August 1st 2021.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: master b72f885: Make dlet work like let, not let*

[Tassilo Horn]

Jean Louis <bugs@gnu.support> writes:

> My temporary personal solution is simply to bring it back how it was
> and rename the macro to my own.
>
> (defmacro rcd-dlet (binders &rest body)
>   "Like `let*' but using dynamic scoping."
>   (declare (indent 1) (debug let))
>   ;; (defvar FOO) only affects the current scope, but in order for
>   ;; this not to affect code after the main `let' we need to create a new scope,
>   ;; which is what the surrounding `let' is for.
>   ;; FIXME: (let () ...) currently doesn't actually create a new scope,
>   ;; which is why we use (let (_) ...).
>   `(let (_)
>      ,@(mapcar (lambda (binder)
>                  `(defvar ,(if (consp binder) (car binder) binder)))
>                binders)
>      (let* ,binders ,@body)))

Another variant would be like this which doesn't need to know the
mechanics of dlet but just creates a nested dlet:

(defmacro dlet* (bindings &rest body)
  (declare (indent 1) (debug let))
  (if bindings
      `(dlet (,(car bindings))
         (dlet* ,(cdr bindings)
                ,@body))
    `(progn ,@body)))

> As a side note, the advise for variables to be first `defvar-ed' if
> they are to be used in `let*' is not practical. It increases work, it
> does not lessen the work.

The advice is to defvar variables which should be dynamically bound, and
to have few of them because dynamic scope is very hard to debug.  So the
work saved at coding time might be invested when debugging later. ;-)

> You know when you start creating `let*' variables you don't want to
> think much, just do it. Now I am supposed to make 50-100 `defvar-ed'
> variables.

Well, it seems not to match your design.  If I would try to build a
templating system I'd try to have just one defvar-ed wcr::variables and
access that when replacing the template placeholders rather than having
to dlet each and every thing inside vcr::variables.

Bye,
Tassilo

Re: master b72f885: Make dlet work like let, not let*

[Jean Louis]

* Tassilo Horn <tsdh@gnu.org> [2021-09-21 11:52]:
> > As a side note, the advise for variables to be first `defvar-ed' if
> > they are to be used in `let*' is not practical. It increases work, it
> > does not lessen the work.
> 
> The advice is to defvar variables which should be dynamically bound, and
> to have few of them because dynamic scope is very hard to debug.  So the
> work saved at coding time might be invested when debugging
> later. ;-)

I understand the approach. On my side I look at it practically. I had
no problems with the implementation.

> > You know when you start creating `let*' variables you don't want to
> > think much, just do it. Now I am supposed to make 50-100 `defvar-ed'
> > variables.
> 
> Well, it seems not to match your design.  If I would try to build a
> templating system I'd try to have just one defvar-ed wcr::variables and
> access that when replacing the template placeholders rather than having
> to dlet each and every thing inside vcr::variables.

I understand idea, though I think with uncertainty, it would bring the
unwanted limitations.

With certainty I know that such change would give more problems then
it is worth, not less.

Once programmed it worked for months, and I have not touched it until
today. 

The RCD Template system it will interpolate any passed variables in
hash first, if any is there, otherwise global variables, including any
Emacs Lisp code. It does not expect by rule variables to be passed.



Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/