I am sorry that I have been rather slow in following up the earlier discussion, but I have been preoccupied with another project. Yes, I had worked out the mechanism that you describe for providing optional arguments. However, it does not work for all argument types. Also, the order of the arguments is important. To explain: A. The current version (1.7.6rc1) won't accept the following syntax in an argument list function xxx( ... string *var[null], ... ) which means that string arguments cannot be omitted. As far as I can work out, it is valid to use this syntax for integers, scalars, matrices and series, but not for lists and strings. Given the recent discussion of list arguments, the first is probably sensible but it seems arbitrary to rule out the possibility of null string arguments. B. The argument list is read from left to right - fair enough but it means that if a user provides 3 arguments for a function with, say, 5 potential arguments, then these 3 arguments are mapped to argument 1, argument 2, argument 3. This is entirely reasonable for the programmer but less obvious for the novice user who wants to define arguments 1, 2 & 5. Of course, what they must do is specify function xxx (arg1, arg2, null, null, arg3) but much of the simplicity has been lost unless the programmer can guess how the function is most likely to be used. That is really my point about the convenience of using $accessors rather than pointer arguments. I have also thought some more about my functions. On reflection, it seems to be sensible to retain separate functions for certain purposes - e.g. the calculation of residuals because a user may wish to do this for observations that were not part of the estimation sample. On the other hand, I would also like to allow a user to supply initial parameter values because some models have serious problems with convergence. Hence, what one really needs is a flexible front-end function that can be used to control calls to one or more helper functions that have more rigid requirements but which the average user doesn't need to know about. At the moment that is difficult, but it may be worth bearing in mind as a long term goal. Finally, with respect to access to functions through the GUI my reaction is that the key thing is to flag the defaults clearly - ie what happens if arguments are omitted. This should be done on the main page, so that users would know what will happen if they do not define any arguments on the 2nd optional page of the notebook. However, I am not the best judge of this because I rely almost entirely upon script or command files in order to have a record of what I have done. Gordon