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

Groups > comp.lang.c > #74191 > unrolled thread

CAlive utility casks for arbitrary code injection as needed

Back to article view | Back to comp.lang.c

Contents

  CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-29 12:10 -0700
    Re: CAlive utility casks for arbitrary code injection as needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-29 20:05 +0000
    Re: CAlive utility casks for arbitrary code injection as needed Barry Schwarz <schwarzb@dqel.com> - 2015-10-29 14:36 -0700
      Re: CAlive utility casks for arbitrary code injection as needed asetofsymbols@gmail.com - 2015-10-29 14:55 -0700
      Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-29 15:46 -0700
        Re: CAlive utility casks for arbitrary code injection as needed Barry Schwarz <schwarzb@dqel.com> - 2015-10-29 18:17 -0700
    Re: CAlive utility casks for arbitrary code injection as needed Bartc <bc@freeuk.com> - 2015-10-29 21:48 +0000
      Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-29 16:00 -0700
        Re: CAlive utility casks for arbitrary code injection as needed Ian Collins <ian-news@hotmail.com> - 2015-10-30 14:25 +1300
          Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-29 18:41 -0700
            Re: CAlive utility casks for arbitrary code injection as needed Philip Lantz <prl@canterey.us> - 2015-10-29 21:51 -0700
              Re: CAlive utility casks for arbitrary code injection as needed gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-30 13:07 +0000
                Re: CAlive utility casks for arbitrary code injection as needed Philip Lantz <prl@canterey.us> - 2015-11-01 11:45 -0800
            Re: CAlive utility casks for arbitrary code injection as needed Ian Collins <ian-news@hotmail.com> - 2015-10-30 20:34 +1300
              Re: CAlive utility casks for arbitrary code injection as needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-30 02:09 -0700
                Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-10-30 11:12 +0100
                  Re: CAlive utility casks for arbitrary code injection as needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 12:03 +0000
                    Re: CAlive utility casks for arbitrary code injection as needed gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-30 13:16 +0000
                    Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-10-30 14:22 +0100
                      Re: CAlive utility casks for arbitrary code injection as needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-30 08:54 -0700
                        Re: CAlive utility casks for arbitrary code injection as needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 16:12 +0000
                          Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 09:32 -0700
                            Re: CAlive utility casks for arbitrary code injection as needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-30 09:57 -0700
                              Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 10:16 -0700
                              Re: CAlive utility casks for arbitrary code injection as needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 18:33 +0000
                                Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-10-30 22:28 +0100
                                  Re: CAlive utility casks for arbitrary code injection as needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 23:03 +0000
                                    Re: CAlive utility casks for arbitrary code injection as needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 01:35 -0700
                                      Re: CAlive utility casks for arbitrary code injection as needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 11:39 +0000
                                        Re: CAlive utility casks for arbitrary code injection as needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 12:04 -0700
                                          Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 17:56 -0700
                                            Re: CAlive utility casks for arbitrary code injection as needed Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-01 03:06 -0800
                        Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 09:28 -0700
              Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 04:24 -0700
                Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-10-30 13:04 +0100
                  Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 06:18 -0700
                    Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-10-30 16:23 +0100
                      Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 09:25 -0700
                      Re: CAlive utility casks for arbitrary code injection as needed gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-30 16:47 +0000
                        Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 10:13 -0700
                          Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 10:56 -0700
                        Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-10-31 17:04 +0100
                          Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 09:48 -0700
                          Re: CAlive utility casks for arbitrary code injection as needed gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-31 17:51 +0000
                            Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-11-01 00:10 +0100
                              Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 17:11 -0700
                                Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-11-01 15:24 +0100
                                  Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 06:37 -0800
                                    Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-11-01 21:21 +0100
                                      Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 16:39 -0800
                                        Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-11-02 02:02 +0100
                                          Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 17:17 -0800
          Re: CAlive utility casks for arbitrary code injection as needed raltbos@xs4all.nl (Richard Bos) - 2015-11-02 14:24 +0000
          Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 07:46 -0800
            Re: CAlive utility casks for arbitrary code injection as needed gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-02 16:30 +0000
              Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 08:46 -0800
            Re: CAlive utility casks for arbitrary code injection as needed Les Cargill <lcargill99@comcast.com> - 2015-11-02 12:20 -0600
              Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 10:23 -0800
              Re: CAlive utility casks for arbitrary code injection as needed David Brown <david.brown@hesbynett.no> - 2015-11-02 20:17 +0100
        Re: CAlive utility casks for arbitrary code injection as needed Bartc <bc@freeuk.com> - 2015-10-30 01:32 +0000
          Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-29 18:59 -0700
            Re: CAlive utility casks for arbitrary code injection as needed Philip Lantz <prl@canterey.us> - 2015-10-29 21:55 -0700
              Re: CAlive utility casks for arbitrary code injection as needed gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-30 13:10 +0000
                Re: CAlive utility casks for arbitrary code injection as needed Philip Lantz <prl@canterey.us> - 2015-11-01 11:45 -0800
            Re: CAlive utility casks for arbitrary code injection as needed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 10:55 +0000
    Re: CAlive utility casks for arbitrary code injection as needed Philip Lantz <prl@canterey.us> - 2015-10-29 22:00 -0700
      Re: CAlive utility casks for arbitrary code injection as needed "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 04:01 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#74191 — CAlive utility casks for arbitrary code injection as needed

One issue I've always had with C is the need sometimes to initialize
pass-thru values.  I thought this might be a nice way to visualize
the use of a cask.

Consider:

    01:   struct SAbc* abc;
    02:
    03:   for (....)
    04:   {
    05:       abc = NULL;
    06:       if (some_function(&abc))
    07:           // Do something
    08:   }
    09:
    10:   SAbc* some_function(struct SAbc** abcp)
    11:   {
    12:       if (some_condition)
    13:           *abcp = &some_other_abc_var;
    14:
    15:       return(*abcp);
    16:   }

In this case, the value of abc on line 06, it must be initialized on
line 05 before it can be used in this context because if it is not
initialized, it may contain a value from the prior iteration.

Rather than initialize the value on line 05, that code could be changed
into this, allowing the initialization to occur where it's needed:

    01:   struct SAbc* abc;
    02:
    03:   for (....)
    04:   {
    05:
    06:       if (some_function(  ~|abc=NULL;|~  &abc))
    07:           // Do something
    08:   }
    09:

In this context, the ~|utility|~ cask allows the arbitrary injection
of code into the otherwise syntactically correct statement.  It
initializes abc to NULL at the point of use, helping also to document
why that operation takes place.  And in a future vision, the entire
code surrounding that parameter can be logically extracted and placed
into a conceptual cask, one which would appear in source code like
this:

    05:                          +------------+
    06:       if (some_function(|| abc=NULL;  ||))
    07:           // Do somethin|| &abc       ||
    08:       }                  +------------+
    09:

Showing a type of graphical popup which visualizes all of the source
code which is associated with input into that parameter, allowing
the more traditional form as by the original line 05 up above to also
remain within the cask, but only within the view provided for by the
editor.  In source code, it is brought in to where it is used, which
conveys more closely the reason why it's needed at that point.

And, of course, with multiple similar parameters, they can all be
updated likewise, with each of them having their own parameter popup
window, showing the multi-line code which feeds into each parameter
as it's used.

-----
In a GUI editor it would be showing graphically what a utility cask
looks like, and it would appear visual.  In this text-based form I
have inserted extra spaces to make it stand out.  However, it could
actually appear like this in source code without any extra spaces:

    05:       if (some_function(~|abc=NULL;|~&abc))

But without the syntax highlighting, it is confusing to the eye,
even to my eye which is beginning to recognize casks.  With syntax
highlighting it would look something like this:

    In the upper-right editor window
    http://www.visual-freepro.org/images/vjr_047.png

    Here you see (|reference|) casks for (|width|) and (|height|)
    http://www.visual-freepro.org/images/vjr_053.png

Those are in VXB, which is an XBASE language.  However, they will
be identical in CAlive.  You can see their definition here beginning
around line 110:

    https://github.com/RickCHodgin/libsf/blob/master/exodus/tools/rdc/rdc_specs.txt

And I am working on getting my book completed here:

    https://github.com/RickCHodgin/libsf/blob/master/books/rdc/rdc.odt

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#74201

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> One issue I've always had with C is the need sometimes to initialize
> pass-thru values.  I thought this might be a nice way to visualize
> the use of a cask.
>
> Consider:
>
>     01:   struct SAbc* abc;
>     02:
>     03:   for (....)
>     04:   {
>     05:       abc = NULL;
>     06:       if (some_function(&abc))
>     07:           // Do something
>     08:   }
>     09:
>     10:   SAbc* some_function(struct SAbc** abcp)
>     11:   {
>     12:       if (some_condition)
>     13:           *abcp = &some_other_abc_var;
>     14:
>     15:       return(*abcp);
>     16:   }
>
> In this case, the value of abc on line 06, it must be initialized on
> line 05 before it can be used in this context because if it is not
> initialized, it may contain a value from the prior iteration.
>
> Rather than initialize the value on line 05, that code could be changed
> into this, allowing the initialization to occur where it's needed:

Alternatively (and more topically) you could use standard C:

>     01:   struct SAbc* abc;
>     02:
>     03:   for (....)
>     04:   {
>     05:
>     06:       if (some_function(  ~|abc=NULL;|~  &abc))

  if (some_function( (abc = NULL, &abc) ))

or, if the value of abc does not need to be retained:

  if (some_function( &(struct abc *){NULL} ))

>     07:           // Do something
>     08:   }

These many not be equivalent (you've never fully defined what a "cask"
is) but the first fits the description given here, and the second works
with the scant code outline you gave.

Much better would be to post an actual code sample, a real algorithm
that's got you bothered about how to write it in C, and people here can
then help with ideas on how they would do it.  (Such threads are often
very informative.)

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#74203

On Thu, 29 Oct 2015 12:10:12 -0700 (PDT), "Rick C. Hodgin"
<rick.c.hodgin@gmail.com> wrote:

>One issue I've always had with C is the need sometimes to initialize
>pass-thru values.  I thought this might be a nice way to visualize
>the use of a cask.
>
>Consider:
>
>    01:   struct SAbc* abc;
>    02:
>    03:   for (....)
>    04:   {
>    05:       abc = NULL;
>    06:       if (some_function(&abc))
>    07:           // Do something
>    08:   }
>    09:
>    10:   SAbc* some_function(struct SAbc** abcp)
>    11:   {
>    12:       if (some_condition)
>    13:           *abcp = &some_other_abc_var;
>    14:
>    15:       return(*abcp);
>    16:   }
>
>In this case, the value of abc on line 06, it must be initialized on
>line 05 before it can be used in this context because if it is not
>initialized, it may contain a value from the prior iteration.

The value of abc is not passed to some_function.  Only its address is
passed.  Since some_function does not attempt to evaluate the value
pointed to by abcp, there is no need to initialize abc prior to the
call.

Even if abc contained a value from a prior iteration, some_function
changes that value without regard to the previous value.


-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#74209

Barry Schwarz  wrote:
The value of abc is not passed to some_function.  Only its address is 
passed.  Since some_function does not attempt to evaluate the value 
pointed to by abcp, there is no need to initialize abc prior to the 
call. 

Even if abc contained a value from a prior iteration, some_function 
changes that value without regard to the previous value.
------
I agree; for me initialization
for the pointer has to be inside
the function: Example
u32  *p;

f(&p, args)

Where
i32 f(u32** pp, args)
{...
 if(pp==0) return -1;
 *pp=0;

}

[toc] | [prev] | [next] | [standalone]

#74213

On Thursday, October 29, 2015 at 5:36:21 PM UTC-4, Barry Schwarz wrote:
> On Thu, 29 Oct 2015 12:10:12 -0700 (PDT), "Rick C. Hodgin"
> <rick.c.hodgin@gmail.com> wrote:
> 
> >One issue I've always had with C is the need sometimes to initialize
> >pass-thru values.  I thought this might be a nice way to visualize
> >the use of a cask.
> >
> >Consider:
> >
> >    01:   struct SAbc* abc;
> >    02:
> >    03:   for (....)
> >    04:   {
> >    05:       abc = NULL;
> >    06:       if (some_function(&abc))
> >    07:           // Do something
> >    08:   }
> >    09:
> >    10:   SAbc* some_function(struct SAbc** abcp)
> >    11:   {
> >    12:       if (some_condition)
> >    13:           *abcp = &some_other_abc_var;
> >    14:
> >    15:       return(*abcp);
> >    16:   }
> >
> >In this case, the value of abc on line 06, it must be initialized on
> >line 05 before it can be used in this context because if it is not
> >initialized, it may contain a value from the prior iteration.
> 
> The value of abc is not passed to some_function.  Only its address is
> passed.  Since some_function does not attempt to evaluate the value
> pointed to by abcp, there is no need to initialize abc prior to the
> call.

In this example, the called function assigns a pointer to the pointer-
to-pointer passed by &abc.

> Even if abc contained a value from a prior iteration, some_function
> changes that value without regard to the previous value.

some_function() doesn't always update the value.  If it didn't update
it, the pass-thru NULL value would be desired.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74215

On Thu, 29 Oct 2015 15:46:55 -0700 (PDT), "Rick C. Hodgin"
<rick.c.hodgin@gmail.com> wrote:

>On Thursday, October 29, 2015 at 5:36:21 PM UTC-4, Barry Schwarz wrote:
>> On Thu, 29 Oct 2015 12:10:12 -0700 (PDT), "Rick C. Hodgin"
>> <rick.c.hodgin@gmail.com> wrote:
>> 
>> >One issue I've always had with C is the need sometimes to initialize
>> >pass-thru values.  I thought this might be a nice way to visualize
>> >the use of a cask.
>> >
>> >Consider:
>> >
>> >    01:   struct SAbc* abc;
>> >    02:
>> >    03:   for (....)
>> >    04:   {
>> >    05:       abc = NULL;
>> >    06:       if (some_function(&abc))
>> >    07:           // Do something
>> >    08:   }
>> >    09:
>> >    10:   SAbc* some_function(struct SAbc** abcp)
>> >    11:   {
>> >    12:       if (some_condition)
>> >    13:           *abcp = &some_other_abc_var;
>> >    14:
>> >    15:       return(*abcp);
>> >    16:   }
>> >
>> >In this case, the value of abc on line 06, it must be initialized on
>> >line 05 before it can be used in this context because if it is not
>> >initialized, it may contain a value from the prior iteration.
>> 
>> The value of abc is not passed to some_function.  Only its address is
>> passed.  Since some_function does not attempt to evaluate the value
>> pointed to by abcp, there is no need to initialize abc prior to the
>> call.
>
>In this example, the called function assigns a pointer to the pointer-
>to-pointer passed by &abc.

I don't see that.  The called function stores a value in the object
pointed to by abcp.  That object is abc.  abc is a pointer, not a
pointer-to-pointer.

But I see now that if some_condition is false, the function will
return the value of abc and therefore it needs to be
initialized/assigned prior to the function call.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#74207

On 29/10/2015 19:10, Rick C. Hodgin wrote:

>      03:   for (....)
>      04:   {
>      05:       abc = NULL;
>      06:       if (some_function(&abc))
>      07:           // Do something
>      08:   }

>      03:   for (....)
>      04:   {
>      05:
>      06:       if (some_function(  ~|abc=NULL;|~  &abc))
>      07:           // Do something
>      08:   }
>      09:

The first example is a lot easier to understand than the second. And 
it's simpler (I assume they do the same thing. If not, then that's 
another problem.)

(It helps sometimes if you imagine yourself trying to dictate code over 
the phone. The second example would tie you both up in knots.)

IMO.

If you want to sell the idea of 'casks', you need a better example I think.

Does ~|....|~ denote a bit of code that is not immediately evaluated 
(maybe like QUOTE in Lisp)? If so, then perhaps {...} (used in an 
expression context) might be better, although it's still not clear how 
it would be used.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#74214

On Thursday, October 29, 2015 at 5:48:26 PM UTC-4, Bart wrote:
> Does ~|....|~ denote a bit of code that is not immediately evaluated 
> (maybe like QUOTE in Lisp)?

The ~|utility|~ cask is an arbitrary injection of any code.  It will
be inserted at whatever point you insert the cask in a statement.
The contents of the utility can contain anything.  If it is a larger
block it will be filled with multi-line content between the ~| and |~
sides.  However, CAlive provides for another feature whenever larger
bits of code are required.  They would typically be used, along with
the (|reference|) casks, instead of the ~|utility|~ cask:

    // adhocs are basically local functions, but they are defined
    // near where they're used to remove some complex logic for use
    // of a placeholder.
    adhoc somename
    {
        // Complex/larger code goes here
    }

    example(  (|somename|)  ...);

    // adhoc functions can also be called as normal functions:
    somename();

    // Or as stand-alone casks:
    (|somename|);

With casks, you can inject the code at any point in the flow.

To pass a parameter, use the (|reference|param||) syntax.  To return
a value, use the (||return|reference|) syntax.  To use both use the
(||return|reference|param||) syntax.  These have the equivalents of
reference(param);, return = reference();, and return = reference(param);
operations.

And, they can be dropped in at any point in code:

    adhoc value(int x)
    {
        printf("%d\n", x);
    }

    printf("%d\n", (|value|x||) some_function(&x) (|value|x||) );

In this case, (|value|) is called twice with the value x.  In this
case, x is updated by the some_function() call, so the cask on the
left is called before some_function(&x); is called, and the cask on
the right is called after x is updated, showing two potentially
different values and all of this happens before the outer printf()
is called.

It's just a way to inject arbitrary code at any location, allowing
for parameters to be passed, and return values to be received.

> If so, then perhaps {...} (used in an 
> expression context) might be better, although it's still not clear how 
> it would be used.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74218

Rick C. Hodgin wrote:
> On Thursday, October 29, 2015 at 5:48:26 PM UTC-4, Bart wrote:
>> Does ~|....|~ denote a bit of code that is not immediately evaluated
>> (maybe like QUOTE in Lisp)?
>
> The ~|utility|~ cask is an arbitrary injection of any code.  It will
> be inserted at whatever point you insert the cask in a statement.
> The contents of the utility can contain anything.  If it is a larger
> block it will be filled with multi-line content between the ~| and |~
> sides.  However, CAlive provides for another feature whenever larger
> bits of code are required.  They would typically be used, along with
> the (|reference|) casks, instead of the ~|utility|~ cask:

If I remember correctly, the last time this topic came up it was 
demonstrated that C++ cam already do what you were after.

You should broaden your knowledge of other languages before trying to 
reinvent wheels.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#74221

On Thursday, October 29, 2015 at 9:25:39 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Thursday, October 29, 2015 at 5:48:26 PM UTC-4, Bart wrote:
> >> Does ~|....|~ denote a bit of code that is not immediately evaluated
> >> (maybe like QUOTE in Lisp)?
> >
> > The ~|utility|~ cask is an arbitrary injection of any code.  It will
> > be inserted at whatever point you insert the cask in a statement.
> > The contents of the utility can contain anything.  If it is a larger
> > block it will be filled with multi-line content between the ~| and |~
> > sides.  However, CAlive provides for another feature whenever larger
> > bits of code are required.  They would typically be used, along with
> > the (|reference|) casks, instead of the ~|utility|~ cask:
> 
> If I remember correctly, the last time this topic came up it was 
> demonstrated that C++ cam already do what you were after.

And as I told you back then, and you refused to listen to it, C++
cannot do what casks do.  Nor a dozen other things I propose in
my language.

> You should broaden your knowledge of other languages before trying to 
> reinvent wheels.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#74225

Rick C. Hodgin wrote:
> 
> On Thursday, October 29, 2015 at 9:25:39 PM UTC-4, Ian Collins wrote:
> > Rick C. Hodgin wrote:
> > > On Thursday, October 29, 2015 at 5:48:26 PM UTC-4, Bart wrote:
> > >> Does ~|....|~ denote a bit of code that is not immediately evaluated
> > >> (maybe like QUOTE in Lisp)?
> > >
> > > The ~|utility|~ cask is an arbitrary injection of any code.  It will
> > > be inserted at whatever point you insert the cask in a statement.
> > > The contents of the utility can contain anything.  If it is a larger
> > > block it will be filled with multi-line content between the ~| and |~
> > > sides.  However, CAlive provides for another feature whenever larger
> > > bits of code are required.  They would typically be used, along with
> > > the (|reference|) casks, instead of the ~|utility|~ cask:
> > 
> > If I remember correctly, the last time this topic came up it was 
> > demonstrated that C++ cam already do what you were after.
> 
> And as I told you back then, and you refused to listen to it, C++
> cannot do what casks do.  Nor a dozen other things I propose in
> my language.

Perhaps, but it *can* do everything you have shown in your examples. If 
you want to show casks' utility, you might wish to expand your examples 
to show things that C++ cannot do.

[toc] | [prev] | [next] | [standalone]

#74282

In article <MPG.309c972cb500f5d058@news.eternal-september.org>,
Philip Lantz  <prl@canterey.us> wrote:
>Rick C. Hodgin wrote:
>> 
>> On Thursday, October 29, 2015 at 9:25:39 PM UTC-4, Ian Collins wrote:
>> > Rick C. Hodgin wrote:
>> > > On Thursday, October 29, 2015 at 5:48:26 PM UTC-4, Bart wrote:
>> > >> Does ~|....|~ denote a bit of code that is not immediately evaluated
>> > >> (maybe like QUOTE in Lisp)?
>> > >
>> > > The ~|utility|~ cask is an arbitrary injection of any code.  It will
>> > > be inserted at whatever point you insert the cask in a statement.
>> > > The contents of the utility can contain anything.  If it is a larger
>> > > block it will be filled with multi-line content between the ~| and |~
>> > > sides.  However, CAlive provides for another feature whenever larger
>> > > bits of code are required.  They would typically be used, along with
>> > > the (|reference|) casks, instead of the ~|utility|~ cask:
>> > 
>> > If I remember correctly, the last time this topic came up it was 
>> > demonstrated that C++ cam already do what you were after.
>> 
>> And as I told you back then, and you refused to listen to it, C++
>> cannot do what casks do.  Nor a dozen other things I propose in
>> my language.
>
>Perhaps, but it *can* do everything you have shown in your examples. If 
>you want to show casks' utility, you might wish to expand your examples 
>to show things that C++ cannot do.

What does C++ have to do with anything???  Have you checked which newsgroup
you are posting in?

As people in this newsgroup so charmingly always put it, that comp.lang.c++
thing is down the hall, left at the water cooler, 3 doors down on your
right.

Or something like that...

-- 
(This discussion group is about C, ...)

Wrong.  It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...

[toc] | [prev] | [next] | [standalone]

#74577

Kenny McCormack wrote:
> 
> In article <MPG.309c972cb500f5d058@news.eternal-september.org>,
> Philip Lantz  <prl@canterey.us> wrote:
> >Rick C. Hodgin wrote:
> >> 
> >> On Thursday, October 29, 2015 at 9:25:39 PM UTC-4, Ian Collins wrote:
> >> > Rick C. Hodgin wrote:
> >> > > On Thursday, October 29, 2015 at 5:48:26 PM UTC-4, Bart wrote:
> >> > >> Does ~|....|~ denote a bit of code that is not immediately evaluated
> >> > >> (maybe like QUOTE in Lisp)?
> >> > >
> >> > > The ~|utility|~ cask is an arbitrary injection of any code.  It will
> >> > > be inserted at whatever point you insert the cask in a statement.
> >> > > The contents of the utility can contain anything.  If it is a larger
> >> > > block it will be filled with multi-line content between the ~| and |~
> >> > > sides.  However, CAlive provides for another feature whenever larger
> >> > > bits of code are required.  They would typically be used, along with
> >> > > the (|reference|) casks, instead of the ~|utility|~ cask:
> >> > 
> >> > If I remember correctly, the last time this topic came up it was 
> >> > demonstrated that C++ cam already do what you were after.
> >> 
> >> And as I told you back then, and you refused to listen to it, C++
> >> cannot do what casks do.  Nor a dozen other things I propose in
> >> my language.
> >
> >Perhaps, but it *can* do everything you have shown in your examples. If 
> >you want to show casks' utility, you might wish to expand your examples 
> >to show things that C++ cannot do.
> 
> What does C++ have to do with anything???  Have you checked which newsgroup
> you are posting in?

The point is that he claims that he is inventing new capabilities.

[toc] | [prev] | [next] | [standalone]

#74233

Rick C. Hodgin wrote:
> On Thursday, October 29, 2015 at 9:25:39 PM UTC-4, Ian Collins wrote:
>> Rick C. Hodgin wrote:
>>> On Thursday, October 29, 2015 at 5:48:26 PM UTC-4, Bart wrote:
>>>> Does ~|....|~ denote a bit of code that is not immediately evaluated
>>>> (maybe like QUOTE in Lisp)?
>>>
>>> The ~|utility|~ cask is an arbitrary injection of any code.  It will
>>> be inserted at whatever point you insert the cask in a statement.
>>> The contents of the utility can contain anything.  If it is a larger
>>> block it will be filled with multi-line content between the ~| and |~
>>> sides.  However, CAlive provides for another feature whenever larger
>>> bits of code are required.  They would typically be used, along with
>>> the (|reference|) casks, instead of the ~|utility|~ cask:
>>
>> If I remember correctly, the last time this topic came up it was
>> demonstrated that C++ cam already do what you were after.
>
> And as I told you back then, and you refused to listen to it, C++
> cannot do what casks do.  Nor a dozen other things I propose in
> my language.

So provide an example use that C++ can't match.  If you are attempting 
to prove the utility of a new idea, you have to show that is is new.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#74252

On Friday, October 30, 2015 at 7:34:25 AM UTC, Ian Collins wrote:
> 
> So provide an example use that C++ can't match.  If you are attempting 
> to prove the utility of a new idea, you have to show that is is new.
> 
"Power" is rather an elusive idea.
It's presumably possible to write an interpreter for CAlive in C++,
there's nothing it can do that C++ totally can't. 
However a cask looks a bit like a lambda function to me. The utility
isn't immediately obvious, but actually thought is moving in that
direction.

[toc] | [prev] | [next] | [standalone]

#74261

On 30/10/15 10:09, Malcolm McLean wrote:
> On Friday, October 30, 2015 at 7:34:25 AM UTC, Ian Collins wrote:
>>
>> So provide an example use that C++ can't match.  If you are attempting 
>> to prove the utility of a new idea, you have to show that is is new.
>>
> "Power" is rather an elusive idea.
> It's presumably possible to write an interpreter for CAlive in C++,
> there's nothing it can do that C++ totally can't. 
> However a cask looks a bit like a lambda function to me. The utility
> isn't immediately obvious, but actually thought is moving in that
> direction.
> 

I think Rick's "adhoc" functions are basically lambdas, or perhaps
simply nested functions (a gcc extension, and legal in many other
programming languages).  There is always a bit of detail when talking
about such functions (how do you access local data in the surrounding
scope, how and when are variables captured, and so on) - but the
principle is there.

I /think/ casks could also be handled by making and then calling a
lambda function at the same point:

for (...)
{
	if (some_function(~| abc = NULL; |~ &abc))
		// Do something
}

is the same as (if I've got the syntax correct):

for (...)
{
	if (some_function([&]{ abc = NULL;}(), &abc))
		// Do something
}

I much prefer the simpler, clearer version:

for (...)
{
	struct SAbc* abc = NULL;
	if (some_function(&abc))
		// Do something
}


So I too am waiting for an example of casks that a) /really/ improve the
code, and b) cannot be done just as well (and just as clearly) using C++
(or perhaps even standard C, or with compiler-specific extensions).

But I'm glad to see Rick is trying to answer this challenge.

[toc] | [prev] | [next] | [standalone]

#74274

David Brown <david.brown@hesbynett.no> writes:
<snip>
> I think Rick's "adhoc" functions are basically lambdas, or perhaps
> simply nested functions (a gcc extension, and legal in many other
> programming languages).  There is always a bit of detail when talking
> about such functions (how do you access local data in the surrounding
> scope, how and when are variables captured, and so on) - but the
> principle is there.

Rick has stated that he does not want to learn about programming
languages so he is bound to keep reinventing things, and coming up
non-standard names for them.

> I /think/ casks could also be handled by making and then calling a
> lambda function at the same point:
>
> for (...)
> {
> 	if (some_function(~| abc = NULL; |~ &abc))
> 		// Do something
> }
>
> is the same as (if I've got the syntax correct):
>
> for (...)
> {
> 	if (some_function([&]{ abc = NULL;}(), &abc))

You need ()s round the comma expression.  But since abc is in scope
where the lambda is called, it serves no purpose.  It can play a
syntactic role in this situation -- by allowing declarations and a block
of statements for example -- but that's all.  But when that's what you
are doing, gcc's ({...}) is clearer.

> 		// Do something
> }

But in this case it's also the same as a comma expression with an
assignment.  Rick needs to take more care pricking examples.  A feature
needs be illustrated with an example that needs it.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#74287

In article <871tccfts5.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
...
>Rick needs to take more care pricking examples.

Nice typo.

-- 
"Every time Mitt opens his mouth, a swing state gets its wings."

(Should be on a bumper sticker)

[toc] | [prev] | [next] | [standalone]

#74290

On 30/10/15 13:03, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <snip>
>> I think Rick's "adhoc" functions are basically lambdas, or perhaps
>> simply nested functions (a gcc extension, and legal in many other
>> programming languages).  There is always a bit of detail when talking
>> about such functions (how do you access local data in the surrounding
>> scope, how and when are variables captured, and so on) - but the
>> principle is there.
> 
> Rick has stated that he does not want to learn about programming
> languages so he is bound to keep reinventing things, and coming up
> non-standard names for them.
> 
>> I /think/ casks could also be handled by making and then calling a
>> lambda function at the same point:
>>
>> for (...)
>> {
>> 	if (some_function(~| abc = NULL; |~ &abc))
>> 		// Do something
>> }
>>
>> is the same as (if I've got the syntax correct):
>>
>> for (...)
>> {
>> 	if (some_function([&]{ abc = NULL;}(), &abc))
> 
> You need ()s round the comma expression.  

True.

> But since abc is in scope
> where the lambda is called, it serves no purpose.  It can play a
> syntactic role in this situation -- by allowing declarations and a block
> of statements for example -- but that's all.  But when that's what you
> are doing, gcc's ({...}) is clearer.

Agreed.  But of course, simply putting "abc = NULL" in the sensible
place is even clearer.

> 
>> 		// Do something
>> }
> 
> But in this case it's also the same as a comma expression with an
> assignment.  Rick needs to take more care pricking examples.  A feature
> needs be illustrated with an example that needs it.
> 

Yes, I'd like to see such an example too.  While I know without doubt
that I would never use CAlive (for a good many reasons), it would be
nice to see a case where casks really give added value to the language.
 Rick has invested a lot of time and effort in them, and received almost
completely negative feedback here - it would be nice to see that his
effort has not been entirely wasted.

Alternatively, if he keeps "pricking" examples like these and seeing
that others dislike them or can implement them easily in C, maybe he
will see that casks are not the marvel he hopes.

[toc] | [prev] | [next] | [standalone]

#74328

On Friday, October 30, 2015 at 1:22:50 PM UTC, David Brown wrote:
>
> 
> Yes, I'd like to see such an example too.  While I know without doubt
> that I would never use CAlive (for a good many reasons), it would be
> nice to see a case where casks really give added value to the language.
>  Rick has invested a lot of time and effort in them, and received almost
> completely negative feedback here - it would be nice to see that his
> effort has not been entirely wasted.
> 
As far as I see it a cask is a) a reinvention of a lambda function and b)
marked up so the IDE displays or hides the code according to mouse
position.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web