[R6RS] my notes on today's conference call (10 May 2006)

[William D Clinger]

Conference call May 10 2006 12:45pm
All present by about 12:45pm:
Kent, Anton, Will, Mike, Matthew

0. finalize agenda (1 minute)
    enumerations proposal (5 minutes)
    discuss sealed feature of records (10 minutes)
    SRFI-1 (15 minutes)
    change condition votes agenda item to discuss conditions;
        delay vote to next week

1. action items from 5/3/2006 (5 minutes)
   - post new arithmetic SRFI (Will)
        will submit document to SRFI editor tomorrow,
        reference implementation will follow later
   - mail condition vote list (Will)
        done, but not in time for everyone to vote
   - carried over:
     - withdraw Unicode SRFI (Matthew)
        not yet
     - syntax-case SRFI, with reference implementation (Kent)
        done
     - continue refining core/language split proposal (Anton)
        in progress
     - refine library modifications to allow subsetting, etc. (Matthew & Kent)
        in progress
     - email "final" enumerations proposal (Will and Mike)
        semi-done; Will wants to discuss possible changes

enumerations
    combine enumeration types with enumeration set types,
        perhaps with some provision for leaving out some set stuff
    add mechanism for injecting from one universe to another

sealed feature of records
    although rationale still hazy in some details,
        the sealed feature seems like something we'll want eventually
    decision: put it in now

3. SRFI-1 functionality for R6RS
    The six most important, according to Anton and Will:
        filter
        fold
        fold-right
        iota
        any
        every
    The next four most important, according to Mike:
        find (the most important of these four)
        filter-map
        partition
        concatenate
    generalized versions of member, assoc, remove

2. condition votes (now discussion)
    Mike and Kent proposed refinements to condition hierarchy
        Will will incorporate the refinements
    Matthew pointed out that condition hierarchy is too detailed
        Matthew will propose a simplified hierarchy
    "must raise" can be unreasonable
        what if a concurrent thread modifies the second arg of map?
    two different ways in which something can fail to be a list
    must/should vote might not be uniform across a list, e.g. memq
    Will will send out revised list of votes; everyone must revote
    
Mike has two requests
    look over -> proposal
    look over eval proposal

4. adjourned about 1:45pm