Find file
Fetching contributors…
Cannot retrieve contributors at this time
422 lines (342 sloc) 18.2 KB
# -*- mode: org; -*-
#+TITLE: *Notes of the EuLisp meeting 19/11/93*
#+OPTIONS: ^:{} author:nil
* Notes of the EuLisp meeting 93/11/19, the Emerald Meeting
*** Friday 19th, notes by Russell Bradford
*** Saturday 20th, notes by David DeRoure
These are outlines of the discussions at the meeting: Julian will email a
summary of the proposals shortly.
*** Present were
Julian Padget, Harley Davis, Nitsan Seniak, Horst Friedrich, Klaus Daessler,
Richard Tobin, Willem van der Poel, Christian Queinnec, Neil Berrington,
John Fitch, Russell Bradford, Juergen Kopp, Harry Bretthauer, Toni Moreno,
Ulises Cortes, and David DeRoure.
* Friday 19th.
We proceeded the email list of points, with some held over for the arrival of
DDER on Saturday.
*** static errors might be signalled
JAP: two proposals (1) extend definition of 'dynamic signal' (2) extend
definition of 'static signal', HD added (3) remove distinction. KD described
the way Prolog distinguishes static violations and run-time static errors,
and this general approach was adopted. Thus 'static error' becomes
'violation' (RT noted that violations should produce diagnostics in the PPU
== program preparation unit). Other errors might be detected by the PPU, but
if a runnable program is produced, this program must signal an error.
*** macros -> syntax functions, remove defmacro
HD noted that macros are equivalent to functions only in the presence of
symbol-function, otherwise we have two namespaces. General disquiet
resolved to ignore this proposal.
*** add export-syntax
HD proposed the definition be more clear that macros are bound in a lexical
environment, and consequently export-syntax is useful. Also that macro
names are not bound to anything in the program (macros are only meaningful
to the PPU). Changes needed in section We shall explicitly allow
macros to have the same names as functions (due to modules), and we make
explicit that apparent ambiguities are resolved in favour of the macro by
the PPU (after all, anything else is meaningless). Sections 9.7, 9.5.
Export-syntax will make module processing simpler; it will be a violation to
export-syntax a function (and vice versa for export and macros).
*** defconstant redundant
As a side point, HD remarked that defconstant is not useful in practice, it
does not allow in general any significant optimisations. Ilog Talk
additionally has defliteral (cf C's #define) that is expanded in
non-functional positions. HD to send proposal.
*** level-0 telos conditions
subsumed by static errors above.
*** add <wrong-number-of-args>
OK. This is an error (not a violation).
*** case in format directives
HD proposed the POSIX view of function names fprintf, sprintf and % for
formats. Plus the additional %a corresponding to print. Also %s will
convert its argument to a string as in write. There is a need to list the %
operations with relevant converter methods. HD also proposed the inclusion
of eprintf, a print function guaranteed never to signal an error (as far as
is possible), to confound infinite loops that arise when there is an error
in a print method. JPFF noted that scanf should be made compatible, while
HD argued for its removal. HD will send a proposal.
*** add read function
*** class-specific input functions
These were proposed as an aid to type inference, which RT felt was
insufficient reason (there are too many other similar changes we could
make). HD described how something like (convert (read) <integer>) could be
used for extreme cases. It was decided to defer this pending better
understanding of the consequences, and after discussions of streams.
*** invariant gf application behaviour
This was deemed a good principle ('definition before use'), but raised the
difficulties consequent of undefined module initialisation order. Invariant
behaviour was seen as a partial sealing of the class hierarchy (NB sealing
upwards from a class), and there was discomfort from some that this sealing
was a side effect, and not explicit. This led to the general problem of
development vs run-time environments, and it was revealed by HD that there
is no way to check for a correct program if certain errors (e.g., add-method
to an existing method) are ignored in a development system. Restrictions
that currently exist to aid the compiler should be "an error", not "signal
an error". HB will find such cases (in Telos). RT was of the opinion that
there are too many small tweaks for efficiency, and that more wide-ranging
techniques might be considered (e.g., declarations, sealing...)
Back to invariant behaviour. RT inquired as to the behaviour of a method
that adds a new method super to itself, and then calls call-next-method....
Lunch was held at a variety of pizzeria.
... CQ suggested a new subclass of immutable gfs as a solution. This was
deferred to be discussed later.
*** method default specialisers
This was felt to be unhelpful, and difficult to implement in the case of
unattached method-lambdas. Some mooted that all arguments specialised in
the defgeneric must always be specialised in the method, but there was no
enthusiasm for this. It was decided that the default will be <object>, and
an error will be signalled if a method attempts to widen a gf's domain. In
summary, no change.
*** rest args in gfs
OK. A short dicussion of the name of the new initarg 'rest' vs 'restp'.
The former for future use in a generalised type scheme.
*** remove method-function-lambda et al
HD felt that these functions were necessary to avoid an extra function call
in the execution of gfs (e.g., the MOP has compute-primitive-reader return a
function that must be wrapped by a method-lambda). On the other hand HB
wanted method-lambdas to be indecomposable, and described congruency
problems with lambda lists of method-lambdas and their functions. These
could be solved by the introduction of functions method-lambda-list and
function-lambda-list. These were shelved for future consideration. It was
noted that (make <method>) would make a method that was 1 funcall more
expensive to call than one created by method-lambda, unless a method was
initialised from a method-lambda rather than a function. Discussion would
continue offline.
*** additional scan directives held over
*** deep-copy and shallow-copy
NS wanted the definition only to require equal of an object and its copy.
This was considered to be another case of ad-hocness around the edges and
dropped. It is related to specification of "result types",
below. Summary---leave as is.
*** specification of result types
*** abstract classes
JK described how having abstractness defined by a metaclass was
inappropriate. The proposal to have abstractness encoded by a slot in the
class was accepted, with the reader renamed from abstractp to
abstract-class-p [editor's note: wouldn't class-abstract-p be more
*** add required initargs
HD opined that 'initarg' as a word was not understood by many, and it was
agreed to change the term to 'initkey'. After discussion of where to put
things, it was decided to introduce a new slot option 'requiredp' to
indicate that the initkey for this slot is required. However, class
initargs would remain unchanged, it would be the responsibility of the
programmer to check for the required class initkeys, as this would require
minimal extra work (since the programmer has already to look for the value
of the initkey). HB noted that this would prevent an easy
Further renamings were agreed, namely 'initkey' to 'keyword', 'initform' to
'default' and the dependent compound names.
*** add openp for streams
*** D or E for exponent in numbers
It was decided to use E, as it was felt that support for the input of
single-precision floats wasn't needed, quads are more important.
*** module initialisation order
*** arg order of (setter element)
This was only relevant to objects referred to by keys, viz., using element.
Thus this is left as is.
*** <collection> and <sequence>
This was felt to be generally OK, but would have consequences, such as the
clarification of sequence objects vs collection objects, and the allowing of
defstruct to subclass any abstract class. This was postponed until the
discussion of the class hierarchy later.
*** thread-start, thread-value generic
*** add generic-signal
OK, but the last argument of signal (the optional thread) becomes the first
argument of generic-signal, and the function is to be called
*** wait method on <lock>
It was felt that a timeout on a lock would be desirable, but then there
might be breaking of abstraction with a zero timeout. RJB suggested an
optional timeout argument to the function lock. More discussion tomorrow.
*** non-hygenic semantics for syntax functions
Extra documentation on the pitfalls of macros will be added.
*** status of and and or
This arose from the wish to pass 'and' as a function argument. After the
discussion of macros above, it is clear that this is an error, no such
binding. Suggested names for functional and generic variants included:
binary-and, binary-or, ||, &&, generic-and, generic-or, every, any, all,
some, both, either, strict-or, strict-and.
This ended the email list. Further points arose.
*** character naming conventions
For uniformity over characters and strings, replace extended character names
by the names used in strings, e.g., #\newline -> #\\n
*** keywords
HD wanted the introduction of keywords as a class (aside: there are some
missing characters in the table on p.9, namely colon). A minimal change
could be the convention of using :s in names (at the end) to indicate a
keyword, but they would still need to be quoted. In Ilog Talk there is a
hierarchy <id> <symbol> <keyword> (the class <id> was later renamed <name>),
with keywords acting like self-evaluating, non bindable symbols, denoted by
a terminal colon.
*** with-handler
The example of with-handler in the document was revealed to be poor, as it
used generic-lambda, which is expensive to set up, while handlers should be
cheap to install. Since with-handler is a special form, it could have a
lazy computation of the handler function, but this is complicated. It was
decided to fix the example.
Dinner was held at the Commission Restaurant. Conversation was lively, as
was some of the seafood.
* Saturday 20th
*** Organisation of class hierarchy.
Harley proposed that, as a general principle of organisation, concrete
classes should not inherit from concrete classes.
Implications on fig 3 p.13 - these are the classes:
A = abstract, C = concrete, S = subclassable, S1 = subclassable at L1
Level 0
object A S
character C
condition A S
function A S
continuation C
simple-function C
generic-function A S1
simple-generic-function C
collection A S
sequence A S
list A
cons C
null C
character-sequence A S
string C
vector C
table A S
hash-table C
lock C
number A S
integer A S
fixed-precision-integer C
variable-precision-integer C
float A S
double-float C
stream A S
string-stream C
char-file-stream C
name A S
symbol C
keyword C
thread A S
simple-thread C
Level 1
class A S
built-in-class A
simple-class C
function-class C
slot A S (was slot description)
local-slot C
function A S
generic-function A S
simple-generic-function C
method A S
simple-method C
After discussion, character was not an abstract class. Then after further
discussion it was. Then after yet more discussion there was an implicit
majority and it wasn't again. Stronger case for strings, hence
character-sequence introduced as abstract class. Should streams be a
subclass of sequence/collection? Not yet. Harley and Harry agreed that
structure and structure-class are not needed. Now we don't need defstruct
(accessors by default are now functions, not generic; default metaclass is
simple-class). The question of what is inherited from abstract classes is
too complicated to address now.
We need to be able to subclass some abstract classes at level 0 - so we
don't need structure class anymore.
Should variable precision integers be added? Not such a big deal these days
(eg DEC or GNU libraries). Julian to decide.
Harry: Definition permits implementor to introduce extra classes but no new
Harley: p.70 tables: remove `unique' else requires perfect hash
Harley: condition classes - we should distinguish between lexical syntax
errors and syntax errors which arise given a correct s-expression. So
`syntax' error condition from read should be called read-error.
dder: text for function call and apply should accommodate continuations,
i.e. `if the function returns...'
wait method on locks
minor points raised by mail
which generic functions on collections are specialised to sequence
n-ary comparators
publication schedule
After an informal vote, we are all in favour of having another meeting.
Date not fixed.
Wait method - delegated to dder/jap/nb dder observed lack of orthogonality
of wait. Richard observed that ways of waiting on collections of objects
not in definition.
*** Minor points:
+ p.59 number class metaclass to be removed (because this is level 0) need a
class hierarchy for level 1 with metaclasses harry: in appendix B need a
_complete_ hierarchy
+ p.52 cross reference to binary< etc
+ p.59 how are mixed number args handled? All we have now is floating point
contagion (section A.13).
nitsan: + etc call lift on args of binary+ etc
jpff: floating point contagion on comparison is
a bad strategy. So lifting not to be used for
comparators. Position agreed - further work needed
before version 1.
+ p.14 initform - reference to dynamic env of make should apply to
use of constructors as well as make. Also, defconstructor description
should require compliance of constructor and make. Agreed.
We have initialisation options on conditions, but we don't name the
accessors for these slots - are they the same as the initargs? If so
there will be some name clashes (see Ulrich's mail). Agreed to merge
slots - generic-function-condition has two slots, i.e. generic function
and message. Format of message needs to be specified in definition too.
+ BTW No longer need defcondition since we can use defclass.
*** n-ary comparators
+ Harley wants n-ary >, >=, <=. Agreed.
+ Do we want != to be n-ary? No, this is not n-ary in Dylan.
*** Apres pizza
Harley: no comment
accumulate C
accumulate1 C
anyp C
do C
element C
emptyp C what about fill value? (see below)
fill C begin or end, or set of keys
map C
member C returns rest of list (only) (historical)
size C number of keys, not size allocated
(but what is size of circular list?)
delete C destructive
remove C constructive
concatenate S because of hash tables
reverse S
first S
second S
forty-second S
last S
sort S
We should change the fill value default mechanism to a fill function: this
is a lambda of two args, the condition and the key. Nitsan, Harley, Dave,
Russell would like vector-ref and string-ref, and associated setters. Also
lengths, i.e. list-length, vector-length, string-length, table-size/length.
Names still need discussion.
Some discussion of remove and delete (non-destructive and destructive).
*** Publication schedule.
We need a guillotine. Publish and be damned. Target is next Spring.
Harley will manage negotiations with commission; he noted his
concern at this expectation. It was suggested that objectors to the
publication can have their names removed from the contributors list.
*** streams.
History. Edinburgh meeting. Dave explained the stream protocol
solution. Harley explained the `posix' style solution. This
was well received. Harley to send text to Julian.
*** Pathnames. Renamed filenames.
VMS, symbolics etc compatibility no longer a
priority. UNIX and Windows NT are the priorities instead.
Syntax #F"..."
+ string->filename "/hux/baz/"
+ basename ""
+ extension ".bar"
+ dirname "/hux/baz"
+ device "C:"
+ merge-filenames