On Apr 22, 2022, at 05:39, Jean Abou Samra wrote:
>
> You both made a good point. My conclusion is that I should stick to
>
> {
> Local_assumption la (Lily::prebreak_estimate, SCM_BOOL_T);
> ...
> }
>
> where the constructor does everything, included scm_dynwind_begin ()
> and
Jean Abou Samra writes:
> Re call/cc: I would actually like to use
> static_cast (0)
> and not SCM_F_WIND_EXPLICITLY. I have no idea whether the stuff I write
> is going to interact gracefully with rewinding the stack via continuations,
> and I honestly don't want to wonder.We're using C++ (on
Le 22/04/2022 à 09:52, Luca Fascione a écrit :
[snipped]
Where the problem is that dwc.free(p) is actually effectively acting
as if it was dwc2.free(p); because the API doesn't pass around the
context like the C++ wrappers appear to do, rather it statefully "just
goes for it".
This is a
On Thu, Apr 21, 2022 at 11:46 PM Jean Abou Samra wrote:
> Well, the C++ and Scheme interfaces can feel different and idiomatic
> in their respective languages as long as they share the same
> underlying implementation.
>
I think this is a super important goal. In fact, I'd upgrade 'can' to
Le 21/04/2022 à 23:35, David Kastrup a écrit :
Properties will be coded a lot in Scheme. So the interface needs to map
naturally to Scheme programming.
Well, the C++ and Scheme interfaces can feel different and idiomatic
in their respective languages as long as they share the same
underlying
Jean Abou Samra writes:
> Le 21/04/2022 à 13:10, Dan Eble a écrit :
>> That is probably mostly due to your early remark that your
>> control-flow options are limited in the case of a with_fluid wrapper
>> taking a lambda. (It definitely steered my answer.)
>
>
> Well, I find it better if it
Le 21/04/2022 à 13:10, Dan Eble a écrit :
That is probably mostly due to your early remark that your
control-flow options are limited in the case of a with_fluid wrapper
taking a lambda. (It definitely steered my answer.)
Well, I find it better if it doesn't require reworking the control
Le 21/04/2022 à 12:58, David Kastrup a écrit :
My personal take on this would move the magic out of the normal reach of
users. You get (*start-column*) and (*end-column*) which you can use
for accessing the respective fluids but the function *start-column* does
not merely access %start-column
Le 21/04/2022 à 11:18, Han-Wen Nienhuys a écrit :
OK. I'm curious to see how that turns out.
I am too :-)
I've been intermittently working on this project for more than
6 months now. When I do an experimental refactoring, I make
a new branch from the current one to avoid losing the previous
On Apr 21, 2022, at 06:54, Jean Abou Samra wrote:
>
> Le 21/04/2022 à 12:47, David Kastrup a écrit :
>> So what one would want is a C++ wrapper working with functionals?
...
> So this needs an interface that is easier to use, whether it uses
> RAII or functionals or something else. Current
Jean Abou Samra writes:
> Le 21/04/2022 à 10:38, Han-Wen Nienhuys a écrit :
>> On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra wrote:
>>> I am working on code that pervasively utilizes Guile fluids. They should
>>> be set in dynamic scopes.
>> That sounds scary. Care to tell more?
>
> What is
Le 21/04/2022 à 12:47, David Kastrup a écrit :
So what one would want is a C++ wrapper working with functionals?
My criterion is rather convenience. scm_c_with_fluid could
be convenient if I could use it with a lambda. However, I cannot,
I'd need to define a separate function every time,
I wonder if you can 'chain' them:
Dynwind_context dwc2(dwc);
(you can at a minimum 'pause' dwc so to emit a runtime message that the
"wrong" thing is happening, but I guess you could hand yourself to your
parent and do more sophisticated shenanigans too... I must say I loathe
this stateful stuff
Jean Abou Samra writes:
>> Le 21/04/2022 11:05, David Kastrup a écrit :
>> Just for the record, your usage would not fit with the existing
>> lily/include/fluid.hh ,
>
>
> The existing code in fluid.hh is concerned with retrieving
> fluids. I'm asking about setting them. Whether the new code
>
On Apr 21, 2022, at 02:55, Luca Fascione wrote:
>
> I'd think you can up this by one, and get a cleaner looking piece of code
> if you implement scm_dynwind_fluid() as a forwarded method on your context:
...
> dwc.fluid (fluid2, value2);
Here's something that does bother me. That reads as if
Not sure why my message got mangled? Resending, properly formatted.
Le 21/04/2022 à 10:51, Jean Abou Samra a écrit :
Le 21/04/2022 à 10:38, Han-Wen Nienhuys a écrit :
On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra
wrote:
I am working on code that pervasively utilizes Guile fluids. They
On Thu, Apr 21, 2022 at 10:53 AM Jean Abou Samra wrote:
> >> On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra
> >> wrote:
> >>> I am working on code that pervasively utilizes Guile fluids. They
> >>> should
> >>> be set in dynamic scopes.
> >> That sounds scary. Care to tell more?
> >
> > What
> Le 21/04/2022 11:05, David Kastrup a écrit :
> Just for the record, your usage would not fit with the existing
> lily/include/fluid.hh ,
The existing code in fluid.hh is concerned with retrieving
fluids. I'm asking about setting them. Whether the new code
can go in fluid.hh is a question, but
Jean Abou Samra writes:
> Hi,
>
> It's me again ...
>
> I am working on code that pervasively utilizes Guile fluids. They should
> be set in dynamic scopes. In C++, usage of the Guile API looks like this:
>
> scm_dynwind_begin ();
> scm_dynwind_fluid (fluid, value);
> ...
>
Hi Luca,
Thanks for your insights! Much appreciated.
Le 21/04/2022 à 08:55, Luca Fascione a écrit :
I'd think you can up this by one, and get a cleaner looking piece of
code if you implement scm_dynwind_fluid() as a forwarded method on
your context:
{
Dynwind_context dwc; // overloaded
Le 21/04/2022 à 10:38, Han-Wen Nienhuys a écrit :
On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra wrote:
I am working on code that pervasively utilizes Guile fluids. They should
be set in dynamic scopes.
That sounds scary. Care to tell more?
What is scary about it exactly?
I am trying to
On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra wrote:
> I am working on code that pervasively utilizes Guile fluids. They should
> be set in dynamic scopes.
That sounds scary. Care to tell more?
--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
On Thu, Apr 21, 2022 at 8:12 AM Jean Abou Samra wrote:
> Le 21/04/2022 à 04:57, Dan Eble a écrit :
> > {
> >// dwc constructor calls scm_dynwind_begin ()
> >Dynwind_context dwc;
> >scm_dynwind_fluid (fluid1, value1);
> >scm_dynwind_fluid (fluid2, value2);
> >
Le 21/04/2022 à 04:57, Dan Eble a écrit :
On Apr 20, 2022, at 18:04, Jean Abou Samra wrote:
Calls to scm_dynwind_begin () and scm_dynwind_end () must be
paired correctly. Obviously, if '...' contains statements
causing non-local control flow like return, break, continue,
and such, it is easy
On Apr 20, 2022, at 18:04, Jean Abou Samra wrote:
>
> Calls to scm_dynwind_begin () and scm_dynwind_end () must be
> paired correctly. Obviously, if '...' contains statements
> causing non-local control flow like return, break, continue,
> and such, it is easy to miss a scm_dynwind_end (). I
Hi,
It's me again ...
I am working on code that pervasively utilizes Guile fluids. They should
be set in dynamic scopes. In C++, usage of the Guile API looks like this:
scm_dynwind_begin ();
scm_dynwind_fluid (fluid, value);
...
scm_dynwind_end ();
Docs:
26 matches
Mail list logo
