Feedback on parameter redirects

[Rick C. Hodgin]

I was hoping to get some feedback on a feature I'm adding to CAlive.
It's called parameter redirects. It's designed to allow incoming
parameters to be auto-assigned to other variables (before the first
local line of function code is run), and to assign a single input
value to multiple targets, including type conversion.


https://groups.google.com/d/msg/caliveprogramminglanguage/Bgx4v4xLhXc/6cXeHw2FAwAJ

Example:

my_function(1, 2, 3, 4);

void my_function(int a, int b, to max, total, int c)
{
int i = 5; // By the time this line of code is
// run, max and total are already set
// to the value of the 3rd parameter

int max, total;

// Right now:
// a = 1
// b = 2
// max = 3, total = 3
// c = 4
// i = 5
}

It derives the target type by the name in use, and CAlive auto-
performs conversions where they're defined, and standard casts
where they're not defined.

To create new types from a single input parameter, use the syntax:

void my_function(int a, int b, to {int max, int total}, int c)
{
int i = 5;

// Right now:
// a = 1
// b = 2
// max = 3, total = 3
// c = 4
// i = 5
}

Please advise any notes or comments. Thank you in advance.

--
Thank you, | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count

[Chris M. Thomasson]

On 9/29/2017 6:44 AM, Rick C. Hodgin wrote:
> I was hoping to get some feedback on a feature I'm adding to CAlive.
> It's called parameter redirects.  It's designed to allow incoming
> parameters to be auto-assigned to other variables (before the first
> local line of function code is run), and to assign a single input
> value to multiple targets, including type conversion.

[...]

Damn it Jim... Create a little compiler that others can use wrt playing
around with CAlive. Make it relatively easy to install. If you keep
adding new features, the damn thing might never get into a solid state.

Perhaps, you should create an online CAlive compiler. I can go to your
site, type in my program, hit compile and see output.

[red floyd]

But it won't allow constants that equal 666. It's his "Christian"
compiler/language.

[Rick C. Hodgin]

On Friday, September 29, 2017 at 4:47:47 PM UTC-4, red floyd wrote:
> But it won't allow constants that equal 666. It's his "Christian"
> compiler/language.

When I worked at a place that had production lines, I created a
desktop app which shows our production lines and their working
unit numbers using a large display, and the values would cycle
through repeatedly from 000 to 999 and then repeat. It typically
took a few days to cycle.

I actually coded the display, which showed the current item being
processed on a very large flat screen monitor, to show "66_" when
they were on 666.

Management let it stand. :-) It was that way all the time I was
there. People would always laugh when that number came around.

Thank you,
Rick C. Hodgin

[Ivan Shmakov]

>>>>> red floyd <dont....@its.invalid> writes:
>>>>> On 9/29/2017 12:24 PM, Chris M. Thomasson wrote:

[...]

>> Perhaps, you should create an online CAlive compiler. I can go to
>> your site, type in my program, hit compile and see output.

> But it won't allow constants that equal 666.

Not much different to how some countries won't allow 13th floors,
I guess.

[...]

--
FSF associate member #7257 http://am-1.org/~ivan/ 7D17 4A59 6A21 3D97 6DDB

[Rick C. Hodgin]

??

Does anybody have any thoughts on this feature, positive or negative?

[bartc]

I've read it, and can't understand it. And you have two versions of
my_function(), but both apparently do the same thing.

What problem does this solve: how would the equivalent be done in C now,
and how would this new feature transform that?

And in the above, how many parameters does my_function() actually take,
is it 3, 4 or 5? Ie. how many values does the caller put on the stack
before passing control, or is there some magic that happens at the
call-site too?

--
bartc

[Rick C. Hodgin]

The first my_function() stores the incoming 3rd parameter to the
types indicated by max and total.

The second my_function() declares the incoming 3rd parameter as
two int variables, with the 3rd parameter being automatically
copied into both.

> What problem does this solve: how would the equivalent be done in C now,
> and how would this new feature transform that?

In C today:

my_function(1, 2, 3, 4);

void my_function(int a, int b, int p3, int c)
{
int max = p3;
int total = p3;
int i = 5;
}

The p3 value is received as a single parameter, and it is manually
copied to max and total.

> And in the above, how many parameters does my_function() actually take,
> is it 3, 4 or 5? Ie. how many values does the caller put on the stack
> before passing control, or is there some magic that happens at the
> call-site too?

You pass in four parameters, but this parameter redirect ability kind
of reinterprets the parameters as incoming slots. Those slots then
align with their parameter definition in the target function, but can
also have logic applied by the compiler to automatically re-direct an
incoming parameter to multiple targets, or to multiple types, allowing
for the compiler to inject that code for you without multiple lines of
source code, or explicit casting (where required).

It's a way to save some code lines, document that the incoming params
are used in multiple local variables, or is the default value for the
return value (if it's redirected there), so that only those things
which actually alter the value (in the code within the function) are
seen in that code.

It de-clutters code, and performs the same kind of compiler-injected
initialization that creating a new class with default member values
does, in that they are assigned automatically before the first line
of function code is run.

[David Brown]

On 02/10/17 14:50, Rick C. Hodgin wrote:

> Does anybody have any thoughts on this feature, positive or negative?
>

It strikes me as a complicated solution to a non-existent problem. I
cannot see any benefit over:

void my_function(int a, int b, int max_total, int c)
{
int i = 5;
int max = max_total;
int total = max_total;
...
}

At best, you are introducing a new syntax to save a line of code, or a
few characters of typing. That is a very poor tradeoff in my book.

Or have I misunderstood something here?

[bartc]

On 02/10/2017 14:19, Rick C. Hodgin wrote:
> On 10/2/2017 9:09 AM, bartc wrote:

>>>      void my_function(int a, int b, to max, total, int c)

>>>          //     max = 3, total = 3

>> I've read it, and can't understand it. And you have two versions of
>> my_function(), but both apparently do the same thing.
>
> The first my_function() stores the incoming 3rd parameter to the
> types indicated by max and total.

Max and total are types (which types?) or variables?

> The second my_function() declares the incoming 3rd parameter as
> two int variables, with the 3rd parameter being automatically
> copied into both.

So what's the difference here, or isn't there any?

>> What problem does this solve: how would the equivalent be done in C
>> now, and how would this new feature transform that?
>
> In C today:
>
>     my_function(1, 2, 3, 4);
>
>     void my_function(int a, int b, int p3, int c)
>     {
>         int max   = p3;
>         int total = p3;
>         int i     = 5;
>     }


> The p3 value is received as a single parameter, and it is manually
> copied to max and total.

OK, everyone can understand this.

>> And in the above, how many parameters does my_function() actually
>> take, is it 3, 4 or 5? Ie. how many values does the caller put on the
>> stack before passing control, or is there some magic that happens at
>> the call-site too?
>
> You pass in four parameters, but this parameter redirect ability kind
> of reinterprets the parameters as incoming slots.  Those slots then
> align with their parameter definition in the target function, but can
> also have logic applied by the compiler to automatically re-direct an
> incoming parameter to multiple targets, or to multiple types, allowing
> for the compiler to inject that code for you without multiple lines of
> source code, or explicit casting (where required).

Sorry, I can't parse that! But if all it does is copy a parameter to
multiple values, then it is easy enough to do now.

Using one (IMO more useful) extension to avoid re-stating a parameter
type, the above can be written like this:

void my_function(int a, b, max, c) {
int total = max;
int i = 5;

This assumes you don't need p3 as well (so three copies of the parameter
are needed). If so then it's what you have in C apart from writing the
params as 'int a, b, p3, c)'.

> It de-clutters code,

I've not convinced that this would be very useful. It happens sometimes
that you need to take a copy of an incoming parameter, leaving the
original unchanged. But that can be done most easily, AND WITHOUT ADDING
A NEW FEATURE, just by writing:

int total = p3;

--
bartc

[Rick C. Hodgin]

On 10/2/2017 10:32 AM, bartc wrote:
> On 02/10/2017 14:19, Rick C. Hodgin wrote:
>> On 10/2/2017 9:09 AM, bartc wrote:
>
>>>>      void my_function(int a, int b, to max, total, int c)
>
>>>>          //     max = 3, total = 3
>
>>> I've read it, and can't understand it. And you have two versions of
>>> my_function(), but both apparently do the same thing.
>>
>> The first my_function() stores the incoming 3rd parameter to the
>> types indicated by max and total.
>
> Max and total are types (which types?) or variables?

In the original post they were identified as local variables
within the function:

void my_function(int a, int b, to max, total, int c)

{
int i = 5;
int max, total;

}

>> The second my_function() declares the incoming 3rd parameter as
>> two int variables, with the 3rd parameter being automatically
>> copied into both.
>
> So what's the difference here, or isn't there any?

One of them declares max and total on the function declaration
line, the other uses the variables declared internally as local
variables.

>>> What problem does this solve: how would the equivalent be done in C
>>> now, and how would this new feature transform that?
>>
>> In C today:
>>
>>      my_function(1, 2, 3, 4);
>>
>>      void my_function(int a, int b, int p3, int c)
>>      {
>>          int max   = p3;
>>          int total = p3;
>>          int i     = 5;
>>      }
>
>> The p3 value is received as a single parameter, and it is manually
>> copied to max and total.
>
> OK, everyone can understand this.
>
>>> And in the above, how many parameters does my_function() actually
>>> take, is it 3, 4 or 5? Ie. how many values does the caller put on the
>>> stack before passing control, or is there some magic that happens at
>>> the call-site too?
>>
>> You pass in four parameters, but this parameter redirect ability kind
>> of reinterprets the parameters as incoming slots.  Those slots then
>> align with their parameter definition in the target function, but can
>> also have logic applied by the compiler to automatically re-direct an
>> incoming parameter to multiple targets, or to multiple types, allowing
>> for the compiler to inject that code for you without multiple lines of
>> source code, or explicit casting (where required).
>
> Sorry, I can't parse that! But if all it does is copy a parameter to
> multiple values, then it is easy enough to do now.

It is. But, it requires lines of code to do it, and those can be
scattered about.

> Using one (IMO more useful) extension to avoid re-stating a parameter
> type, the above can be written like this:
>
>    void my_function(int a, b, max, c) {
>      int total = max;
>      int i = 5;
>
> This assumes you don't need p3 as well (so three copies of the parameter
> are needed). If so then it's what you have in C apart from writing the
> params as 'int a, b, p3, c)'.

I don't see that saving as beneficial, and largely for the same
reason I don't see using tabs instead of spaces as beneficial.
If I use tabs, then I can make minor tweaks and adjustments to
my code and it will only occasionally move other things that are
aligned nearby. If I use spaces, I have to make adjustments to
aligned code every time I change the width of anything.

Similarly, in your example, if I suddenly wanted to convert one of
the parameters after int a to another type, I'd have to make more
than one change to the line. It also has me scanning left on each
parameter to see how it's defined.

With parameter re-directs, you can have an incoming parameter be
an int, and have it auto-redirected/copied into other types, like
a float or larger / smaller / unsigned integer type.

The biggest benefit I can see is assigning a pass-thru value to
a return variable (something CAlive allows, but C/C++ do not),
by name, so that the only code that will change that value is
something processed in the function.

>> It de-clutters code,
>
> I've not convinced that this would be very useful. It happens sometimes
> that you need to take a copy of an incoming parameter, leaving the
> original unchanged. But that can be done most easily, AND WITHOUT ADDING
>  A NEW FEATURE, just by writing:
>
>      int total = p3;

It has more utility than that. You could assign to a global variable,
for example, which then brings the reference to the global variable as
being tied explicitly to that function's input, for documentation
purposes. It has the ability to assign things before any local function
code is run. In C++ or CAlive, if it was a class that's being copied,
it will call the constructors before-hand, etc.

It won't have utility in most programming circumstances, but I can see
some where it will help with code clarity, documentation, and it helps
to re-define the input parameters to a function as something other than
mechanical things. They become logical things, and logical things can
be altered into other things.

We'll see how it goes. I appreciate your feedback, Bart.

[Öö Tiib]

On Monday, 2 October 2017 16:53:34 UTC+3, David Brown wrote:
> On 02/10/17 14:50, Rick C. Hodgin wrote:
>
> > Does anybody have any thoughts on this feature, positive or negative?
> >
>
> It strikes me as a complicated solution to a non-existent problem.

For feature being worth it there should be several motivating examples.
Motivating example is like that:
1) actual code how it is currently.
2) explanation what in that code misleads, is inconvenient and/or is
error prone.
3) equivalent code that uses proposed improvement.
4) explanation of how it is better.

All code in this thread seems absurd, unused parameters or parameters
assigned to unused function-local variables. Feels like author of
feature was incapable of imagining motivating examples.