Declaring arguments to a function

[Jeremy Dunn]

Hans-Dieter.Dreier@materna.de wrote:



> >I am not certain that I understand what you mean by "chained infix
> >operators", could you give me
> >an example?
> 
> cout << "The result is " << i << "." << endl
> 
> ... or, to chain strings:
> 
> str = "The result is " + NumToStr (i) + "." + CrLf
> 
> ... or, to build a list:
> 
> list = a, b, c
> 
> (Here the "," operator forms a new list from two simple values or appends a value to a list).



Thanks, I know what you mean now.



> >[Name-JeremyDunn : BirthYear-1957 : HomeTown-Bellingham,
> >Name-HarryHoudini : BirthYear-1957 : HomeTown-NewYork]
> >
> >I could also write this as
> >
> >[Name(JeremyDunn,HarryHoudini),
> > BirthYear(1957),
> > HomeTown(Bellingham,NewYork)]
> >
> >There are some advantages to doing it this way, as one can concentrate
> >on the category of information quickly. This particular case is more
> >readable than the first method and displays the information in a more
> >meaningful manner. The lack of indice on 1957 would have the default
> >meaning of applying to all the Names and the HomeTowns don't need to be
> >indiced because they equal the number of Names and correspond directly
> >to them. Indicing need only occur when the position of the item in the
> >given list does not correspond with the same indice in the Names list.
> 
> If I forget to specify a value, I'd prefer to get a warning, even if that means that I have to write a little more. Maybe it is simply a matter of personal preferences. How about allowing both forms, alternatively ?



Sure, I'm all for freedom of choice. Let the given situation dictate
which form is more useful for readibility.



> >> You would write FUNCTION (EmptyArguments ()), right?
> >
> >No, the EmptyArguments() function is used INSIDE a function to gather
> >information about what has actually been
> >supplied to the function. You could write something like
> >
> >FUNCTION(a,b,c,d){
> >   Z = EmptyArguments()
> >   If Member(3,Z) Then <do steps>
> >}
> >
> >If the user now uses this function and writes FUNCTION(a,b,c,) where d
> >is missing then EmptyArguments() will return a list (3) with the indice
> >of the argument that is there but empty. The function will then compare
> >3 to the list Z and if 3 is in the
> >list then a series of steps will be performed. EmptyArguments() enables
> >the programmer to easily determine what is not there and respond to it.
> 
> I see. I thought you wanted to supply default values from "the previous function statement" which I misunderstood as "the previous function call".
> 
> 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, names 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.



> I would not allow variable numbers of arguments: use lists instead. I would not allow optional arguments: Either have a "skip" value (similar to C-NULL pointers, but potentially usable for any type), or -better still, because it requires no extra rule- somehow derive all potentially-optional values from 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. 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)?


> >Your first paragraph here gives me DejaVu Dieter. I recall making the
> >argument for completely consistent syntax but everyone
> >balked when I suggested applying it to ALL operators including unary
> >ones like +-*/. The reason? They just don't like it. It reminds me of
> >the American attitude about the metric system, they don't want to get
> >rid of those silly feet and inches. Anything short of what I suggested
> >automatically depends on context! How can you write pow(a,b) and in the
> >next line write a+b rather than +(a,b) and not use context to tell what
> >is going on? That is one reason I don't like most languages, most them
> >have "special" layouts for certain functions but not others, and each
> >time they do this requires the user to remember yet another exception to
> >what could be a completely consistent grammar. I have often found it
> >interesting that out of the hundreds of languages that have been written
> >that LISP is probably the only language that is grammatically
> >consistent. There are only 3 grammars possible:
> >
> >x FUNC y    unary operators (inherently limited, requires precedence
> >rules)
> >FUNC(x,y)   works fine-no precedence
> >(FUNC,x,y)  works fine-no precedence
> 
> Why do you call +-*/ "unary" operators? They require two operands, therefore they should be named "binary" or "infix" operators. How do you call operators that take just one argument, like "-" (to take the negative value of a number)?


You're right, bad terminology on my part. Even with my bad terminology
the "-" operator when used to indicate negation is really not a unary
operator because -X is simply a shorthand for 0-X which is a binary
operator.


> >If we want the minimum of context rules we are forced to pick one of the
> >last two forms and carry it out without exception.
> >Oh well, I am wasting my time. Human nature is against me, people want
> >feet and inches and the Julian calendar. Enough ranting for today!



> Maybe the truth lies in the middle. Certainly, LISP has a very simple syntax, which is good, but it pays dearly by requiring a pretty printer just to be readable. Taken to extremes, we could do with just two symbols, 0 and 1, and encode everything binary, or we could go the APL way and invent a special character set which has a special symbol for each keyword (very short but, again, hard to read). IMO it is not by chance that most "main stream" programming languages nowadays look so similar to each other. It's the same as with bicycles or pencils: A mature design is hardly improvable unless done in a completely new way (say, programming by data glove).
>


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. 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. Probably most
language designers come from a C background and kludge their syntax on
top of it so that they can minimize their effort of relearning. I
learned a GIS system created by programmers, it had the most godawful
bad human inteface a person could create, it was almost as though they
deliberately designed it to be as bad as possible. I am not certain that
programmers are necessarily the most qualified to design syntax. 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?
I often hear "that is harder to read" (including me!) without any human
factors experimental results to back up such a statement.


> Regarding the syntactic handling of special (ie operator) symbols like ordinary names: You are right, in principle, BUT if you also allow the "traditional" form, the syntax tends to get too permissive, allowing too many typos to form legal (but nonsensical) expressions. For this reason, it may also be harder to read by humans. And if you don't have traditional infix operators, you end up with LISP-like syntax.
>


Right, or Mathematica syntax which I also love. The nice thing about
consistent syntax is that once you know it for one function you know it
for ALL of them. Consider VB, first you learn to write A + B then you
learn to write Abs(X) then you learn the special forms for a Select Case
statement (remember those colons!). That isn't the end, the FOR function
has a special syntax, CONST statements have a special form. It is like
this with all the C-like languages out there and that is why they are
all such a pain in the ass to dive into.


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

Yours,

Jeremy Dunn