Hiya all,
I've been looking at Lisp for a few days (reading the gigamonkeys book),
and I'm loving what I see so far. I'm a fair way from getting it all,
though.
I'm looking for confirmation that I can do a couple of things in Lisp
that I *suspect* I can do, but don't have sufficient grasp of the
details to *know* so. If I'm correct, it'll be a huge incentive for me
to continue with Lisp.
I'm considering writing a MUD client. Am I correct in thinking that
1) I could choose to treat user input as Lisp? That is, not bother with
a "script" layer - just allow me to execute Lisp code directly from the
client, as if it were the REPL loop? And that I could load Lisp
dynamically from files?
2) Rather than invent an intermediate representation for the parsed
input from the MUD, I could just represent them as Lisp code itself? For
example, the MUD output will have embedded colour information, and the
user may choose to further add colour triggers to the text. I'm hoping
to have more than one GUI to the client, so am I right that I could
produce a Lisp representation of the text (via macros?) that would be
abstracted away from the method of displaying the text to the user, and
that when *executed* would actually generate the output.
Thanks in advance.
--
Keith Willoughby http://flat222.org/keith/
War is peace
From: Ken Tilton
Subject: Re: Clarification of Lisp features for a newbie
Date:
Message-ID: <miM%h.41$AI5.27@newsfe12.lga>
Keith Willoughby wrote:
> Hiya all,
>
> I've been looking at Lisp for a few days (reading the gigamonkeys book),
> and I'm loving what I see so far. I'm a fair way from getting it all,
> though.
Go away. Use Ruby. Python if you are Old Skool.
>
> I'm looking for confirmation that I can do a couple of things in Lisp
> that I *suspect* I can do, but don't have sufficient grasp of the
> details to *know* so. If I'm correct, it'll be a huge incentive for me
> to continue with Lisp.
>
> I'm considering writing a MUD client. Am I correct in thinking that
>
> 1) I could choose to treat user input as Lisp? That is, not bother with
> a "script" layer - just allow me to execute Lisp code directly from the
> client, as if it were the REPL loop? And that I could load Lisp
> dynamically from files?
>
> 2) Rather than invent an intermediate representation for the parsed
> input from the MUD, I could just represent them as Lisp code itself? For
> example, the MUD output will have embedded colour information, and the
> user may choose to further add colour triggers to the text. I'm hoping
> to have more than one GUI to the client, so am I right that I could
> produce a Lisp representation of the text (via macros?) that would be
> abstracted away from the method of displaying the text to the user, and
> that when *executed* would actually generate the output.
There exists a gray area: macrology. A macro is "Lisp code", but inside
the macro one takes apart the macro arguments as if they were an
intermediate representation. But one sticks with Lispy syntax so that
the "parsing" is just a matter of using destructuring-bind, with all its
wonderfulness. Yeah, one still Just Loads Lisp, but the macro author has
the mindset of one providing a scripting language.
Hopefully I have confused things enough to drive you away forever.
kenny
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Ken Tilton <···@theoryyalgebra.com> writes:
> Keith Willoughby wrote:
>> Hiya all,
>>
>> I've been looking at Lisp for a few days (reading the gigamonkeys book),
>> and I'm loving what I see so far. I'm a fair way from getting it all,
>> though.
>
> Go away. Use Ruby. Python if you are Old Skool.
:-) I've been using Ruby for 5 or 6 years now, on and off. I keep
reading that that means I'm so far along the Road To Lisp, I may as well
keep walking.
[...]
> Hopefully I have confused things enough to drive you away forever.
Not yet.
Thanks.
--
Keith Willoughby http://flat222.org/keith/
Keith Willoughby wrote:
> Hiya all,
>
> I've been looking at Lisp for a few days (reading the gigamonkeys book),
> and I'm loving what I see so far. I'm a fair way from getting it all,
> though.
Welcome. :)
> I'm looking for confirmation that I can do a couple of things in Lisp
> that I *suspect* I can do, but don't have sufficient grasp of the
> details to *know* so. If I'm correct, it'll be a huge incentive for me
> to continue with Lisp.
>
> I'm considering writing a MUD client. Am I correct in thinking that
>
> 1) I could choose to treat user input as Lisp? That is, not bother with
> a "script" layer - just allow me to execute Lisp code directly from the
> client, as if it were the REPL loop?
Yes, that's possible. However, there are security issues involved here.
As soon as you evaluate arbitrary user input, it can actually execute
aribtrary code, including code that changes your underlying program at
runtime. Common Lisp provides very little wrt protecting a running
program from being changed.
So it may still be advisable to implement another interpreter for user
scripts on top, which allows you to better control what a user is and
isn't allowed to do. The good news is that implementing an interpreter
in Lisp is a very straightforward undertaking, especially if you stick
to s-expressions as the surface syntax for your scripting language. (No
need for parsing, etc.)
> And that I could load Lisp dynamically from files?
Yes.
> 2) Rather than invent an intermediate representation for the parsed
> input from the MUD, I could just represent them as Lisp code itself? For
> example, the MUD output will have embedded colour information, and the
> user may choose to further add colour triggers to the text. I'm hoping
> to have more than one GUI to the client, so am I right that I could
> produce a Lisp representation of the text (via macros?) that would be
> abstracted away from the method of displaying the text to the user, and
> that when *executed* would actually generate the output.
Yes.
The latter two are not only possible, but actually common approaches in
Lisp.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Keith Willoughby wrote:
>> Hiya all,
>>
>> I've been looking at Lisp for a few days (reading the gigamonkeys book),
>> and I'm loving what I see so far. I'm a fair way from getting it all,
>> though.
>
> Welcome. :)
Hey! :)
[...]
>> I'm considering writing a MUD client. Am I correct in thinking that
>>
>> 1) I could choose to treat user input as Lisp? That is, not bother with
>> a "script" layer - just allow me to execute Lisp code directly from the
>> client, as if it were the REPL loop?
>
> Yes, that's possible. However, there are security issues involved
> here. As soon as you evaluate arbitrary user input, it can actually
> execute aribtrary code, including code that changes your underlying
> program at runtime. Common Lisp provides very little wrt protecting a
> running program from being changed.
Well, I'm not so bothered about that. The input would be solely from the
user, who couldn't do more with my program than he could without
it. (Especially as the user would probably be just me :P) As long as I
don't try to interpret untrusted input, I think I should be ok . . .
[snip answers to other questions]
> The latter two are not only possible, but actually common approaches
> in Lisp.
Many thanks! Now I know I'm on the right track, it's head-back-in-the-
book time.
--
Keith Willoughby http://flat222.org/keith/
Freedom is slavery
On May 7, 9:00 pm, Keith Willoughby <····@flat222.org> wrote:
> Hiya all,
>
> I've been looking at Lisp for a few days (reading the gigamonkeys book),
> and I'm loving what I see so far. I'm a fair way from getting it all,
> though.
>
> I'm looking for confirmation that I can do a couple of things in Lisp
> that I *suspect* I can do, but don't have sufficient grasp of the
> details to *know* so. If I'm correct, it'll be a huge incentive for me
> to continue with Lisp.
>
> I'm considering writing a MUD client. Am I correct in thinking that
>
> 1) I could choose to treat user input as Lisp? That is, not bother with
> a "script" layer - just allow me to execute Lisp code directly from the
> client, as if it were the REPL loop? And that I could load Lisp
> dynamically from files?
>
> 2) Rather than invent an intermediate representation for the parsed
> input from the MUD, I could just represent them as Lisp code itself? For
> example, the MUD output will have embedded colour information, and the
> user may choose to further add colour triggers to the text. I'm hoping
> to have more than one GUI to the client, so am I right that I could
> produce a Lisp representation of the text (via macros?) that would be
> abstracted away from the method of displaying the text to the user, and
> that when *executed* would actually generate the output.
>
> Thanks in advance.
>
> --
> Keith Willoughbyhttp://flat222.org/keith/
> War is peace
Maybe below migh give you some idea , if i understand your question
corecctly:
http://www.lispworks.com/documentation/lw445/CAPUG-W/html/capiuser-w-28.htm#pgfId-884465
http://www.lispworks.com/documentation/lw43/CAPUG-U/html/capiuser-u-97.htm