I've noticed that I'm regulary using AND & OR instead of IF in things
like
(defun add-staff (staff)
(or (staff-exists-p staff) (insert-staff staff))
which is prettier than
(defun add-staff (staff)
(if (not (staff-exists-p staff))
(insert-staff staff)
(staff-exists-p staff))) ; (*)
(*) Returning nil means success with me ,other return values are
signals for different kinds of errors
So I'm interested does Common Lisp standard *enforces* compatible
implementations to use short circuit implementation of logical AND &
OR? Or I should rather use IF?
Slobodan Blazeski
From: Edi Weitz
Subject: Re: What's standard says about implementation of AND & OR ?
Date:
Message-ID: <u645yy43l.fsf@agharta.de>
On Fri, 08 Jun 2007 13:15:15 -0000, fireblade <·················@gmail.com> wrote:
> So I'm interested does Common Lisp standard *enforces* compatible
> implementations to use short circuit implementation of logical AND &
> OR?
Why don't you look it up yourself?
http://www.lispworks.com/documentation/HyperSpec/Body/m_and.htm
http://www.lispworks.com/documentation/HyperSpec/Body/m_or.htm
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Jun 8, 3:21 pm, Edi Weitz <········@agharta.de> wrote:
> On Fri, 08 Jun 2007 13:15:15 -0000, fireblade <·················@gmail.com> wrote:
> > So I'm interested does Common Lisp standard *enforces* compatible
> > implementations to use short circuit implementation of logical AND &
> > OR?
>
> Why don't you look it up yourself?
>
> http://www.lispworks.com/documentation/HyperSpec/Body/m_and.htm
> http://www.lispworks.com/documentation/HyperSpec/Body/m_or.htm
>
> Edi.
>
> --
>
> Lisp is not dead, it just smells funny.
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
I've looked at lispworks hyperspec but I'm interested what's the
situation with other lisp implementations, I'm currently using only
lispworks under windows . I don't want any other dependencies besides
those from clsql, hunchentoot & cl-who.
Does writing code like above is considered bad style?
Slobodan Blazeski
In article <························@g4g2000hsf.googlegroups.com>,
fireblade <·················@gmail.com> wrote:
> On Jun 8, 3:21 pm, Edi Weitz <········@agharta.de> wrote:
> > On Fri, 08 Jun 2007 13:15:15 -0000, fireblade <·················@gmail.com> wrote:
> > > So I'm interested does Common Lisp standard *enforces* compatible
> > > implementations to use short circuit implementation of logical AND &
> > > OR?
> >
> > Why don't you look it up yourself?
> >
> > http://www.lispworks.com/documentation/HyperSpec/Body/m_and.htm
> > http://www.lispworks.com/documentation/HyperSpec/Body/m_or.htm
> >
> > Edi.
> >
> > --
> >
> > Lisp is not dead, it just smells funny.
> >
> > Real email: (replace (subseq ·········@agharta.de" 5) "edi")
>
> I've looked at lispworks hyperspec
You are aware that the 'lispworks hyperspec' is a HTML version directly
derived from the ANSI Common Lisp standard? The look and feel of the HyperSpec
may be special, but the content should be unchanged (more here:
http://www.lispworks.com/documentation/common-lisp.html ). There
is nothing LispWorks specific to the Hyperspec technical contents.
> but I'm interested what's the
> situation with other lisp implementations, I'm currently using only
> lispworks under windows . I don't want any other dependencies besides
> those from clsql, hunchentoot & cl-who.
>
> Does writing code like above is considered bad style?
>
>
> Slobodan Blazeski
--
http://lispm.dyndns.org
In article <························@q69g2000hsb.googlegroups.com>,
fireblade <·················@gmail.com> wrote:
> I've noticed that I'm regulary using AND & OR instead of IF in things
> like
>
> (defun add-staff (staff)
> (or (staff-exists-p staff) (insert-staff staff))
> which is prettier than
> (defun add-staff (staff)
> (if (not (staff-exists-p staff))
> (insert-staff staff)
> (staff-exists-p staff))) ; (*)
>
> (*) Returning nil means success with me ,other return values are
> signals for different kinds of errors
>
> So I'm interested does Common Lisp standard *enforces* compatible
> implementations to use short circuit implementation of logical AND &
> OR? Or I should rather use IF?
>
>
> Slobodan Blazeski
I'd write it differently:
* successful functions always return a useful object.
This allows a functional composition style
of programming.
* errors are either signalled by conditions
or via (VALUES NIL 'staff-already-exists) using
a second value for the error reason.
--
http://lispm.dyndns.org
fireblade <·················@gmail.com> writes:
> I've noticed that I'm regulary using AND & OR instead of IF in things
> like
>
> (defun add-staff (staff)
> (or (staff-exists-p staff) (insert-staff staff))
> which is prettier than
> (defun add-staff (staff)
> (if (not (staff-exists-p staff))
> (insert-staff staff)
> (staff-exists-p staff))) ; (*)
>
> (*) Returning nil means success with me ,other return values are
> signals for different kinds of errors
>
> So I'm interested does Common Lisp standard *enforces* compatible
> implementations to use short circuit implementation of logical AND &
> OR? Or I should rather use IF?
AND and OR are specified to do shortcut, so there's no need to convert
them to IF (it's done automatically by their macro).
On the other hand, in Common Lisp, we have a nice condition system so
you can forget about error codes.
(define-condition staff-error (error)
((operation :initarg :operation :accessor staff-error-operation)
(staff :initarg :staff :accessor staff-error-staff)
(reason :initarg :reason :accessor staff-error-reason)))
(defun insert-staff (staff)
(if (can-insert-staff-p)
(do-insert-staff staff)
(error 'staff-error :operation 'insert-staff
:staff staff
:reason "Cannot insert staff")))
So:
(handler-case (add-staff "new staff")
(staff-error (err)
(format *error-output* "Could not ~A ~A~%" (staff-error-operation err)
(staff-error-staff err)))
(error (err)
(do-what-should-be-done-in-case-of-other-errors err)))
prints:
Could not INSERT-STAFF new staff
returns:
NIL
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Jun 8, 3:31 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> fireblade <·················@gmail.com> writes:
> > I've noticed that I'm regulary using AND & OR instead of IF in things
> > like
>
> > (defun add-staff (staff)
> > (or (staff-exists-p staff) (insert-staff staff))
> > which is prettier than
> > (defun add-staff (staff)
> > (if (not (staff-exists-p staff))
> > (insert-staff staff)
> > (staff-exists-p staff))) ; (*)
>
> > (*) Returning nil means success with me ,other return values are
> > signals for different kinds of errors
>
> > So I'm interested does Common Lisp standard *enforces* compatible
> > implementations to use short circuit implementation of logical AND &
> > OR? Or I should rather use IF?
>
> AND and OR are specified to do shortcut, so there's no need to convert
> them to IF (it's done automatically by their macro).
>
> On the other hand, in Common Lisp, we have a nice condition system so
> you can forget about error codes.
>
> (define-condition staff-error (error)
> ((operation :initarg :operation :accessor staff-error-operation)
> (staff :initarg :staff :accessor staff-error-staff)
> (reason :initarg :reason :accessor staff-error-reason)))
>
> (defun insert-staff (staff)
> (if (can-insert-staff-p)
> (do-insert-staff staff)
> (error 'staff-error :operation 'insert-staff
> :staff staff
> :reason "Cannot insert staff")))
>
> So:
>
> (handler-case (add-staff "new staff")
> (staff-error (err)
> (format *error-output* "Could not ~A ~A~%" (staff-error-operation err)
> (staff-error-staff err)))
> (error (err)
> (do-what-should-be-done-in-case-of-other-errors err)))
>
> prints:
> Could not INSERT-STAFF new staff
>
> returns:
> NIL
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> NOTE: The most fundamental particles in this product are held
> together by a "gluing" force about which little is currently known
> and whose adhesive power can therefore not be permanently
> guaranteed.- Hide quoted text -
>
> - Show quoted text -
Ok, ok I get it. I was using low hack. MVP is handy but in my case it
will grow into a code clutter. I will rewrite the functions using the
condition system.
Slobodan Blazeski
Damn Lispers, they want everything to be perfect. Avoid global
variables,avoid assignment, use functional decomposition, write
bugfree code, don't optimize prematurely,blah blah blah.
Why didn't I learned Java when I had a chance, now I hate OOP? :(