Hi,
- I am trying to insert a newline in a string:
(defun sql-expand-matchcol-matchval (c v begin)
(if (null v)
";"
(if (equal begin 1)
(concatenate 'string " " c " = '" (first v) "'"
(sql-expand-matchcol-matchval c (rest v) 'n))
(concatenate 'string "#\newline or " c " = '" (first v) "'"
(sql-expand-matchcol-matchval c (rest v) 0)))))
(sql-expand-matchcol-matchval "mycol" '("a" "b" "c") 1)
>
" mycol = 'a'#newline or mycol = 'b'#newline or mycol = 'c';"
And it doesn't work...Any ideas?
I 've got a more general question:
What should be the maximum number of lines for a lisp function to be
"clean".
If a function has 500 lines, there is obviously a problem as it could
be simplified. What do you think is the optimal length?
Thanks
From: Erik Naggum
Subject: Re: newline and concatenate. length of a lisp function.
Date:
Message-ID: <3205061214248143@naggum.net>
* ·········@netscape.net (Delaregue)
> (concatenate 'string "#\newline or " c " = '" (first v) "'"
:
> And it doesn't work...Any ideas?
Why do you believe that the characters "#\newline" in a string produces
anything other than the characters "#newline"?
> What should be the maximum number of lines for a lisp function to be
> "clean".
At least one less than would make it "unclean", which also needs defining.
> If a function has 500 lines, there is obviously a problem as it could be
> simplified. What do you think is the optimal length?
The length at which its author stops worrying about its length.
Strive, if you must, to make things as small as possible, but not smaller.
#:Erik
--
There is nothing in this message that under normal circumstances should
cause Barry Margolin to announce his moral superiority over others, but
one never knows how he needs to behave to maintain his belief in it.
From: ·······@inetmi.com
Subject: Re: newline and concatenate. length of a lisp function.
Date:
Message-ID: <ud76og995.fsf@chicago.inetmi.com>
Erik Naggum <····@naggum.net> writes:
> > If a function has 500 lines, there is obviously a problem as it
> > could be simplified. What do you think is the optimal length?
>
> The length at which its author stops worrying about its length.
>
> Strive, if you must, to make things as small as possible, but not
> smaller.
There is a function in Franz' open source XML parser that is over
2,200 lines long. I wouldn't be surprised if that was exactly the
size it needs to be.
John Wiseman
<·······@inetmi.com> wrote in message
··················@chicago.inetmi.com...
> There is a function in Franz' open source XML parser that is over
> 2,200 lines long. I wouldn't be surprised if that was exactly the
> size it needs to be.
>
While admittedly I don't quite know *everything* (but plan to by 2002)....
I can not for the life of me imagine _any_ good reason to have one function
of such length! Or any class of problem that would require that....
(with the notable exception of code that was written by other
code...hopefully lots of concise and well focused methods of much shorter
length!)
Can anyone else??
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
From: Erik Naggum
Subject: Re: newline and concatenate. length of a lisp function.
Date:
Message-ID: <3205086696355384@naggum.net>
* "Coby Beck" <·····@mercury.bc.ca>
> While admittedly I don't quite know *everything* (but plan to by 2002)....
>
> I can not for the life of me imagine _any_ good reason to have one function
> of such length! Or any class of problem that would require that....
Come back when you have tried to figure out how best to parse SGML and
XML. Since you have not been very kind to me, let me assure that you
_need_ to know thees things and should not consider the pain you suffer
to be a good indication to stop. So go be good at XML! :)
Essentially, state machines are best implemented in huge tagbody's.
Trying to break them up into little "modular" pieces causes much more
code and much less efficiency. Also, each state, labeled by a tag, _is_
a little module, but the way it has been expressed is different from the
function-level modularization that is hailed as universally better by
people who lack experience from real life.
#:Erik
--
There is nothing in this message that under normal circumstances should
cause Barry Margolin to announce his moral superiority over others, but
one never knows how he needs to behave to maintain his belief in it.
In article <················@naggum.net>, Erik Naggum wrote:
>* "Coby Beck" <·····@mercury.bc.ca>
>> While admittedly I don't quite know *everything* (but plan to by 2002)....
>>
>> I can not for the life of me imagine _any_ good reason to have one function
>> of such length! Or any class of problem that would require that....
>
> Come back when you have tried to figure out how best to parse SGML and
> XML. Since you have not been very kind to me, let me assure that you
> _need_ to know thees things and should not consider the pain you suffer
> to be a good indication to stop. So go be good at XML! :)
>
> Essentially, state machines are best implemented in huge tagbody's.
> Trying to break them up into little "modular" pieces causes much more
> code and much less efficiency. Also, each state, labeled by a tag, _is_
> a little module, but the way it has been expressed is different from the
> function-level modularization that is hailed as universally better by
> people who lack experience from real life.
If you write a 2000 line compound statement with goto labels by hand
in any language, you are wrong. You should have written a program
to *generate* that. ;)
···@ashi.footprints.net (Kaz Kylheku) writes:
> In article <················@naggum.net>, Erik Naggum wrote:
> >* "Coby Beck" <·····@mercury.bc.ca>
> >> While admittedly I don't quite know *everything* (but plan to by 2002)....
> >>
> >> I can not for the life of me imagine _any_ good reason to have one function
> >> of such length! Or any class of problem that would require that....
[ ... ]
> > Essentially, state machines are best implemented in huge tagbody's.
> > Trying to break them up into little "modular" pieces causes much more
> > code and much less efficiency. Also, each state, labeled by a tag, _is_
> > a little module, but the way it has been expressed is different from the
> > function-level modularization that is hailed as universally better by
> > people who lack experience from real life.
>
> If you write a 2000 line compound statement with goto labels by hand
> in any language, you are wrong. You should have written a program
> to *generate* that. ;)
Nonsense. One should use the abstraction that most naturally
represents the problem. Writing a 2000 line tagbody purely for speed
is insanity. When it's the best representation of the problem, it's
the best way to write it -- inventing abstractions that don't buy you
any benefit aside from fulfilling an emotional avoidance of goto's, is
counterproductive. Just because one *can* write spaghetti code with
tagbodies, doesn't mean it's bound to happen; one can spaghetti code
using any abstraction.
I suppose you could maybe implement a state machine using DEFSTATE and
DEFINE-STATE-MACHINE macros, but I don't know that that would be any
clearer.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I suppose you could maybe implement a state machine using DEFSTATE and
> DEFINE-STATE-MACHINE macros, but I don't know that that would be any
> clearer.
In general, having done quite a bit of the above
(cfr. http://www.path.berkeley.edu/shift) I would advise to look first
into some more advanced FSA languages like Esterel
(http://www.esterel.org).
Just think what Regular Expressions really are: a concise shorthand
for Automata.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Arseny Slobodjuck
Subject: Re: newline and concatenate. length of a lisp function.
Date:
Message-ID: <3b614d05.6133669@news.vtc.ru>
On 25 Jul 2001 16:05:16 -0700, ···@conquest.OCF.Berkeley.EDU (Thomas
F. Burdick) wrote:
>I suppose you could maybe implement a state machine using DEFSTATE and
>DEFINE-STATE-MACHINE macros, but I don't know that that would be any
>clearer.
What language do you using ? I 've been astonished at first - "how
small do I know about CL!".
From: Frank A. Adrian
Subject: Re: newline and concatenate. length of a lisp function.
Date:
Message-ID: <3B6636CA.FFC4C2FB@qwest.net>
"Thomas F. Burdick" wrote:
> I suppose you could maybe implement a state machine using DEFSTATE and
> DEFINE-STATE-MACHINE macros, but I don't know that that would be any
> clearer.
But it might make the code a bit more readable and navigable. I would
still tend to think that a 2200 LoC Lisp function is bordering on the
edge of maintainability and understandability, but then I am also
hesitant to introduce code generation infrastructure into a project
where it was only used once, unless I knew of other places where such an
abstraction came in handy. I guess I've been brain-damaged by systems
that managed to do OK with modules much shorter than this.
In the end, I probably would write an NDFSA -> DFSA -> State Machine
generator, but for appropriate reasons: first, because I am a
self-indulgent programmer who would like to try my hand at writing this
sort of thing :-); second, because I could think of a lot of other uses
for an FSA generation system.
faa
"Frank A. Adrian" <·······@qwest.net> writes:
> "Thomas F. Burdick" wrote:
>
> > I suppose you could maybe implement a state machine using DEFSTATE and
> > DEFINE-STATE-MACHINE macros, but I don't know that that would be any
> > clearer.
>
> But it might make the code a bit more readable and navigable. I would
> still tend to think that a 2200 LoC Lisp function is bordering on the
> edge of maintainability and understandability, but then I am also
> hesitant to introduce code generation infrastructure into a project
> where it was only used once, unless I knew of other places where such an
> abstraction came in handy. I guess I've been brain-damaged by systems
> that managed to do OK with modules much shorter than this.
The point is that the 2k line function is not the granularity of the
problem as broken up into modules. The top-level (in the function)
tags are. The abstraction is states, not functions. So you could
have a series of (DEFSTATE state1 ... ) (DEFSTATE state2 ... )
... (DEFINE-STATE-MACHINE state-machine state1 state2 ...) forms, or
something like that, but you're not changing the level of modularity.
> In the end, I probably would write an NDFSA -> DFSA -> State Machine
> generator, but for appropriate reasons: first, because I am a
> self-indulgent programmer who would like to try my hand at writing this
> sort of thing :-); second, because I could think of a lot of other uses
> for an FSA generation system.
So would I ... or, so did I ... or, I started on that, but I needed my
state machine sooner than I would have gotten that way. :)
·········@netscape.net (Delaregue) writes:
> I 've got a more general question:
> What should be the maximum number of lines for a lisp function to be
> "clean".
> If a function has 500 lines, there is obviously a problem as it could
> be simplified. What do you think is the optimal length?
It should fit on your screen.
;-)
Peter
·········@netscape.net (Delaregue) writes:
> - I am trying to insert a newline in a string:
Have you tried (format nil "~a~%~a" string1 string2)?
Ole
From: Thomas A. Russ
Subject: Re: newline and concatenate. length of a lisp function.
Date:
Message-ID: <ymik80uujxw.fsf@sevak.isi.edu>
·········@netscape.net (Delaregue) writes:
>
> Hi,
>
> - I am trying to insert a newline in a string:
Just insert it verbatim:
"This is a string with a newline between here
and here"
Lisp allows you to break strings over multiple lines, unlike some other
languages you may be familiar with.
The #\newline is the newline character and is only intrepreted as that
when encountered OUTSIDE a string by the reader. Inside a string it has
no particular signicance (again unlike certain other languages...)
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu