

Lambda’s New Coat: 21st century syntactic Mexps - gnosis
http://lubutu.com/idea/lambdas-new-coat

======
ynniv
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.

~~~
lubutu
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.

------
spacemanaki
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?

~~~
oconnore
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.

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

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

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

Something about nipples comes to mind.

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

~~~
lubutu
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 :/

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

~~~
lubutu
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.

------
Apocryphon
A Python with a Lisp- Parseltongue?

------
jpr
Shouldn't this

    
    
        if fruit is 'apricot':
    

be

    
    
        if fruit == 'apricot':
    
    ?

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

~~~
devinj
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.

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

~~~
jerf
"==" 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>

