July 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Where do you want to go tomorrow? 27 years

William M. Perry

Andy Piper <andyp(a)parallax.co.uk> writes: > 1e) gif animation. Don't forget PNG animation. The module stuff needs to be spiffed into better shape as well, and possibly move some things out into loadable modules. > 2) I've mentioned CORBA support ;) It would be nice to browse the name > service, say, with dired. A proper lisp binding would allow cool debugging > of CORBA services. This would be a good candidate for a loadable module (like the LDAP stuff in .../modules/ldap) > 3) unify url base file finding. So for instance you could type in: > > ftp://somehost/ > or > http://somehost/ > or > iiop://somehost/ > > maybe someone has done this already? I did this with file-name-handlers once upon a time in the URL package, but there were problems with then Emacs called the filehandlers. If I recall, it was something along the lines of if you called (expand-file-name "foo.html" "http://www.bar.com/") then the handler wouldn't get called. -Bill P.

1 participants
0 comments

Re: [??] same architecture, many builds, where DOC? 27 years

Colin Rafferty

Hrvoje Niksic writes: > Colin Rafferty <craffert(a)ms.com> writes: >> > This scheme will fail to work for people who use `-q -no-site-file'. >> > Maybe you should modify the code to initialize >> > `internal-doc-file-name' from C to the correct value. >> >> Ugh. I don't really want to start messing with the code that >> heavily. > I wouldn't call that "heavy." That's what we ship the sources for, > after all. :-) > Seriously, the change is pretty trivial, and results in a more robust > executable. If you extend it a little bit further, your changes might > be of use to others -- mail us the patch, and why not apply it? I hadn't thought of it that way. Now you've got me thinking about a good way to specify the doc-file name. Maybe a configure option? There are a lot of options already, but I really don't want to generate a unique doc-file name unnecessarily. On the other hand, most people don't even realize this is a problem, so maybe this really should be a forced option. So I create a bitmask of all the configure options set, generate a uuencoded string, and the doc-file name is XL4J.DOC. This may actually work. If I'm only allowed [A-Z0-9], I can sqeeze in 5 options per character. With an 8+3 filename limit, that's 40 options. >> I guess if our users start with `-q -no-site-file', they get what >> they deserve. > Uh-oh. Oh well. -- Colin

2 participants
1 comments

Re: Engines (CL vs Scheme...) 27 years

Michael Sperber

>>>>> "Anthony" == Anthony Rossini <arossini(a)biostat.washington.edu> writes: Anthony> One more naive question: with either a Scheme or CL engine, Anthony> can we emulate elisp (or the other language), in a similar Anthony> way to how cl.el helps us emulate CL? I.e. could we have an Anthony> elisp.el or cl.el or scheme.el? No, more rewriting is required. The most serious issue is the lexical/dynamic binding issue, but there are others. Anthony> Note that I'm wondering if it makes sense to distinguish Anthony> between the engine and the final programming syntax used Anthony> (more from a pragmatic, "do the approximately wrong thing", Anthony> rather than a clean approach). That absolutely makes sense. For an "engine" (i.e. some sort of bytecode machine or other low-level execution model), I want compilers for both the new language as well as vanilla Elisp. Now the Elisp compiler may be a direct one, or one that works by translating into the new language first, or may actually work on top of an Elisp interpreter written in the new language. You still want to be able to migrate old source code, however, rather than just run it. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years

Holger Schauer

>>>>"MS" == Michael Sperber schrieb am 03 Jul 1998 15:18:46 +0200: MS> Note that I'm not (not at all!) arguing against the change, I'm MS> just trying to clarify that it has a cost. I believe that this cost is very, very high. Again, not necessarily for my code or the one shipped currently with XEmacs or which is in the LCD. But hey, there are certainly TONS of old Elisp around - who are we, that we can say "Hey, guy, revise your old stuff !" ? I believe that such a change would not help the acceptability of XEmacs, instead it would be a big hurt for all users out there that use such code. A related issue: I thought, okay, then let's support old ELisp and new-<lisp-flavour-here>-Elisp. But now, I do not see an elegant solution to this either: how would one determine whether <foo>.el is programmed in Elisp or in Scheme\\|CL ? With an (require 'cl) ? And if it is not present, than assume its old-style Elisp ? Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- "Deine capslock und '!' Tasten klemmen." "Nee, ich habe eine Win95 Tastatur." -- Robin Socha und H.Wulff in de.comp.os.linux.misc

2 participants
1 comments

Engines (CL vs Scheme...) 27 years

A.J. Rossini

One more naive question: with either a Scheme or CL engine, can we emulate elisp (or the other language), in a similar way to how cl.el helps us emulate CL? I.e. could we have an elisp.el or cl.el or scheme.el? (or is there one that really wouldn't be possible, in the sense of creating a hierarchy?) Note that I'm wondering if it makes sense to distinguish between the engine and the final programming syntax used (more from a pragmatic, "do the approximately wrong thing", rather than a clean approach). best, -tony --- Anthony Rossini UW Biostatistics / Center for AIDS Research Epimetrics Corporation

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> While there are valid arguments against Common Lisp, this > Hrvoje> one is not such an example of such. `cond' and `if' have > Hrvoje> been with us for ages, and I believe they are almost > Hrvoje> unchanged in Scheme. `(when this ...)' is simply a nice > Hrvoje> shortcut for `(if this (progn ...))' and is *very* useful. > > Hmm. Not to me. I never use it. I _may_ start using it now that > you have explained it to me, for which I am grateful. > > However, this is a matter of taste. For me it is in fact a valid > argument against Common Lisp. OK, Steven, you are entitled to your opinion. But I *am* astonished that out of all the valid argument against of Common Lisp, you choose the `when' macro. > And whether having to learn zillions of redundant (in a formal > sense) idioms as well as huge libraries of editing functions just to > read other people's code will repel potential new developers. ?????? -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Oh lord won't you buy me a color TV...

2 participants
1 comments

Re: Where do you want to go tomorrow? 27 years

Michael Sperber

>>>>> "Reggie" == Reggie Perry <Reggie.Perry(a)digital.com> writes: Reggie> [1 <text/plain; iso-8859-1 (quoted-printable)>] Reggie> Sorry, I cant let you get away with this. :-) Reggie> We were talking about DEFVAR. I like your example, but it should look Reggie> like this: Reggie> (defvar x 3) Who says? Certainly not the Elisp manual. Reggie> (defun f (g) Reggie> (let ((x 2)) Reggie> (funcall g))) Reggie> (let ((x 1)) Reggie> (f #'(lambda () x))) Reggie> now this works correctly in elisp and common lisp and this Reggie> would be more like what I would expect lots of elisp code to Reggie> look. The point is that you can't be sure, and the Elisp compiler isn't any help in spotting the migration problem. Someone will actually have to *read* the code to convert it. Note that I'm not (not at all!) arguing against the change, I'm just trying to clarify that it has a cost. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> >> This would entail changing existing Emacs Lisp code in an >> >> incompatible fashion. >> Hrvoje> Can you explain what you mean by incompatible? >> >> Old code will obviously not run under the new Elisp engine, because >> it may intrinsically use dynamic binding for non-DEFVAR'ed names. Hrvoje> True. >> New code will not run under the old engine because that does not >> support static binding, Hrvoje> Only if you actually use the lexical scope to your advantage. Your Hrvoje> argument is like saying "specifiers are incompatible because lemacs Hrvoje> can't use them." Ermh, I didn't argue anything. You asked what I meant. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Where do you want to go tomorrow? 27 years

Hrvoje Niksic

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >> This would entail changing existing Emacs Lisp code in an > >> incompatible fashion. > > Hrvoje> Can you explain what you mean by incompatible? > > Old code will obviously not run under the new Elisp engine, because > it may intrinsically use dynamic binding for non-DEFVAR'ed names. True. > New code will not run under the old engine because that does not > support static binding, Only if you actually use the lexical scope to your advantage. Your argument is like saying "specifiers are incompatible because lemacs can't use them." Of course they are, but this is no argument for not introducing them. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth

1 participants
0 comments

RE: Where do you want to go tomorrow? 27 years

Reggie Perry

Sorry, I cant let you get away with this. :-) We were talking about DEFVAR. I like your example, but it should look like this: (defvar x 3) (defun f (g) (let ((x 2)) (funcall g))) (let ((x 1)) (f #'(lambda () x))) now this works correctly in elisp and common lisp and this would be more like what I would expect lots of elisp code to look. Although I would imagine that people dont code in this way normally since it would be a bear to debug in a complex module. -Reggie P.S. Please forgive the [application/ms-tnef]. Our company has been forced to use exchange and I havent coerced Microsoft OutHouse to do the correct thing yet. -----Original Message----- From: sperber(a)informatik.uni-tuebingen.de [mailto:sperber＠informatik.uni-tuebingen.de] Sent: Friday, July 03, 1998 5:25 AM To: xemacs-beta(a)xemacs.org Subject: Re: Where do you want to go tomorrow? >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: >> Someone (Hrvoje?) proposed that we change the semantics of let to work >> like in Common Lisp, Hrvoje> It has been discussed multiple times in the past. In fact, it would Hrvoje> have already been done if the fate hadn't transpired against Chuck and Hrvoje> Ben working on XEmacs. >> This would entail changing existing Emacs Lisp code in an >> incompatible fashion. Hrvoje> Can you explain what you mean by incompatible? Old code will obviously not run under the new Elisp engine, because it may intrinsically use dynamic binding for non-DEFVAR'ed names. New code will not run under the old engine because that does not support static binding, even if it syntactically is totally acceptable to the old engine. Also, the Elisp compiler does not reliably detect which variables should be DEFVAR'ed which aren't already. Consider the following program fragment which has different semantics depending on the interpretation of LET: (defun f (g) (let ((x 2)) (funcall g))) (let ((x 1)) (f #'(lambda () x))) ... and watch what sort of (bogus) message the compiler produces. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

2025

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