In article <··········@nz12.rz.uni-karlsruhe.de> ······@ilog.fr (Bruno Haible) writes:
Scott Fahlman <···@CS.CMU.EDU> wrote:
>
> No, I think that this is a silly Europe vs. US/Japan war.
It's more like US vs. Europe/Japan.
Whatever...
> This ISO standard will be ignored, of course,
It is not being ignored. At least two commercial Lisp implementations
I know of (ILOG Talk being one of them) implement most of ISLisp.
I meant that it would be ignored by those not deeply involved in
creating the ISO standard. Clearly ILOG has a major interest in
seeing this standard "take". Who is doing the other implementation,
if you're allowed to say?
> Well, this is no longer my problem. I'm off trying to establish the
> next great langauge (Dylan),
Dylan requires a much more intelligent compiler than ISLisp does.
Not really. In some ways it is easier, once you get past the parser
(which is pretty standard technology). Implementing method dispatch
efficiently adds some complication, but you get that problem with CLOS
as well.
Who
on the world (except Harlequin) has the human and financial resources
to develop a Dylan compiler and development environment? ISLisp is
simpler, so you don't have to invest that much.
Our group at CMU whipped up the Mindy implementation of Dylan in a
couple of wizard-months, though more work has gone into extending it
since then.
If you're talking about a super-optimizing compiler completely
integrated with a hypercode environment, that is indeed a difficult
and open-ended problem, though not (we hope!) beyond the capabilities
of a strong university project.
Cheers,
Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 268-5576
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================
As soon as I heard about ISlisp, I downloaded the current (15.6) draft,
and spent the weekend studying it in some detail.
Who precisely is helped by renaming RPLACA to SET-CAR
If you don't like the name RPLACA, just leave it out, (SETF (CAR ..) ..)
will do fine.
Renaming DO to FOR looks like petty spite.
Renaming &REST to :REST was rather petty too. (Yes, there is one sentence
that says you can use either of them, but all the examples use :REST.)
The standard is supposed to be more oriented to the needs of industry,
but in marked contrast to Common Lisp gives you no information about
floating point properties, less floating-point support than C, not least
no choice of floating-point output formats (only unparametrised ~G, the
result of which is not spelled out).
There are several kinds of simplicity.
1. How easy is it to _specify_ something?
The ISlisp 15.6 draft is about 120 pages. No argument that it is
easy to specify. (Well, maybe. The text needs a *lot* of work.)
2. How easy is it to _implement_ something?
keyword parameters have been left out.
multiple inheritance is provided for in the same as as Object Pascal;
it's not clear to me that this simplifies the implementation much.
The specification of (format --) has been limited (to the point where
it is less capable at numeric formatting than C, which is pretty limited)
Hash tables are missing.
Packages are not there.
Apart from that, pretty much all the hard stuff is there.
I see no evidence that type inference, for example, is easier than in
Scheme or Common Lisp.
I am not up to speed on current Lisp compilation techniques, but I
really do get a strong impression that writing a really good compiler
for ISlisp is not _significantly_ simpler than writing a really good
compiler for Common Lisp.
There is no call-with-current-continuation (so much for learning from
Scheme). Nor are there multiple values. (Which _are_ in R5RS Scheme.)
3. How easy is it to _teach_ and _learn_?
A good small language is a real winner there. Roughly speaking, the
main advantage of ISlisp over Scheme is
- format (but that's in most Scheme libraries including SLIB)
- the condition system
The main disadvantage opf ISlisp over Scheme for teaching is
- separate name spaces (variables, functions -- in variable name
space in Scheme), block labels (block exit done using call/cc
in Scheme), goto labels (no gotos in Scheme)
- which necessitates the somewhat confusing 'funcall' and #'
For example, I _can_ say in ISlisp
(defvar foo (lambda (x) (car (cdr x)) ))
but I then have to call it with 'funcall'. Note the absence
of #' on the lambda expression.
Providing hash tables instead of property lists would be a good move
for teaching and learning. (So it proved in Pop.)
4. How easy is it to _use_?
Much of the reason why ISlisp 15.6 is smaller than CLtL2 is the
omission of a good deal of the library. For example, the ISlisp
designers seem to think that industrial programmers have no need
for case conversion or case-ignoring string comparison. Leaving
string-equal out simplifies the standard, but does little to
impress an industrial programmer who wants to know the Lisp
equivalent of strcasecmp(). Putting property lists (properties
can only be attached to symbols, and property names can only be
symbols) does nothing to help industrial programmers, who _would_
be well served by hash tables.
I know that in my own Scheme programming I spent a lot of time
reproducing things from Common Lisp, because they were useful.
ISlisp programmers will have to do the same. This is silly.
The only mapping function available for vectors (or any non-list
sequence) is map-into. Heck, even the C++ draft standard provides
operators mapped over arrays (see section 26.3 in the draft standard
and the vector<> template).
Industrial programmers are benefitted by
- the code they _don't_ have to write
(that is, well structured libraries are a good thing, even if
large)
- bindings to the environment (POSIX.1/1a bindings, GUI bindings,
network bindings)
- training materials
(splitting the market helps *nobody* here).
Given the existence of MCL, CLISP, GCL, CMU Common Lisp, &c, I can see
no advantage to potential industrial users in having yet another dialect.
Consider this. For C programming, a currently popular debugging kit is
ddd on top of gdb. This gives C programmers _some_ of the inspection
and debugging capabilities I was used to in Interlisp-D. On the machine
I'm posting from, gdb is 1.5M and ddd is 2.2M. That's 3.7 *megabytes*
for a C debugging environment. On the same machine, gcl is 2.5 megabytes.
Given those sizes, I don't see any need for a smaller Lisp standard.
I *certainly* don't see any advantage to *users*.
--
"conventional orthography is ... a near optimal system for the
lexical representation of English words." Chomsky & Halle, S.P.E.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
··@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) wrote:
> Nor are there multiple values. (Which _are_ in R5RS >Scheme.)
Uh, what R5RS? Was this ever published?
--
T. Kurt Bond, ···@wvlink.mpl.com
This is not very relevant to ISLisp.
>>>>>> "mad" == MAEDA Atusi ····@math.keio.ac.jp> writes:
mad> Local functions are easier to handle in Common Lisp, because they
mad> cannot be redefined within their scope. In Scheme, however,
mad> LETREC-bound variables can be modified with SET!. So compiler must
mad> first prove that the value is a procedure at the time of invocation
mad> before emitting direct call instruction.
>>>>> "will" == William D Clinger <····@ccs.neu.edu> writes:
will> This is true. It is also a very easy optimization to implement:
will> If a LETREC binds a variable to a procedure, and that variable
will> does not appear on the left hand side of a SET! within its scope,
will> then the compiler knows not only that that variable is a procedure
will> throughout its scope, but it also knows the code for the procedure.
>>>>> "ok" == Richard A O'Keefe <··@goanna.cs.rmit.EDU.AU> writes:
ok> You do a very cheap pass over the body governed by the declaration in
ok> question, find that there are no instances of (SET! id ...), and in
ok> O(n) time you know what you need to know.
So, here's yet another SMOP. But is it worth doing it? How many
programmers modify variables bound by LETREC? I read in Lisp Pointer
about proposal to prohibit assignment to such variables.
;;; Keio University
;;; Faculty of Science and Technology
;;; Department of Math
;;; MAEDA Atusi (MAEDA is my family name)
;;; ···@math.keio.ac.jp
>>>>>> "mad" == MAEDA Atusi ····@math.keio.ac.jp> writes:
mad> * UNWIND-PROTECT no longer works with it. The following code:
mad> (UNWIND-PROTECT
mad> <some file processing>
mad> (CLOSE FILE))
mad> looks okay. But what will happen if someone captured continuation
mad> inside <some file processing> and try to resume processing later?
>>>>> "will" == William D Clinger <····@ccs.neu.edu> writes:
will> UNWIND-PROTECT is a special case of DYNAMIC-WIND. It is true that
will> UNWIND-PROTECT is not powerful enough to protect against all uses
will> of CALL-WITH-CURRENT-CONTINUATION. That's why Scheme programmers
will> use DYNAMIC-WIND instead.
>>>>> "ok" == Richard A O'Keefe <··@goanna.cs.rmit.EDU.AU> writes:
ok> Funny, I thought that problem had been solved by the introduction of
ok> (DYNAMIC-WIND before-thunk result-thunk after-thunk)
ok> It is widely available, and does deal with the issue of CALL/CC exits
ok> (after-thunk is called) and reentrances (before-thunk is recalled).
I think DYNAMIC-WIND won't help in this particular case, unless the
language provide a way to reopen and reset the state of closed file.
One possible solution is to make before-thunk flag an error when
invoked twice, preventing reentrances.
Now, should ISLisp include CALL/CC and define CATCH, THROW, and
UNWIND-PROTECT in terms of CALL/CC? I'd like to hear from people who
are using CALL/CC heavily. Is CATCH/THROW insufficient in many cases?
(I write programs in mainly Common Lisp).
mad> * CALL/CC defeats some compiler optimizations.
mad> (LET ((A ..))
mad> ..
mad> (LET ((X A))
mad> (FOO)
mad> (SETQ X (+ X 1)))
mad> ..)
mad> cannot be transformed into:
mad> (LET ((A ..))
mad> ..
mad> (PROGN
mad> (FOO)
mad> (+ A 1))
mad> ..)
mad> in the presence of CALL/CC.
ok> Yes. IF it is used. Most escape handling methods in most programming
ok> languages defeat some compiler optimisations, when they are used.
Actually, my example illustrates that CALL/CC disables some
optimizations even if it isn't really used. The problem is the
*possibility* of captured continuation.
will> (let ((a ...))
will> ...
will> (let ((x a))
will> (foo #'(lambda (v)
will> (setq x (+ x 1)))))
will> ...)
will> cannot be transformed into
will> (let ((a ...))
will> ...
will> (let ((x a))
will> (foo #'(lambda (v)
will> (+ a 1))))
will> ...)
will> either, even in a language without CALL/CC. My example is, of
will> course, equivalent to MAEDA's.
This CPS version is equivalent to mine only when the language provides
first-class continuations.
My point is that, in the presence of CALL/CC, compiler can't prove
that a form after (unknown) function call is evaluated just once.
Hence, compiler can't move any side-effecting forms across (unknown)
function call, and can't remove some side effect.
>>>>> "erik" == Erik Naggum <····@naggum.no> writes:
erik> is it meaningful to restrict a continuation to be the continuation of a
erik> currently active activation? i.e., not allow re-entry to a continuation
erik> and no separate life of a continuation apart form the activation records?
erik> this would once again make co-routines harder to implement, but that could
erik> perhaps be another (related) conce000000012
ok> the usage_ of call/cc to the "structured" case WITHOUT LOSING SCHEME
ok> COMPATIBILITY. It's called Elk. (Whether you get full call/cc or cheap
ok> call/cc depends on how much work the person did who ported Elk to your
ok> machine.) The result is that you can write code using call/cc in a
ok> "structured" way in Elk, and run the _same_ code in another Scheme.
EuLisp also has continuations with dynamic extent.
;;; Keio University
;;; Faculty of Science and Technology
;;; Department of Math
;;; MAEDA Atusi (MAEDA is my family name)
;;; ···@math.keio.ac.jp
>>>>> "ok" == Richard A O'Keefe <··@goanna.cs.rmit.EDU.AU> writes:
ok> I do appreciate the line of argument here, but it is precisely the
ok> same kind of "nyaa nyaa ni nyaa nyaa i'm not gunna play with YOUR
ok> language I'm gunna play with MY language" approach that nearly wrecked
ok> the Prolog standard and quite certainly delayed it for more years than
ok> is creditable. We're talking about a situation where there was
ok> - one "Lisp" standard already official (Scheme)
ok> (and lots of free implementations including some great ones)
ok> - one "Lisp" standard in use by a large fraction of the community
ok> undergoing revision with the ANSI standard very close (CL)
ok> (and a KCL to name but one)
ok> - a rival "Lisp" standard under development with a freely evailable
ok> implementation and a lot of really neat ideas (EULisp)
ok> and ISlisp is compatible with *none* of them, in broad or in detail.
...`MY language'? I've never said I particulary prefer ISLisp over
Common Lisp or Scheme. I think much (but not all) of the criticism
made against ISLisp in this group is just right.
>>>>> "erik" == Erik Naggum <····@naggum.no> writes:
erik> I find ISLisp a depressing development. it appears unnecessary, and it is
erik> gratuitously different from Common Lisp. have you failed to realize that
erik> Lispers are facing people who want nothing stronger than to ridicule Lisp
erik> because they don't understand it and so don't want to use it? what better
erik> weapon to give them than to point out that even Lispers don't want to talk
erik> each others' languages?
Do you mean you want single standard, instead of several parallel
standards (as we have now)? Then that's what ISLisp is intended to be.
Or are you asking for accepting Common Lisp (or one of other existing
standards) as international standard? If the standard, as a result of
deep arguments on individual features, eventually becomes exactly the
same as Common Lisp, then that's fine. I'm willing to accept it. But
I don't think modification is automatically a bad thing.
;;; Keio University
;;; Faculty of Science and Technology
;;; Department of Math
;;; MAEDA Atusi (MAEDA is my family name)
;;; ···@math.keio.ac.jp
[Erik Naggum]
| I find ISLisp a depressing development. it appears unnecessary, and it
| is gratuitously different from Common Lisp. have you failed to realize
| that Lispers are facing people who want nothing stronger than to
| ridicule Lisp because they don't understand it and so don't want to use
| it? what better weapon to give them than to point out that even
| Lispers don't want to talk each others' languages?
[MAEDA Atusi] (supercite undone)
| Do you mean you want single standard, instead of several parallel
| standards (as we have now)?
I'm curious which "several parallel standards" you mean. is it IEEE Scheme
and ANSI Common Lisp? as far as I'm concerned, that's one, single standard
for _each_ of those languages. in this sense, I already have what I want.
| Then that's what ISLisp is intended to be.
do you mean that ISLisp will cause IEEE Scheme and ANSI Common Lisp to go
away? that's an amazing attitude. unless it takes important steps to the
contrary, ISLisp will clutter up the Lisp world even _more_ than the
current set of standard and non-standard Lisps do. (see my followup to
Fernando D. Mato Mira for a suggestion.)
when Unicode was marketed at the heaviest, they also clamored on about how
Unicode would be the new "single standard, instead of several parallel
standards" for character representation. what happened? we got _another_
parallel standard for character representation, and then Unicode went into
a phase of random cell division and now we have numerous kinds of Unicode.
| Or are you asking for accepting Common Lisp (or one of other existing
| standards) as international standard?
of course I'm asking that instead of going ahead to create yet another Lisp
standard, we use the one that successfully became a standard.
| If the standard, as a result of deep arguments on individual features,
| eventually becomes exactly the same as Common Lisp, then that's fine.
| I'm willing to accept it. But I don't think modification is
| automatically a bad thing.
"modification" is neutral. the _reason_ for making modifications may be
good or bad. a change may be an improvement with a strong consensus behind
it, one that users have essentially already adopted and are just waiting
for their standard to reflect. a change may also be a gratuitous departure
from the past and the consensus among users. ISLisp represents the latter
in the areas where it does not do useful invention (like the way it treats
dynamic binding), but invention in committees is not building a consensus,
it's an attempt to force something down someone's throat, however immature.
(this latter point is unfortunatly true of many standards in information
technology published in the last few years.)
#<Erik 3028579343>
--
suppose we actually were immortal...
what is the opposite of living your life as if every day were your last?
In article <···················@arcana.naggum.no> Erik Naggum <····@naggum.no> writes:
>
>| Do you mean you want single standard, instead of several parallel
>| standards (as we have now)?
>
>I'm curious which "several parallel standards" you mean. is it IEEE Scheme
>and ANSI Common Lisp? as far as I'm concerned, that's one, single standard
>for _each_ of those languages. in this sense, I already have what I want.
>
>| Then that's what ISLisp is intended to be.
>
>do you mean that ISLisp will cause IEEE Scheme and ANSI Common Lisp to go
>away? that's an amazing attitude.
That is not what ISLisp is for. It's another language in the Lisp
family (along with CL and Scheme), not a standard for all of Lisp.
>when Unicode was marketed at the heaviest, they also clamored on about how
>Unicode would be the new "single standard, instead of several parallel
>standards" for character representation.
Also? There's no clamoring on about ISLisp being a new, single
standard. There's just one news article from one person who seems
to be under a mistaken impression.
-- jd
Ok, I withdraw my "new users" silliness. Erik Naggum is right. If
ISLisp retains CAR and CDR tradition, and *if* it provides functions
that are equivalent to (SETF (CAR ...) ...) and (SETF (CDR ...) ...)
forms, then SET-CAR and SET-CDR would be good names. Should whole
update functions be dropped? I don't know. This affects, at least
+ Meaning of :accessor and :writer slot options of DEFCLASS.
+ We can't do something like (APPLY #'SET-AREF V ARRAY INDEX-LIST)
unless we have (SETF (APPLY ...) ...).
+ Renaming GET to PROPERTY becomes unnecessary.
--------------------------------------------------------
>>>>> "erik" == Erik Naggum <····@naggum.no> writes:
(MAEDA Atusi wrote)
erik> | (CL's DEFINE-SETF-METHOD is a mess).
erik> could you elaborate on that?
It is much more complicated than DEFSETF, but for what reason?
DEFSETF is just fine for almost all purposes. I know that
DEFINE-SETF-METHOD is necessary when we want to define setf method for
some place forms such as (LDB ...) and (MASK-FIELD ...), but they are
all special in that they do not destructively modify specified data
structure. That is, (SETF (LDB BYTE INT) V) does not update bits in
integer bound to INT, but the variable INT. I find this confusing.
If such special cases are the only purposes for DEFINE-SETF-METHOD,
then I think it isn't worth having it. Or is there more obvious
reason to have it? If so, enlighten me, please.
;;; Keio University
;;; Faculty of Science and Technology
;;; Department of Math
;;; MAEDA Atusi (MAEDA is my family name)
;;; ···@math.keio.ac.jp
>>>>>> "mad" == MAEDA Atusi ····@math.keio.ac.jp> writes:
mad> Compare this with Scheme. When executing procedure call (CAR
mad> something), compiled Scheme code (without dangerous optimization) must
mad> first fetch the value of the global variable CAR, check that it is a
mad> procedure, and then invoke it.
>>>>> "will" == William D Clinger <····@ccs.neu.edu> writes:
In article <··········@camelot.ccs.neu.edu> ····@ccs.neu.edu (William D Clinger) writes:
will> This would be true if, like Ada, it were illegal to extend Scheme.
will> In reality, the Scheme standards state that extensions are legal
will> so long as they don't conflict with the standards. In particular,
will> it is legal to extend Scheme to allow the programmer to specify that
will> certain procedures should be inlined. This is, of course, a very
will> common extension. Since inlining is done only by permission of the
will> programmer, it is not a dangerous optimization.
I failed to find out where in R4RS the above statements were made.
Would you please point on the section? Or is that in IEEE Standard?
About functions in COMMON-LISP package, yes, I was out-of-date, for
around ten years. I should have read CLtL2 more carefully.
About user-defined functions, there are three approaches.
1. Include (DECLARE (INLINE ...)) in standard, or allow equivalent
extension to implementation. Functions can be redefined.
Redefinition affects other functions that calls redefined one
unless redefined functions are declared to be inlined.
2. No (DECLARE (INLINE ...)) and functions can be redefined.
3. No (DECLARE (INLINE ...)) and functions can't be redefined.
Common Lisp and Scheme takes the first approach and ISLisp the third.
If both approach can achieve efficiency of almost same level, then
what is the difference? Programmers should add in Common Lisp
programs or Scheme programs to gain maximum efficiency (this may be
trivial). Compilers of Common Lisp or Scheme will be complicated
compared to ISLisp, to support multiple linkage method (it may also be
a Small Matter Of Programming, but difference is difference).
ISLisp's approach has a big disadvantage. Although the draft states
that it does not specify how to prepare an ISLisp text for execution
and how to execute it, the fact that it forbids redefinition of
functions effectively kills the usefulness of READ-EVAL-PRINT style
interpreters. Toplevel loop for ISLisp, if exists, will look more like
GDB command line rather than ordinary Lisp environment.
How about ease of distribution and installation of applications?
Now I must admit that I don't know how commercial Lisp programs are
distributed. Are applications distributed as stand-alone programs?
Or must users have entire Lisp system in advance?
>>>>> "ok" == Richard A O'Keefe <··@goanna.cs.rmit.EDU.AU> writes:
(On MAEDA's statements saying "calling redefinable functions requires
run-time checking".)
ok> The claim that this _must_ be done is simply false. What you _do_ need is
ok> a good module system (which could certainly be added to Scheme without
ok> breaking anything except a few reserved words; there are several proposals
ok> around) so that the compiler can know when it is compiling a particular
ok> module that every other module _can't_ assign to this variable and that this
ok> module _doesn't_. It's not even hard.
>>>>ernet.media-coverage
(In reply to MAEDA's statements saying "ISLisp compilers can always
inline function calls".)
erik> rather than throwing the baby (redefinition) out with the bathwater (lack
erik> of static analysis), couldn't ISLisp have provided a facility to freeze
erik> packages? (oh, right, it doesn't have packages.)
ISLisp does need module facility, as I wrote in my article
<·················@tanzanite.math.keio.ac.jp>.
It should differ from Common Lisp packages, though. (CL packages
solve name clash, but they don't provide encapsulation. Internal
symbols can be freely accessed via qualified names.)
ok> One thing I have learned to dislike is environments where the debugging
ok> environment has different semantics from the production environment. For
ok> example, if functions _can_ be redefined somehow in the debugging
ok> environment but not in the production environment, then you are debugging
ok> a different language from the one your shipped application is written in.
Well, I thought having both interpreter and compiler makes debugging
easier. Following your opinion, switching compiler settings or adding
declarations to programs both change the language, then. So can this
be counted as an advantage of ISLisp?
ok> Oh yes, the idea that function calls can _always_ be mapped to a simple
ok> call instruction in C is quite a few years behind the times. Windows,
ok> OS/2, VMS, and modern UNIX systems, all have some form of dynamic linking.
My point is that calls to redefinable Scheme functions may add extra
indirection in addition to the ones required by OS's dynamic link. Of
course, you can avoid it by throwing away assemblers and linkers
provided by OS and reimplementing it by yourself. Another SMOP.
;;; Keio University
;;; Faculty of Science and Technology
;;; Department of Math
;;; MAEDA Atusi (MAEDA is my family name)
;;; ···@math.keio.ac.jp
From: Bruno Haible
Subject: Re: Immutable function bindings (was Re: ISO/IEC CD 13816 -- ISLisp)
Date:
Message-ID: <4bfatn$9du@nz12.rz.uni-karlsruhe.de>
MAEDA Atusi <···@math.keio.ac.jp> wrote:
>
> ISLisp's approach has a big disadvantage. Although the draft states
> that it does not specify how to prepare an ISLisp text for execution
> and how to execute it, the fact that it forbids redefinition of
> functions effectively kills the usefulness of READ-EVAL-PRINT style
> interpreters. Toplevel loop for ISLisp, if exists, will look more like
> GDB command line rather than ordinary Lisp environment.
Your interpretation of the forbidden redefinition for functions is
unfortunate. The ISLisp text specifies what a correct ISLisp program
is, but it has not the intent of specifying the interpreter.
It is of course expected that function redefinition is possible in a
debugging environment.
An interpreter and debugging environment always extends the language
spec: by providing debugging commands such as `inspect-object', environ-
mental commands such as `exit', documentation such as `help', and
by not enforcing some language restrictions.
For example, no CL implementation forbids you to execute
(setf (car '(a . b)) 'x)
in the interpreter, although this is illegal according to CLtL2.
The major mistake is the design of CL was to consider debugging commands
and features (such as redefinability of functions) as being part of the
language, hence meaningful in files to be compiled, and this is what
ISLisp tries to address.
----------------------------------------------------------------------------
Bruno Haible net: <······@ilog.fr>
ILOG S.A. tel: +33 1 4908 3585
9, rue de Verdun - BP 85 fax: +33 1 4908 3510
94253 Gentilly Cedex url: http://www.ilog.fr/
France url: http://www.ilog.com/
From: Jeff Dalton
Subject: Re: Immutable function bindings (was Re: ISO/IEC CD 13816 -- ISLisp)
Date:
Message-ID: <DKoA6E.M69.0.macbeth@cogsci.ed.ac.uk>
In article <··········@nz12.rz.uni-karlsruhe.de> ······@ilog.fr (Bruno Haible) writes:
>
>The major mistake is the design of CL was to consider debugging commands
>and features (such as redefinability of functions) as being part of the
>language, hence meaningful in files to be compiled, and this is what
>ISLisp tries to address.
That is at least very misleading. You, and the others who
take this line, need to bear in mind that things are not that
simple and clear-cut.
It's true that Common Lisp has some debugging features in the
"language". TRACE is a good example. It's questionable whether
this was a mistake rather than just one of several reasonably
good ways of doing things. It's a bit extreme, to say the least,
to say it's "the major mistake in the design of Common Lisp".
In any case, function redefinition is in another category.
No one says assignment to global variables is a debugging command, or
meaningless in files to be compiled. Redefining a function is not all
that different. In a "one namespace" Lisp (such as Scheme), it's the
same. Moreover, in some programs redefining functions at run-time
makes sense. I've written a number of programs that redefine
functions in ways that are not debugging or development. And I
compile the code as well.
ISLisp was supposed to do something that EuLisp was also supposed
to do, namely to leave function redefinition out of the language
and leave it up to implementations. The idea was to avoid saying
that conforming implementations had to suppose redefinition, and
hence to allow (as conforming) implementations that performed
certain kinds of static analysis.
(I say "supposed", because it's possible people have messed it up
and ended up going further than they should have.)
-- jd
From: Jeff Dalton
Subject: Re: Immutable function bindings (was Re: ISO/IEC CD 13816 -- ISLisp)
Date:
Message-ID: <DKo7rq.Lw4.0.macbeth@cogsci.ed.ac.uk>
In article <·················@tanzanite.math.keio.ac.jp> ···@math.keio.ac.jp writes:
>ISLisp's approach has a big disadvantage. Although the draft states
>that it does not specify how to prepare an ISLisp text for execution
>and how to execute it, the fact that it forbids redefinition of
>functions effectively kills the usefulness of READ-EVAL-PRINT style
>interpreters. Toplevel loop for ISLisp, if exists, will look more like
>GDB command line rather than ordinary Lisp environment.
I am not convinced that ISLisp forbids implementations from allowing
function redefinition. What is your textual evidence from the ISLisp
definition?
-- jd
From: Jeffrey Mark Siskind
Subject: Re: Local functions (was Re: ISO/IEC CD 13816 -- ISLisp)
Date:
Message-ID: <QOBI.95Dec21101257@qobi.ai>
In article <·················@tanzanite.math.keio.ac.jp> ···@math.keio.ac.jp (MAEDA Atusi) writes:
So, here's yet another SMOP. But is it worth doing it? How many
programmers modify variables bound by LETREC? I read in Lisp Pointer
about proposal to prohibit assignment to such variables.
There is no reason to since a compiler can very efficiently determine when a
program doesn't modify a bound variable.
Jeff (home page http://www.cs.toronto.edu/~qobi)
--
Jeff (home page http://www.cs.toronto.edu/~qobi)
From: Jeffrey Mark Siskind
Subject: Re: CALL/CC (was Re: ISO/IEC CD 13816 -- ISLisp)
Date:
Message-ID: <QOBI.95Dec21101037@qobi.ai>
In article <·················@tanzanite.math.keio.ac.jp> ···@math.keio.ac.jp (MAEDA Atusi) writes:
Actually, my example illustrates that CALL/CC disables some
optimizations even if it isn't really used. The problem is the
*possibility* of captured continuation.
My point is that, in the presence of CALL/CC, compiler can't prove
that a form after (unknown) function call is evaluated just once.
Hence, compiler can't move any side-effecting forms across (unknown)
function call, and can't remove some side effect.
This is incorrest. If you make a closed-world assumption and batch compile an
entire application (yes this is compatible with a strict interpretation of
R4RS) then it is possible to detect that a program doesn't use CALL/CC and
perform all optimizations as if the language didn't contain CALL/CC. But you
can do better than that. You can determine on an expression by expression
basis which expressions might be reentered due to a continuation call and
control your optimiziations accordingly. See my previous posting for more
details.
Jeff (home page http://www.cs.toronto.edu/~qobi)
--
Jeff (home page http://www.cs.toronto.edu/~qobi)
From: Pekka P. Pirinen
Subject: Re: SET-CAR vs. RPLACA vs. SETF (only) (was Re: ISO/IEC CD 13816 -- ISLisp)
Date:
Message-ID: <PEKKA.95Dec27135708@gaspode.harlqn.co.uk>
In article <·················@tanzanite.math.keio.ac.jp> ···@math.keio.ac.jp (MAEDA Atusi) writes:
(CL's DEFINE-SETF-METHOD is a mess).
It is much more complicated than DEFSETF, but for what reason?
DEFSETF is just fine for almost all purposes. I know that
DEFINE-SETF-METHOD is necessary when we want to define setf method for
some place forms such as (LDB ...) and (MASK-FIELD ...), but they are
all special in that they do not destructively modify specified data
structure. [...]
If such special cases are the only purposes for DEFINE-SETF-METHOD,
then I think it isn't worth having it. Or is there more obvious
reason to have it? If so, enlighten me, please.
I'd say the real reason is that Lisp wizards want access to the
internals so they can leverage off those mechanisms, when they're
extending the language. DEFINE-SETF-METHOD is only half of it; the
other half is that GET-SETF-METHOD returns the same five values.
In practical terms, this allows writing macros that use _generalized
variables_ for operations more sophisticated than just setting, such
as SHIFTF, ROTATEF, PUSH, POP, and GETF. It also allows extending the
idea to places such as APPLY, THE, VALUES -- all now part of ANSI.
We've also found ASSOC a useful place, and there was a article in Lisp
Pointers some years ago that suggested a use for QUOTE as a place! I
notice that we've even used it in the LispWorks sources to implement a
few places that could have been written using DEFSETF, for efficiency
or clarity of code.
--
Pekka P. Pirinen
Harlequin Limited, Cambridge, UK
(I failed to post this article and retried several times. Sorry if
you see this many times).
> [Erik Naggum]
> | I find ISLisp a depressing development. it appears unnecessary, and it
> | is gratuitously different from Common Lisp. have you failed to realize
> | that Lispers are facing people who want nothing stronger than to
> | ridicule Lisp because they don't understand it and so don't want to use
> | it? what better weapon to give them than to point out that even
> | Lispers don't want to talk each others' languages?
> [MAEDA Atusi] (supercite undone)
> | Do you mean you want single standard, instead of several parallel
> | standards (as we have now)?
> and precisely which several parallel standards do you mean? IEEE Scheme
> and ANSI Common Lisp, right? as far as I'm concerned, that's one, single
> standard for each of those languages. I this sense, I already have what I
> want.
> | Then that's what ISLisp is intended to be.
> do you mean that ISLisp will cause IEEE Scheme and ANSI Common Lisp to go
> away? that's an amazing attitude, to put it mildly. ISLisp will clutter
> up the Lisp world even _more_ than the current set of standard and
> non-standard Lisps do.
Please don't extract sentence out of its context. My sentence above
should be read "(if you want single standard) then that's what ISLisp
is intended to be."
[Unicode stuff deleted]
> | Or are you asking for accepting Common Lisp (or one of other existing
> | standards) as international standard?
> again, _which_ "other existing standards"? of course I'm asking that
> instead of going ahead to create yet another Lisp standard, we use the one
> that successfully became a standard.
Why do you belive two is the best number for standards? I agree with
you that Common Lisp and Scheme each has its own importance. And
ISLisp emphasizes another aspect. It tries to be a language which is
small and easy to implement efficiently.
> | If the standard, as a result of deep arguments on individual features,
> | eventually becomes exactly the same as Common Lisp, then that's fine.
> | I'm willing to accept it. But I don't think modification is
> | automatically a bad thing.
> "modification" is neutral. it's the _reason_ for making modifications that
> may be good or bad. a change may be an improvement with a strong consensus
> behind it, one that users have essentially already adopted and are just for
> the standard to reflect. a change may also be a gratuitous destruction of
> the past and of the consensus among users. ISLisp represents the latter in
> the areas where it does not do useful invention (like the way it treats
> dynamic binding), but invention in committees is not building a consensus.
Yes, a change can be good or bad. And "the past" alone doesn't make
it good or bad. And consensus can be made after proposal, through
argument. By what way can changes be made, other than proposing
changes first?
BTW, I can recall there were many arguments against Common Lisp. Some
people said: "Lisp doesn't need standard at all", "Common Lisp is
largely incompatible with existing implementations (e.g. in lexical
variable bindings)", "Some features of Common Lisp (e.g. multiple
values, dynamically adjustable arrays, etc.) has significant
overhead", etc.
And now Common Lisp seems to be successful and it is widely accepted.
Some inventions in committee may be discarded if they turn out to be
bad and some may survive. If *all* changes proposed by the committee
are discarded, then we have a consensus rejecting the whole standard.
So why not talking about technical and/or practical aspects of the
language, instead of talking about politics?
;;; Keio University
;;; Faculty of Science and Technology
;;; Department of Math
;;; MAEDA Atusi (MAEDA is my family name)
;;; ···@math.keio.ac.jp
In article <················@tanzanite.math.keio.ac.jp> ···@math.keio.ac.jp writes:
> > | Then that's what ISLisp is intended to be.
>
> > do you mean that ISLisp will cause IEEE Scheme and ANSI Common Lisp to go
> > away? that's an amazing attitude, to put it mildly. ISLisp will clutter
> > up the Lisp world even _more_ than the current set of standard and
> > non-standard Lisps do.
>
>Please don't extract sentence out of its context. My sentence above
>should be read "(if you want single standard) then that's what ISLisp
>is intended to be."
What do you mean by "a single standard". ISLisp is *not* supposed
to be a standard for all of Lisp; it's supposed to be a standard for
one language in the Lisp family. That's one of the reasons it's
called "ISLisp" instead of "Lisp" (which would then be called "ISO
Lisp" and appear to be a standard for all of Lisp).
This was discussed explicitly at the first meeting of WG-16 (the
ISO committee that produced the ISLisp definition).
-- jeff
If they would use
Call/CC continuations instead
of
TAG
CATCH
THROW
Call/CC is more powerful can be used to
write nondeterminative and multitasking
and has inherent continuations--
this is Schemes strong point eleminates three
commands and does more, so why do we use Call/CC insted of
THROW
CATCH
TAG,
ETC.
--
Khos AI
VIRX
M'Isr <···········@CompuServe.COM> writes:
>If they would use Call/CC continuations instead
>of
> TAG
> CATCH
> THROW
>Call/CC is more powerful can be used to
>write nondeterminative and multitasking
>and has inherent continuations--
>this is Schemes strong point eleminates three
>commands and does more, so why do we use Call/CC insted of
> THROW
> CATCH
> TAG,
> ETC.
Call/cc is more controversial than you might suppose. Indeed,
some knowledgeable people feel it is a significant defect in
Scheme.
By the way, what is your "etc"? What other cases do you have in
mind?
-- jd