Francogrex <······@grex.org> writes:
> Hi, I would like to ask two simple questions to you guys who have much
> more expertise in lisp than I do.
> 1) I'm new to Lisp and at work I was explaining that what I find
> beautiful in Lisp (all lisp is beautiful but what I find especially
> beautiful) is the concept of macros that make of lisp a programmable
> programming language. But then some guys from the stats department who
> are SAS addicts (those who don't know how to programm but use only
> canned procedures) said: "yeah, that's nothing new or special, you
> have macros in SAS also"... I was annoyed because I knew that somehow
> the concept of macros is SAS (or other real programming languages) is
> quite different from the macros in lisp but couldn't explain really
> how, didn't have enough knowledge of other languages. Can someone tell
> me how macros in Lisp are different?
The major difference is that instead of being merely text substitution,
lisp macros allow you to COMPUTE source transformations. That allows
you to use the entire power of the language to figure out what the
expansion of the macro should be. As a simple example, but one that is
likely to be a challenge to other macro system (I know nothing about
SAS), how about the following:
Write a macro that establishes variable bindings for N variables with
starting with PREFIX that have initial values of N down to 1. These
variables are available for reference in a body of code also passed in
to the procedure. (N, PREFIX and BODY are the macro arguments):
(defmacro try-it (prefix n &body body)
`(let ,(loop for i from 1 to n
as value downfrom n
collect (list (intern (format nil "~A-~D" prefix i))
value))
,@body))
(macroexpand '(try-it "VAR" 5 (list var-5 var-3 var-1 var-4 var-2)))
> 2) I have written programs in Lisp that I would want collegues to use
> them, but I don't want them to alter the source codes (actually my
> boss asked me to do that, not that he or I are against open source
> codes, not at all, but for regulatory reasons we are afraid that some
> "smarties" might start modifying and misusing the codes (those are
> stat procedures).
Well, you don't say which variety of Lisp you are using. Most lisp
systems that I use don't comile to bytecodes, but rather to machine
code. In which case the compiled code would be roughly the same as what
you would get from a C compiler.
You also don't quite say what level of effort you need to protect
against. Against a determined attacker, pretty much anything you do
won't really work, since they can just take the binary code and modify
that by editing at the machine language level. For the deterrence of
casual modification, just distributing fasl (compiled lisp) instead of
source should suffice.
--
Thomas A. Russ, USC/Information Sciences Institute
F> really modify it in any meaningful way. Though the output of the
F> system's C compiler (like the one GCL uses) appears less
F> readable/decodable than the bytcode compiled file (like the one of
F> CLISP), I think both outputs would be difficult to understand just by
F> the human eye looking at the code opened in any text editor right?
yup. also core file produced by SBCL is pretty much undecipherable
F> Ideally I would like to generate excutable (exe) programs but I think
F> that's not an easy option in CL.
why do you think so? i think _most_ implementations can make executables,
for example, bundling loader and core dump in one file.
"Alex Mizrahi" <········@users.sourceforge.net> wrote in message
······························@news.sunsite.dk...
> F> Ideally I would like to generate excutable (exe) programs but I think
> F> that's not an easy option in CL.
> why do you think so? i think _most_ implementations can make executables,
> for example, bundling loader and core dump in one file.
In fact, it is very easy with clisp, see the following example.
(defun save-application (name main &optional (documentation "Hello World"))
(ext:saveinitmem name
:executable t
:quiet t
:norc t
:init-function main
:script t
:documentation documentation))
(defun main ()
(format t "~%Hello World!~%") (ext:exit 0))
(save-application "hw" (function main))
(ext:shell "./hw")
--
Joseph Iacobucci
Email: ·······@mail.gatecch.edu
Francogrex wrote:
> I think both outputs would be difficult to
> understand just by the human eye looking at the code opened in any
> text editor right?
Right, I guess.
> Ideally I would like to generate excutable (exe)
> programs but I think that's not an easy option in CL.
See http://clisp.cons.org/impnotes/image.html and look for
the :EXECUTABLE keyword.
Matthias
On May 22, 2:19 pm, Matthias Benkard <······@mail.matthias.benkard.de>
wrote:
> Francogrex wrote:
> > I think both outputs would be difficult to
> > understand just by the human eye looking at the code opened in any
> > text editor right?
>
> Right, I guess.
>
> > Ideally I would like to generate excutable (exe)
> > programs but I think that's not an easy option in CL.
>
> Seehttp://clisp.cons.org/impnotes/image.htmland look for
> the :EXECUTABLE keyword.
>
And for SBCL, I've written a short blurb on the matter at
http://mikael.jansson.be/journal/2008/03/freezing-lisp-in-time
The commercial distributions (LispWorks, Allegro, ...) allow you to
even easier create distributable applications, some with a cross-
platform GUI library.
--
Mikael Jansson
http://mikael.jansson.be
Francogrex <······@grex.org> writes:
> Thomas A. Russ wrote:
>> Well, you don't say which variety of Lisp you are using.
>
> Hi, yes I'm using the common lisp implementation of CLISP on windows
> XP.
You mean "the clisp implementation of Common Lisp."
or "the Common Lisp implementation (named) clisp".
clisp is the implementation.
Common Lisp is the language.
>> You also don't quite say what level of effort you need to protect
>> against.
>
> Although they're not professional hackers, some still would try to
> mess with the code to make it "different" and our regulations won't
> allow that. I guess if it's compiled in machine language they wouldn't
> know how to really modify it in any meaningful way. Though the output
> of the system's C compiler (like the one GCL uses) appears less
> readable/decodable than the bytcode compiled file (like the one of
> CLISP), I think both outputs would be difficult to understand just by
> the human eye looking at the code opened in any text editor right?
> Ideally I would like to generate excutable (exe) programs but I think
> that's not an easy option in CL.
On the contrary, there's nothing simplier:
#+clisp(ext:saveinitmem "your-pgm"
:executable t
:norc t
:init-function (function main))
--
__Pascal Bourguignon__