Declaring arguments to a function

[Hans-Dieter.Dreier@materna.de]

--GAIRQi3ui68RXMAWVHKroHx76ts0N5fm
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


>> Why not check the argument directly, like this:
>> =

>> FUNCTION(a,b,c,d) {
>>    If IsEmpty(d) Then <do steps>
>> }
>> =

>> Isn't that shorter? And you don't need to count arguments. Actually, nam=
es
>were invented for that purpose.
>
>
>
>Sure, that would be fine. My main concern was with being able to have
>empty arguments without getting syntax errors. VB will let you write a
>statement like that but will not allow you to have an expression like
>FUNCTION(a,b,,,). Your arguments can be optional and not there but they
>cannot be empty. Using a ParamArray I have been able to use a little
>trick with the first argument to write something like FUNCTION(,a,b) but
>it just doesn't like that anywhere else.

If we define that missing operands default to "skip" (which can be explictl=
y written as "?"), it would be legal to write FUNCTION (a,b,,,) which would=
 be the same as FUNCTION (a,b,?,?,?). It would also be legal to write
If d =3D ? Then ...
or even
If d =3D Then ...

which is nice, orthogonal and invites a lot of errors due to missing operan=
ds.

>> I would not allow variable numbers of arguments: use lists instead. I wo=
uld
>not allow optional arguments: Either have a "skip" value (similar to C-NUL=
L
>pointers, but potentially usable for any type), or -better still, because =
it
>requires no extra rule- somehow derive all potentially-optional values fro=
m a
>(predefined) singleton class that serves the purpose of supplying a "skip"
>value which can be tested for.
>>
>
>
>I don't know that I want the overhead of having to format my input in a
>list before I can input it into a function to get a result.

Not that much overhead: Just add extra parentheses to form a list

printf ("%s%d", ("What's the meaning of it all?", 42))

>For some
>functions this would be the logical way to do it, but for others I think
>it would be clunky. Using AutoLISP in AutoCAD requires one to input
>variable numbers of arguments in this manner and I often found that it
>required more verbiage than should have been necessary and detracted
>from the function having the most simple form possible. Suppose the
>addition function required you to supply your numbers as a list instead
>of being able to write a+b+c+ or +(a,b,c). I don't think I like this as
>a general rule. If I understand you correctly, if we have a function of
>the form FUNCTION(a,b,c,d,e) that can have up to 5 arguments and the
>last three arguments would normally be optional then you would require
>me to write FUNCTION(a,b,,,) if I don't need the last three? I would not
>be able to write FUNCTION(a,b)?

Normally yes, but one could define that missing parameters default to "skip=
" (and risk more programming errors due to accidentally omitting a paramete=
r).

It's the old story: Either have a liberal syntax at the expense of inviting=
 errors, or have a strict one, requiring more writing but being less error =
prone.

>I'll take the readability of LISP over PERL any day. You're right, it is
>not by accident that most mainstream languages look similar to each
>other. Most TV programs look similar to each other also, but I don't
>think that is necessarily an indicator of good writing.

Now you're mixing style and content.

>C for instance
>uses << in a streaming context and elsewhere as a binary left shift
>operator, a very bad human factors design in my opinion.

I agree - IMHO C (and C++ to an even greater extent) are no shining example=
s of well designed syntax. See multiple purpose use of "break", "static", "=
<", ">".

>[...] Has
>anyone got any information other than personal opinion that shows a
>tabulation of different types of syntaxes and how difficult or readable
>a particular syntax is?

Not AFAIK. Readability certainly is hard to quantify.

>I often hear "that is harder to read" (including me!) without any human
>factors experimental results to back up such a statement.

True. People tend to like best what they are used to, we have to accept thi=
s, it's another point in favour of sticking to standards.

>> IMO questions of program representation are not so important if the
>*structure* and the *concepts* of a language are well designed. Remember, =
one
>of the goals of Ultra is to allow for *different* front-ends: LISP-like or
>APL-like or C-like: no problem as long as there is a transformation to
>internal repesentation, which must be chosen to be as flexible as possible
>(AST). And of course, there must be runtime support for the services neede=
d by
>the language, but that is exchangeable and extendable, if done right.
>> =

>> So, let's not talk about syntax. Let's talk about language structure and
>concepts and the foundations on which they build: memory management and
>execution mechanism, and not worry about representation.
>
>
>This is probably true, the structure and concepts of the language are a
>higher priority. However, syntax discussion IS important because you are
>not going to be able to create this general front end without input as
>to what kind of syntax forms people find important to their needs. To
>say let's not talk about syntax and not worry about representation is to
>me a little like saying let's concentrate on the carburetor and the
>piston and not concern ourselves as to what the car looks like. If you
>give the user a 454 V8 and he wants to put a Pinto body on it he might
>be frustrated. Syntax discussion provokes thoughts about ways of doing
>things that one might normally have not thought of, I know this
>discussing has been very helpful to me.

I was assuming that there is a (suitable) translation between representatio=
n and language. Given the language, it should be rather easy to find one. K=
eeping the language structure simple, orthogonal yet powerful - that's the =
interesting part. Of course it is easier to find a nice syntax for a simple=
 language than for a complicated one.

>Yours,
>
>Jeremy Dunn
>


--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--GAIRQi3ui68RXMAWVHKroHx76ts0N5fm
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a20973a.txt IA5 DX-MAIL X.400 User Agent=

--GAIRQi3ui68RXMAWVHKroHx76ts0N5fm--