What makes different things lispy or unlispy?
Dmitry Dzhus
What makes you consider something lispy or unlispy?
What is the spirit of Lisp?
Recently a Lisp hacker called my code un-lispy and that left me
questioning why.
The problem was that I pulled some sort of C-like notation to address
recursive data structures into Lisp land by writing a function which
acts as follows:
(get-field basket ".apples[0].taste")
=>
delicious
Where `basket` is:
(setq basket '((apples . (((color . green)
(taste . delicious))
((color . red)
(taste . disgusting))))))
I didn't fully like this notation myself, but I thought that it's good
because it's short and compact.
Would this function be more lispy if it was written to work this way:
(get-field basket 'apples 0 'taste)
=>
delicious
?
I've been playing with Lisp for nearly two years know, but the further
I learn, the more confused about the answer to my question I get.
I think that lispy means living and flexible. Another (funny)
interpretations include unlispy meaning having not enought parentheses
(I think this one is Siebel's).
I relied on strings in my code, and it looks like that it lowered
lispyness of my program. As Perlis once said, strings are stark. What
may this mean in the context of Lisp?
Let me know what you think about all this.
--
Happy Hacking.
Dimiter "malkia" Stanev
> Hi lispers!
>
> What makes you consider something lispy or unlispy?
>
> What is the spirit of Lisp?
>
> Recently a Lisp hacker called my code un-lispy and that left me
> questioning why.
>
> The problem was that I pulled some sort of C-like notation to address
> recursive data structures into Lisp land by writing a function which
> acts as follows:
>
> (get-field basket ".apples[0].taste")
> =>
> delicious
I think it's lispy, especially if get-field is a macro that expands your
little ".apples[0].taste" DSL into:
(cdr (assoc 'taste (nth 0 (cdar basket))))
> Where `basket` is:
>
> (setq basket '((apples . (((color . green)
> (taste . delicious))
> ((color . red)
> (taste . disgusting))))))
>
This can hardly be made efficient in many other languages (e.g. it would
require some kind of code-generation mid-step, and recompilation).
Unless you are a boostafarian! Then you could do anything in C++!
Cheers,
Dimiter "malkia" Stanev.
Dimiter "malkia" Stanev
> Dmitry Dzhus wrote:
>> Hi lispers!
>>
>> What makes you consider something lispy or unlispy?
>>
>> What is the spirit of Lisp?
>>
>> Recently a Lisp hacker called my code un-lispy and that left me
>> questioning why.
>>
>> The problem was that I pulled some sort of C-like notation to address
>> recursive data structures into Lisp land by writing a function which
>> acts as follows:
>>
>> (get-field basket ".apples[0].taste")
>> =>
>> delicious
>
> I think it's lispy, especially if get-field is a macro that expands your
> little ".apples[0].taste" DSL into:
>
> (cdr (assoc 'taste (nth 0 (cdar basket))))
Hah.. Too hasty! That should read:
(cdr (assoc 'taste (nth 0 (cdr (assoc 'apples basket)))))
Chris Riesbeck
> Hi lispers!
>
> What makes you consider something lispy or unlispy?
>
> What is the spirit of Lisp?
>
> Recently a Lisp hacker called my code un-lispy and that left me
> questioning why.
>
> The problem was that I pulled some sort of C-like notation to address
> recursive data structures into Lisp land by writing a function which
> acts as follows:
>
> (get-field basket ".apples[0].taste")
> =>
> delicious
>
> Where `basket` is:
>
> (setq basket '((apples . (((color . green)
> (taste . delicious))
> ((color . red)
> (taste . disgusting))))))
>
> I didn't fully like this notation myself, but I thought that it's good
> because it's short and compact.
Getting a handle on "lispy" is like trying to get a handle on what a
"game" is. The hacker was probably focusing on the construction of a
C-like mini-language for accessing fields. That means you have to write
a parser for period and brackets. Why not use Lisp lists, which are
compact equivalent to the parse tree such a parser produces?
>
> Would this function be more lispy if it was written to work this way:
>
> (get-field basket 'apples 0 'taste)
> =>
> delicious
That's a more typical approach. Note that it's just as compact to use,
much simpler to implement, and easily generalized. You might want to use
keyword symbols, i.e.,
(get-field basket :apples 0 :taste)
to avoid package problems.
>
> ?
>
> I've been playing with Lisp for nearly two years know, but the further
> I learn, the more confused about the answer to my question I get.
>
> I think that lispy means living and flexible.
Your second solution is more flexible. It leaves open the possibility of
more complex non-atomic forms for XPath-like queries on the tree structure.
> Another (funny)
> interpretations include unlispy meaning having not enought parentheses
> (I think this one is Siebel's).
Note that your second solution has the same number of parentheses.
Introducing XPath-like facilities would add nested parens, but the
string approach would require adding a lot more punctuation, and a much
more complicated parser.
>
> I relied on strings in my code, and it looks like that it lowered
> lispyness of my program. As Perlis once said, strings are stark. What
> may this mean in the context of Lisp?
The second part of Perlis' quote is key: "everywhere it is passed there
is much duplication of process" -- that parser for ".apples[0].taste"
you had to write is the process duplication he meant.
Duncan
> What makes you consider something lispy or unlispy?
That's a hard question. Lots of people have lots of ideas about that. To
me lispiness is about bottom-up programming. So that's what I think-
Bottom-up development is the lispiest thing around.
Pascal J. Bourguignon
> Hi lispers!
>
> What makes you consider something lispy or unlispy?
>
> What is the spirit of Lisp?
>
> Recently a Lisp hacker called my code un-lispy and that left me
> questioning why.
>
> The problem was that I pulled some sort of C-like notation to address
> recursive data structures into Lisp land by writing a function which
> acts as follows:
>
> (get-field basket ".apples[0].taste")
> =>
> delicious
>
> Where `basket` is:
>
> (setq basket '((apples . (((color . green)
> (taste . delicious))
> ((color . red)
> (taste . disgusting))))))
>
> I didn't fully like this notation myself, but I thought that it's good
> because it's short and compact.
>
> Would this function be more lispy if it was written to work this way:
>
> (get-field basket 'apples 0 'taste)
> =>
> delicious
>
> ?
Basically, the difference is that strings are pure data. They are
less code than s-exps.
There's a whole category of s-exps, called forms, which are both code
and data. You just need to pass them to EVAL or to return them from a
macro to switch from data to code.
Unfortunately, for strings, it's more complex, you have to parse them
first, and generate the corresponding form.
Now, this parsing wouldn't be too much of a problem, if it weren't for
the macros. Macros take some data, and must produce some data, that
will be then interpreted by the system as code.
The problem with strings is that you're in danger of code injection.
Assume I write a macro (insert-index ".apples[" index "].taste") whose
purpose is build a 'form' with the index evalualted and inserted. If
the index evaluates to a string such as "0];shell(\"rm -rf /\");x",
instead of a number you may well generate:
".apples[0];shell(\"rm -rf /\");x.taste" [*]
With s-exp based macros, and the parentheses, that is, the fact that
macros actually manipulate a tree that is scoped to itself, you cannot
generate but a single s-exp. There's now to slice a tree in two and
to insert a rogue one in the middle, so you can control the whole
environment of the sub-s-exps you insert in your s-exp.
And besides, thanks to backquote and comma, and all the lisp and tree
manipulating functions provided by lisp, it's easier to manipulate
s-exps than strings.
There are whole PhD theses being written about code injection in
string based processing, and searching tricks to avoid them.
Totally useless when you have s-exps...
[*] It could be worse than `rm -rf /`. It could be something sending
you to jail. Ask that poor perl programmer:
http://yro.slashdot.org/article.pl?sid=01/03/13/208259
--
__Pascal Bourguignon__
Rob Warnock
+---------------
| The problem with strings is that you're in danger of code injection.
| Assume I write a macro (insert-index ".apples[" index "].taste") whose
| purpose is build a 'form' with the index evalualted and inserted. If
| the index evaluates to a string such as "0];shell(\"rm -rf /\");x",
| instead of a number you may well generate:
|
| ".apples[0];shell(\"rm -rf /\");x.taste" [*]
Ahhh yezzz... And let us never forget Little Bobby Tables:
http://xkcd.com/327/
Exploits of a Mom
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Keith H Duggar
wrote:
> The problem with strings is that you're in danger of code injection.
> Assume I write a macro (insert-index ".apples[" index "].taste") whose
> purpose is build a 'form' with the index evalualted and inserted. If
> the index evaluates to a string such as "0];shell(\"rm -rf /\");x",
> instead of a number you may well generate:
>
> ".apples[0];shell(\"rm -rf /\");x.taste" [*]
>
> With s-exp based macros, and the parentheses, that is, the fact that
> macros actually manipulate a tree that is scoped to itself, you cannot
> generate but a single s-exp.
Please show the equivalent Lisp macro you have in mind
that would prevent the problem you demonstrated above.
KHD
Vassil Nikolov
Here is a much simpler example. Let's say we want to handle version
numbers having the popular structure of <major>, <minor>, and
<patch level>, and let's also say we live in the paradise where
<major> is incremented if and only if there is an incompatible change,
otherwise <minor> is incremented if and only if there is a functional
change, otherwise only bug fixes were done and <patch level> alone is
incremented. Then "handle version numbers" might include trying to
compute the consequences for our program when upgrading some subset
of its quarter of a zillion library dependencies.
I submit that one lispy way of representing [*] such a version number
would be as (<major> <minor> <patch level>), a list of three integers,
where in other environments a string might be used having the syntax
of "<major>.<minor>.<patch level>" or perhaps an assumption will be
made that neither <major> nor <minor> or <patch level> will ever be
greater than 99999 and a 53-bit-significand floating-point number
might be used, computed as <major> + <minor>/1e5 + <patch level>/1e10.
_________
[*] internally, without prejudice to any interchange format
---Vassil.
--
Vassil Nikolov <vnik...@pobox.com>
(1) M(Gauss);
(2) M(a) if M(b) and declared(b, M(a)),
where M(x) := "x is a mathematician".
Rob Warnock
+---------------
| I submit that one lispy way of representing [*] such a version number
| would be as (<major> <minor> <patch level>), a list of three integers,
| where in other environments a string might be used having the syntax
| of "<major>.<minor>.<patch level>" or perhaps an assumption will be
| made that neither <major> nor <minor> or <patch level> will ever be
| greater than 99999 and a 53-bit-significand floating-point number
| might be used, computed as <major> + <minor>/1e5 + <patch level>/1e10.
It's that "assumption...that neither <major> nor <minor> or <patch level>
will ever be greater than 99999" that makes the last variant "non-Lispy".
Now if you'd said to encode them this way: ;-} ;-}
(* (expt 2 major) (expt 3 minor) (expt 5 patch-level))
[Hint: Decoding is "easily" done using the Prime Factoring Theorem...]
Dimiter "malkia" Stanev
> Here is a much simpler example. Let's say we want to handle version
> numbers having the popular structure of <major>, <minor>, and
> <patch level>, and let's also say we live in the paradise where
> <major> is incremented if and only if there is an incompatible change,
> otherwise <minor> is incremented if and only if there is a functional
> change, otherwise only bug fixes were done and <patch level> alone is
> incremented. Then "handle version numbers" might include trying to
> compute the consequences for our program when upgrading some subset
> of its quarter of a zillion library dependencies.
>
> I submit that one lispy way of representing [*] such a version number
> would be as (<major> <minor> <patch level>), a list of three integers,
> where in other environments a string might be used having the syntax
> of "<major>.<minor>.<patch level>" or perhaps an assumption will be
> made that neither <major> nor <minor> or <patch level> will ever be
> greater than 99999 and a 53-bit-significand floating-point number
> might be used, computed as <major> + <minor>/1e5 + <patch level>/1e10.
>
> _________
> [*] internally, without prejudice to any interchange format
>
> ---Vassil.
>
>
Or as G�del number - no limitations, just enough memory to hold your bignum.
Marco Antoniotti
> Vassil Nikolov <vniko...@pobox.com> wrote:
> +---------------
> | I submit that one lispy way of representing [*] such a version number
> | would be as (<major> <minor> <patch level>), a list of three integers,
> | where in other environments a string might be used having the syntax
> | of "<major>.<minor>.<patch level>" or perhaps an assumption will be
> | made that neither <major> nor <minor> or <patch level> will ever be
> | greater than 99999 and a 53-bit-significand floating-point number
> | might be used, computed as <major> + <minor>/1e5 + <patch level>/1e10.
> +---------------
>
> It's that "assumption...that neither <major> nor <minor> or <patch level>
> will ever be greater than 99999" that makes the last variant "non-Lispy".
>
> Now if you'd said to encode them this way: ;-} ;-}
>
> (* (expt 2 major) (expt 3 minor) (expt 5 patch-level))
>
> [Hint: Decoding is "easily" done using the Prime Factoring Theorem...]
>
Yep. But then either your version numbers are unsound or
incomplete. :)
Cheers
--
Marco
Nicolas Neuss
> Ahhh yezzz... And let us never forget Little Bobby Tables:
>
> http://xkcd.com/327/
> Exploits of a Mom
Wonderful!
A maybe stupid question: How safe am I against something like this as a
rather naive administrator of a webserver which uses CLSQL in the
background?
Nicolas
Vassil Nikolov
On Thu, 25 Jun 2009 23:46:07 -0500, rp...@rpw3.org (Rob Warnock) said:
> Vassil Nikolov <vnik...@pobox.com> wrote:
> +---------------
> | I submit that one lispy way of representing [*] such a version number
> | would be as (<major> <minor> <patch level>), a list of three integers,
> | where in other environments a string might be used having the syntax
^^^^^^^^^^^^^^^^^^^^^
> | of "<major>.<minor>.<patch level>" or perhaps an assumption will be
> | made that neither <major> nor <minor> or <patch level> will ever be
> | greater than 99999 and a 53-bit-significand floating-point number
> | might be used, computed as <major> + <minor>/1e5 + <patch level>/1e10.
> +---------------
> It's that "assumption...that neither <major> nor <minor> or <patch level>
> will ever be greater than 99999" that makes the last variant "non-Lispy".
It is certainly non-lispy, both for this reason and for using an
atom, and I gave it as a contrasting non-lispy example; I should
have written "in other, non-Lisp environments" above.
^^^^^^^^
---Vassil.
P.S. Analyzing a representation of version numbers (perhaps with
build numbers included) as quaternions, and so modelling library
upgrades as operators on rotations, is left as an exercise...
Rob Warnock
+---------------
CLSQL isn't a problem per se; the problem is front-end web applications
that don't correctly validate and/or escape their client-supplied inputs.
In the XKCD example, the malicious input was:
Robert'); DROP TABLE Students; --
so simply SQL-escaping the input correctly would have probably
avoided the problem:
Robert''); DROP TABLE Students; --
though a more thorough check for questionable characters/sequences
would probably be a good idea.
But to answer your *real* question[1], you're screwed unless you can get
your management to fund real[2] code reviews of all the front-end web
applications that run on your server to make sure that nothing like the
above can sneak onto your server. (Sorry.)
That's one of the problems open-source code has created for us all:
there's *gobs* of free PHP, phpBB, phorm.php (PHPmail), etc., code
available out there for free, and you can't blame your users for trying
to save time by just grabbing huge hunks of it, dropping it on your
server, and whacking it as fast as possible into doing approximately
whatever their boss asked them to do on a ridiculous schedule. The
problem is that so much of the open-source code has these teensy little
security vulnerabilities the bad guys can drive a truck through, and
*you* don't have time to read it all before you allow it on your system!
Think I'm kidding? Why, just this week...
http://isc.sans.org/diary.html?storyid=6649
PHPMYADMIN scans
Published: 2009-06-26,
Last Updated: 2009-06-26 00:28:03 UTC
by Mark Hofman (Version: 1)
http://isc.sans.org/diary.html?storyid=6634
Exploit tools are publicly available for phpMyAdmin
Published: 2009-06-24,
Last Updated: 2009-06-24 16:42:44 UTC
by Kyle Haugsness (Version: 1)
http://isc.sans.org/diary.html?storyid=6619
phpMyAdmin Scans
Published: 2009-06-21,
Last Updated: 2009-06-23 12:47:11 UTC
by Scott Fendley (Version: 2)
-Rob
[1] Which I also face myself as a part-time volunteer sysadmin for a
non-profit web site with lots of part-time volunteer PHP coders.
[Problem: I don't know PHP! (*Ouch!*)]
[2] "Real" as in competent programmers in the language(s) in question
actually reading & understanding other peoples' code, and who
are rewarded for finding something substantive *wrong* with it.
[As opposed to the check-off, feel-good shams that "code reviews"
so often are these days.]
Robert Uhl
It all boils down to making sure that you're properly submitting SQL.
In that comic, there's a problem because the SQL query string is
generated with something like:
(concatenate 'string
"insert into students (name) values ('"
"Robert'); drop table students;--"
"');")
You can see that the string submitted to the database is:
insert into students (name) values ('Robert'); drop table students;--');
And I think you can see why that's not good.
As long as you're using CLSQL's symbolic SQL expressions, and as long as
CLSQL isn't buggy (I trust it), then you're safe.
If you're constructing SQL strings by hand, you could use CLSQL:SQL to
ensure that your strings are properly escaped:
cl-user> (clsql:sql "Robert'); delete table students;--")
"'Robert''); delete table students;--'"
You could use it like this:
(concatenate 'string
;; note that CLSQL:SQL includes the quotes, so we don't need to
"insert into students (name) values ("
(clsql:sql "Robert'); drop table students;--")
");")
And as you can see the generated SQL in this case is just fine:
insert into students (name) values ('Robert''); drop table students;--');
Although IMHO generating SQL strings by hand like that is a pretty good
sign that you're doing something wrong.
--
Robert Uhl <http://public.xdi.org/=ruhl>
You cannot kiss a girl unexpectedly--only sooner than she thought you would.
--Unknown
Pascal J. Bourguignon
Sorry, I've not been clear enough.
It's not the rm -rf / which is prevented by s-exp based macros, it's
the splitting of one form into several.
(defmacro m (subform)
`(progn
(print 'before)
,subform
(print 'after)))
(m ...) you may try whatever you want, you will never have m return
two distinct forms.
(if cond
(m ...))
There's no way to create an 'else' branch for that if.
--
__Pascal Bourguignon__
Nicolas Neuss
> As long as you're using CLSQL's symbolic SQL expressions, and as long as
> CLSQL isn't buggy (I trust it), then you're safe.
Thanks, that was what I wanted to know. I use the symbolic SQL
expressions, so - I hope to be safe.
Nicolas
P.S.: This web app is a management system for courses at our institute
which works very well and saves us a lot of work. Edi helped me getting
started with it about two years ago.
Robert Uhl
>
> P.S.: This web app is a management system for courses at our institute
> which works very well and saves us a lot of work. Edi helped me
> getting started with it about two years ago.
Sounds useful & interesting...since you mention Dr. Weitz I'm assuming
it's running atop Hunchentoot. How's that working out for you?
I've got a little site with beer tasting notes at
<http://octopodial-chrome.com/tasting-notes/> which is built on
Hunchentoot, CLSQL & Cl-WHO. Unfortunately it hasn't been updated in a
year and a half...
--
Robert Uhl <http://public.xdi.org/=ruhl>
Sometimes, I think the French were put on earth for no other reason than
to give Germany an over-inflated sense of their military prowess. Other
times, I can't come up with any reason at all. --Burt Prelutsky
Nicolas Neuss
> That's one of the problems open-source code has created for us all:
> there's *gobs* of free PHP, phpBB, phorm.php (PHPmail), etc., code
> available out there for free, and you can't blame your users for trying
> to save time by just grabbing huge hunks of it, dropping it on your
> server, and whacking it as fast as possible into doing approximately
> whatever their boss asked them to do on a ridiculous schedule. The
> problem is that so much of the open-source code has these teensy little
> security vulnerabilities the bad guys can drive a truck through, and
> *you* don't have time to read it all before you allow it on your system!
Yes, I was also sceptical about this, and have at the moment only Mailman
and Hunchentoot running on my server (behind Apache2).
Thanks,
Nicolas
Nicolas Neuss
> Nicolas Neuss <last...@math.uni-karlsruhe.de> writes:
>>
>> P.S.: This web app is a management system for courses at our institute
>> which works very well and saves us a lot of work. Edi helped me getting
>> started with it about two years ago.
>
> Sounds useful & interesting...since you mention Dr. Weitz I'm assuming
> it's running atop Hunchentoot. How's that working out for you?
I am using the old version of Hunchtentoot (pre-1.0), and I have no
complaints. However, I also cannot really compare to other possibilities.
> I've got a little site with beer tasting notes at
> <http://octopodial-chrome.com/tasting-notes/> which is built on
> Hunchentoot, CLSQL & Cl-WHO. Unfortunately it hasn't been updated in a
> year and a half...
You have stopped drinking beer? :-)
Nicolas
Robert Uhl
>
> I am using the old version of Hunchtentoot (pre-1.0), and I have no
> complaints. However, I also cannot really compare to other
> possibilities.
I upgraded to the latest version when I started packaging it for
Fedora...it was actually a pretty quick change. The only thing I miss
is being able to specify dispatch tables on a per-server basis. No
doubt there's some way to do this that I haven't noticed yet...it was
just a quick-and-dirty fix.
>> I've got a little site with beer tasting notes at
>> <http://octopodial-chrome.com/tasting-notes/> which is built on
>> Hunchentoot, CLSQL & Cl-WHO. Unfortunately it hasn't been updated in a
>> year and a half...
>
> You have stopped drinking beer? :-)
Too lazy to update it, mostly. I keep on meaning to add a web interface
to edit the DB, but life has been hectic. You know how it goes!
--
Robert Uhl <http://public.xdi.org/=ruhl>
Liberty, equality, diversity. Pick any two. --Peter H. Coffin
Rob Warnock
| > That's one of the problems open-source code has created for us all:
| > there's *gobs* of free PHP, phpBB, phorm.php (PHPmail), etc., code
...
| Yes, I was also sceptical about this, and have at the moment only
| Mailman and Hunchentoot running on my server (behind Apache2).
Heh! "Only Mailman" isn't necessarily reassuring. ;-} ;-}
Depending on which version you're using & how old
it is, you might want to do a web search for:
Mailman security vulnerability 2009
and then prepare to update! ;-}
Especially if you're using "Kjtechforce mailman beta1", see
CVE-2009-2164 (2009-06-22, updated 2009-06-23).
Also CVE-2008-0564 (2008-03-15), with Mailman prior to version 2.1.10b1.
And others, see <http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mailman>.
(Sorry.)
-Rob
Robert Uhl
> Heh! "Only Mailman" isn't necessarily reassuring. ;-} ;-}
No, it's certainly not:
http://www.jwz.org/doc/mailman.html
And yet over the last few weeks I've discovered that almost every Lisp
library uses a Mailman list...
--
Robert Uhl <http://public.xdi.org/=ruhl>
It's time we went and built a society for ourselves where
sunrise==bedtime. I think we've got our best shot someplace like Las
Vegas. --Mike Sphar
Nicolas Neuss
> Nicolas Neuss <last...@math.uni-karlsruhe.de> wrote:
> +---------------
> | rp...@rpw3.org (Rob Warnock) writes:
> | > That's one of the problems open-source code has created for us all:
> | > there's *gobs* of free PHP, phpBB, phorm.php (PHPmail), etc., code
> | > available out there for free, ...
> ...
> | Yes, I was also sceptical about this, and have at the moment only
> | Mailman and Hunchentoot running on my server (behind Apache2).
> +---------------
>
> Heh! "Only Mailman" isn't necessarily reassuring. ;-} ;-}
> [...explanations...]
I was afraid you'd say something like that. However, I need it because I
allow an optional mailing list for each course I administrate which is very
important. OTOH, I have also thought about dropping the Mailman dependency
in favor of a more low-level solution, because as much as I see it, neither
me nor the students do use much of its functionality. For such a low-level
solution I would need as the bare minimum:
* Mails directed to "course-XX@server" should be mailed to all students in
course-XX (I have their emails in my database anyhow).
* For avoiding spam, mails to "course-XX"-Addresses coming from Email
addresses not in the database should be discarded.
I would be really interested in how the experts here would tackle this.
[At the moment, I am using exim4 as mail transfer agent, but using sendmail
or something else instead would also be no problem (maybe there is even a
CL MTA?).]
Nicolas
Wade
is not very Lispy
(get-field basket 'apples 0 'taste)
is more Lispy
(defvar basket '((apples . (((color . green)
(taste . delicious))
((color . red)
(taste . disgusting))))))
(defmacro defpaccessor (name)
`(defun ,name (alist)
(cdr (assoc ',name alist))))
(defpaccessor apples)
(defpaccessor color)
(defpaccessor taste)
CL-USER> (taste (first (apples basket)))
DELICIOUS
CL-USER> (mapcar 'taste (apples basket))
(DELICIOUS DISGUSTING)
CL-USER> (taste (third (apples basket)))
NIL
Is Lispiest.
Reason:
Using STRINGS in Lisp code to write code is not Lispy.
This includes things like FORMAT and CL-PPCRE (regex
strings (though it does have an alternative sexp
syntax)). The motivation behind them is brevity and to
a lesser extent expressibility. However the original
Lisp s-expression syntax was to allow programmers
to communicate the deep structure of the program to
other programmers. Mini languages put a learning
overhead on the reader and in the end the meaning
of the expression has to be effectively "compiled"
by the human and machine into a tree (list) structure.
S-expressions were the preferred way. (That's why
lisps which try alternate structures never quite
catch-on). Lisp does not try to hide the structure
of the program, it should meet some WYSIWYG
requirements. Humans should be able to read
the program.
Wade
Nicolas Neuss
> [...] For such a low-level solution I would need as the bare minimum:
>
> * Mails directed to "course-XX@server" should be mailed to all students in
> course-XX (I have their emails in my database anyhow).
>
> * For avoiding spam, mails to "course-XX"-Addresses coming from Email
> addresses not in the database should be discarded.
>
> I would be really interested in how the experts here would tackle this.
> [At the moment, I am using exim4 as mail transfer agent, but using sendmail
> or something else instead would also be no problem (maybe there is even a
> CL MTA?).]
Googling more carefully I just found
<http://wcp.sdf-eu.org/software/smta.lisp>.
Nicolas
Vsevolod Dyomkin
> Hi lispers!
>
> What makes you consider something lispy or unlispy?
>
> What is the spirit of Lisp?
>
> Recently a Lisp hacker called my code un-lispy and that left me
> questioning why.
>
> The problem was that I pulled some sort of C-like notation to address
> recursive data structures into Lisp land by writing a function which
> acts as follows:
>
> delicious
>
> Where `basket` is:
>
> (taste . delicious))
> ((color . red)
> (taste . disgusting))))))
>
> because it's short and compact.
>
> Would this function be more lispy if it was written to work this way:
>
> delicious
>
> ?
>
> I've been playing with Lisp for nearly two years know, but the further
> I learn, the more confused about the answer to my question I get.
>
> interpretations include unlispy meaning having not enought parentheses
> (I think this one is Siebel's).
>
> lispyness of my program. As Perlis once said, strings are stark. What
> may this mean in the context of Lisp?
>
> Happy Hacking.
>
> http://sphinx.net.ru
> む
There's a good rant by late Erik Naggum, which can shed a little light
on what's lispy (in comparison to other approaches, in this case --
the Unix one)
Best regards,
Vsevolod Dyomkin
Vsevolod Dyomkin
and the link was: http://groups.google.com/group/comp.lang.lisp/msg/7c588cdb91a10d4d
Ashanti Larson
✅▶️▶️ CLICK HERE Full HD✅720p✅1080p✅4K✅
WATCH ✅💻📺📱👉https://co.fastmovies.org
ᗪOᗯᑎᒪOᗩᗪ ✅📺📱💻👉https://co.fastmovies.org
🔴WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>HERE>👉https://co.fastmovies.org
✅WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>HERE>👉https://co.fastmovies.org
💚WATCH>>ᗪOᗯᑎᒪOᗩᗪ>>HERE>👉https://co.fastmovies.org
🔴ALL>Movies>ALL>TIME>Save>LINK👉https://co.fastmovies.org
🔴ALL>Movies>ALL>TIME>Save>LINK👉https://co.fastmovies.org
🔴💻ALL>Movies>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org
🔴📱ALL>Movies>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org
🔴📺ALL>Movies>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org
🔴📺ALL>Movies>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org
🔴✅📺📱💻ALL>Movies>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org
🔴✅📺📱💻ALL>Movies>WATCH>ᗪOᗯᑎᒪOᗩᗪ>LINK>👉https://co.fastmovies.org