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

Groups > comp.lang.javascript > #39628 > unrolled thread

input/output parameters

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

Contents

  input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-13 15:32 +0300
    Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-13 15:16 +0000
      Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-14 18:51 +0300
        Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-14 16:15 +0000
          Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-14 18:31 +0000
            Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-14 22:27 +0300
              Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-14 23:44 +0000
              Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-15 06:41 -0700
          Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-14 22:17 +0300
            Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-14 23:28 +0000
            Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-15 06:39 -0700
        Re: input/output parameters Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-03-14 22:32 +0000
        Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-15 06:36 -0700
          Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-20 14:49 +0300
            Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 11:59 -0700
              Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 13:07 -0700
            Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-20 19:29 +0000
              Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-20 20:35 +0000
    Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-15 00:27 +0300
      Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-14 23:51 +0000
        Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-20 14:56 +0300
          Re: input/output parameters Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-03-20 15:08 +0000
            Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-21 15:16 +0300
              Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-21 08:46 -0700
                Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-04-10 14:54 +0300
          Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 12:05 -0700
            Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-21 15:58 +0300
      Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-15 06:43 -0700
      Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-15 18:01 +0100
        Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-16 18:06 +0000
          Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-16 23:58 +0100
            Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-17 19:14 +0000
              Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-17 23:46 +0100
                Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-18 18:04 +0000
                  Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-22 00:39 +0100
                    Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-23 10:44 +0000
                      Re: input/output parameters Silvio <silvio@internet.com> - 2021-03-30 00:33 +0200
                        Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-31 19:53 +0100
                          Re: input/output parameters Silvio <silvio@internet.com> - 2021-04-01 01:17 +0200
                            Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-01 18:02 +0100
        Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-20 15:50 +0300
          Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-20 18:52 +0000
            Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-21 17:35 +0300
              Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-21 08:50 -0700
                Re: input/output parameters Anton Shepelev <anton.txt@gmail.com> - 2021-03-21 19:31 +0300
              Re: input/output parameters John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-21 19:27 +0000
          Re: input/output parameters "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 13:02 -0700
    Re: input/output parameters Postiljon Petskin <yyyyyyyyyyyywwwww@zohomail.eu> - 2023-04-22 08:47 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#39718

Silvio:

> Give it up. The first mistakes beginners make when
> learning a new language is trying to coerce them into the
> programming style they used in their previous language.

It is not about style but about the whole paradigm, the way
one thinks about problems. Consider the programming
languages designed by Niklaus Wirth. They are all different,
with their own idioms and keywords and statements, yet they
all encourage the same disciplied, academic approach and
clean programming style. I am thankful to languages that do
not force the user to resort to their complicated object-
oriented or functional infractructures, letting him express
himself in the basic terms of procedural programming. In C#,
for example, one can use static classes and methods for
modules.

That said, I have no trouble switching between C, C#,
Pascal, or GNU Troff, or Bash. Naturally, I do not redefine
curly braces as `begin' and `end', but use whatever
facilities the language provides for procedural programming
with more or less success.

> Out parameters where a bad idea from the get go in any
> language that contained them dating back at least as far
> as Algol 60 and dozens of subsequent languages.

Why are they a bad idea? I do not remember that such
promiment computer scientists as Nickaus Wirth, Donald
Knuth, or Edjger Dijkstra criticised them.  Nor such
promiment programmers as Brian Kernighan or Linus Torvalds.

> Obviously they had to be added to the be-all-and-end-all
> that has become C++ with the introduction of references
> and from there they made their way into C#. Forget about
> them and you will not bother looking back.

I still fail to see elegant alternatives. Multiple
assignments (destructuring) do not entirely replace them.
Futhermore, output parameters are logical from the viewpoint
of symmetry: if a procedure or function may accept a several
input parameters, there no reason it should not several
several output parameters too.

I see that JavaScript tries to replace them with its various
exotic facilities, each of which is more comlicated than
than the thing it replaces.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#39722

On Sat, 20 Mar 2021 15:50:06 +0300, Anton Shepelev
<anton.txt@gmail.com> wrote:

Silvio:

  <snip>
>> Out parameters where a bad idea from the get go in any
>> language that contained them dating back at least as far
>> as Algol 60 and dozens of subsequent languages.
>
>Why are they a bad idea?
  <snip>

One disadvantage is that proving that the function does what it's
supposed to do is more complicated. If there's just a returned data
structure to check then that is (we hope) straightforward. If there
are external altered data structures to check then the job becomes
partly a check of the function and partly a check that it's used
sensibly. Also, building code that runs a confidence test of the
function becomes more complicated.

That said, sometimes it can't be avoided : where a file is read by
several different functions for instance.

  John

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

#39731

John G Harris about output parameters:

> One disadvantage is that proving that the function does
> what it's supposed to do is more complicated. If there's
> just a returned data structure to check then that is (we
> hope) straightforward. If there are external altered data
> structures to check then the job becomes partly a check of
> the function and partly a check that it's used sensibly.

I don't see how the introduction of output parameters makes
you check the function itself and data structures it has
altered instead of just testing its output. One must
*always* check that any function is used sensibly: is
applied to the right values, its result is store in the
right variable(s). It hardly matters whether the result
comes from the return value of output parameters.

Consider the following examples:

   var i1, i2, i3;
   var o1; makeref("o1");
   var o2; makeref("o2");
   var o3; makeref("o3");
   // ...
   ( {o1, o2, o3} = f1( i1, i2, i3 ) );
   f2( i1, i2, i3, $o1, $o2, $o3 );

where the second one uses my makeref() macro-like function
that wraps a value into a pair of getter/setter closures to
make it behave like a by-reference argument.

Both invocations are equally easy to test, say, by some
function

   check( o1, o2, o3 )
   { /* ... */ }

As to the human reader, local reasoning about both the
invocations is the same.  It becomes somewhat harder,
though, when you pass not scalar variables, but the
properties of an object.  Let us now try to do what you call
alteration of local data structures, first my way:

   function makeref(v, n)
   {   return `var ${n} = {set _(val){${v}=val;},get _() {return ${v};}}`;  }

   function func1( $1, $2 )
   {   $1._ += 1;
       $2._ += 2;
   }

   function func2( v1, v2 )
   {   return [ v1 + 1, v2 + 2 ];  }

   var obj = {f1:0, f2:0};
   eval( makeref("obj.f1", "$1") );
   eval( makeref("obj.f2", "$2") );

   func1( $1, $2 );
   console.log(`${obj.f1} ${obj.f2}`);

Althouth the invocation of func1() now changes local
structures, it is still perfectly transparent because the
reader can see the passing of the individual properties as
"output" parameters.

With multiple assignments it would look like this:

   function func2( v1, v2 )
   {   return [ v1 + 1, v2 + 2 ];  }

   ({obj.f1, obj.f2} = func1( $1, $2 ););

but destructuring does not work with object properties,
which is why it is not called multiple assignment (I guess).

A third way to modify local data structures is by passing
them to the function wholesale:

   function func3( o )
   {   o.f1 += 1;
       o.f2 += 2;
   }
   /* ... */
   func3(obj);

Now we have introduced a level of non-transparency, where
the reader of invocation cannot tell which properties are
going to change and which are not.  Sometimes it is OK, as I
know the intent of the function. But formally, the effect of
the invocation upon the local structures is not evident.

But I must admit that the need to modify several properties
of an object in a single invocation of a function not
specific to that object type is quite rare in well-
structured code. A more ralistic example would be the
modification of a signle property:

   o.f1 = func4();
   // or:
   func4( $o_f4 );

which, again, are equally transparent, or would be if
JavaScirpt had supported output parameters natively.

> Also, building code that runs a confidence test of the
> function becomes more complicated.

What is a confidence test?  All I find in the internet are
psychological quizzes.  Anyway, ease of use should be always
preferred to the ease of testing.  A little wrapper to
invoke the function according to its interface is not a big
deal, if you need automated tests.

> That said, sometimes it can't be avoided : where a file is
> read by several different functions for instance.

What can't be avoided -- managing the state of the file
object?

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#39733

On Sunday, March 21, 2021 at 9:35:51 AM UTC-5, Anton Shepelev wrote:

> With multiple assignments it would look like this: 
> 
> function func2( v1, v2 ) 
> { return [ v1 + 1, v2 + 2 ]; } 
> 
> ({obj.f1, obj.f2} = func1( $1, $2 );); 
> 
> but destructuring does not work with object properties, 
> which is why it is not called multiple assignment (I guess). 

Yes, it does:

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#object_destructuring>

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

#39734

Michael Haufe to Anton Shepelev:

> > but destructuring does not work with object properties,
> > which is why it is not called multiple assignment (I
> > guess).
>
> Yes, it does:
> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#object_destructuring>

I now see my error: the destructuring via arrays and objects
works differently: by position and by property name
respectively. Thanks you.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#39735

On Sun, 21 Mar 2021 17:35:45 +0300, Anton Shepelev
<anton.txt@gmail.com> wrote:

>John G Harris about output parameters:
>
  <snip>
>What is a confidence test?  All I find in the internet are
>psychological quizzes. 

It's a description, not an official name. 

Test : "We've tested it so it can't be a software fault" :-(

Convidence test : We've done a small update or small bug correction
and want some confidence that we haven't buggered up something else
that was working.


>Anyway, ease of use should be always
>preferred to the ease of testing.  

You obviously don't work for an ISO 9000 company. Customers want to
pay money for software that works.


>A little wrapper to
>invoke the function according to its interface is not a big
>deal, if you need automated tests.

A little wrapper that now needs to be checked, and to have update
control.


>> That said, sometimes it can't be avoided : where a file is
>> read by several different functions for instance.
>
>What can't be avoided -- managing the state of the file
>object?

Reading a character alters the position in the file. Something outside
the function has changed.

  John

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

#39726

On Saturday, March 20, 2021 at 7:50:13 AM UTC-5, Anton Shepelev wrote:

> It is not about style but about the whole paradigm, the way 
> one thinks about problems. Consider the programming 
> languages designed by Niklaus Wirth. They are all different, 
> with their own idioms and keywords and statements, yet they 
> all encourage the same disciplied, academic approach and 
> clean programming style. I am thankful to languages that do 
> not force the user to resort to their complicated object- 
> oriented or functional infractructures, letting him express 
> himself in the basic terms of procedural programming. In C#, 
> for example, one can use static classes and methods for 
> modules. 

I'd say don't confuse the paradigm with the implementation of it.

Haskell and Scheme are both functional but the approaches are significantly different.

Smalltalk,  Eiffel, and Self are all OOP, but their approaches are significantly different.

If your preference is the Procedural+Imperative style then you have to be more explicit about why you think that is "simpler" than the others and not just "simplistic". Lego blocks don't come with a single peg alone for example. Pushing the burden of some activities onto the programmer and calling it "discipline" is not a positive.

> Why are [out parameters] bad idea? I do not remember that such 
> promiment computer scientists as Nickaus Wirth, Donald 
> Knuth, or Edjger Dijkstra criticised them. Nor such 
> promiment programmers as Brian Kernighan or Linus Torvalds.

An argument from authority is often a logical fallacy, so we should avoid relying on their names alone. Alan Kay who is also a Turing Award winner had serious disagreements with Dijkstra for example. He famously said: 

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras."

He also criticized his approach to software engineering which is another story.

Regarding their comments on out parameters, they would agree that structured programming and local reasoning is what we should be pursuing and they have written on this in different forms. 

I've commented on this in an earlier reply and I want to bring up the point of orthogonality again. This time as a challenge to you:

How do I do function composition with the existence of out parameters?

```
const counter = (n) => n == 0 ? [] : [n].concat(counter(n-1))

const prod = (xs) => xs.length == 0 ? 1 : xs[0] * prod(xs.slice(1))

const compose = (f,g) => x => f(g(x)) 

const fact = compose(prod, counter)

counter(5) // [5, 4, 3, 2, 1]

fact(5) //120
``

Composition would not be trivial as you would need an intermediate variable for each step.

> I still fail to see elegant alternatives. Multiple 
> assignments (destructuring) do not entirely replace them. 
> Futhermore, output parameters are logical from the viewpoint 
> of symmetry: if a procedure or function may accept a several 
> input parameters, there no reason it should not several 
> several output parameters too. 

Which is accomplished by returning a datastructure representing it. Multiple inputs to a function can be seen as a tuple. Adding a space to make it clear:

```
myFunc (1,2,3)
```

And multiple results are as well:

```
let myFunc = (a,b,c) => (a*2, b*2, c*2)
```

Since JavaScript does not have tuples (yet), you use an array:

```
let myFunc = (a,b,c) => [a*2, b*2, c*2]

let [a,b,c] = myFunc(1,2,3) 
```

There is your symmetry.

> I see that JavaScript tries to replace them with its various 
> exotic facilities, each of which is more comlicated than 
> than the thing it replaces.

Hardly. The problem are your misconceptions. JavaScript has a number of problems, this is not one of them.

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

#41300

On Saturday, March 13, 2021 at 2:32:40 PM UTC+2, Anton Shepelev wrote:
> Hello, all 
> 
> I started learning JavaScript but yesterday, but am already 
> stuck at implementing input/output parameters. As I 
> understand, they are not part of the language, yet I find 
> them very convenient for normal procedural programming. For 
> example, they allow returning a boolean flag and using 
> functions inside `if` tests, similar to the very convenient 
> TryParse() and TryGetValue() functions in C#: 
> 
> TryParse: https://docs.microsoft.com/en-us/dotnet/api/system.int32.tryparse 
> TryGetValue: https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.dictionary-2.trygetvalue 
> 
> Unfortunately for me, JavaScript seems to compensate the 
> lack of in/out parameters with much more complicated 
> functional and object-oriented mechanisms. I therefore have 
> tried to implement them myself, but have not come up with a 
> satisfactory solution. The examples below demonstrate a 
> function for integer division that stores the result in 
> variable and returns a boolean value indicating whether the 
> division was exact: 
> 
> // for bi-direction in/out parameters, return a code that 
> // creates an anonymous object storing the the value *and* 
> // setter clousure: 
> 
> function out_1(vn) 
> { return "x => " + vn + " = x"; } 
> 
> function int_div_1(a, b ,c) 
> { var /*integer */ r; // ratio 
> var /*boolean */ x; // result is exact 
> 
> r = Math.floor(a / b); 
> x = r * b === a; 
> c( r ); 
> return x; 
> } 
> 
> function out_2( vn, val, ret ) 
> { return `${vn} = ${val}, ${ret}`; } 
> 
> function int_div_2(a, b, vn) 
> { var /*integer */ r; // ratio 
> var /*boolean */ x; // result is exact 
> 
> r = Math.floor(a / b); 
> x = r * b === a; 
> return out_2(vn, r, x); 
> } 
> 
> { let /*integer */ ratio; 
> let /*boolean */ exact; 
> 
> exact = int_div_1(7, 3, eval(out_1("ratio"))); 
> console.log(`7/3: ratio = ${ratio}; exact = ${exact}.`); 
> 
> exact = int_div_1(6, 3, eval(out_1("r"))); 
> console.log(`6/3: ratio = ${ratio}; exact = ${exact}.`); 
> 
> exact = eval(int_div_2(7, 3, "ratio")); 
> console.log(`7/3: ratio = ${ratio}; exact = ${exact}.`); 
> 
> exact = eval(int_div_2(6, 3, "ratio")); 
> console.log(`6/3: ratio = ${ratio}; exact = ${exact}.`); 
> } 
> 
> Can you think of better way to emulate output parameters, 
> and preferable also bi-directional input/output parameters? 
> 
> -- 
> () ascii ribbon campaign -- against html e-mail 
> /\ http://preview.tinyurl.com/qcy6mjc [archived]

You agree, that You are the most unoriginal person in the history of the universe ?

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web