Thread: Why should I learn Lisp?

  1. #46
    Ticked and off
    Join Date
    Oct 2011
    Location
    La-la land
    Posts
    1,728
    I think this is the best possible point to mention that every time I look at the thread list, I read the title of this thread as

    Why should I learn to Lisp?

  2. #47
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,730
    Nominal Animal has spoken the secret thought that crossed my mind when I first saw this topic.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #48
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    Why should I learn to Lisp?
    O_o

    Lusty lady lycans love a leaky lisp.

    Soma
    Last edited by phantomotap; 02-03-2015 at 10:03 PM. Reason: ... can't decide ...
    “Salem Was Wrong!” -- Pedant Necromancer
    “Four isn't random!” -- Gibbering Mouther

  4. #49
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by Nominal Animal View Post
    I think this is the best possible point to mention that every time I look at the thread list, I read the title of this thread as
    Why should I learn to Lisp?
    There's rarely a good reason to stick to the plan.

    (But it would be ok if laserlight forked the discussion, I guess)

    @Phantomotap,

    Have to digest your post later. But in the meantime, the suite statement represents a nested block or statement, which is a category concept above the notion of a simple statement, or a group of statements (the latter of which Python has no concept of, beyond +). A nested block is what we are discussing here. A simple statement has no bearing in the discussion since it can appear anywhere in the code and doesn't carry the semantics necessary for the discussion of "What constitutes the delimiter for nested code? And suite makes it clear that nested code is either a simple statement or a block of simple statements. In Python as in many other languages.

    The grammar does not make the separation for good reason. And if you look at your own grammar code, neither have you. When you went to be more explicit about that separation and broke the 'or', you introduced ambiguity, which could only be resolved by introducing a new branch (which we could anyways, I'll give you that).

    I would marginally agree with you, if you wanted to discuss nested code in the strict context of a code block made up of more than one statement. Then I would say IDENT and EDENT are the good looking fellas that appear to delimit blocks of statements. Sure. But that says nothing about nested code, which is defined one branch up in the parser.

    Meanwhile, the following is perfectly valid python code:

    Code:
    if (True):
        print(True)
    else:
        print(False)
    The parser travels through suite and into simple_stmt branch to parse the print() statement. It's important to note the order. But you also have wrapped the condition in parenthesis, killing the idea that ':' behaves more like an open parenthesis.

    But as I said, I have to look at your post more carefully later. In a rush for work.
    Last edited by Mario F.; 02-04-2015 at 02:19 AM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #50
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    But as I said, I have to look at your post more carefully later.
    o_O

    Your sloppy use of extraneous grouping, discussed below, to show anything about the ':' character is foolish and a waste of that time available.

    I spent about fifteen minutes responding, but I'll gladly stop posting before responding to another such bit of nonsense.

    The grammar does not make the separation for good reason.
    The reason being that the ':' doesn't bind with the block in either event.

    When you went to be more explicit about that separation and broke the 'or', you introduced ambiguity,
    Code:
    A1: simple_stmt
    A2: A1
    A3: NEWLINE
    A4: A3 INDENT
    A5: A4 stmt+
    A6: A5 DEDENT
    A7: A6
    suite: A2 | A7
    The grammar hasn't been augmented. I've not introduced any sort of ambiguity.

    Your an idiot if you think separation introduces the ambiguity.

    which could only be resolved by introducing a new branch.
    When you choose to bind the ':' as being part of the block, you introduce ambiguity.

    An ambiguity, by the way, that isn't resolved by intruding a new branch.

    But that says nothing about nested code, which is defined one branch up in the parser.
    Correct. Nested code, a compound statement, has nothing to do with a block statement which is a block of statements.

    We've been talking about block statements ("Technically it is not true that Python doesn't impose a block delimiter. That delimiter exists and it is obligatory. It's the colon you see in the code snippets above.") the entire time so I'm not sure why you've brought up compound--"nested code"--statements.

    In any event, you are definitely still wrong if you think the ':' character is the "open compound-statement" delimiter.

    Code:
    while(a): if(b): a = c() else: a = d()
    You aren't seeing three compound statements--"nested code"--delimited by a ':' character.

    You are seeing one--"nested code"--compound statement. You see a while-branch statement and a if-branch statement with the option "else" clause.

    You do indeed see two simple statements, but the ':' character isn't either a "open simple-statement" delimiter.

    Your use of the "nested code" rule doesn't say anything, more below, about the ':' character.

    Meanwhile, the following is perfectly valid python code:
    The following C++ code is perfectly valid:

    Code:
    if(((((((((((((((((((((((((((((((true)))))))))))))))))))))))))))))));
    The code can be simplified by removing the extraneous grouping tokens:

    Code:
    if(true);
    I can't remove either the '(' or the ')' character. The remaining '(' and ')' characters are part of the `if' itself.

    But you also have wrapped the condition in parenthesis, killing the idea that ':' behaves more like an open parenthesis.
    A language allowing almost arbitrary extraneous grouping tokens doesn't change the delimiter requirements or binding for any characters required as part of a rule.

    The following is a valid Python program:

    Code:
    (((((((((((((((((((((((((((((((True)))))))))))))))))))))))))))))))
    The code in the example is also valid as a condition statement.

    Code:
    if(((((((((((((((((((((((((((((((True))))))))))))))))))))))))))))))): pass
    The code can be simplified by removing the extraneous grouping tokens:

    Code:
    if True: pass
    I can't remove ':' character. The ':' character is part of the `if' itself.

    The parser travels through suite and into simple_stmt branch to parse the print() statement. It's important to note the order.
    Okay...

    The parser uses the if_stmt rule to parse the "if" fragment before moving onto the test rule which allows for extraneous grouping tokens through combining other rules which themselves allow for extraneous grouping tokens before moving onto the ':' fragment which neither delimits the test rule or suite rule being part of the "if" rule before moving onto the suite rule which here begins with the alternative NEWLINE INDENT stmt+ DEDENT component before moving onto the "else" fragment before moving onto the ':' fragment which still doesn't delimit the suite statement being part of the "else" component of the "if" rule before moving onto the suite rule which here begins with the alternative NEWLINE INDENT stmt+ DEDENT fragment.

    It is very important to note the order.

    But you also have wrapped the condition in parenthesis, killing the idea that ':' behaves more like an open parenthesis.
    Congratulations. You wrapped the condition in parenthesis.

    You very effectively showed that the option grouping tokens you added are extraneous.

    You've killed the idea that wrapping a condition in extraneous parentheses changes the meaning of a sentence.

    The following is also valid Python code:

    Code:
    if True:
        (print(True))
    else:
        (print(False))
    The example shows that the option grouping tokens I added are extraneous.

    The example says literally nothing about the ':' character.

    *shrug*

    I also never said "the idea that ':' behaves more like an open parenthesis", but I'm pretty sure that a mistype.

    Soma
    Last edited by phantomotap; 02-04-2015 at 05:02 AM.
    “Salem Was Wrong!” -- Pedant Necromancer
    “Four isn't random!” -- Gibbering Mouther

  6. #51
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by phantomotap View Post
    Correct. Nested code, a compound statement, has nothing to do with a block statement which is a block of statements.

    We've been talking about block statements ("Technically it is not true that Python doesn't impose a block delimiter. That delimiter exists and it is obligatory. It's the colon you see in the code snippets above.") the entire time so I'm not sure why you've brought up compound--"nested code"--statements.
    Damn. You are thick when you want to be. Call me an idiot and behave like an idiot. Typical of you.

    That quote is taken from the context of nested statements. I called it a block statement. You are right, it's the wrong term. Smartass.


    Quote Originally Posted by phantomotap View Post
    In any event, you are definitely still wrong if you think the ':' character is the "open compound-statement" delimiter.

    Code:
    while(a): if(b): a = c() else: a = d()
    You aren't seeing three compound statements--"nested code"--delimited by a ':' character.

    You are seeing one--"nested code"--compound statement. You see a while-branch statement and a if-branch statement with the option "else" clause.
    I see 2 compound statements and 3 suits there. A while compound statement and an if compound statement wrapped in the while statement suite. The if statement meanwhile -- because of the optional else -- has two suits. Each of the three suites are preceded by a colon.

    Quote Originally Posted by phantomotap View Post
    You do indeed see two simple statements, but the ':' character isn't either a "open simple-statement" delimiter.
    So. What exactly is the ':' character then, if not a delimiter for a suite (suite, which defines nested code)?
    What is its purpose then? You must have an opinion, no? Tell us.

    Or is this really all because you aren't seeing the colon in the suite definition? Because as much as you write 20 minute long posts, you aren't doing a good job at spinning this, doctor Phantomotap.
    Last edited by Mario F.; 02-04-2015 at 06:30 AM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #52
    Ticked and off
    Join Date
    Oct 2011
    Location
    La-la land
    Posts
    1,728
    Quote Originally Posted by Epy View Post
    Since reading this, I went and checked out Forth and want to use it more and more every time I look at it. I've got an HP calculator that uses the RPN notation (which I love), so at least having a Forth prompt on my computer seems appealing.
    One of my favourite games, Starflight, was written in Forth.

    Currently, OpenFirmware and OpenBIOS supports device drivers/firmware written in Forth. Well, FCode, a bytecode version.

  8. #53
    ... kermit's Avatar
    Join Date
    Jan 2003
    Posts
    1,533
    Quote Originally Posted by Epy View Post
    Since reading this, I went and checked out Forth and want to use it more and more every time I look at it. I've got an HP calculator that uses the RPN notation (which I love), so at least having a Forth prompt on my computer seems appealing.
    Speaking of smug.... (I have a 50g and a 35s, and I love them both).

    Quote Originally Posted by Yarin View Post
    Attract smug users.
    I like this, but I thought it was C that attracted smug users, being the system language for UNIX:

    Dilbert Comic Strip on 1995-06-24 | Dilbert by Scott Adams

    That is probably my favourite Dilbert strip.

  9. #54
    Make Fortran great again
    Join Date
    Sep 2009
    Posts
    1,413
    I love that strip too, and I've got a 50g as well. I love the older Dilberts, good thing you can download them all from the site.

  10. #55
    Registered User
    Join Date
    Feb 2015
    Posts
    11
    Hmm, interesting.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Lisp Help
    By anirban in forum Tech Board
    Replies: 1
    Last Post: 01-15-2012, 04:14 PM
  2. Help on LISP please?
    By ssharish2005 in forum Tech Board
    Replies: 1
    Last Post: 02-08-2008, 10:12 AM
  3. Lisp
    By Silvercord in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 08-26-2003, 12:41 PM
  4. Lisp
    By MethodMan in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 11-18-2002, 04:41 PM
  5. Lisp
    By Lechugas in forum A Brief History of Cprogramming.com
    Replies: 2
    Last Post: 01-18-2002, 12:21 PM