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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#39717

Jon Ribbens to Anton Shepelev:

> > var /* number */ root  ; eval( makeref( "root"   ) );
> > var /* string */ errmsg; eval( makeref( "errmsg" ) );
>
> Bear in mind that using 'eval' is extremely bad for
> performance.  It means the language runtime has to give up
> on compilation and go back to using a basic interpreter.
> And, stop trying to fight the language. You will end up
> with terrible unreadable unmaintainable code.

Thank you for this valuable comment. What is the scope of
this negative effect of eval() -- current block, current
function, or the entire program?

It means I should not use my `makeref' function in
performace-critical code sections. Fortunately, most of our
code is going to have other performace bottlenecks, such as
DB IO and interaction over network.

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

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

#39719

On 2021-03-20, Anton Shepelev <anton.txt@gmail.com> wrote:
> Jon Ribbens to Anton Shepelev:
>> > var /* number */ root  ; eval( makeref( "root"   ) );
>> > var /* string */ errmsg; eval( makeref( "errmsg" ) );
>>
>> Bear in mind that using 'eval' is extremely bad for
>> performance.  It means the language runtime has to give up
>> on compilation and go back to using a basic interpreter.
>> And, stop trying to fight the language. You will end up
>> with terrible unreadable unmaintainable code.
>
> Thank you for this valuable comment. What is the scope of
> this negative effect of eval() -- current block, current
> function, or the entire program?

I'm not sure I'm afraid - and it's possible of course that it varies
from one implementation to another and from one version to another.
You can use 'new Function()' however which avoids some of the problems
(bearing in mind I'm still strongly disrecommending your entire
approach). e.g.

  const add = new Function('a', 'b', 'return a + b')

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/Function

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

#39729

Jon Ribbens to Anton Shepelev:

> > Thank you for this valuable comment. What is the scope
> > of this negative effect of eval() -- current block,
> > current function, or the entire program?
>
> I'm not sure I'm afraid -- and it's possible of course
> that it varies from one implementation to another and from
> one version to another.

Since JavaScript is advertised as a functional language, it
would behove its compilers and interpreters to be aware of
pure fuctions. Observer that my `makeref' defined above as

   // Returns JavaScript for the defintion of a "pointer" to a variable named `v':
   // The identifier of the pointer is that of the variable prepended by a $.
   function makeref(v)
   {   return `var $${v} = {set _(val){${v}=val;},get _() {return ${v};}}`;  }

and applied exclusively to string literals:

   var /* number */ root  ; eval( makeref( "root" ) );

is pure in the sense that the compiler/interpreter need not
analyse it at every invocation, but can simply expand it
like a macro at a pre-processing stage, resulting in zero
`eval' overhead.

> You can use 'new Function()' however which avoids some of
> the problems
> const add = new Function('a', 'b', 'return a + b')

I don't understand how to implement my `makeref' function
via `new Function'.

> https://paiza.io/projects/jEjvMFPZyKTzNi6oBWKAOQ?language=javascript

It says that "However, unlike eval, the Function constructor
creates functions which execute in the global scope only,"
whereas in practice they seem to work in local scope as
well:

   const sum = new Function('a', 'b', 'return a + b');
   function test()
   {  console.log(sum(2,1));  }

   test();

In the example above, dynamiucally created function `sum' is
invoked in the local scope function `test()'. Aparently, I
misunderstand the remark...

> (bearing in mind I'm still strongly disrecommending your
> entire approach).

I do bear that in mind. Confining oneself to a subset of
language features is one thing, whereas struggling like
salmon against the langauge is another, and if I find myself
rushing upstream and exhausted, I will revise my strategy,
gradually bringing in more JS-specific features.

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

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

#39732

On Sunday, March 21, 2021 at 7:17:06 AM UTC-5, Anton Shepelev wrote:

> Since JavaScript is advertised as a functional language, it 
> would behove its compilers and interpreters to be aware of 
> pure fuctions. 

They are aware. Talk of a "pure" annotation comes up from time to time in the design committee but practically part of the debate is: why annotate if you can identify purity with program analysis? Some JavaScript compilers such as Babel inject this information for other tools to use:

<https://babeljs.io/blog/2018/08/27/7.0.0#pure-annotation-support>

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

#39882

Michael Haufe:

> Talk of a "pure" annotation comes up from time to time in
> the design committee but practically part of the debate
> is: why annotate if you can identify purity with program
> analysis?

Program analysis is desirable in either case, at least to
make sure that the programmer does not misinform the reader
and compiler by marking an impure function as pure. My point
is that pieces of "pure" eval() code (including non-strict
mode) can be considered compile-time macros. I still feel a
cognitive dissonance, however, every time a compiler is
mentioned for a language named JavaScript...

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

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

#39724

On Saturday, March 20, 2021 at 6:56:37 AM UTC-5, Anton Shepelev wrote:
> Jon Ribbens to Anton Shepelev:
> > > var /* number */ root ; eval( makeref( "root" ) ); 
> > > var /* string */ errmsg; eval( makeref( "errmsg" ) ); 
> > 
> > Bear in mind that using 'eval' is extremely bad for 
> > performance. It means the language runtime has to give up 
> > on compilation and go back to using a basic interpreter. 
> > And, stop trying to fight the language. You will end up 
> > with terrible unreadable unmaintainable code.
> Thank you for this valuable comment. What is the scope of 
> this negative effect of eval() -- current block, current 
> function, or the entire program? 
> 
> It means I should not use my `makeref' function in 
> performace-critical code sections. Fortunately, most of our 
> code is going to have other performace bottlenecks, such as 
> DB IO and interaction over network.

eval is generally unnecessary. JavaScript has extensive reflective capabilities as well as a meta-object protocol. That in addition to first class functions and the ability to change their 'this' target. There are very few use-cases left for needing the giant hammer of eval.

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

#39730

Michael Haufe:

> eval is generally unnecessary. JavaScript has extensive
> reflective capabilities as well as a meta-object protocol.
> That in addition to first class functions and the ability
> to change their 'this' target. There are very few use-
> cases left for needing the giant hammer of eval.

I am glad of it, actually: it is better to work within a
well-structured model than constructing code out of strings.
But I personally dislike reflection, too, and hope that most
practical programs can be written in JavaScript without
either reflection or eval. As you see, I have employed eval
as a tiny convenience facility to imitate input/output
parameters, but of course it is not necessary as JavaScript
has other means of returning several scalar outputs from a
function, including object orientation (this),
desturcturing, and (for errors) exceptions.

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

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

#39653

On Sunday, March 14, 2021 at 4:27:39 PM UTC-5, Anton Shepelev wrote:
> I wrote: 
> 
> > I started learning JavaScript but yesterday, but am 
> > already stuck at implementing input/output parameters.
> I have come up with what might be called emulated poiters: 

Don't. You're trying to move baggage from your language into a new one which
is not appropriate in this case.

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

#39657

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.

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. 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.

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

#39669

On Mon, 15 Mar 2021 18:01:32 +0100, Silvio <silvio@internet.com>
wrote:

  <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. 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#. 
  <snip>

Objects are out paramenters in ECMAScript and hence in all
JavaScripts. Not using them means not touching the DOM. But doing that
was the reason for inventing JavaScript.

  John

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

#39670

On 3/16/21 7:06 PM, John G Harris wrote:
> On Mon, 15 Mar 2021 18:01:32 +0100, Silvio <silvio@internet.com>
> wrote:
> 
>    <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. 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#.
>    <snip>
> 
> Objects are out paramenters in ECMAScript and hence in all
> JavaScripts. Not using them means not touching the DOM. But doing that
> was the reason for inventing JavaScript.
> 
>    John
> 

Utter nonsense.

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

#39683

On Tue, 16 Mar 2021 23:58:08 +0100, Silvio <silvio@internet.com>
wrote:

>On 3/16/21 7:06 PM, John G Harris wrote:
>> On Mon, 15 Mar 2021 18:01:32 +0100, Silvio <silvio@internet.com>
>> wrote:
>> 
>>    <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. 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#.
>>    <snip>
>> 
>> Objects are out paramenters in ECMAScript and hence in all
>> JavaScripts. Not using them means not touching the DOM. But doing that
>> was the reason for inventing JavaScript.
>> 
>>    John
>> 
>
>Utter nonsense.

You would be right if a function can't alter an object given to it in
a way that is visible to the caller.

  John

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

#39685

On 3/17/21 8:14 PM, John G Harris wrote:
> On Tue, 16 Mar 2021 23:58:08 +0100, Silvio <silvio@internet.com>
> wrote:
> 
>> On 3/16/21 7:06 PM, John G Harris wrote:
>>> On Mon, 15 Mar 2021 18:01:32 +0100, Silvio <silvio@internet.com>
>>> wrote:
>>>
>>>     <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. 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#.
>>>     <snip>
>>>
>>> Objects are out paramenters in ECMAScript and hence in all
>>> JavaScripts. Not using them means not touching the DOM. But doing that
>>> was the reason for inventing JavaScript.
>>>
>>>     John
>>>
>>
>> Utter nonsense.
> 
> You would be right if a function can't alter an object given to it in
> a way that is visible to the caller.
> 
>    John
> 

No. That is called immutability and is completely orthogonal to out 
parameters. The fact that a compound value is mutable has absolutely 
nothing to do with parameter passing. Any reference to a compound value 
can be outside the view of an observer and still modify that compound 
value in a way that is visible to the observer.

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

#39699

On Wed, 17 Mar 2021 23:46:24 +0100, Silvio <silvio@internet.com>
wrote:

>On 3/17/21 8:14 PM, John G Harris wrote:
>> On Tue, 16 Mar 2021 23:58:08 +0100, Silvio <silvio@internet.com>
>> wrote:
>> 
>>> On 3/16/21 7:06 PM, John G Harris wrote:
>>>> On Mon, 15 Mar 2021 18:01:32 +0100, Silvio <silvio@internet.com>
>>>> wrote:
>>>>
>>>>     <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. 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#.
>>>>     <snip>
>>>>
>>>> Objects are out paramenters in ECMAScript and hence in all
>>>> JavaScripts. Not using them means not touching the DOM. But doing that
>>>> was the reason for inventing JavaScript.
>>>>
>>>>     John
>>>>
>>>
>>> Utter nonsense.
>> 
>> You would be right if a function can't alter an object given to it in
>> a way that is visible to the caller.
>> 
>>    John
>> 
>
>No. That is called immutability and is completely orthogonal to out 
>parameters. The fact that a compound value is mutable has absolutely 
>nothing to do with parameter passing. Any reference to a compound value 
>can be outside the view of an observer and still modify that compound 
>value in a way that is visible to the observer.

You distinguish between Inner Out parameters and Outer Out parameters.
Fair enough. It's worth remembering that both are forbidden in pure FP
languages, as it is in C++ for constant reference parameters.

  John

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

#39736

On 3/18/21 7:04 PM, John G Harris wrote:
> 
> You distinguish between Inner Out parameters and Outer Out parameters.
> Fair enough. It's worth remembering that both are forbidden in pure FP
> languages, as it is in C++ for constant reference parameters.
> 
>    John
> 

Do not forget that C++ const pointers/references fail to provide two-way 
guarantees about immutability. When you hand out a const 
pointer/reference you can rely on the referenced data not being altered 
through that pointer/reference. But the code that is handed the 
reference can not make the same assumption. At any time can the data 
referenced by their const pointer/reference be modified. As such const 
pointers/references are of limited use for safe data sharing in complex 
scenarios.

Only truly (observably) immutable objects (either atomic ones like 
integers or strings or compound ones like arrays, lists, maps etc) can 
provide such guarantees.

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

#39745

On Mon, 22 Mar 2021 00:39:21 +0100, Silvio <silvio@internet.com>
wrote:

>On 3/18/21 7:04 PM, John G Harris wrote:
>> 
>> You distinguish between Inner Out parameters and Outer Out parameters.
>> Fair enough. It's worth remembering that both are forbidden in pure FP
>> languages, as it is in C++ for constant reference parameters.
>> 
>>    John
>> 
>
>Do not forget that C++ const pointers/references fail to provide two-way 
>guarantees about immutability. When you hand out a const 
>pointer/reference you can rely on the referenced data not being altered 
>through that pointer/reference. But the code that is handed the 
>reference can not make the same assumption. At any time can the data 
>referenced by their const pointer/reference be modified. 

If the argument given to the function can change while the function is
using it then you have a data race problem. The cure is a lock, or a
transaction, or similar.


>As such const 
>pointers/references are of limited use for safe data sharing in complex 
>scenarios.

A const ref parameter has nothing to do with race conditions. It's to
do with the caller needing to guarantee that its invariants will be
preserved while not wanting to copy a large data structure such as a
long string or a tree.


>Only truly (observably) immutable objects (either atomic ones like 
>integers 

Boy, are you going to have a nasty surprise one day.

Or do you mean variables built into ROM or Read-Only VM segments ?


>or strings or compound ones like arrays, lists, maps etc) can 
>provide such guarantees.

Even more so.

  John

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

#39803

On 3/23/21 11:44 AM, John G Harris wrote:
> On Mon, 22 Mar 2021 00:39:21 +0100, Silvio <silvio@internet.com>
> wrote:
> 
>> On 3/18/21 7:04 PM, John G Harris wrote:
>>>
>>> You distinguish between Inner Out parameters and Outer Out parameters.
>>> Fair enough. It's worth remembering that both are forbidden in pure FP
>>> languages, as it is in C++ for constant reference parameters.
>>>
>>>     John
>>>
>>
>> Do not forget that C++ const pointers/references fail to provide two-way
>> guarantees about immutability. When you hand out a const
>> pointer/reference you can rely on the referenced data not being altered
>> through that pointer/reference. But the code that is handed the
>> reference can not make the same assumption. At any time can the data
>> referenced by their const pointer/reference be modified.
> 
> If the argument given to the function can change while the function is
> using it then you have a data race problem. The cure is a lock, or a
> transaction, or similar.

Hardly a cure but rather a clumsy way of forcing things in a somewhat 
predictable and manageable order to keep them from causing havoc.

I have spent thirty+ years fiddling with semaphores, synchronized blocks 
etc. and although clumsily up to a certain level of complexity they do 
enable us to manage mutable state in multi-threaded scenarios.

> 
> 
>> As such const
>> pointers/references are of limited use for safe data sharing in complex
>> scenarios.
> 
> A const ref parameter has nothing to do with race conditions. It's to
> do with the caller needing to guarantee that its invariants will be
> preserved while not wanting to copy a large data structure such as a
> long string or a tree.
> 
> 
>> Only truly (observably) immutable objects (either atomic ones like
>> integers
> 
> Boy, are you going to have a nasty surprise one day.
> 
> Or do you mean variables built into ROM or Read-Only VM segments ?

Immutability is all about preventing surprises. Mutability can not be 
avoided at all levels but many parts of a system can be built without 
having mutable state. That is what I am talking about and it has nothing 
to do with ROM.

> 
> 
>> or strings or compound ones like arrays, lists, maps etc) can
>> provide such guarantees.
> 
> Even more so.
> 
>    John
> 

No, even less so. Immutable lists, maps, sets but also simple immutable 
objects like strings or user defined classes can greatly simplify 
multi-threaded (and even single threaded) scenarios.

Using const references is a poor substitute for actual constness.

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

#39814

On Tue, 30 Mar 2021 00:33:50 +0200, Silvio <silvio@internet.com>
wrote:

  <snip>
>No, even less so. Immutable lists, maps, sets but also simple immutable 
>objects like strings or user defined classes can greatly simplify 
>multi-threaded (and even single threaded) scenarios.
>
>Using const references is a poor substitute for actual constness.

Implementing your immutability is easy to do in any programming
language. The CEO sends a letter to every programmer saying they will
be sacked if they ignore a requirement. After two or three know-it-all
'experts' get the sack the message will get through. 

Even in ECMAScript :

  function f(x)
		// Precondition : x does not vary while f is executing.
		// Reminder     : Ignoring preconditions gets you sacked.
		{ ... }

  John

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

#39815

On 3/31/21 8:53 PM, John G Harris wrote:
> On Tue, 30 Mar 2021 00:33:50 +0200, Silvio <silvio@internet.com>
> wrote:
> 
>    <snip>
>> No, even less so. Immutable lists, maps, sets but also simple immutable
>> objects like strings or user defined classes can greatly simplify
>> multi-threaded (and even single threaded) scenarios.
>>
>> Using const references is a poor substitute for actual constness.
> 
> Implementing your immutability is easy to do in any programming
> language. The CEO sends a letter to every programmer saying they will
> be sacked if they ignore a requirement. After two or three know-it-all
> 'experts' get the sack the message will get through.
> 
> Even in ECMAScript :
> 
>    function f(x)
> 		// Precondition : x does not vary while f is executing.
> 		// Reminder     : Ignoring preconditions gets you sacked.
> 		{ ... }
> 
>    John
> 

No, it is not easy at all. Immutable containers like maps or lists for 
example are immutable by design. It is not possible to add/remove items 
to/from the map/list. You can create a new map from an existing one by 
adding a key-value pair but that will return a new map and leave the old 
one as it was before. To do this efficiently one needs special data 
structures that allow different instances of such a map to share much or 
even most of their data. Basically this gives complex containers value 
semantics allowing you to pass them into a function or return them from 
a function without caring about ownership or possible unexpected 
modification.

Actual functional programming languages use such data structures a lot. 
Scala and Haskell have them in their standard library.

What you describe does not even come close.

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

#39832

On Thu, 1 Apr 2021 01:17:14 +0200, Silvio <silvio@internet.com> wrote:

>On 3/31/21 8:53 PM, John G Harris wrote:
>> On Tue, 30 Mar 2021 00:33:50 +0200, Silvio <silvio@internet.com>
>> wrote:
>> 
>>    <snip>
>>> No, even less so. Immutable lists, maps, sets but also simple immutable
>>> objects like strings or user defined classes can greatly simplify
>>> multi-threaded (and even single threaded) scenarios.
>>>
>>> Using const references is a poor substitute for actual constness.
>> 
>> Implementing your immutability is easy to do in any programming
>> language. The CEO sends a letter to every programmer saying they will
>> be sacked if they ignore a requirement. After two or three know-it-all
>> 'experts' get the sack the message will get through.
>> 
>> Even in ECMAScript :
>> 
>>    function f(x)
>> 		// Precondition : x does not vary while f is executing.
>> 		// Reminder     : Ignoring preconditions gets you sacked.
>> 		{ ... }
>> 
>>    John
>> 
>
>No, it is not easy at all. Immutable containers like maps or lists for 
>example are immutable by design. It is not possible to add/remove items 
>to/from the map/list. You can create a new map from an existing one by 
>adding a key-value pair but that will return a new map and leave the old 
>one as it was before. To do this efficiently one needs special data 
>structures that allow different instances of such a map to share much or 
>even most of their data. Basically this gives complex containers value 
>semantics allowing you to pass them into a function or return them from 
>a function without caring about ownership or possible unexpected 
>modification.
>
>Actual functional programming languages use such data structures a lot. 
>Scala and Haskell have them in their standard library.
>
>What you describe does not even come close.

Make up your mind.

Do you want a const ref parameter to mean
  a) This data cannot be changed by the function;
  b) This data will not be changed by the caller;
  c) This data is part of a structure implemented in a particular 
		 way and this constraint is binding on the caller.

Each of these can be specified by a precondition.

Also, (c) is the wrong place to put such a requirement.

  John

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

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

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

csiph-web