dlet (need help): let: Symbol’s value as variable is void: wrs::variables

dlet (need help): let: Symbol’s value as variable is void: wrs::variables

[Jean Louis]

I just know that this code worked, and now it doesn't:

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

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

In my opinion when I define `wrs::variables' as being temporarily
global variable first time then it should be available in the second
line.

It did work before weeks or maybe 1-2 months. Now it doesn't.

Maybe this is bug.

No need to disadvise me using `dlet' as I do need it. Does anybody
know if this could be bug or why it does not work?


Jean

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

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

Re: dlet (need help): let: Symbol’s value as variable is void: wrs::variables

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> I just know that this code worked, and now it doesn't:
>
> (dlet ((wrs::variables (make-hash-table :test 'equal))
>        (wrs::_ (puthash "areas_name" "Hyperscope" wrs::variables)))
>   )
> [...]
> No need to disadvise me using `dlet' as I do need it. Does anybody
> know if this could be bug or why it does not work?

I think this should be due to this:

| b72f88518b Make dlet work like let, not let*
| Mattias Engdegård <mattiase@acm.org> Sun Aug 1 17:05:48 2021 +0200
| 
| 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.

There was a discussion about that before the change, should not be hard
to find if you are interested in the reasons.

AFAIR there were was not much interest in adding `dlet*'.


Michael.

Re: dlet (need help): let: Symbol’s value as variable is void: wrs::variables

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2021-09-21 02:18]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > I just know that this code worked, and now it doesn't:
> >
> > (dlet ((wrs::variables (make-hash-table :test 'equal))
> >        (wrs::_ (puthash "areas_name" "Hyperscope" wrs::variables)))
> >   )
> > [...]
> > No need to disadvise me using `dlet' as I do need it. Does anybody
> > know if this could be bug or why it does not work?
> 
> I think this should be due to this:
> 
> | b72f88518b Make dlet work like let, not let*
> | Mattias Engdegård <mattiase@acm.org> Sun Aug 1 17:05:48 2021 +0200
> | 
> | 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.
> 
> There was a discussion about that before the change, should not be hard
> to find if you are interested in the reasons.
> 
> AFAIR there were was not much interest in adding `dlet*'.


I have dynamic binding script `rcd-template-eval'

RCD Template Interpolation System for Emacs
https://hyperscope.link/3/7/1/3/3/RCD-Template-Interpolation-System-for-Emacs.html

If I call `rcd-template-eval' from dynamic binding script, I guess
that works well.

If I call it from lexical bound script but don't use the hash to pass
it to `rcd-template-eval' that also works.

If I wish to pass a hash to function `rcd-template-eval' from lexical
bound script, that does not work without `dlet' and that is now broken
as `dlet' behaves not any more similar to `let*'

I have only 4120 WWW pages currently depending on `dlet', that is
interest large enough for function to exist.

If there is other solution that would work, I am glad to accept
it, except that I cannot and do not want to change dynamically bound
script to lexical for reasons previously explained.


-- 
Jean

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

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