[R6RS] Goals

[Manuel Serrano]

Here is my personal (open) list. Most of it is, unsurprisingly, exactracted 
from Bigloo (I take for granted that we are going to add modules).

1) Libraries:
-------------

  1.1) operations on files (FILE-EXISTS, DELETE-FILE, REOPEN-INPUT-PORT, 
       APPEND-OUTPUT-PORT, WITH-OUTPUT-TO-PORT, DIRECTORY->LIST< etc), 
       formated outputs.

  1.2) regular expressions.

  1.3) command line parsing.

  1.4) bitwire operations.

  1.5) hash tables.

  1.6) system operations (GETENV, SYSTEM (a la Unix), EXIT, SIGNAL, ...).

  1.7) support for PROCESSES.

  1.8) support for networking programming (sockets).

  1.9) a library for computing over dates.


2) Core language:
-----------------

  2.1) make the language case sensitive (the identifiers of the language).

  2.1) remove the second parameters of eval.

  2.2) errors & exceptions.

  2.3) pattern matching.

  2.4) object oriented programming.

  2.5) keyword parameters (named parameters).

  2.6) serialization/deserialization (such as OBJ->STRING and STRING->OBJ).

  2.7) elaborate a mechanism for creating new primitive types from external
       values (e.g. from C values). 

  2.8) remove FORCE and DELAY.


3) Miscellaneous:
-----------------
  
  3.1) elaborate a mechanism that enables implementations (compilers and
       interpreters) to point out error in the source code.

 
4) To come back to the Marc's list:    
-----------------------------------

> 3.5) Remove multiple values.  Their usefulness is questionable
>          when record types are available, and the syntax to use them
>          is clumsy (I find that for the code I write explicit CPS is
>          more readable and flexible!).
As Kent I disagree. First, as Kent, I like using multiple values in 
my code (I don't use VALUES and CALL-WITH-VALUES but MULTIPLE-VALUE-BIND a la
Common Lisp and Dylan). Second, because MULTIPLE-VALUE-BIND can be implemented
without allocating on the heap (I know, I know, we have said that we were 
not discussing technical details here...).

> >     6.2) Add optional and keyword parameters, as specified by the
> >          DSSSL standard.  Keyword parameters are particularly useful
> >          when a procedure has many optional parameters.  The semantics
> >          should be fairly obvious from this example:
> 
> I prefer case-lambda to the #!optional syntax.  It's more general in
> two ways: (1) one can easily create procedures that take, say, either
> one or three arguments but not two, and (2) one doesn't have to think
> up or test for a default value in cases where one intends to do two
> different things depending upon the number of arguments.  Both are
> fairly common circumstances, at least for us since we have a mechanism
> for supporting them.
I have implemented DSSSL arguments in Bigloo about 5o r6 years ago. 
I'm using them from time to time. I'm not familiar enough with CASE-LAMBDA to 
understand if they are comparable. DSSSL arguments are powerful but, from 
my standpoint, they are ugly. First they require three special 
values (#!rest #!optiional #!key). Second, their semantics is unclear. 
If you don't believe me try to answer this simple puzzle in a couple of 
seconds:
   what is the value of X in
   ((lambda (#!optional a #!rest X #!key foo (bar 4)) ...) 3 5 :foo 4)

In favor of DSSSL arguments, they exist and, in some sense, they are
a standard. 

> > 17) Boxes.
> 
> >     Add the box type.
> 
> I prefer to leave boxes out.  It's no big deal to use pairs and put
> something innocuous in the cdr field, and with a record-definition
> facility, one can always define a single-celled record type if desired.
Marc, could you tell us what is your intention with boxes? (this is a
purely innocent question?)

-- 
Manuel