Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

LISP Code Style

Name: Anonymous 2009-11-03 1:50

Hi.  I'm sortof new to LISP, so I'm not that good at it, but i wrote a program that converts decimal numbers into Roman numerals.  It's not that exciting of a programming, but I like making unique little programs that I can use at the oddest times.  LISP is an awesome language, but I think it's harder to read (i made a game in C before this so i'm a C programmer).  I decided to use the C style to make the code look more organized.  I think it makes it easier to read.  It's not GNU style, but I was wondering if the GNU has a format guideline for LISP.  I was thinking of submitting something like this, because it makes LISP code easier to read.

(
    defun roman1
    (
    )
      "Roman numeral conversion with an unordered P.S."
      (
        let
        (
            (
            x nil
            )
        )
            (
            loop
                  (
                cond
                        (
                    (
                        null x
                    )
                    (
                        format t "Enter number:"
                    )
                    (
                        setf x
                        (
                            read
                        )
                    )
                )
                        (
                    (
                        and
                        (
                            not
                            (
                                null x
                            )
                        )
                        (
                            > x 39
                        )
                    )
                             (
                        format t "too big~%"
                    )
                    (
                        setf x nil
                    )
                )
                        (
                    (
                        and
                        (
                            not
                            (
                                null x
                            )
                        )
                        (
                            < x 40
                        )
                        (
                            > x 9
                        )
                    )
                             (
                        prin1 'x
                    )
                    (
                    setf x
                        (
                            - x 10
                        )
                    )
                )
                        (
                    (
                        and
                        (
                            not
                            (
                                null x
                            )
                        )
                        (
                            = x 9
                        )
                    )
                             (
                        prin1 'ix
                    )
                    (
                        setf x 0
                    )
                )
                        (
                    (
                        and
                        (
                            not
                            (
                                null x
                            )
                        )
                        (
                            < x 9
                        )
                        (
                            > x 4
                        )
                    )
                             (
                        prin1 'v
                    )
                    (
                        setf x
                        (
                            - x 5
                        )
                    )
                )
                        (
                    (
                        and
                        (
                            not
                            (
                                null x
                            )
                        )
                        (
                            = x 4
                        )
                    )
                             (
                        prin1 'iv
                    )
                    (
                        setf x 0
                    )
                )
                        (
                    (
                        and
                        (
                            not
                            (
                                null x
                            )
                        )
                         (
                            < x 4
                        )
                        (
                            > x 0
                        )
                    )
                             (
                        prin1 'i
                    )
                    (
                        setf x
                        (
                            1- x
                        )
                    )
                )
                        (
                    (
                        zerop x
                    )
                    (
                        setf x nil
                    )
                    (
                        terpri
                    )
                )
                     )
        )
    )
)

Name: Anonymous 2009-11-03 17:47

>>34
Duff's device
and it's what real men call DESIGN PATTERNS

Name: Anonymous 2009-11-03 17:55

>>37
from the wiki
This modified form of the Device appears as a "what does this code do?" exercise in Bjarne Stroustrup's book The C++ Programming Language, presumably because novice programmers cannot be expected to know about memory-mapped output registers.
This made me a little sad, knowing that it's true for far too many professional programmers these days

Name: Anonymous 2009-11-03 18:01

>>37
You don't really need it on x86, and on other platforms. memcpy is supposed to be as fast. An optimized buffer copy on x86 is like:

void *memcpy( void *dest, const void *src, size_t count )
{
     __asm
     {
          mov esi, src
          mov edi, dst
          mov edx, count ; in bytes
 
          mov ecx, edx
          shr ecx, 2 ; ecx is now amount of dwords (size/4)
          rep movsd ; copy (size/4) dwords == (size/4)*4

          mov ecx, edx
          and ecx, 4 ; ecx is now amount of bytes left (size%4)
          rep movsb ; copy remaining bytes

          mov eax, edi ; return output buffer
     }
}

Note that I just wrote this from memory, so I haven't tested if it compiles. Note that smarter compilers will inline this, and may remove the last part if the size is divisible by 4. Many compilers on the x86 perform such optimizations, and not only for C compilers.

Name: Anonymous 2009-11-03 18:10

>>31
Scripting languages aren't good for game engines.  They are slower than compiled code and games need to be really fast to keep their FPS.
FrozenVoid detected.  saging for teenage poster.

Name: Anonymous 2009-11-03 18:21

>>39
will it work with memory mapped output register?

Name: Anonymous 2009-11-03 18:24

>>41
I don't see why it wouldn't?

Name: Anonymous 2009-11-03 18:25

>>39
>>37-san's function isn't memcpy, it is sending a buffer out to a MMIO register.

Name: Anonymous 2009-11-03 18:33

>>42
frankly, i only barely know assembly, that's why i asked

Name: Anonymous 2009-11-03 18:44

Name: Anonymous 2009-11-03 18:58

>>45
Never said my way was the most optimized one. My memcpy version assumes at least a 386 x86 CPU. Newer CPUs can use some MMX/SSE copy instructions instead, and 64bit CPUs would benefit from using larger registers.

Name: Anonymous 2009-11-03 21:01

I actually think this looks better than most Lisp programs.  I would recommend not going as far as you did, and revert parts like this:

(
  (
    stuff
  )
  (
    stuff
  )
)

into

(
  (stuff)
  (stuff)
)

Also, I wouldn't try to get this format standardized by the GNU.  They are into batshit standards, as you probably know from their C standard. They probably loved how fucked up most Lisp programs look.

Name: Anonymous 2009-11-03 22:28

>>31
You don't read code all at once, you read it sequentally.
Oh look, a slow reader. Maybe one day you'll learn to read fluently.

Name: Anonymous 2009-11-03 22:33

>>19
OP here.  I don't get it.  Are you guys saying this is good or bad?  have you guys ever programmed in C? I think its a lot easier to read for a C programming because it is layed out in C style.  Sometimes when I read other people's LISP programs they have 10 statements on one line.  its like trying to read:

while {if ((x > 20) && (x < 40)) { printf("a"); x++; } else { return 0; } }

I knwo there are other standards, but what Im saying is mine is better.

I find the Lisp code easier to read than that C code (which isn't even correct, look at the syntax for the while loop in your example is wrong - I'm assuming while(true) or while(x > 20) && (x < 40)):

(loop
   (cond
     ((< 20 x 40) (princ "a") (incf x))
     (t (return 0))))

(loop
   (if (and (< 20 x)
        (< x 40))
       (progn (format t "a") (incf x))
       0))

(let ((x 21))
  (loop while (< 20 x 40)
     do (progn (format t "a") (incf x)))
  0)

You also stated that you're forced to put everything on the same line, which is just wrong, because if you had a good editor like Emacs, formatting something like:
(+ (* 5 6) (/ 9 8) (- 10 (+ 11 12 13 (1- 16))))
into something more readable, like:

(+
 (* 5 6)
 (/ 9 8)
 (- 10
    (+ 11 12
       13 (1- 16))))

can be done only with a few key presses: moving the cursor around, and pressing enter, that's all.

Name: Anonymous 2009-11-03 22:35

Oops, fixed indentation(Shiichan formats tabs differently) and one statement.

(loop
   (if (and (< 20 x)
            (< x 40))
       (progn (format t "a") (incf x))
       (return 0)))

Name: Anonymous 2009-11-03 23:39

>>47
Thanks, I'm glad you agree with me.  I will try that style in the next code I write.  I was thinking about making a LISP program that does matrix multiplication so I can use it when I try to make a 3D game!

>>49
Ugh, I guess I can never show LISP users how much easier C is to read.  I give up.  I also said I don't let the IDE write my code.  That is what newbies do and they cant even read there own code afterwards.

Name: Anonymous 2009-11-04 0:07

they cant even read there own code afterwards.
What about they are own code?

Name: Anonymous 2009-11-04 0:17

Ugh, I guess I can never show LISP users how much easier C is to read
That's because it isn't, duh. Lisp and C are fundamentally different beasts and expecting to be able to write them in exactly the same way is, at best, folly and at worst, a crime against your fellow programmer. That's like suggesting we take a Haskell program and write it out as a C program Oh wait, Haskell caved with it's do syntax, although even that is better than standard C

Name: Anonymous 2009-11-04 0:30

>>53
No, Haskell is a modern language that is well thought out and knows that C has a good format.  LISP came before and doesn't evolve.

Name: Anonymous 2009-11-04 0:33

>>52
Yes, I used the wrong "there", but that's not the write one either. They're means "they are", it should be their.

Name: Anonymous 2009-11-04 0:36

>>54
Explain why the C specification is littered with undefined behaviours, as opposed to Lisp where evaluation order is explicit

Name: Anonymous 2009-11-04 0:41

ITT: lisp weenies don't know C.

Name: Anonymous 2009-11-04 0:43

>>577
also
ITT: C weenies don't know lisp.

Name: Anonymous 2009-11-04 1:02

>>57
LISP isn't a bad language, but I agree with you that a lot of the LISP users here are "weenies".  I guess I can try another LISP place, people here probably aren't even as good at LISP as I am.  That one guy couldn't even write as fast of a program as me.

>>56
That isn't formatting.

Name: Anonymous 2009-11-04 1:04

ITT: some idiots assume people who know Lisp don't know C, and people who know C don't know Lisp.

Knowledge of both languages (and some others) is required for achieving satori.

Name: Anonymous 2009-11-04 1:05

>>60
Of course, that assumes that people have either achieved satori or are even on the correct path.

Name: Anonymous 2009-11-04 1:10

>>56
Both languages' specifications are littered with implementation specific behaviours. This goes for ANSI C, and it surely goes for ANSI CL(just look at the Hyperspec). This isn't anything bad about that, as some liberty is required in real languages about how certain platform specific things are implemented, and in the case of CL, they left certain things open as there were multiple Lisp implementations/languages which did things differently and their goal was to unify the language while making it not too hard for them to turn their implementations into a Common Lisp. I think they did a very good job, even though some parts could have been more specific.

Name: Anonymous 2009-11-04 1:12

>>1,54
implying Lisp' evolution is changing the indentation style
Nothing stops you from your silly quest, just don't expect many people to follow you on this path.

Name: Anonymous 2009-11-04 1:18

>>63
If I get it standardized then a lot of people will.  Thats why I am thinking about submitting it to GNU

Name: Anonymous 2009-11-04 1:20

>>64
Nobody uses GNU indentation stye for anything.

Name: Anonymous 2009-11-04 1:22

>>65
What about Unix?

Name: Anonymous 2009-11-04 1:23

>>64
And what makes you think that people will not just continue on with their own preferred, widely accepted and well rationalized indentation style just because you manage to convince some halfwit at the GNU project?

Name: Anonymous 2009-11-04 1:24

>>66
BSD uses K&R, what you talking about?

Name: Anonymous 2009-11-04 1:25

>>68
i meant Linux.  Unix and Linux are similar sorry

Name: Anonymous 2009-11-04 1:27

>>69
The linux kernel has it's own coding guidelines, which are separate from GNU's. Which is why on a default emacs you have to use C-c C-. linux to use their coding style

Name: Anonymous 2009-11-04 1:28

>>64
I don't think GNU would accept it. GNU's Emacs Lisp indentation style is similar to the Common Lisp style, but is older, and has some minor differences about indenting a few forms.

You should understand that the indentation style is a shared culture among Lisp programmers, and is fairly important, so important that few people would bother reading incorrectly indented code. rms is more conservative than most Lispers, I have doubts he would not completly ignore your mail. Not only that, but almost nobody except some really green newbies would consider writing in a different indentation style, and that is because they haven't used a good editor capable of indenting Lisp code automatically or they're just plain stubborn fools. How many days did you say you studied Lisp for, and what books have you read on the subject?

Name: Anonymous 2009-11-04 1:30

Corrections to >>70
1. That should be C-c . linux
2. Linux coding style http://www.kernel.org/doc/Documentation/CodingStyle

Name: Anonymous 2009-11-04 1:32

>>71
Are you trying to suggest that the $20 and 24 hours I spent on "Sams guide to Internet Trolling with Common Lisp" was a complete waste?

Name: Anonymous 2009-11-04 1:35

>>73
I suppose you have already succeeded.

Name: Anonymous 2009-11-04 3:39

>>16
>>1
>>19
>>22
>>31
So this are /prog/ trolls? Rather weak, I must say.

Name: Anonymous 2009-11-04 4:26

>>73
Shouldn't that be "SAMS Learn to Troll With Common Lisp in 48 Hours"?

Name: Anonymous 2009-11-04 5:19

>>76
You should know, Xah Lee

Name: Anonymous 2009-11-04 15:15

>>1
IHBT

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List