arguments by another name. 
Author Message
 arguments by another name.

Specifying options (or arguments) by name to procedures is useful and
natural in system interface procedures.  Scheme's lack of such a
construct means that many desirable options (raw/cooked,
buffered/unbuffered, output-width, append/overwrite) are not available
to it's I/O procedures.  Specifying error handlers for procedure calls
(which was discussed a few months ago) could have been done with a
named option capability.

In my view, such named options should be syntactically distinguished
from regular arguments.  Has this been done in a lisp-like language?
Common Lisp keyword arguments lack the syntactic distinction and hence
become a dynamic construct.  This allows such (in my opinion) abuses
as having expressions whose values are keywords.  If an argument to a
function might or might not be a keyword, compiled code always has to
check for it.  This would seem to slow compiled code.



Thu, 21 Jul 1994 10:33:00 GMT  
 arguments by another name.
To my mind, you always want to be able to get to a lambda that you can
call with the same arguments as you would to a named argument
procedure with the particular options specified.

For example, suppose you have an open procedure with Aubrey's options:
Raw, Cooked, Buffered, Unbuffered, Output-Width: x, Append, and
Overwrite.  Suppose further that your syntax for calling for calling
named option procedures is:

     (& open "foo.scm" &cooked &output-width: 80 &append)

(I'm not advocating this as a syntax; it's just an example.)

Then, according to my rule, I must be able to set a variable
("my-open") to the lambda which corresponds to calling open with the
Cooked, Output-Width, and Append options.  Here I get to call
"my-open" (which is a normal Scheme closure) with the same arguments
as before:

     (my-open "foo.scm" 80)

If "open" is the procedure to call to get this lambda, I can define
"my-open" by:

     (define my-open (open 'cooked 'output-width: 'append))

And so the original syntax for calling open would be expanded into:

     ((open 'cooked 'output-width: 'append) "foo.scm" 80)

(And since the call to "open" contains only constants, it would be
possible to make the call at compile time for efficiency, if you knew
that "open" was not going to be rebound.)  This allows procedures to
be called with named arguments without forcing the procedure to
decipher it's arguments at runtime.

A question still to be resolved is, how do you make sure that a call
such as:

     (& open "foo.scm" &cooked: 80 &output-width)

raises an error at compile time?  Of course, if a specialized lambda
such as "my-open" is generated you don't know which options the user
thinks the arguments are going to.  When this information is available
you want to be able to check the call.

Anyone have an idea of a nice syntax for calling named option
procedures?

Andrew Wilcox
Department of Astronomy & Astrophysics, Pennsylvania State University



Fri, 22 Jul 1994 11:02:14 GMT  
 arguments by another name.

Why doesn't one standardize a Scheme++ which would offer a set of all
the nice extensions everybody begs for?

R4RS Scheme could be left as it is and used for educational purposes.
Maybe R4RS Scheme could adopt meaningful consistent language features
in further revisions which showed their usefullness in Scheme++. Every
implentation of Scheme++ must only implement the standard features but
may also implement a subset of standardized features of Scheme++
(which availability should be detected at runtime).

Why not introduce something like a scheme language level which would
correspond to the set of features the level exposes? (We have two
levels now anyhow: 'essential syntax/procedure' and 'syntax/procedure')

The question is whether the language esoteric process of discussion
could be turned into a more pragmatic one, i.e. should scheme be used
as a professional implementation language or not? If this is the case,
how does this reflect on the process of the development of new scheme
language revisions?

Dirk
--
--

GMD-FOKUS         | Tel. Voice: +49 30 25499-282
Hardenbergplatz 2 | Tel. FAX:   +49 30 25499-202
D-1000 Berlin 12  | Room: ZAZ520



Fri, 22 Jul 1994 18:50:20 GMT  
 arguments by another name.

Quote:

>Why doesn't one standardize a Scheme++ which would offer a set of all
>the nice extensions everybody begs for?

>R4RS Scheme could be left as it is and used for educational purposes.

I'm for this.  I've been squirming over this discussion of keyword
arguments -- one more step on the long march toward Common Lisp -- but
stoically refraining from posting "oh no not another one."  If we had two
official languages, all of us could be happy.

The only thing we should change in R4RS Scheme is that all those "the return
value is unspecified" forms should be specified to return the nonprinting
object.  (The reason that change qualifies for the smaller language is that
it is needed for educational reasons, not for industrial-strength reasons.)



Fri, 22 Jul 1994 22:03:47 GMT  
 arguments by another name.
   There is no way to prevent a user from doing a vref on
   a structure implemented as a vector, or to take the cdr of a structure
   implemented as a list.  Much as I love scheme, this is a MAJOR shortcoming
   of the language, IMHO.

I feel the same way. I've been involved in teaching a data structures
and algorithms course in Tampere Univ. of Tech for a couple of years
now, and we use Scheme for teaching them. For someone who knows what
abstract data types are and is used to them, it is easy to define an
interface and forget about the implementation. For a novice, though,
it is not that easy to see the abstraction barriers, because the
language does not enforce them.

I do know about using closures and message passing to hide the
implementation, but somehow it seems a bit of overkill when all I want
is a simple type representing, say, pairs of numbers.

What I'm going to do this semester is that I continue using Scheme,
but introduce examples using Standard ML and C++. (To prevent flames:
Scheme and ML are not much use when you want to talk about freeing and
reserving memory etc., which IMHO are worthy things to know).
--
Pertti Kellom\"aki (TeX format)  #       These opinions are mine,
  Tampere Univ. of TeXnology     #              ALL MINE !
      Software Systems Lab       #  (but go ahead and use them, if you like)



Sun, 24 Jul 1994 17:02:01 GMT  
 arguments by another name.

Quote:

>...  (This is less of a problem with extensions that can
>themselves be written in portable Scheme; a lot of them can't, and
>(IMHO) next to none of them can be written "properly", because they
>typically involve at least one of adding what should be new types,

...

One of the great things about Scheme is that you can add new data types
without changing the language.  

[I think that you just got carried away here, David]




Sun, 24 Jul 1994 00:11:02 GMT  
 arguments by another name.
|2) Why blah=?, blah<?, blah>?, blah<=?, blah>=?, when just two of them
|suffice (if we want them all, why was blah!=? left out?).

Two possibilities:

1. Because blah!=? doesn't extend nicely to more than two arguments.
(Think about it, then look at Common Lisp's /=.)

2. (more likely) Because no one has come up with a reasonable name.



Sun, 24 Jul 1994 11:01:06 GMT  
 arguments by another name.

Quote:

>One of the great things about Scheme is that you can add new data types
>without changing the language.  

This is not quite true.  Scheme provides numbers, strings, symbols, lists
and vectors.  You can define sets of operators that look like the interface
for a new abstract data type, but there is no way to hide the underlying
implementation.  There is no way to prevent a user from doing a vref on
a structure implemented as a vector, or to take the cdr of a structure
implemented as a list.  Much as I love scheme, this is a MAJOR shortcoming
of the language, IMHO.  (T provides a much better facility for defining new
types.)

Erann Gat



Sun, 24 Jul 1994 05:39:02 GMT  
 arguments by another name.

Quote:

>Specifying options (or arguments) by name to procedures is useful and
>natural in system interface procedures.

You mean like: (compile-file "tak" 'M68000 'Asm 'Stats) ?  People
don't do this?

Quote:
>In my view, such named options should be syntactically distinguished
>from regular arguments.  ... compiled ...

The natural thing to do (IMHO) would be to create a syntactic
convention (macro) such that a function always gets called with all
required arguments, including the defaulted ones.  As syntax
transformation is typically done at read-time, no runtime cost is
incurred.

  (%&key1 val1) -> (%val1 `,(if (memq val1 key1-options) val1 default-val1))
  (%&key2 <exp>) -> (%val2 <exp>)

The only tricky bit is setting up the cases to rearrange argument
orders and filling in the blanks with the defaults.

  (operation (%val2 <exp>)) -> (%operation default-val1 <exp>)

[Personally I would rarely use keyword arguments, so I am not
interested in implementing this.  It might be fun for someone,
however.]




Sat, 23 Jul 1994 04:44:43 GMT  
 arguments by another name.

   Why doesn't one standardize a Scheme++ which would offer a set of all
   the nice extensions everybody begs for?

   R4RS Scheme could be left as it is and used for educational purposes.
   Maybe R4RS Scheme could adopt meaningful consistent language features
   in further revisions which showed their usefullness in Scheme++. Every
   implentation of Scheme++ must only implement the standard features but
   may also implement a subset of standardized features of Scheme++
   (which availability should be detected at runtime).

   Why not introduce something like a scheme language level which would
   correspond to the set of features the level exposes? (We have two
   levels now anyhow: 'essential syntax/procedure' and 'syntax/procedure')

I just want to point out that the EuLisp project is an effort in just
these directions.  EuLisp begins with a Scheme-like kernel level, and
adds in many of the features which users want, including a module
system and an object system.  (Keywords have not been addressed.)
While EuLisp is not a strict Scheme superset -- some of the function
names are based on CommonLisp rather than Scheme, and there are some
differences in the numeric domain -- nearly 100% compliant Scheme
modules have been implemented in EuLisp, and used for teaching SICP.

The latest definition of EuLisp and a PD implementation called FEEL
are available via ftp from gmdzi.gdm.de, directory lang/lisp/eulisp.

-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis                       ILOG S.A.

tel: (33 1) 46 63 66 66                 94253 Gentilly Cedex, France



Sat, 23 Jul 1994 18:47:23 GMT  
 
 [ 121 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9]

 Relevant Pages 

1. name for how many arguments

2. Naming conventions for method arguments

3. list comprehension and default argument name

4. Using DB or DW without name argument

5. file name expansion in command line arguments with CVF and LF95

6. Interaction of generic names and assumed size arguments

7. Derived type name as a dummy argument - possible?

8. getting argument names from a function

9. INCLUDE, interfaces, function names as arguments, modules

10. Getting the argument names passed to a function ?

11. Win32 - COM - argument by name?

12. How to force keyword argument name?

 

 
Powered by phpBB® Forum Software