Lambda’s New Coat: 21st century syntactic Mexps | Hacker News Reader

Lambda’s New Coat: 21st century syntactic Mexps

lubutu.com

12 pointsgnosis21 comments

This idea comes up periodically, but it's something that appeals more to those who don't use lisp than those who do. I thought the same thing before I started really using lisp, but once you start feeling comfortable with sexps a superficial pythonic skin sounds annoying. The suggestion of trading lisp's macro features (how would you define macros with "mexps", and how would mexps interact with macros?) for syntactic whitespace that people either love or hate doesn't sound like a long term improvement.

"Mexps" might attract a few new people to lisp, but the existing lisp community would reject them. It would be more effective in the long term to show people the value of lisp's existing syntax.

maybe an alternative to sexps appeals to those who don't use lisp because they don't use lisp because of sexps?

the idea is that mexps translate directly (and simply) into sexps, so macros would work in exactly the same way as they do now.

This proposal is very similar to "sweet expressions":

http://www.dwheeler.com/readable/sweet-expressions.html

edited to add:

"it makes the language far more flexible than any other language and provides a foundation for fully hygienic macros: you can modify the program entirely while it’s running and guarantee that there will be no crazy conflict behaviour. "

That's not true though, Common Lisp's macros can have nasty variable capture issues, can't they? This isn't using the word "hygienic" in the sense of Scheme's, so what does this mean exactly?

thanks, i'd not read this. they do seem quite similar, though i think we focus on different things.

i think i prefer haskell operators to infixing with {}. still, i hadn't considered subscripting.

Common Lisp macros allow the programmer to capture variables if they desire and/or are ignorant of the semantics of the language. Sometimes this is nice, like in the anaphora package. Defining hygienic macros is not hard though.

That's basically what I thought. I misread the OP to mean that s-expressions alone guaranteed hygienic macros.

Declaring that lisp is unintuitive when compared with python is like saying Shakespeare is unpopular when compared with Lady Gaga.

>However, Lisp has a big problem: it’s not intuitive.

Something about nipples comes to mind.

Okay, how was it, did Lisp introduce if expressions or if statements?

lisp introduced if-then-else expressions. 'if statements' was a little vague, so i've rephrased.

i wasn't really expecting to be on hn :/

The article made an interesting proposal. Do you intend to implement it?

i'd like to, it's just a case of finding the time. i'm sure i'll get around to it at some point.

A Python with a Lisp- Parseltongue?

Shouldn't this

    if fruit is 'apricot':

    if fruit == 'apricot':

?

in python they're equivalent (for strings and numbers and such).

Nope; that's a common misconception.

   >>> "1"*1000 is "1"*1000
   False
   >>> 2**31 is 2**31
   False

The fact is that the only thing guaranteed by "is" is that if you have "a = b", then "a is b". Whether or not "new" objects are going to be identical to old ones is left undefined, and may change depending on type or value.

that is very confusing, but fair enough. it at least seems to work in the sample code.

Well, "is" in Python is a specific notion of object identity, and Python happens to sometimes decide it's not worth creating new objects. Not really confusing, it's just completely different from '==' (except by coincidence basically).

"==" is an equality check that calls various methods[1] to answer the question. "is" is true if and only if the two references are actually the exact same reference, or, under the hood, basically that the two pointers are equal.

  >>> [1,2,3] == [1,2,3]
  True
  >>> [1,2,3] is [1,2,3]
  False

The equality check in the case of lists is recursive and checks the equality of its elements piecewise. But they are two different lists, so they don't check "is" the same.

As an optimization, because everything in Python is an object (despite occasional claims to the contrary by the Ruby community), certain objects are created at interpreter start time and cached forever, such as (IIRC) the numbers 0 through 100 or so, so if you happen to use "is" it will sometimes "work":

  >>> (1 + 3) is (2 + 2)
  True

but it's not good or reliable:

  >>> (1000 + 3000) is (2000 + 2000)
  False

Basically, unless you are doing something with "object identity" and you know what you are doing (and if you don't know what I mean by caring about "object identity" you probably don't pass this check), OR are checking that something is specifically "None" and not merely false (as None is another of those cached values and there is only ever one None in the system), don't use "is".

[1]: http://docs.python.org/reference/expressions.html#notin

fine fine, i've changed the code slightly.

sometimes i wonder whether i am too imprecise for a programmer. :o

Sure. `==` should be used for such comparisons, not `is`, as the latter is semantically different. They have the same effect for "apricot" because Python interns strings up to length 20:

  >>> "1"*20 is "1"*20
  True
  >>> "1"*21 is "1"*21
  False

Reply on news.ycombinator.com