genly@bubble.multiflow.COM (Chris Hind Genly) (09/14/89)
I've done a little bit of icon programming, and I enjoy the language. I use it under Unix, and I've started to use Icon instead of shell scripts. It's nice to switch over to a real language for quick jobs. I was wondering if anyone besides myself misses var parameters. A var parameter being a way to return a value through a parameter. Without them one is limited to returning one value. Or alternatively, multiple values would have to be packaged into a list, or some other aggregate, and then the list returned. I find this a little clumsy. Do you miss var params? Opinions and techniques welcome. -- ======================================================================= Chris Hind Genly, N1GLZ - Multiflow Computer - mfci!genly (203)488-6090
vicc@unix.cie.rpi.edu (VICC Project (Rose)) (09/14/89)
I too miss var parameters, unfortuanately they require a new data type (to some
extent at least) to implement.
I am planning on playing arround with adding some features to Icon and I would
like to know what people are interested in and what people have worked on
and what their experiences have been. I will be working on the ms-dos version.
What I plan to play with are:
Arrays - static sized multiple dimnensioned arrays, will be more space
and time efficient than lists. A procedure will be used to generate
an empty array.
A range data type that can be converted into that needed for subscripting
strings. (I'm not sure this is really needed, and I'm not sure that the
current string range mechanism won't work, I have to read the implementation
book.
variable parameters, and maybe general pointer variables
a system() function like I described earlier
anyone who has comments on this please feel free to contact me. I've always
wanted to hack with a compiler and Icon seems just right for that, complete
source code, a manual which describes the designers philosophy behind
everything etc. I wish to maintain as much of Icon's original philosophy as
possible in my work.
also, what are the additional documents which come with the implementation
documentation package? I may need to order them, I've signed out the
implementation book from my school library (they have a neat cs section,
they have the Snobol implementation book also)
Frank Filzaj-mberg@dasys1.UUCP (Micha Berger) (09/22/89)
"var" params, as you call it, is normally called "passing by reference. What this means is that you're passing the variable, not the value it holds. "var" is just the keyword Pascal uses, it's not the standard term. (The type of passing ICON allows is "pass-by-value"; i.e. only the value is passed.) Now, back to your question.... Passing by reference is considered by most language feature as dangerous. It allows a function to change the value of a variable without the user realizing. If you came back to your program years later, will you remember all the side effects? The problem is that you can end up with p(a)+a <> a+p(a). If p's parameter is passed by reference, and p changes the value of a, it makes a difference which gets done first. If you want to return a bunch of values from one function, why not return a list? -- Micha Berger ...cucard!dasys1!aj-mberg Imitatio Dei means never having to say "I'm sorry."
vicc@unix.cie.rpi.edu (VICC Project (Rose)) (09/22/89)
In article <10746@dasys1.UUCP>, aj-mberg@dasys1.UUCP (Micha Berger) writes: > Passing by reference is considered by most language feature as dangerous. It > allows a function to change the value of a variable without the user > realizing. If you came back to your program years later, will you remember > all the side effects? One must program ones procedures which use pass by reference such that side effects will be obvious. > The problem is that you can end up with p(a)+a <> a+p(a). If p's > parameter is passed by reference, and p changes the value of a, > it makes a difference which gets done first. One of my personal styles is to avoid using a procedure which returns a value (other than some kind of return code) in combination with pass by reference parameters. The result is that the construct p(a) + a should not occur. > If you want to return a bunch of values from one function, why not return a > list? This might in general be fine, but there have been comments about the int86() function for MS-DOS Icon which returns a list. It is a little slower because of this, also in certain programs (which are probably using int86() to speed things up) there is heavy use of int86() which then causes needless garbage collections. Of course in this instance one doesn't need special pass by reference since Icon structures are always passed by reference. Frank Filz Center For Integrated Electronics Rensselaer Polytechnic Institute vicc@unix.cie.rpi.edu
ok@cs.mu.oz.au (Richard O'Keefe) (09/23/89)
[I've lost the original context] In article <10746@dasys1.UUCP>, aj-mberg@dasys1.UUCP (Micha Berger) writes: > "var" params, as you call it, is normally called "passing by reference. If you will be content with pass by value result (as Fortran and Ada are), you can get that effect just by bending the Icon translator. Suppose, for example, that you add Ada syntax for arguments: 'in' value passed in 'out' result passed back 'in out' value passed in and result passed back. A procedure definition like procedure foo(in x, out y, in out z) ... end could be translated as procedure foo(x, OUTARGS) use OUTARGS[1] wherever y appears use OUTARGS[2] wherever z appears end A call foo(eks, out wye, in out zed) would then be translated as temp := [&null, zed]; foo(eks, temp); wye := temp[1], zed := temp[2] This gets a wee bit tricky if wye and zed are expressions, but Icon already has the machinery to represent "references" so that procedure calls can be used on the left hand side of := . This looks as though it should work, and it seems like a better idea to just bend the translator than to hack the low level stuff -- more portable if you do it right. And you'll have to bend the translator anyway.
genly@bubble.multiflow.COM (Chris Hind Genly) (09/27/89)
In article <10746@dasys1.UUCP> aj-mberg@dasys1.UUCP (Micha Berger) writes:
From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
I too miss var parameters, unfortuanately they require a new data
type (to some extent at least) to implement.
Thanks for the reply.
From: aj-mberg@dasys1.UUCP (Micha Berger)
"var" params, as you call it, is normally called "passing by reference.
I was being informal here. Either pass by reference or copy-in copy-out would
accomplish what I want.
Passing by reference is considered by most language feature as
dangerous. It allows a function to change the value of a variable
without the user realizing.
This is an issue of exposition. It is not clear from looking at a
call using pass-by-reference that it is actually using pass by
reference. One must go to the definition of the procedure being
called. Rather than the feature of pass-by-reference being dangerous,
this seems to be a weakness in the syntax of a language like Pascal.
There is no difference in the syntax between passing an argument by
value or by reference. If the syntax were different, anyone reading
the source would know that the value of an argument could be changed.
As an example, if the values which are to be passed by referenced were
followed by an '=', then it would be clear which variables could be
changed. In the following example, a could not change value, while b
and c could.
p(a, b=, c=)
If you want to return a bunch of values from one function, why not
return a list?
This is a matter of clarity and efficiency. I want to be able to
express pass-by-reference in the language directly. I don't want to
introduce an auxiliary structure like a list, and have to pack it and
unpack it. The list has nothing to do with the reason I am writing
the program. I don't want to introduce it just to work around the
lack of call by reference.
From: vicc@unix.cie.rpi.edu (VICC Project (Rose))
One must program ones procedures which use pass by reference such that side
effects will be obvious.
Agreed. I would be interested in what techniques you've been using to do this.
From: ok@cs.mu.oz.au (Richard O'Keefe)
If you will be content with pass by value result (as Fortran and Ada are),
you can get that effect just by bending the Icon translator. Suppose, for
example, that you add Ada syntax for arguments:
'in' value passed in
'out' result passed back
'in out' value passed in and result passed back.
I wasn't actually proposing to change the language, but this is along
the lines I was thinking.
I understand how to work around call-by-value, and I see that its
possible to change the translator. But I'm still wondering if people
miss the ability to return multiple values from a call. Regardless of
the mechanism, either by call-by-reference, copy-in copy-out, or by a
multi-valued return value.
Do you find you have to return multiple value so few times that its
not a problem? Are the icon programs you write so small that you
resort to using global variables without trading off
understandability? Do you find using an auxiliary structure to pack
multiple return values to be unobtrusive?
--
=======================================================================
Chris Hind Genly, N1GLZ - Multiflow Computer - mfci!genly (203)488-6090