July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Where do you want to go tomorrow? 26 years, 5 months

Michael Sperber

>>>>> "Olivier" == Olivier Galibert <galibert(a)pobox.com> writes: Olivier> Just to put some gasoline on the fire, what about and ILU-like Olivier> approach to extension language independence ? Olivier> ftp://ftp.parc.xerox.com/pub/ilu/ilu.html Olivier> We could have Common lisp, Java, Scheme and Perl simultaneously ;-) A future Emacs Lisp engine is hopefully going to have some sort of interface via RPC, preferrably CORBA. ILU does this, indeed. However, CORBA and related IDL's are pretty heavyweight currently. The sensible approach is to a have a low-level FFI and build RPC support on top of it. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Where do you want to go tomorrow? 26 years, 5 months

Michael Sperber

>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes: Andy> My $0.02 based on almost zero understanding ;) Andy> I am assuming that Michael is talking about replacing the underlying Andy> execution engine so that we would benefit from basically increased Andy> performance with the existing elisp remaining largely unchanged? The emphasis is slightly different: I want to keep full Elisp support, while introducing an additional substrate meant to slowly replace Elisp. Preferrably, Elisp will simply run inside the substrate. Andy> My impression is that a scheme engine would be smaller and Andy> faster than a clisp engine. Smaller, definitely. Faster is a matter of implementation technology, and pretty independent of that choice. CLISP as well as most existing Scheme engines are plenty fast for our purposes. There are native-code implementations for Scheme and CLISP which are plenty faster. Andy> Whatever the case I think the replacement should be as small and as fast as Andy> possible rather than as feature rich as possible. :-) -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Where do you want to go tomorrow? 26 years, 5 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Common Lisp is much closer to elisp than any Scheme dialect Hrvoje> is. You've said that on a number of occasions, but I don't even know what you mean. Actually, I claim this is false. Hrvoje> Using Scheme as a primary language in XEmacs will alienate a Hrvoje> large number of our contributors, and I, for one, do not want Hrvoje> to see that happen. If that is indeed so, I'm more than willing to give in. However, we don't have any evidence for this statement yet. That's why I said we need more discussion. It would generally be nice if people actually took a look at both languages (or any other candidates) and posted about their impressions and conclusions. I personally believe a small substrate is less likely to alienate people than a large substrate. (Hey, we're replacing Elisp by something really cool! Hack great things with it! Contribute code! The language reference is only slightly more than 500 pages ...) Hrvoje> Translators or compatibility packages for elisp implemented in Scheme Hrvoje> would of little help, except for porting old code. You consider porting old code (several hundred thousands of lines) "of little help"? Hrvoje> I doubt anyone will consider using them to write new, Hrvoje> XEmacs-specific code. Of course not, that's why we want a substrate change in the first place. What's your point? Hrvoje> My second argument is that XEmacs has been going in the direction of Hrvoje> Common Lisp for several years now. Extensions such as cl.el show that Hrvoje> pretty clearly. I honestly want to understand what you mean by this, but I don't. Sure, it has made sense to write Elisp libraries with constructs modelled like equivalent constructs in Common Lisp. It makes sense to write Scheme libraries with those constructs as well. It would make sense to write Common Lisp libraries to emulate Scheme constructs. (Or ... libraries to emulate ... constructs, or ...) However, the *language* has not changed through the evolution of libraries. What we've been doing with Emacs Lisp is easily possible with Scheme, or any of a number of other languages. Sure, some people will prefer different programming idioms when they have the full power of Scheme available. But they don't have to. I use Scheme programming idioms when writing Elisp, for that matter. Look at my code. If you want to use Common Lisp idioms when using Scheme, that's absolutely fine. In fact, you can make Scheme look almost completely like Common Lisp, if you want to. (Note that the reverse is not generally possible, since Common Lisp is not properly tail-recursive and does not support control abstraction.) Hrvoje> If we want to extend elisp further, I think we should take a Hrvoje> radical step in the same direction, rather than turn into a Hrvoje> wholly different one. I don't think we want to extend Elisp further, we want to replace it by something new. The differences between Elisp and Common Lisp are at least as great as those between Elisp and Scheme. Replacing Elisp by Common Lisp is simply not a "radical step in the same direction," it's a great leap into a new one. I claim that moving to Scheme would be moving into essentially the same direction as Common Lisp, it's only the pragmatics and trade-offs which are different, mainly dictated by the state of the art in implementation technology. Hrvoje> Suppose the impossible happens, and Erik does come in and does all the Hrvoje> work to port XEmacs Lisp to, say, clisp. Would you quit XEmacs Hrvoje> development? Yes. Hrvoje> If yes, why? Arguing with Erik aggravates me. This is independent of the technical merit of the content of his postings (which I generally also find pretty low), it's just my gut-level reaction to what he writes. Hrvoje> Now replace Erik with Bruno or Hrvoje. Do the answers change? Absolutely. Hrvoje> I think that you are arguing for Scheme because of personal Hrvoje> preferences, which is perfectly natural. Your battle plan includes Hrvoje> only Scheme-based options, and I think that no words of mine would Hrvoje> ever convince you to consider anything else. There must be a misunderstanding here, Hrvoje. My "battle plan" (I assume you're referring to my Web page on the subject matter) *specifically* includes other options. Up until the last possible moment, it is totally independent of the language or language substrate we'll drop in. If we do our jobs well, we can have several extension languages to drive XEmacs. Moreover, I've reserved Web space for arguments on Common Lisp, but nobody has sent me anything yet to put there. I'm willing to hear arguments, I've tried out implementations that you've suggested to me and commented on them (and not just negatively, for that matter). What more do you want from me to prove I'm open to arguments? Hrvoje> This is why I think our disagreements can be only settled by a Hrvoje> split, or by one of us leaving the development. I don't get it Hrvoje, we've hardly started discussion on this, and already you claim an irreconcileable split. Why? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Where do you want to go tomorrow? 26 years, 5 months

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> Been there. The only thing I understood in that page was that Scheme Stephen> is small, elegant, extensible and thus a good candidate for a Stephen> substrate. Agreed. The rest was so much noise, except for the "now Stephen> you've got two big problems" comment about CL, which I would tend to Stephen> agree with but as you point out yourself, and Hrvoje agrees, XE-CL Stephen> would be a scaled-down version. Agreed. The page is just an old xemacs-beta posting taken out of context. I'll try to update it as I have time. ms> Many features aren't part of the Scheme standard because they ms> can be easily expressed within the language as it stands. True ms> concepts are more important, and here CL is weak. I could go ms> on about the virtues of hygienic macros, the evils of CL-style ms> macros, especially in connection with module systems, the ms> usefulness and beauty of call-with-current-continuation ms> etc. etc. etc. Someone make me. Stephen> OK. *twist, twist, twist* Stephen> However, URLs where I can find out WTF the vocabulary means ahead of Stephen> time would be vewy hehpfuh.[1] I've been to Indiana's Scheme Stephen> Repository; I don't know where to start. Hygienic macros: ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/misc/macros-0[1-4].txt.gz ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/prop/macinsch.ps.gz The latter also contains some brief comparisons to Common Lisp. It's difficult to find electronic versions of good explanations and examples for CALL-WITH-CURRENT-CONTINUATION. The basic idea is that every expression in a Scheme program has a context to which its return value is fed once it's been computed. This amounts to the "future" of that expression, and the underlying implementation usually implements it as a stack of activation records. Most programming languages support capturing the context via some catch/throw or exception handling or setjmp/longjmp mechanism which allows you to restore a context which is part of the current context, i.e., to unwind part of the stack. This means that they work only "upwards" on the stack. However, to implement sophisticated control structures, you need to be able to: 1. Restore the context even if it's not lying around on the stack. 2. Restore it multiple times. The most popular example are threads. From a C programmer's viewpoint, all threads share the same global memory, but each has its own stack aka context. CALL-WITH-CURRENT-CONTINUATION simply converts its own context (the "current continuation") into a one-argument procedure. When you call that procedure, the current context is replaced by that of the call to CALL-WITH-CURRENT-CONTINUATION. In connection with one global reference (which Scheme gives you easily), you can model *any* control structure (in a certain formal sense). CL's mechanism is not strong enough for this. (Another good example is the Icon language which uses a control structure called "generator" as the backbone of a very powerful model for text processing---much more powerful than Emacs Lisp. Generators are a slightly generalized version of coroutines, and trivial to implement in Scheme.) Good explanations of continuations are in: ＠BOOK{FriedmanWandHaynes1992, author = "Daniel P. Friedman and Mitchell Wand and Christopher T. Haynes", title = "Essentials of Programming Languages", publisher = "MIT Press and McGraw-Hill", year = 1992, annote = "EOPL", ISBN = {MIT 0-262-06145-7, McGraw-Hill 0-07-022443-9} } ＠BOOK{SpringerFriedman1989, author = {George Springer and Daniel P. Friedman}, title = {Scheme and the Art of Programming}, year = 1989, publisher = {MIT Press and McGraw-Hill}, keywords = {scheme-art} } ＠Book{Queinnec1994, author = {Christian Queinnec}, title = {Lisp in Small Pieces}, publisher = {Cambridge University Press}, year = 1994 } Stephen> Re: global options and keyword arguments ms> However, Scheme idiomatics usually uses a parameterization ms> mechanism to achieve what you're talking about; they're ms> similar to a structured and thread-compatible version of ms> dynamic binding. Stephen> Urk. I mean, URL please. :-) http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node99.htm Stephen> I'm not sure I agree with you, if I do get the general direction of Stephen> your thought. I'm talking about situations where we are currently Stephen> stuck choosing between Stephen> ;; isn't it a shame that the FSF is now doing Stephen> ;; (defun foo (arg &optional face) ...)? Stephen> (defun foo (arg &optional coding-sys) ...) Stephen> (foo "insert me in" 'euc-jp) Stephen> and Stephen> (defun foo (arg) ...) Stephen> ;; boy this is ugly compared to Stephen> ;; (foo "insert me in" :coding-sys 'euc-jp) Stephen> (let ((coding-system-for-insertion 'euc-jp)) Stephen> (foo "insert me in")) Stephen> What does that look like in Scheme idiom, if your idea does apply? All three are possible. The advantage to the latter (the "ugly" one) is that the same parameterization can apply to a whole dynamic context rather than just a single procedure call. ms> The term [proper tail recursion] doesn't exist as a noun. As ms> I said above, a Scheme implementation is properly ms> tail-recursive if it implements tail calls as gotos. Stephen> No, you didn't say it. At least, not in words _I_ could understand. Scheme takes the stance that recursion is sufficient to express, well, recursion, as well as the common iterative control structures, such as loops. However, the main difference between recursion and iteration in most other languages is that a procedure call (specifically a recursive procedure call) consumes space, on the stack or elsewhere, to store its context. This means that, each iteration of a loop consumes space, and may therefore lead to stack overflow or something similar. However, when you formulate loops via recursion, the context does not change between successive iterations, because the recursive calls are "tail calls"---they have no context. Scheme guarantees that such calls will not consume space, and it's therefore safe to write loops this way. The tail calls compile to goto + parameter passing. Tail calls are important in other contexts, because not having them can lead to space leaks. Now, a lot code obviosuly depends on Scheme implementations having this property because loops are so common. It's not possible to support the general property of being properly tail-recursive after the fact, unless you want to rewrite your whole program in terms of goto. The Scheme standard, available under: http://www-swiss.ai.mit.edu/scheme-home.html elaborates on this. Stephen> Point is that a lot of the people who should contribute to Stephen> this discussion don't even know where to start asking Stephen> questions. I assume I'm not the only person totally ignorant Stephen> of modern programming language theory on this list. Is that Stephen> assumption unjustified? Absolutely not. Let me know if I'm not doing a good job explaining the issues. Doing programming language research all day clouds my vision as to what I can assume and what I still need to explain. More about module systems later ... -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Where do you want to go tomorrow? 26 years, 5 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Hrvoje> Lots of elisp code can run under Common Lisp almost Hrvoje> unchanged. This is not true for Scheme. >> >> Please substantiate this. By default, for instance, `let' is >> lexically scoped in Common Lisp, which is clearly incompatible with >> Emacs Lisp. Hrvoje> Not so by design. In fact, we were discussing introduction of a Hrvoje> lexically scoped `let' to elisp many times. And guess what? The Hrvoje> proposed semantics were equivalent to those used by CL -- lexical Hrvoje> scope by default, dynamic scope for special variables. Great. While I don't remember the proposed semantics, and don't necessarily agree with this, this is just as easy to implement in Scheme. Hrvoje> I don't care. Emacs is not ANSI CL. If that was the Hrvoje> impression I was giving, I apologize, because that is not what Hrvoje> I meant. One important benefit in swapping the extension language would be that we could use library code not specifically written for XEmacs. There's lots and lots of library code for both Scheme and Common Lisp. Stripping down the language would mean we couldn't use much of it. If we're going to hook to a Lisp engine maintained by someone else (which we hopefully will), there's no reason to take only a part of it. Hrvoje> I will probably not be the one doing the work, and I have not a clear Hrvoje> idea of what it would take. This, however, should not mean I get no Hrvoje> vote in the discussion. I know where I want to end up. Sure. But in the end, we'll need someone who knows what it would take. I have a pretty good idea, and the effort required is only marginally different between Scheme and CL. Hrvoje> The Scheme users and implementors don't have the constraint of Hrvoje> previous implementation of Common Lisp idioms. We do, and I would Hrvoje> like us to preserve them. Sure. Let's. Hrvoje> I don't believe this. Common Lisp may not be perfect, but it's far Hrvoje> too complex to simulate correctly without a *lot* of effort. Most of it's been done. PC Scheme used to come with a substantial emulation, and we could probably hack it to make it work for us. Hrvoje> What kind of write-up? Haven't I sent you my discussion with Bruno Hrvoje> Haible? Ermh, no, you haven't ... Please do! Hrvoje> I don't like CMU CL (far too slow and buggy IMHO), Actually, CMU CL produces pretty much the fastest CL code around. Unfortuntately, it only works on very few architectures. Hrvoje> and I haven't worked with GCL much. It might be usable. Now *that*'s what I would call slow and buggy. (Took me three days just to get it installed without dumping core.) CLisp is significantly preferrable. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Where do you want to go tomorrow? 26 years, 5 months

Michael Sperber

>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: Stephen> But (from this third party's point of view) neither of you has really Stephen> explained what the advantages are to your preferred dialect. My case for Scheme has been at http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-gener... for a while. It's fairly rudimentary, but I'll be happy to elaborate on anything anyone wants. The highlights (in a comparison to CL) are: 1. Scheme is a small language, both conceptually and in implementation. It carries little historical baggage. 2. Many complete implementations of Scheme exist, and several would make suitable substrates for XEmacs. Some of the best-performing compilers for higher-order languages exist for Scheme. 3. Scheme is built in such a way so as to be able to model most other concepts existing in other programming languages. In particular, it supports high-level macros, control abstraction, and reflection. Stephen> One thing that we have banged up against a couple of times Stephen> recently is the "global option-variable vs. function Stephen> argument" thing. This is especially annoying in the Mule Stephen> modules, since the FSF implementation keeps changing and it's Stephen> useful to keep synch in many cases. It would be nice to have Stephen> CL-like keyword arguments. Is this doable in a robust way in Stephen> Scheme? Would it be efficient, especially when compiled? Sure. In fact, the DSSSL subset of Scheme specifies keyword arguments, and several Scheme implementations already have them. No problem there. (Of course, it's equally possible to add them to the language with a bunch of macros.) However, Scheme idiomatics usually uses a parameterization mechanism to achieve what you're talking about; they're similar to a structured and thread-compatible version of dynamic binding. Stephen> If Hrvoje is correct that much elisp code can be swallowed raw by a CL Stephen> implementation, then this should make synching with the FSF much less Stephen> painful. This is especially dear to Mule people, since the active Stephen> development of Mule, at least in terms of (natural) language Stephen> additions, is nearly all taking place at the FSF. You must have some Stephen> thoughts about that. Or are you assuming that an eventual adoption of Stephen> Guile by the FSF will make an XE-scheme a positive advantage in Stephen> porting FSF code? I think any Lisp engine swap should be preceded by two things: 1. A full emulation of Emacs Lisp, either within the language substrate, or via a native compiler, or via simply including the old Elisp engine, for legacy code support. 2. A source-to-source translator which turns readable Elisp into halfway-readable substrate code for permanent migration. The need for both won't go away with either Scheme or CL. ms> (Note that the reverse is not generally possible, since Common ms> Lisp is not properly tail-recursive and does not support ms> control abstraction.) Stephen> Do we care? Ie, can you give specific examples where those features Stephen> would be useful to developers, either of the core XEmacs or of Stephen> application libraries, or enhance efficiency of a running XEmacs? You're quoting me out of context: I was talking about running Scheme code inside a Common Lisp substrate. Scheme code *very* often depends on the underlying implementation being properly tail recursive. (This essentially means that tail-recursive call don't consume stack space. The Revised^5 Report on Scheme contains a rationale.) Therefore, these Scheme programs won't run properly in a Common Lisp implementation which isn't properly tail-recursive. Some Scheme code relies on full-fledged continuation reification, specifially code which implements co-routines, threads, generators, exception mechanisms, etc. etc. Common Lisp supports only a very limited form of control abstraction in the form of catch/throw which works only in one direction (upwards-only). This makes catch/throw unsuitable for the applications I enumerated. Scheme's call/cc works in both directions. Adding efficient call/cc to a language substrate which wasn't designed with it in mind is usually very difficult, because it requires either a CPS-converting compiler or a stack fragmentation mechanism. Stephen> The answer I need is _not_ "I already told you it's properly Stephen> tail-recursive, what more do you need to know?" I know what tail Stephen> recursion is; I don't know what "proper tail recursion" is. The term doesn't exist as a noun. As I said above, a Scheme implementation is properly tail-recursive if it implements tail calls as gotos. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: ANNOUNCE: I am speaking about XEmacs, July 1 26 years, 5 months

Remek Trzaska

Anybody could see the mbone session tonight? Remek

1 participants
0 comments

Re: Where do you want to go tomorrow? 26 years, 5 months

Hrvoje Niksic

Olivier Galibert <galibert(a)pobox.com> writes: > We could have Common lisp, Java, Scheme and Perl simultaneously ;-) Thanks but no thanks. At least both Scheme and CL have concepts such as CAR/CDR, symbols, etc. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "I came here to chew bubble gum and to kick ass... and I'm all out of ass." -- Crow, MST3K #519 ("Outlaw")

1 participants
0 comments

Re: Where do you want to go tomorrow? 26 years, 5 months

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Hrvoje> Lots of elisp code can run under Common Lisp almost > Hrvoje> unchanged. This is not true for Scheme. > > Please substantiate this. By default, for instance, `let' is > lexically scoped in Common Lisp, which is clearly incompatible with > Emacs Lisp. Not so by design. In fact, we were discussing introduction of a lexically scoped `let' to elisp many times. And guess what? The proposed semantics were equivalent to those used by CL -- lexical scope by default, dynamic scope for special variables. > Consequently, you would need a library of macros and procedures to > emulate/translate Emacs Lisp functionality into Common Lisp. Quite true -- I am not denying this. > >> I personally believe a small substrate is less likely to alienate > >> people than a large substrate. > > Hrvoje> I believe clisp is small enough, especially if we remove the > Hrvoje> parts we don't need. > > This, however, means that Emacs CLisp won't be a standard Common > Lisp implementation anymore, and surely old CL buffs will complain. I don't care. Emacs is not ANSI CL. If that was the impression I was giving, I apologize, because that is not what I meant. > Hrvoje> My point is that choosing Common Lisp is a better idea > Hrvoje> because it is closer to Emacs Lisp. > > The thing I'm having trouble is that you have not substantiated this > statement based on the nature of the three languages involved. We > really need to get down to the technical issues of this, and you > haven't addressed them. I did outline what would be needed to adapt > Scheme to Emacs Lisp. Someone should do the same for Common Lisp, > and we can compare. I will probably not be the one doing the work, and I have not a clear idea of what it would take. This, however, should not mean I get no vote in the discussion. I know where I want to end up. > >> I honestly want to understand what you mean by this, but I don't. > >> Sure, it has made sense to write Elisp libraries with constructs > >> modelled like equivalent constructs in Common Lisp. It makes > >> sense to write Scheme libraries with those constructs as well. > > Hrvoje> Does it? Not for me! > > Well, a lot of Scheme users and implementors disagree with you. The Scheme users and implementors don't have the constraint of previous implementation of Common Lisp idioms. We do, and I would like us to preserve them. > Hrvoje> Yes, that's what we were doing with Emacs Lisp, and I don't > Hrvoje> really like the "poor man's common lisp" any more. > > In Scheme, you could actually implement a "rich man's Common Lisp" I don't believe this. Common Lisp may not be perfect, but it's far too complex to simulate correctly without a *lot* of effort. > >> There must be a misunderstanding here, Hrvoje. My "battle plan" (I > >> assume you're referring to my Web page on the subject matter) > >> *specifically* includes other options. > > Hrvoje> Yes, but all the "Lisp engines" you mention are Scheme engines. > > Yes, because that's what I have personal experience with. Send me a > write-up on CLisp or GCL or CMU CL, and I'll put it up. What kind of write-up? Haven't I sent you my discussion with Bruno Haible? Bruno's messages are an excellent case /pro/ clisp. I don't like CMU CL (far too slow and buggy IMHO), and I haven't worked with GCL much. It might be usable. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- HOW YOU CAN TELL THAT IT'S GOING TO BE A ROTTEN DAY: #15 Your pet rock snaps at you.

1 participants
0 comments

problem with inserting image files 26 years, 5 months

Charles G Waldman

If I do C-x i foo.xpm RET with point at position 0 in a buffer, the image is inserted and displayed correctly. If point is anywhere else in the buffer, the image insert fails. Seems like the whole contents of the buffer are being handed to the image decoder, not just the image data. I noticed this at first when trying to add support for JPEG and GIF to the native Win32 version (this works by the way), but the bug is not Windows-specific.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta July 1998