ACL 4.3 For Linux license concerns
David Steuber
unpacked and installed it yet. I have some concerns about the license
that bother me. I was wondering if someone from Franz could clear
them up for me.
My first concern is with the expiration of the license. It expires on
1, Jan 1999. That doesn't give me much time to try it out. I suppose
I should have read the license before downloading the software instead
of after, but there was no indication of an expiration before getting
to the download page.
My second concern is with this part:
> 2. LIMITATIONS ON LICENSE. The license granted in Section 1 is
> subjectto the following restrictions:
>
> a. The Software is to be used only for non-commercial purposes
> unless you obtain Franz's prior written consent otherwise. Prohibited
> commercial purposes include, but are not limited to:
>
> (iv) using the Software to develop an application which is ported to
> other platforms for commercial distribution;
Suppose I develope code which compiles under both ACL 4.3 For Linux
and CMUCL. I then decide that the software I have written has some
commercial value, so I decide I want to sell it. I build it with
CMUCL or some derived CL environment and create a commercial
distribution. Is this a violation of the quoted portion of the
license? I would probably have tested the source code under ACL.
My second concern may be a moot point, unless Franz extends the
license. There is no way I can write anything significant before the
end of the year. Or the millenium probably.
Chris Double
>
>My first concern is with the expiration of the license. It expires on
>1, Jan 1999. That doesn't give me much time to try it out.
ACL 5 is out already so I guess the other option is to use that. ACL 5.0
under windows is very nice if you are used to the Delphi/Visual Basic type
of interface for building applications. I'm not sure if the Linux version
has this as well.
Chris.
Erik Naggum
| My first concern is with the expiration of the license. It expires on
| 1, Jan 1999. That doesn't give me much time to try it out.
so go get 5.0, then. what _is_ it that is so hard about this?
#:Erik
Erik Naggum
| ACL 5.0 under windows is very nice if you are used to the Delphi/Visual
| Basic type of interface for building applications. I'm not sure if the
| Linux version has this as well.
no, the IDE has not been ported to any Unix version.
#:Erik
David Steuber
> David Steuber wrote in message ...
> >
> >My first concern is with the expiration of the license. It expires on
> >1, Jan 1999. That doesn't give me much time to try it out.
>
> ACL 5 is out already so I guess the other option is to use that. ACL 5.0
> under windows is very nice if you are used to the Delphi/Visual Basic type
> of interface for building applications. I'm not sure if the Linux version
> has this as well.
My impression of VB was hate on first site. I really hope I wouldn't
be locked into that model under Linux.
Maybe I should just wait for 5.0. Will 4.3 stop working when the
license expires, or am I bound by honor to remove it? In any case, I
am not interested in pirate ware.
Johan Kullstam
> "Chris Double" <ch...@cnd.co.nz> writes:
>
> > David Steuber wrote in message ...
> > >
> > >My first concern is with the expiration of the license. It expires on
> > >1, Jan 1999. That doesn't give me much time to try it out.
> >
> > ACL 5 is out already so I guess the other option is to use that. ACL 5.0
> > under windows is very nice if you are used to the Delphi/Visual Basic type
> > of interface for building applications. I'm not sure if the Linux version
> > has this as well.
>
> My impression of VB was hate on first site. I really hope I wouldn't
> be locked into that model under Linux.
i agree.
> Maybe I should just wait for 5.0. Will 4.3 stop working when the
> license expires, or am I bound by honor to remove it? In any case, I
> am not interested in pirate ware.
why not try 5.0? it is out of beta. ignore the silly webpage, go
straight for the ftp site.
ftp.franz.com:/pub/linux/acl50/redhat[45].tar
redhat 4 is libc5 and redhat 5 is libc6 (aka glibc2). they really
don't have much to do with redhat other than the name. the tars will
unpack and can be installed on any linux system.
i am using eli with emacs. i am still lost as to how to work with
lisp/emacs/eli in the sense of how do i edit files? how do i compile
them? how do i best run my resulting code &c. but i am reading the
readme.htm that came with eli and moving along slowly.
--
Johan Kullstam [joh...@idt.net] Don't Fear the Penguin!
David Steuber
> so go get 5.0, then. what _is_ it that is so hard about this?
Ja, ja.
Do I need both tar files? Or is there a tar.gz now? Guess it won't
hurt to look when the ISDN rates go down.
Why can't things just happen when I think about them? Hmmm. I guess
all those naked college girls running around in winter wouldn't
appreciate it.
Erik Naggum
| Do I need both tar files? Or is there a tar.gz now?
you need only one, unless you have both libc5 and libc6 systems.
ftp.franz.com can give you a .tar or a .tar.gz if you just tack the
suffix onto any file or directory name, and does .gz for any file. just
ask for it, you'll get it. most modern FTP servers do this, which is a
boon for people who use _real_ FTP clients, compared to the losers who
use "browsers" and can only get what they see.เธ
not that it will help a lot in this case, since the .tar file contains a
.zip file that has be unzipped with a password you get after following
the instructions in the README file. (maybe I shouldn't have said that
-- people who can't read README files maybe shouldn't be allowed to play
with power languages.)
#:Erik
-------
เธ semi-involved pun puzzle
--
if people came with documentation, could men get the womanual?
David Steuber
-> why not try 5.0? it is out of beta. ignore the silly webpage, go
-> straight for the ftp site.
->
-> ftp.franz.com:/pub/linux/acl50/redhat[45].tar
->
-> redhat 4 is libc5 and redhat 5 is libc6 (aka glibc2). they really
-> don't have much to do with redhat other than the name. the tars will
-> unpack and can be installed on any linux system.
I'm pulling in the files now. I mean as I type this, not as you read
this ;-)
-> i am using eli with emacs. i am still lost as to how to work with
-> lisp/emacs/eli in the sense of how do i edit files? how do i compile
-> them? how do i best run my resulting code &c. but i am reading the
-> readme.htm that came with eli and moving along slowly.
I've been using ILISP with CMUCL. It is a pretty cool package. With
luck, I can use it with ACL.
--
David Steuber
http://www.david-steuber.com
s/trashcan/david/ to reply by mail
"Hackers penetrate and ravage delicate, private, and publicly owned
computer systems, infecting them with viruses and stealing materials
for their own ends. These people, they're, they're terrorists."
-- Secret Service Agent Richard Gill
Johan Kullstam
> Johan Kullstam <joh...@idt.net> writes:
> -> i am using eli with emacs. i am still lost as to how to work with
> -> lisp/emacs/eli in the sense of how do i edit files? how do i compile
> -> them? how do i best run my resulting code &c. but i am reading the
> -> readme.htm that came with eli and moving along slowly.
>
> I've been using ILISP with CMUCL. It is a pretty cool package. With
> luck, I can use it with ACL.
what is the story with ilisp? does it come with emacs or not? there
is an inferior-lisp package already with my emacs. i downloaded ilisp
and installed that and didn't get much further than a 5 minute session
with C-h m.
anyhow, i've dumped emacs' own inferior-lisp and ilisp in favor of
eli. eli afaik is fairly tied to ACL but that's ok assuming ACL is
half as good as its reputation around here.
i got the updated eli (look at the franz site for an
emacs directory) and went to make. the build barfed since i'm running
emacs 20.3 and i took out the emacs-18 compatibility flag in the
config. then it compiled smoothly.
well i followed the eli instructions and put a `load eli' into my
.emacs file.
i now get franz-lisp-mode when i visit a file with a .l (for *l*isp)
ending. first it cursed about me not having rsh. i installed rsh and
it made eli happy to fire off a slave lisp process. (i don't use rsh
for anything else, can i remove the dependency on it?)
i have lost most of the party colors of emacs lisp-mode with
font-lock-mode. (is it worth it to try to restore the colors or is
common-lisp better without a syntax guesser?)
i can pop between source editor and slaved lisp process with C-c l.
C-c C-b compiles. so far so good. i can type in the little function
examples from grahams books and try them out in the lisp slave. is
this how you do it in general?
i am still a bit stumped about how the process is supposed to work.
my books are a bit sketchy on the particulars of the environment (not
their fault since there are lot of implementations and such but it is
still hard to know how to proceed). using make and command line
compile commands and getting a normal unix executable as with C or
fortran doesn't seem to be the right thing with lisp.
someone let me know if i am going down a wrong path and i'd be
grateful for a hint or two on my way forward.
David Steuber
-> * David Steuber <tras...@david-steuber.com>
-> | Do I need both tar files? Or is there a tar.gz now?
->
-> you need only one, unless you have both libc5 and libc6 systems.
->
-> ftp.franz.com can give you a .tar or a .tar.gz if you just tack the
-> suffix onto any file or directory name, and does .gz for any file. just
-> ask for it, you'll get it. most modern FTP servers do this, which is a
-> boon for people who use _real_ FTP clients, compared to the losers who
-> use "browsers" and can only get what they see.ยน
Another useful feature of a 'real' ftp client (I used the command line
version that comes with SuSE 5.3) is reget works. Very useful when
the server pauses long enough for the ISDN connection to think it is
finished and hang up.
-> not that it will help a lot in this case, since the .tar file contains a
-> .zip file that has be unzipped with a password you get after following
-> the instructions in the README file. (maybe I shouldn't have said that
-> -- people who can't read README files maybe shouldn't be allowed to play
-> with power languages.)
I've always wondered what those README files were for. I wonder if
emacs can open one?
-> #:Erik
-> -------
-> ยน semi-involved pun puzzle
-> --
-> if people came with documentation, could men get the womanual?
Available in stores everywhere: "Take out the garbage, lard ass!: A
simple man's guide to women" By Glory Steinbrenner.
David Steuber
-> David Steuber <tras...@david-steuber.com> writes:
->
-> > I've been using ILISP with CMUCL. It is a pretty cool package. With
-> > luck, I can use it with ACL.
->
-> what is the story with ilisp? does it come with emacs or not? there
-> is an inferior-lisp package already with my emacs. i downloaded ilisp
-> and installed that and didn't get much further than a 5 minute session
-> with C-h m.
I'm not sure. I'm using XEmacs. islisp.el(c) is in the XEmacs source
tree, but not the Emacs source tree.
-> i got the updated eli (look at the franz site for an
-> emacs directory) and went to make. the build barfed since i'm running
-> emacs 20.3 and i took out the emacs-18 compatibility flag in the
-> config. then it compiled smoothly.
->
-> well i followed the eli instructions and put a `load eli' into my
-> ..emacs file.
It looks like I will need to fetch eli. You use it. Erik uses it.
It seems to be the tool for using with Franz ACL. No point in using
the wrong tool for the job.
For switching back and forth, I'll have to see if I can set up the key
bindings to be as similar as possible.
-> i now get franz-lisp-mode when i visit a file with a .l (for *l*isp)
-> ending. first it cursed about me not having rsh. i installed rsh and
-> it made eli happy to fire off a slave lisp process. (i don't use rsh
-> for anything else, can i remove the dependency on it?)
I use rsh for loging on to my other machine. Over the course of next
year, I hope to get a few others. You may set up a LAN at some
point. So no point in blowing away a fundimental Un*x utility.
-> i have lost most of the party colors of emacs lisp-mode with
-> font-lock-mode. (is it worth it to try to restore the colors or is
-> common-lisp better without a syntax guesser?)
This is a personal preference issue. I have found syntax highlighting
to be very useful in C++. I like the colors when they can recognize
key words, defined functions and variables.
-> i can pop between source editor and slaved lisp process with C-c l.
-> C-c C-b compiles. so far so good. i can type in the little function
-> examples from grahams books and try them out in the lisp slave. is
-> this how you do it in general?
More or less. One feature that has a coolness factor for me is that I
can put the insertion point on a function and compile just that
function. I expect eli can do that as well?
-> i am still a bit stumped about how the process is supposed to work.
-> my books are a bit sketchy on the particulars of the environment (not
-> their fault since there are lot of implementations and such but it is
-> still hard to know how to proceed). using make and command line
-> compile commands and getting a normal unix executable as with C or
-> fortran doesn't seem to be the right thing with lisp.
The people in this group have been more helpful to me than people in
any other news group. I don't know what, if anything this says about
the class of people who do the Lisp, but I would still be stuck in
Gates' Hell without the advice of this group.
Steve Gonedes
< i have lost most of the party colors of emacs lisp-mode with
< font-lock-mode. (is it worth it to try to restore the colors or is
< common-lisp better without a syntax guesser?)
I always thought the font-locking for lisp-modes under emacs was
pretty good. Do you have the variable lisp-font-lock-keywords set to
lisp-font-lock-keywords-2? I don't know too much about font-lock
beyond this though...
You could always get nasty with (such as replacing some entries in)
`font-lock-defaults-alist', but this shouldn't be necessary.
Maybe M-x font-lock-mode (two times) will work?
< i can pop between source editor and slaved lisp process with C-c l.
< C-c C-b compiles. so far so good. i can type in the little function
< examples from grahams books and try them out in the lisp slave. is
< this how you do it in general?
You don't have to switch to the listener to eval expressions. What I
do is bind C-x C-e (eval-last-sexp) in common-lisp files to a function
I wrote that emulates eval-last-sexp except uses the common-lisp to
eval the expression rather than emacs lisp. I have F-12 switch the
binding for C-x C-e back and forth as needed.
Here's what I have (in emacs lisp)...
(defun my-lisp-eval-last-sexp (prefix)
(interactive "P")
(if prefix
(fi:lisp-eval-last-sexp)
(cl-prettyprint
(let ((sexp (buffer-substring-no-properties
(point) (save-excursion (forward-sexp -1) (point)))))
(fi:eval-in-lisp "%s" sexp)))))
If you do a
(global-set-key [Control-x (Control ?\e)] 'my-lisp-eval-last-sexp)
;; That won't work in emacs; [?\C-x ?\C-e] will though.
you can eval common-lisp expressions just as you would emacs-lisp
expressions.
If no prefix arg (C-u universal-argument) then the result will be
echoed in the minibuffer (or a popup-buffer if it's too big - you can
press C-space to get rid of the window). If there is a prefix arg,
then the result is inserted into the current buffer (can be useful).
You can get an arg-list with C-a (very useful), describe-symbol with
C-d, apropos with C-?, and also very useful is C-c . which will find
a definition.
< i am still a bit stumped about how the process is supposed to work.
< my books are a bit sketchy on the particulars of the environment
< (not their fault since there are lot of implementations and such but
< it is still hard to know how to proceed). using make and command
< line compile commands and getting a normal unix executable as with C
< or fortran doesn't seem to be the right thing with lisp.
Lisp can be more of an environment or a `shell' of sorts. When your
application is done you can dump it and even replace the interactive
`top-level' with whatever suits you.
< someone let me know if i am going down a wrong path and i'd be
< grateful for a hint or two on my way forward.
Here's some stuff I use that I find useful. The following are
`top-level' aliases. This is so that you can type in stuff like
`:ls ~/lib/src/*.*.[0-9]+' or `:del arg.*' to the lisp-listener.
I put these in my dot-clinit file (~/.clinit.cl).
(top-level:alias ("ls" 0 :string) (&optional options)
"List files using the `ls' command according to OPTIONS"
(excl:run-shell-command
(if options
(concatenate 'string "ls -FCT0 " options)
#("ls" "-F" "-C" "-T" "0"))))
(top-level:alias ("erase" 2) ()
"Erase the contents of current buffer"
(lep::eval-in-emacs "(erase-buffer)"))
(top-level:alias ("pprint" 1) (form)
"Pretty print function or macro's lambda expression if possible"
(cond ((consp form) (pprint form))
((macro-function form)
(pprint (function-lambda-expression (macro-function form))))
(t (pprint (function-lambda-expression (fdefinition form))))))
(top-level:alias ("delete" 2 :string) (files)
"Delete the files named in FILES"
(flet ((remove-file (file)
(fresh-line) (write-string ";; Deleted ") (princ file)
(delete-file file)))
(loop for start = 0 then (1+ end)
for end = (position-if #'excl::whitespace-char-p files :start start)
unless (eq start end) do
(let ((filename (subseq files start end)))
(cond ((null filename))
((probe-file filename)
(remove-file filename))
((and filename (find #\* filename))
(dolist (file (directory filename))
(let ((file (probe-file file)))
(when file
(remove-file file)))))
(filename
(when (probe-file filename)
(remove-file filename)))))
until (null end))))
(top-level:alias ("shell" 1 :string) (command)
"Execute shell command COMMAND"
(prin1 (excl:shell command)))
(defconstant #\ )
(defmacro indent-rule (symbol what)
#-excl nil #+excl `(and (lep:lep-is-running)
(lep::eval-in-emacs
,(format nil "(put (quote ~(~s~)) 'fi:lisp-indent-hook (quote ~(~s~)))"
symbol what))))
The `:ls' will do the obvious. If there are no options I used a vector
so that the lisp will do a straight execve rather than call a
subshell.
The `:erase' will erase the buffer - very useful for when your buffer
is getting full. There is no shortcut because it would interfear with
the existing `:err' wich is short for `:error' (lists the current
error message).
The `:pprint' or `:pp' will print a symbol's function. For example:
USER(1): (defun this (x y) (* x y))
THIS
USER(2): :pp this
(LAMBDA (X Y) (BLOCK THIS (* X Y)))
USER(3): . Won't work when the function is compiled (the code is
ditched, but this has been _very_ useful for me at times).
The `:delete' should be obvious. It removes some files. You should
probably look it over or re-write it (don't know how safe it is -
works for me though).
The `:shell' or `:sh' will run a shell command.
The `^O' will print #\^o instead of signalling an error. This happens
when I get real tired (like now) and accidentally hit C-c C-o instead
of C-c C-p (fi:pop-input).
And finally, the `indent-rule' can be used in your source files to
correct the indentation of certain forms. For instance, (pretend this
a source file which will be loaded into the lisp before editing):
;;; Virtual-file begins
;;; The final tip I have before I go to bed. This is a macro that will
;;; automatically create necessary gensyms to prevent
;;; double-evaluation in some macros for some things. Just included it
;;; because it's useful and I am very happy I got it to (seemingly)
;;; work. It also shows what I think are some of the neatest things in
;;; cl. The macro is pretty tricky, it took me quite a time to get it
;;; this far; I don't mean it to turn you off of cl. Just want to
;;; demonstrate some of the more powerful features I have found the
;;; language to offer.
;; (the `cl>' is supposed to be the listener prompt)
;;
;; The problem is like this:
cl> (defmacro this (x y)
`(* ,x (+ ,x ,y) (1- ,y))) ; .
cl> :ma (this 3 4) =>
;; Macro expansion
(* 3 (+ 3 4) (1- 4)) ; no problem here.
cl> (defvar *number* 12) => 12
cl> :ma (this (* 3 4) (incf *number*))
;; Macro expansion
(* (* 3 4) (+ (* 3 4) (INCF *NUMBER*)) (1- (INCF *NUMBER*)))
;; *number* is 14 instead of 13 like it should be. This is a very,
;; very bad problem. Here is my not so quick solution.
(defun side-effect-free-p (exp)
"Return non-nil if the expression EXP has no side-effects"
(or (constantp exp) (atom exp)
(and (eq (car exp) 'function)
(side-effect-free-p (third exp)))))
;; Should probably be called constant-enough-p?
;; (side-effect-free-p 12) => t
;; (side-effect-free-p (list 1 2)) => nil
(defun generate-symbol (var)
"Return an unintened symbol useful for representing the variable VAR"
(cond ((stringp var) (gensym var))
((symbolp var)
(let ((name (symbol-name var)))
(gensym
(case (readtable-case *readtable*)
(:UPPER (string-upcase name))
(:DOWNCASE (string-downcase name))
(:CAPITALIZE (string-capitalize name))
(otherwise name)))))
(t (gensym))))
;; Like `gensym' but works with symbols
;; (generate-symbol "SYM") => #:SYM258
;; (generate-symbol 'one) => #:ONE257
;; This will adjust the indentation for the function `once-only'
;; First expansion:
;; (AND (LEP:LEP-IS-RUNNING)
;; (LEP::EVAL-IN-EMACS
;; "(put (quote once-only) 'fi:lisp-indent-hook (quote 1))"))
(indent-rule once-only 1)
;; return X wrapped in a (')
(defun quote-form (x) (list 'quote x))
;; (quote-form "one") => '"one"
;; (quote-form 'one) => 'ONE
;; Warning: hairy macro (imho) below...
(defmacro once-only (vars &body forms)
"auto-gensymination"
(assert (every #'(lambda (x) (and x (symbolp x))) vars)
(vars)
"~@<Illegal variable bindings: ~:w~:@>" vars)
(let ((gensyms (mapcar #'generate-symbol vars))
($bindings (generate-symbol "BINDINGS"))
(setter-forms ()))
(loop for param in vars
for var in gensyms do
(push `(unless (side-effect-free-p ,param)
(push (list ',var ,param) ,$bindings)
(setq ,param ',var))
setter-forms))
`(let (,@(mapcar #'list gensyms (mapcar #'quote-form vars))
, $bindings)
(declare (ignorable ,@gensyms))
,@ setter-forms
`(let ,, $bindings
,,@forms))))
;;; EOVF
(defmacro this (x y)
(once-only (x y)
`(* ,x (+ ,x ,y) (1- ,y))))
:ma (this 12 34) =>
;; Macro expansion
(LET () (* 12 (+ 12 34) (1- 34)))
cl> :ma (this (* 3 4) 2) =>
;; Macro expansion
(LET ((#:X269 (* 3 4)))
(* #:X269 (+ #:X269 2) (1- 2)))
cl> :ma (this (incf *number*) 3)
;; Macro expansion
(LET ((#:X289 (INCF *NUMBER*))) (* #:X289 (+ #:X289 3) (1- 3)))
Tada! Sorry if it's a little unclear - I am exhausted right now.
Especially sorry if you're not familiar with macros (you said grahms
book - one of his books is just full of macro maddness like the
above).
Could probably explain it better tomorrow if you're curious about
something (or if it doesn't work for some reason <shutter>). Hope this
gives you some stuff to toy with though. Have fun...
Johan Kullstam
> Johan Kullstam <joh...@idt.net> writes:
>
> < i have lost most of the party colors of emacs lisp-mode with
> < font-lock-mode. (is it worth it to try to restore the colors or is
> < common-lisp better without a syntax guesser?)
>
> I always thought the font-locking for lisp-modes under emacs was
> pretty good. Do you have the variable lisp-font-lock-keywords set to
> lisp-font-lock-keywords-2? I don't know too much about font-lock
> beyond this though...
>
> You could always get nasty with (such as replacing some entries in)
> `font-lock-defaults-alist', but this shouldn't be necessary.
the difficulty is that franz-lisp-mode is not lisp-mode and font-lock
has very few default colors to work with. basically only strings are
recognized (and painted brown) and everything else is in
black-and-white.
copying/redifing the lisp-mode font-lock stuff to do the same in
franz-lisp-mode shouldn't be terribly hard. i am just wondering if
commonlisp is a weird enough beast with new keywords that ought to be
lit but are not. more annoying, when i make new functions and macros
which have syntactic meaning similar to keywords, these are not lit
up. for example `defun' is purple. `my-defun' would be plain.
enough of these and font-lock loses its purpose.
i have this same problem in C++. i define my own type, and it is
always black and white while C built-in types like int are made
green. i don't know if it's possible to make my types come out green
in C++ without a lot of work.
[ snip of lots of elisp keybinding &c ]
thanks for the keybindings and commonlisp hacks for ls and delete.
those look very useful. i shall try them out tonight.
> ;;; Virtual-file begins
>
> ;;; The final tip I have before I go to bed. This is a macro that will
> ;;; automatically create necessary gensyms to prevent
> ;;; double-evaluation in some macros for some things. Just included it
> ;;; because it's useful and I am very happy I got it to (seemingly)
> ;;; work. It also shows what I think are some of the neatest things in
> ;;; cl. The macro is pretty tricky, it took me quite a time to get it
> ;;; this far; I don't mean it to turn you off of cl. Just want to
> ;;; demonstrate some of the more powerful features I have found the
> ;;; language to offer.
nod. paul graham's _on lisp_ talks about things like this. borrowing
from my C++ experience, i suppose inline functions could help. but
lisps powerful macro utility allows some pretty fancy stuff too. this
is exactly why i am trying to learn lisp. i want a language i can
use.
> Could probably explain it better tomorrow if you're curious about
> something (or if it doesn't work for some reason <shutter>). Hope this
> gives you some stuff to toy with though. Have fun...
thank you, you have been most helpful.
--
johan kullstam
vnik...@poboxes.com
Johan Kullstam <joh...@idt.net> wrote:
(...)
> i have this same problem in C++. i define my own type, and it is
> always black and white while C built-in types like int are made
> green. i don't know if it's possible to make my types come out green
> in C++ without a lot of work.
int is not just a built-in (if built-in is the word I want) type
like e.g. size_t but also a reserved word.
This does *not* belong in this newsgroup...
--
Vassil Nikolov
http://www.poboxes.com/vnikolov
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
vnik...@poboxes.com
David Steuber <tras...@david-steuber.com> wrote:
(...)
> I use rsh for loging on to my other machine. Over the course of next
> year, I hope to get a few others. You may set up a LAN at some
> point. So no point in blowing away a fundimental Un*x utility.
Don't forget that rsh is a (potential) security hole. Some
people care, others don't. Make sure you know to which category
you belong.
Steve Gonedes
Johan Kullstam <joh...@idt.net> writes:
< copying/redifing the lisp-mode font-lock stuff to do the same in
< franz-lisp-mode shouldn't be terribly hard. i am just wondering if
< commonlisp is a weird enough beast with new keywords that ought to be
< lit but are not. more annoying, when i make new functions and macros
< which have syntactic meaning similar to keywords, these are not lit
< up. for example `defun' is purple. `my-defun' would be plain.
< enough of these and font-lock loses its purpose.
<
< always black and white while C built-in types like int are made
< green. i don't know if it's possible to make my types come out green
< in C++ without a lot of work.
I had font-lock work like this for TeX mode once. It would add new
keywords after seeing \newbox\mybox=0. This really slowed down
font-lock and the code was a royal pain in the butt.
Maybe you could define a macro like the `indent-rule' that would add
new entries to the font-lock keywords? Another alternative is to start
the word with `def' instead of `my-def'. You could use define or such
(this won't work for everything though). Can get annoying though...
< nod. paul graham's _on lisp_ talks about things like this. borrowing
< from my C++ experience, i suppose inline functions could help. but
< lisps powerful macro utility allows some pretty fancy stuff too. this
< is exactly why i am trying to learn lisp. i want a language i can
< use.
Inline functions will work as well - but sometimes macros are the
right choice. I wouldn't suggest using macros for speed hacks - this
usually is a bad idea (you can `(declaim (inline function-name))'...
R. Toy
>
> Johan Kullstam <joh...@idt.net> writes:
>
> < copying/redifing the lisp-mode font-lock stuff to do the same in
> < franz-lisp-mode shouldn't be terribly hard. i am just wondering if
> < commonlisp is a weird enough beast with new keywords that ought to be
> < lit but are not. more annoying, when i make new functions and macros
> < which have syntactic meaning similar to keywords, these are not lit
> < up. for example `defun' is purple. `my-defun' would be plain.
> < enough of these and font-lock loses its purpose.
>
> right choice. I wouldn't suggest using macros for speed hacks - this
> usually is a bad idea (you can `(declaim (inline function-name))'...
But the compiler is not required to inline the function, so if you
really want it inline, you may have no choice but to use a macro....
Ray
--
---------------------------------------------------------------------------
----> Raymond Toy rt...@mindspring.com
http://www.mindspring.com/~rtoy
David Steuber
-> Don't forget that rsh is a (potential) security hole. Some
-> people care, others don't. Make sure you know to which category
-> you belong.
My LAN uses the 10.*.*.* ip addresses. I connect to the Internet
through a router that provides NAT. All the doors in my castle can be
opened with the right key. Getting into the castle should be
impossible.
If I ever switch from ISDN to a cable modem, then I will have to
reinforce my security somewhat.
At work, I can rsh to some machines without typing in my password.
Other's prompt me. At home, I get prompted.
Johan Kullstam
> In article <u67atv...@res.raytheon.com>,
> Johan Kullstam <joh...@idt.net> wrote:
>
> (...)
> > i have this same problem in C++. i define my own type, and it is
> > always black and white while C built-in types like int are made
> > green. i don't know if it's possible to make my types come out green
> > in C++ without a lot of work.
>
> int is not just a built-in (if built-in is the word I want) type
> like e.g. size_t but also a reserved word.
the *_t stuff seems to get picked up as a type (in C mode, but not C++
mode of my emacs). however, i don't like naming all my types
something_t just to get font-lock to put pretty colors on them.
> This does *not* belong in this newsgroup...
i was just trying to relate to a language which i actually understand
somewhat. my lisp knowledge is rudimentary.
let me try to rephrase my question and give it a little context.
say that `if' is identified as a special word in lisp and font-lock
highlights it with a purple color (like in emacs-lisp-mode). then i
go and make an anaphoric if a la paul graham in _on lisp_ p 191.
(defmacro aif (test-form then-form &optional else-form)
'(let ((it ,test-form))
(if it ,then-form ,else-form)))
now i do
(aif (big-long-calculation)
(foo it))
the `aif' will not be recognized by the font-lock regexps. while
(if (big-long-calculation)
(foo big-long-calculation))
would have `if' lit up purple.
now, if lisp does this extension business all over the place, then the
font-lock is more of a distraction than a help. so my question is to
those who have lisp experience, is syntax-highlighting a worthwhile
feature and if so, what things are worth highlighting?
--
johan kullstam
Johan Kullstam
> vnik...@poboxes.com writes:
>
> -> Don't forget that rsh is a (potential) security hole. Some
> -> people care, others don't. Make sure you know to which category
> -> you belong.
>
> If I ever switch from ISDN to a cable modem, then I will have to
> reinforce my security somewhat.
exactly. i have a cablemodem and do not have a lan. therefore, i am
rather exposed. having rshd listening when i do not need or want
outside connexions is just one more weakness i do not need. i'd
rather not be forced to have things i do not want.
--
johan kullstam
vnik...@poboxes.com
"R. Toy" <rt...@mindspring.com> wrote:
> Steve Gonedes wrote:
> > Inline functions will work as well - but sometimes macros are the
> > right choice. I wouldn't suggest using macros for speed hacks - this
> > usually is a bad idea (you can `(declaim (inline function-name))'...
>
> But the compiler is not required to inline the function, so if you
> really want it inline, you may have no choice but to use a macro....
If macros are to be used as surrogate inline functions, it
would be nice if the programmer defines a defining macro
for these called DEFINLINE or some such. It would hide to
some extent the fact that inline functions are defined as
macros and could conditionally expand into DEFUN + inline
declamation for implementations that do do inlining and
into DEFMACRO for those that don't. Such a defining form
could also take care that the arguments are evaluated
exactly once in the right order.
Besides, DEFINLINE or another variant of it could define
automatically a setf expander or a setf function (couldn't
we now use the term `setf method' to mean one or the other?).
In the absence of such a defining form, the programmer is
very tempted to write (even if the implementation does
inlining)
(defmacro someobject-someattribute (object) `(cadar ,object))
instead of `the right thing' which is much longer and more
complex:
;; accessor for some attribute of some object:
(declaim (inline someobject-someattribute))
(defun someobject-someattribute (object)
(cadar object))
(defun (setf someobject-someattribute) (value object)
(setf (cadar object) value))
As an aside, are there many implementations where
(foo bar baz)
and
((lambda (x y) (foo x y)) bar baz)
do not compile to identical code?
--
Vassil Nikolov
http://www.poboxes.com/vnikolov
(If you must have a response from me, send me a cc of your posting.)
vnik...@poboxes.com
Johan Kullstam <joh...@idt.net> wrote:
> vnik...@poboxes.com writes:
(...)
> > This does *not* belong in this newsgroup...
| >
| > i was just trying to relate to a language which i actually understand
| > somewhat. my lisp knowledge is rudimentary.
|
anybody else.
(...)
> now, if lisp does this extension business all over the place, then the
> font-lock is more of a distraction than a help. so my question is to
> those who have lisp experience, is syntax-highlighting a worthwhile
> feature and if so, what things are worth highlighting?
Personally, I am not sure at all if it is worthwhile; assuming it is,
I am not sure if it should be done by colours---using different fonts,
bold, italic, etc. might be better. (The AppleScript editor on the
Macintosh, which does it in this latter way, seems to be doing it well,
though I have not used it quite a lot.)
Second, if syntax highlighting is assumed worthwhile, I would say that
the _syntactic_ features to be highlighted would include special forms
and macros, possibly special variables and such, but semantic features
(such as type names) should not be highlighted.
Besides, with Lisp we have pretty printing, which in my view reduces
the need for syntax highlighting.
My 2e-2, of course; of tastes and colours...
Steve Gonedes
vnik...@poboxes.com writes:
< In article <368AE671...@mindspring.com>,
< "R. Toy" <rt...@mindspring.com> wrote:
< > Steve Gonedes wrote:
< > > Inline functions will work as well - but sometimes macros are the
< > > right choice. I wouldn't suggest using macros for speed hacks - this
< > > usually is a bad idea (you can `(declaim (inline function-name))'...
< >
< > But the compiler is not required to inline the function, so if you
< > really want it inline, you may have no choice but to use a macro....
<
< If macros are to be used as surrogate inline functions, it
< would be nice if the programmer defines a defining macro
< for these called DEFINLINE or some such. It would hide to
< some extent the fact that inline functions are defined as
< macros and could conditionally expand into DEFUN + inline
< declamation for implementations that do do inlining and
< into DEFMACRO for those that don't. Such a defining form
< could also take care that the arguments are evaluated
< exactly once in the right order.
Thanks _so_ much for pointing this out. I had been taking the order of
evaluation for granted and forgot all about it.
< As an aside, are there many implementations where
<
< (foo bar baz)
<
< and
<
< ((lambda (x y) (foo x y)) bar baz)
<
< do not compile to identical code?
I was really trying to eliminate the excessive gensyms for clarity -
bad idea. Thanks again!
Sunil Mishra
> Personally, I am not sure at all if it is worthwhile; assuming it is,
> I am not sure if it should be done by colours---using different fonts,
> bold, italic, etc. might be better. (The AppleScript editor on the
> Macintosh, which does it in this latter way, seems to be doing it well,
> though I have not used it quite a lot.)
>
> Second, if syntax highlighting is assumed worthwhile, I would say that
> the _syntactic_ features to be highlighted would include special forms
> and macros, possibly special variables and such, but semantic features
> (such as type names) should not be highlighted.
>
> Besides, with Lisp we have pretty printing, which in my view reduces
> the need for syntax highlighting.
One of my friends in usability pointed out that in some study, about the
only visual tool that turned out to be generally accepted as useful was
syntax highlighting. I personally have become so used to it that being
without it would make me far less productive. At least until I readapt. I
have practically given up on editing lisp programs over a vt100 terminal,
and find MCL inconvenient because I can't find a facility that does syntax
highlighting. (I did find one, but it inserted font codes into the text
document, which was not acceptable.)
Yes, having a tool figure out new forms to highlight would be nice. What is
already available however is in itself indispensable. I think a better long
term solution might be something that ties in with source code and project
management. Some way of defining a project in some ilisp like environment,
where parameters to font highlighting, among other things, can be specified
for the project as a whole, to be loaded into emacs.
Your milage, could (and does appear to) vary.
Sunil
Faried Nawaz
most modern FTP servers do this, which is a
boon for people who use _real_ FTP clients, compared to the losers who
use "browsers" and can only get what they see.ยน
That doesn't say much for people who use ange-ftp or efs.
Erik Naggum
| i now get franz-lisp-mode when i visit a file with a .l (for *l*isp)
| made eli happy to fire off a slave lisp process. (i don't use rsh for
| anything else, can i remove the dependency on it?)
it is probably not a good idea to retain the franz-lisp mode in Franz
Inc.'s ELI, but I'm not sure here. there is no "Franz Lisp", anymore
that I know of, and the stuff that applies to its files are different
from that which applies to Common Lisp and Allegro CL. so I took out
the franz-lisp-mode stuff in my local version.
for Allegro CL, the canonical Lisp file type is "lisp" or "cl". lots of
things become needlessly harder if you don't use either of these.
| i can pop between source editor and slaved lisp process with C-c l. C-c
| C-b compiles. so far so good. i can type in the little function
| examples from grahams books and try them out in the lisp slave. is this
| how you do it in general?
I compile forms with C-M-x all the time, look at the value of special
variables with C-u C-c C-s, request arglists with C-c a, macroexpand with
C-c m, describe symbols with C-c d, and most usefully jump to definitions
with C-c . and list callers with C-c c. I also use fi:edit-who-calls
(bound to C-c e) when I change the signature of a function. all very
useful stuff. I also use the :edit top-level command a lot, and even use
the ED function to edit files with logical pathnames, since Emacs doesn't
(yet) interface to Allegro CL in that way.
| i am still a bit stumped about how the process is supposed to work.
I find it hard to explain. the way I use Allegro CL is a function of
what I have discovered that I can do. I fire up a number of listeners as
the need arises and basically leave the Initial Lisp Listener alone (the
trace output from Lisp processes go there, so it gets really cluttered if
I try to do anything useful while tracing something).
| using make and command line compile commands and getting a normal unix
| executable as with C or fortran doesn't seem to be the right thing with
| lisp.
that's right. however, if you view the Unix way a little differently,
it's actually a _subset_ of the way you do it in Lisp. with Unix, you
edit a file, invoke some function to make its definitions available in
your environment, then invoke the function you just defined. Unix stores
its functions in files, while Lisp stores them in memory. either way,
you invoke them basically the same way: you give each command loop a form
to evaluate (the parentheses are implied in Unix, and you get a PROGN
wrapper for free if you use the ; syntax). (the first word is even the
name of the function. prefix syntax rules!)
the functions you invoke are just a little different between the two
otherwise quite similar modes of operation. take "foo.c" and "bar.cl".
you would invoke the compiler on "foo".c and get "foo". you would invoke
COMPILE-FILE on "bar.cl" (or use FI:COMPILE-AND-LOAD-FILE directly from
the buffer, which can conveniently be bound to the same key you bound M-x
compile to in other modes). Lisp needs you to LOAD the file if you
hadn't already done that. Allegro CL comes with three top-level commands
that can save you some typing. :cf (compile-file), :ld (load), and :cl
(compile-and-load), and all abbreviated with wild abandon, just like Unix
tools. they also remember what you did last. (I think they should have
had the same memory, though.)
Unix `make' is convenient in that it has a bunch of predefined ways to
compile a number of files, and the Makefile is a nice place to store
variable settings. if you want to make use the DEFSYSTEM facility in
Allegro CL, you'll find that the defaults are less elaborate and you
might need to say something like
(defsystem :foo
(:pretty-name "Functional Object Orientation"
:default-pathname #L"foo:src;")
(:serial "foo" "bar" "zot"))
then you'd say (compile-system :foo) or (load-system :foo :compile t) or
the like, and things are taken care of. (it would have be nice if the
top-level loop had had commands like :cs and :ls, but when I take the
time to figure out how to make top-level commands, I'll post something.)
all in all, I think of Unix depriving me of the conveniences, and being
rather limited in functions that have to do everything to remember their
previous state themselves, but, really, a Unix command is no different
from calling a Lisp function:
Lisp: (foo "x" 14 :mumble t :frotz nil)
GNU style: foo --mumble --no-frotz x 14
Unix style: foo -m -n x 14
the conveniences in Unix (like `make') are there because the lack of them
would be inconvenient. that's how it usually goes with conveniences. to
see how that would work in a language that doesn't have those particular
conveniences, step back a little and think of what you'd do without them:
you'd call the C compiler yourself on the particular file, and specify
the output file. the conveniences of `make' is that it compiles only if
needed and you don't need to tell it any file types. unsurprisingly,
that's what the :cl command does in Allegro CL. the command :cl foo
looks for a file foo.cl (or foo.lisp), sees if it is newer than the
foo.fasl (or similar) file, compiles it if necessary, then loads it. and
just as `make' takes a list of files to make something from, :cl takes a
list of files to compile and load.
another bonus with LOAD-SYSTEM, by the way, is that it only loads the
files it needs to load, so you don't run initializatio code unless you
need to. the same applies to forms you compile with C-M-x: they are
compiled in the same environment they are expected to run: with all the
other functions and variables loaded. obviously, it works best to start
off your work session by loading the last working version of your code.
both LOAD (:ld) and LOAD-SYSTEM default to loading compile files rather
than source files, so you're "safe" in that regard, too.
I hope this helps. I don't know any people who use Allegro CL exactly
the same way, and what works for me may not even be useful advice for
others. and remember: nothing beats reading the manual.
#:Erik
--
webm...@sharknet.ml.org.nospam
> I just downloaded ACL 4.3 For Linux from www.franz.com. I haven't
> unpacked and installed it yet. I have some concerns about the license
> that bother me. I was wondering if someone from Franz could clear
> them up for me.
Why not download the 5.0 package? The one I got was still in beta (about 6
months ago). If it's been released to final, they might be sending demo
CD's like they did with version 4.
brian
Johan Kullstam
> One of my friends in usability pointed out that in some study, about the
> only visual tool that turned out to be generally accepted as useful was
> syntax highlighting.
how about indentation? that's visual. i think it's extremely
useful. perhaps it's simply taken for granted.
> I personally have become so used to it that being
> without it would make me far less productive. At least until I readapt. I
> have practically given up on editing lisp programs over a vt100 terminal,
> and find MCL inconvenient because I can't find a facility that does syntax
> highlighting. (I did find one, but it inserted font codes into the text
> document, which was not acceptable.)
i find unindented lisp code to be largely incomprehesible. C, C++
benefits greatly from good indention and even fortran can be made
easier to read.
--
johan kullstam
Sunil Mishra
> Sunil Mishra <smi...@whizzy.cc.gatech.edu> writes:
> > One of my friends in usability pointed out that in some study, about the
> > only visual tool that turned out to be generally accepted as useful was
> > syntax highlighting.
>
> how about indentation? that's visual. i think it's extremely
> useful. perhaps it's simply taken for granted.
I'm not arguing against the usefulness of indentation. But indentation
along with coloring works even better. At least for me, colors allow me to
quickly identify the location of various special constructs, such as defun
and conditionals, and keywords that are often used, for example, in
argument lists. Indentation good. Color good. Indentation + color even
better.
Sunil
Lyman S. Taylor
Johan Kullstam <joh...@idt.net> wrote:
>Sunil Mishra <smi...@whizzy.cc.gatech.edu> writes:
>> One of my friends in usability pointed out that in some study, about the
>> only visual tool that turned out to be generally accepted as useful was
>> syntax highlighting.
>
>how about indentation? that's visual. i think it's extremely
>useful. perhaps it's simply taken for granted.
Ted Turner and his ilk colorize movies. That doesn't make them any "better".
Just more accepted. (by the masses that is. Personally I think they are
horrible. Especially if the original photography director knew
anything about black and white photography. )
Perhaps the operative word here is "accepted". Where "accepted" means
the user "likes" colored/highlighted syntax more. That doesn't
neccesarily transfer into a large productivity gain ( other than happy
readers are probably slightly more productive readers. ) Given unindented
colorized code and uncolored indented code, I'd bet you'd be hard pressed
to deliver experimental results that the former is significantly more
productive than the latter.
However, if you took a "poll" syntax highlight would probably occur
higher on the "top ten" list.
To drop some Lisp into this thread there was a reference to a Steele
talk about "growing a language". One benefit of Lisp was that you can
add new "operations" that look just like the "primitives". I don't see
the big win over highlighting the language function/macro invocations
over the user defined ones. They both have the same "form" ( I would
say syntax but there are nuances between macros). So coloring
one and not the other draws a distinction that really doesn't seem
to matter much, IMHO.
[ At best it seems a distinction between looking on the HyperSpec versus
looking in the source code for documentation. In Common Lisp if the
environment and user defined code both have doc strings this is moot. ]
Strings, constants, and comments I find useful in font lock mode. When
not terminated properly (e.g., no close doublee quote on a string)
on a the colors tend to get a screwed up. Sort of like the emacs's paren
highlighting. Being able to quickly classify comments vs. code is
useful when reading because they are different semantically.
My personal "MY-IF" and the default "IF" aren't to the same
significance.
However, since some users "accept" vi more than emacs this too will
come down to personal choice. I would just be careful with "usuability"
and "accept" used in the same context.
--
Lyman S. Taylor "I'm a Doctor! Not a commando."
(ly...@cc.gatech.edu) The enhanced EMH Doctor in a ST:Voyager epidsode.
David Lichteblau
> then you'd say (compile-system :foo) or (load-system :foo :compile t) or
> the like, and things are taken care of. (it would have be nice if the
> top-level loop had had commands like :cs and :ls, but when I take the
> time to figure out how to make top-level commands, I'll post something.)
Is my understanding right that the Lisp Machines have various kinds of
listeners for purposes like this? Or is there one which works for
normal language-oriented queries as well as for OS-level (:ls) things?
Someone proposed (in a thread I can't find anymore) that before writing
high-level libraries like CLIM, this listener functionality should be
written. Any information about how this should work? A common Lisp
listener/file system listener/inspector/debugger for all the various
Common Lisp implementations sounds like a useful and powerful thing to
have.
David
Kelly Murray
>...
> To drop some Lisp into this thread there was a reference to a Steele
> talk about "growing a language". One benefit of Lisp was that you can
> add new "operations" that look just like the "primitives". I don't see
> the big win over highlighting the language function/macro invocations
> over the user defined ones. They both have the same "form" ( I would
> say syntax but there are nuances between macros). So coloring
> one and not the other draws a distinction that really doesn't seem
> to matter much, IMHO.
>
IMNSHO, I think there is a problem if there is in fact no distinction
between basic control constructs over user-level application code.
This ability to extend the language is a double-edged sword.
Unfortunately I believe that the net effect has been negative,
in that way too much lisp code is not understandable, extendable,
maintainable, or in many cases useable, by other
than the people who wrote it. This particularly problematic
for extended basic controls, e.g. cond-every (why not cond* ?? ;)
or for total hack macros. e.g. (from my own code ;)
(loop-for-each-segment ...)
Furthermore in many cases such macrology
can requires a big set of not-so-efficient
support machinery to even execute
the layers of abstraction. e.g. CL-HTTP or CLIM..
-Kelly Murray k...@intellimarket.com
Mike McDonald
david.li...@snafu.de (David Lichteblau) writes:
> In article <31243504...@naggum.no>, Erik Naggum wrote:
>> the like, and things are taken care of. (it would have be nice if the
>> top-level loop had had commands like :cs and :ls, but when I take the
>> time to figure out how to make top-level commands, I'll post something.)
>
> listeners for purposes like this? Or is there one which works for
> normal language-oriented queries as well as for OS-level (:ls) things?
The command tables on Symbolics can be hierarchical, ie one command table
can inherit commands from other command tables. So for my app, I can define
just my few new commands and inherit all the other ones from some preexisting
one.
The standard lisp listener has all of those commands in it's default command
table. (If I remember correctly, you can specify the command table to use when
creating a listener.) For instance, the lisp listener has :Show Directory
built in. The nice thing about the LispM implementation, is it has command
completion (using the space key!). So I type in ":sh di " and I get ":Show
Directory :directory <default>?" Since the commands are built upon
presentation types, the reader knows what type the argument is. So I can type
in a directory name, or I can click on an valid pathname displayed anywhere on
the screen. And since Lisp knows the type of everything, when the results are
displayed on the screen, the LispM remembers that info. So after I do the
:Show Directory command, all of the pathnames printed out are mouse sensitive.
The default action (left mouse click) for files is to execute ":Show File"
with that pathname as the arg. For directories, it's too call ":Show
Directory" with the pathname. The middle button is typically bound to
":Describe Object". The right button pops up a menu with several choices of
things you can do to that object. For files, one of the choices is to edit the
file, for instance. For object slots, one of the choices is to modify the
slot. This gives a pretty complete "inspector" for free.
> Someone proposed (in a thread I can't find anymore) that before writing
> high-level libraries like CLIM, this listener functionality should be
> written. Any information about how this should work? A common Lisp
> listener/file system listener/inspector/debugger for all the various
> Common Lisp implementations sounds like a useful and powerful thing to
> have.
>
> David
Actually, I think I proposed just the opposite. You really need CLIM to
write the lisp listener. CLIM provides the framework for PRESENT and ACCEPT,
and command tables upon with a listener would be built. Here's where efforts
are currently at: http://www.mikemac.com/mikemac/McCLIM/index.html (Still got
a ways to go for alpha release!)
Mike McDonald
mik...@mikemac.com
Erik Naggum
| Is my understanding right that the Lisp Machines have various kinds of
| listeners for purposes like this?
I believe that's part of the package.
| Or is there one which works for normal language-oriented queries as well
| as for OS-level (:ls) things?
:LS is ordinarily a Common Lisp keyword, but when the normal Allegro CL
top-level read-eval-print loop reads a line that starts with the value of
TOP-LEVEL:*COMMAND-CHAR* (ordinarily #\:), it is interpreted as a
top-level command instead of an s-expression. however, these commands
are _not_ "OS-level". :ls was intended to be an abbreviation just like
:cf for COMPILE-FILE, :cl for COMPILE-AND-LOAD, etc, intended to mean
LOAD-SYSTEM.
#:Erik
Rainer Joswig
> In article <31243504...@naggum.no>, Erik Naggum wrote:
> > then you'd say (compile-system :foo) or (load-system :foo :compile t) or
> > the like, and things are taken care of. (it would have be nice if the
> > top-level loop had had commands like :cs and :ls, but when I take the
> > time to figure out how to make top-level commands, I'll post something.)
>
> Is my understanding right that the Lisp Machines have various kinds of
> listeners for purposes like this? Or is there one which works for
> normal language-oriented queries as well as for OS-level (:ls) things?
The Lisp Listener accepts Lisp forms and commands. The interesting
thing is the Command Loop substrate. You can have a command loop
anywhere - in your own applications, too.
> Someone proposed (in a thread I can't find anymore) that before writing
> high-level libraries like CLIM,
You need CLIM to write such a listener. CLIM has
as one example a simple listener.
Essentially CLIM is the user interface substrate of the
Symbolics Lisp Machine (Dynamic Windows) rewritten in CLOS
to be portable. It lacks the applications, though.
In my little CLIM Lisp Listener extension one can say "Load System",
Compile System, ... ;-)
Ok., to torture you a bit more: Well, how does it look like on a Mac?
See: http://www.lavielle.com/~joswig/clim/clim1.jpg (sorry for
the image quality)
up left: the Lisp Listener
up right: browsing packages
down left: web hierarchy with browsed with CL-HTTP (it doesn't make
sense for a gif, but you get the idea)
down right: inspecting a class, showing the subclasses
Lyman S. Taylor
Kelly Murray <k...@IntelliMarket.Com> wrote:
>
>IMNSHO, I think there is a problem if there is in fact no distinction
>between basic control constructs over user-level application code.
In the context of "worse is better" and the seemingly sound
arguments for "growing" a language, it isn't the facility that is a
problem. Unconstrained and undirected growth, "Urban sprawl",
is the problem.
The "language addition" feature is a clean/simple solution and it works.
To add additional infrastructure (or complicated restraints ) to make it
always the contexually "correct" solution seems problematical.
>This ability to extend the language is a double-edged sword.
If I may borrow and adapt a phrase....
"Swords don't kill people. People kill people."
>in that way too much lisp code is not understandable, extendable,
>maintainable, or in many cases useable, by other
>than the people who wrote it.
Then perhaps more effort has to be put into making people better
"swordsmen" than in constraining the language.
[ Admittedly, there is no "silver bullet" in producing folks who don't
write code of this ilk. ]
In solving problems you can either bring the problem domain down to the
level of the programming language or bring the programming language
up to the level of the problem domain. [ Most often you have to do a
little of both.] In the latter case, maintenance
is more problematical if the maintainer knows programming language,
but not the domain. However, it seems likely that latter approach would
have less problems with correctness. [ Maintainers who don't understand the
problem domain seem like a landmine just waiting to be stepped on.]
Unfortunately, the same mechanisms for "growing" the language to
up to meet the problem domain can be used by "seat of the pants" language
designers. "The common lisp committee really should have included
my favorite geegaw from the 'whiz-bang' language into the lisp."
That often is an "abuse" of the abstraction/extentsion mechanisms.
Of course, "beauty" is in the eye of the beholder. There is a fine line
between "bring lisp up to the problem domain" and "write a new
programming language (perhaps resembling lisp) layered on top of lisp" to
solve the problem with. The latter is fine it is it your objective
to write a new general purpose language on top of lisp. However,
each new problem doesn't deserve its own unique language.
I think that the cry of "if you don't like common lisp's
syntax, just write your own" should not be outlined as a prominent feature.
Down that path lies the "Dark side". :-)
Indiscriminate use of EVAL can also be "misused" in Common Lisp programs.
I don't think most would like to do without it though. I tell students
to be conservative in its use. Like the "Dark side of the Force", it is
seductive.
I suspect there is lots of "bad" lisp code out there (gratitous use of
EVAL, baroque control mechanisms, etc.). Hopefully those authored by
me have dissappeard in oblivion. :-) However, this legacy code should
be labeled as "bad" and/or baroque. More well formed examples should be
held up as counter-examples.
In summary, I think the "invent a language/feature of the week" culture
is more the root cause of the problem in this case than the
ultra-malleability of Lisp.
David Lichteblau
> however, these commands
> are _not_ "OS-level". :ls was intended to be an abbreviation just like
> :cf for COMPILE-FILE, :cl for COMPILE-AND-LOAD, etc, intended to mean
> LOAD-SYSTEM.
You are right--`:ls' looked so much like Unix `ls' that I managed to
misunderstand your remark, although the lack of :load-system as a
top-level command has occurred to me, too.
Below is a simple definition of :ls and :cs that seems to work, but has
not yet been tested thoroughly. Comments or corrections are
appreciated!
USER(2): :help ls
The `ls' command calls the function `load-system' on its
arguments; keyword arguments are accepted.
The optional first argument is the name of a system. If no arguments
are given, the last argument to one of the top-level commands dealing
with systems is used.
USER(3): :help cs
The `cs' command calls the function `compile-system' on its
arguments; keyword arguments are accepted.
The optional first argument is the name of a system. If no arguments
are given, the last argument to one of the top-level commands dealing
with systems is used.
USER(4): :ls
ls: no previous system
USER(5): :cs
cs: no previous system
USER(6): :ls :test-system
; Loading system: "TEST-SYSTEM".
; Source is newer than product for module: "test-system".
; Loading product for module: "test-system".
; Fast loading /home/david/cl/test-system.fasl
USER(7): :cs
; Compiling system: "TEST-SYSTEM".
; Compiling module "test-system" because the product file is out of date.
;;; Compiling file ./test-system.lisp
;;; Writing fasl file /home/david/cl/test-system.fasl
;;; Fasl write complete
; Loading product for module: "test-system".
; Fast loading /home/david/cl/test-system.fasl
USER(8): :ls
; Loading system: "TEST-SYSTEM".
USER(9): :ls :test-system :reload t
; Loading system: "TEST-SYSTEM".
; Loading product for module: "test-system".
; Fast loading /home/david/cl/test-system.fasl
USER(10):
David
-------- source follows
;;; define new top-level commands
;;; :ls (`LOAD-SYSTEM') and
;;; :cs (`COMPILE-SYSTEM')
;;; similar to :ld and :cl
;;; the commands remember their first argument to make successive invocations
;;; easier to type. Make sure that different listeners do not clobber
;;; each other's memory of the argument. (Remove this form if you always
;;; want to work with the same system in all listeners.)
(push '(*system-command-last-arg* . nil)
excl::*default-lisp-listener-bindings*)
;;; DEFINE-SYSTEM-COMMAND [Macro]
(eval-when (:execute :load-toplevel :compile-toplevel)
(defmacro define-system-command (name (&optional system &rest other-args)
documentation
&body body)
"Defines a new top-level command NAME that takes the optional argument
named SYSTEM (and other arguments if given) and executes the BODY. If no
system is given to the command, it defaults to the last argument to one of
the commands defined. A DOCUMENTATION string is required."
;; this is more work than really needed for only two commands, but
;; it's more generic this way. ACL's DEFSYSTEM is flexible enough to
;; make more commands likely.
(let ((real-name (if (consp name) ;two possible forms:
(first name) ;list of string and options
name)) ;only string
(system-supplied-p (gensym "SYSTEM-SUPPLIED-P")))
`(tpl:alias ,name
(&optional (,system *system-command-last-arg* ,system-supplied-p)
,@other-args)
,(format nil
"The `~A' command ~A.
The optional first argument is the name of a system. If no arguments
are given, the last argument to one of the top-level commands dealing
with systems is used."
real-name documentation)
(declare (special *system-command-last-arg*))
(if (and (not ,system-supplied-p)
(null *system-command-last-arg*))
(format t "~a: no previous system" ,real-name)
(prog1
(locally ,@body)
(setq *system-command-last-arg* ,system)))))))
;;; :LS [Top Level Command]
;;; :CS [Top Level Command]
(define-system-command "ls" (name &rest args)
"calls the function `load-system' on its
arguments; keyword arguments are accepted"
(apply #'excl:load-system name args))
(define-system-command "cs" (name &rest args)
"calls the function `compile-system' on its
arguments; keyword arguments are accepted"
(apply #'excl:compile-system name args))
;;; :MKLS [Top Level Command]
;;; :MKCS [Top Level Command]
;;; :OOS [Top Level Command]
;;; WARNING! These should work, but I couldn't test them yet.
#|
(define-system-command "mkls" (name &rest args)
"calls the function `operate-on-system' with the
operation `load' and possible other arguments given to the command"
(apply #'operate-on-system name 'load args))
(define-system-command "mkcs" (name &rest args)
"calls the function `operate-on-system' with the
operation `load' and possible other arguments given to the command"
(apply #'operate-on-system name 'compile args))
(define-system-command "oos" (name &rest args)
"calls the function `operate-on-system' with the
arguments given to the command"
(apply #'operate-on-system name args))
|#
-------- end of source