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

Groups > comp.lang.c > #142781

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

Show all headers | View raw

[trimming without any further indication]

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> M Joshua Ryan <luser.droog@gmail.com> writes:
>
>> typedef union object *object;
>
> I'm not a fan of hiding a pointer like this.  It tripped me up for
> a while.  For the price of a space and a * you lose the ability to
> remind the reader that its pointers all the way down.

I have a different view.  When the primary type of an interface
is a pointer type and not the pointed-to type, it's better for
the interface to define a typedef name that includes the *, and
use that name in declaring the various interface functions, both
for parameters and return values.  Client code normally uses the
pointer type, not the pointed-to type;  following the principle
of information hiding, the pointerness is better held inside the
typedef name than forcing client code to be reminded at every
turn of more information than is needed.

There is a question of which type should be taken as "the primary
type", especially in settings like this one where there is no
explicit line between client code and code for the abstraction
(and certainly no clearcut expression of what constitutes "the
interface" to the abstraction).  But look at the source.  There
are, not counting the few bottom-level constructor functions,
roughly 30 functions.  About two-thirds of those don't access the
pointed-to internals at all, but just pass around values that
come from lower-level functions (or parameters, etc).  Most of
the code (counting by number of functions) doesn't need to know,
or care, that "under the hood" the values are actually pointers.
Furthermore any additional code is more likely not to need any
internal access either.  So it seems fair to say the primary type
here is the pointer type rather than the pointed-to type.

Incidentally, there is just one function ('new_') that takes the
pointed-to type as a parameter.  The source is easily changed so
new_() takes the pointer type instead (please excuse any changes
in whitespace style):

    object
    new_( object o ){
        object p = calloc( 1, sizeof *p );
        return  p ? *p = *o, p : 0;
    }
    #define OBJECT(...) new_( (union object[]){{ __VA_ARGS__ }} )

For reference, here is the original (modulo whitespace changes):

    object
    new_( union object o ){
        object p = calloc( 1, sizeof o );
        return  p ? *p = o, p : 0;
    }
    #define OBJECT(...) new_( (union object){ __VA_ARGS__ } )

Callers of new_() go through the OBJECT() macro exclusively,
which allows them to work without any further changes (kudos for
good factoring;  unfortunately a demerit for using 'sizeof o'
rather than 'sizeof *p').

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