Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #142730

Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness

Show all headers | View raw

luser droog <luser.droog@gmail.com> writes:

> On Monday, April 1, 2019 at 5:55:40 PM UTC-5, Ben Bacarisse wrote:
>> M Joshua Ryan <luser.droog@gmail.com> writes:
<cut>
>> > object at( object a ){ return  a && a->t == SUSP  ? at( a->Susp.f( a->Susp.v ) ) : a; }
>> > object x( object a ){  return  a && a->t == LIST  ? a->List.a : NULL; }
<cut>
>> > object xs( object a ){ return  a && a->t == LIST  ? a->List.b = at( a->List.b ) : NULL; }
>> 
>> You are cleverly doing a sort of pauper's graph reduction with that
>> assignment.  It's a neat idea (in a sneaky sort of way), but I am used
>> to the suspension being evaluated when a value is actually used.  I hope
>> you don't find this is ever one step too soon.  If you did delay until
>> actual last-minute use, you would not be able to replace the list node,
>> so I see why you are doing it like this.
>
> That also came from the PS code. Since all list access goes through the x() and
> xs() functions, it was a convenient place to do the update.

If everything were "lazy", you could build a new list from the head and
tail of another, with no suspensions being evaluated.  You can't do this
if all list access goes through xs.

Thinking about this a bit more, you have made the tail position of a
list rather special.  Not only is the head never a suspension, but
(unless I've missed something else) the list itself can't be.  In
general, both head(a) and tail(a) would be valid on a SUSP object as
well as a LIST object, and tail(a) on a SUSP would evaluate the
suspension to get a list node and return the tail as is, even it was
itself a SUSP.

> I have considered
> adding comments to the parts where mutations happen. ///MUTATION!
> append() and join() would then needs such comments, but I think bind() might
> not since the mutations done by join() are entirely /internal/ in
> bind().

Don't do that on my account.  I was not complaining about the otherwise
hidden assignment.  After all, if everything is truly functional, the
assignment is simply an optimisation.

>> > object parse( object p, object input ){
>> >   return  p->t == PARSER  ? p->Parser.f( p->Parser.v, input ) : NULL;
>> > }
>> 
>> I am out of time but for one last remark, and I can make it here though
>> it applies to other functions too.  You might find it more helpful, down
>> the line, to replace the
>> 
>>   return check_type ? something : NULL;
>> 
>> pattern with
>> 
>>   retutn check_type_or_fail(), something;
>
> Do you mean '&&' instead of ','?

No, that would return 0 or 1.

I was not clear enough, by a long chalk.  The "_or_fail" in the name was
supposed to suggest a hard fail and an exit(!0) with an error message.
I should also have written it with some arguments.  It would probably be
more like

  return check_type_or_fail(a, PARSER, __func__), something;

I was in too much of a hurry.

<cut>
-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PC] Simulating Monads, Lambdas, Closures, and Laziness M Joshua Ryan <luser.droog@gmail.com> - 2019-04-01 16:26 -0500
  Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Chad <cdalten@gmail.com> - 2019-04-01 14:42 -0700
    Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness luser droog <luser.droog@gmail.com> - 2019-04-01 14:57 -0700
  Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-01 23:55 +0100
    Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness luser droog <luser.droog@gmail.com> - 2019-04-02 00:31 -0700
      Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness David Brown <david.brown@hesbynett.no> - 2019-04-02 10:25 +0200
        Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Manfred <noname@add.invalid> - 2019-04-02 14:11 +0200
          Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness David Brown <david.brown@hesbynett.no> - 2019-04-02 15:51 +0200
      Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-02 12:10 +0100
      Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness luser droog <luser.droog@gmail.com> - 2019-04-02 12:07 -0700
    Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-03 07:59 -0700
      Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-03 16:29 +0100
        Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-04-07 00:11 -0700
          Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness luser droog <luser.droog@gmail.com> - 2019-04-12 23:20 -0700
            Re: [PC] Simulating Monads, Lambdas, Closures, and Laziness Chad <cdalten@gmail.com> - 2019-04-13 04:42 -0700

csiph-web