5 ms·

> syntax-parse and defmacro are good at different things. Yes, `syntax-parse` is good at being compositional - writing macros that don't step on each other's t

> syntax-parse and defmacro are good at different things. Yes, `syntax-parse` is good at being compositional - writing macros that don't step on each other's toes, just like normal functions. > Tell that to everyone developing java. :-). There's a reason why writing Java programs is so painful. The language is like a third world country's bureaucracy: it doesn't do anything useful by itself, and gets in the way of anyone who wants to do anything useful. > Look, you're clearly a hardcore ML fan. You're not going to like Lisp. It's not a matter of what I think. You said: “If it [Lisp] isn't the best at something, you can MAKE it the best.” All I did was give an example of something you can't make Lisp do. > Lisp is hyper-dynamic, ML is incredibly static. Every programming language has both static and dynamic parts. For example, lexical scope is intrinsically a static notion. And ML's exception construction is dynamic. The question is which particular combination of static and dynamic parts is most profitable for one's purposes. In any case, I really didn't want to turn this into a debate about types. My original objection was that Lisp doesn't have compound values. A dynamically typed language can have compound values.

qwertyuiop924 10y ago
>Yes, `syntax-parse` is good at being compositional - writing macros that don't step on each other's toes, just like normal functions. That's hygene. defmacro COULD have hygene, and indeed, some schemes provide ER macros, which are defmacro with hygene. What I was talking about was the fact that defmacro is imperative, and syntax-parse is declarative. The lack of hygene in defmacro is actually awful. >There's a reason why writing Java programs is so painful. The language is like a third world country's bureaucracy: it doesn't do anything useful by itself, and gets in the way of anyone who wants to do anything useful. I'll agree with that, but pretty much every java program out there is an example of guarantees maintained by the programmer, not the language. Not saying it's a good thing, am saying it's possible. >It's not a matter of what I think. You said: “If it [Lisp] isn't the best at something, you can MAKE it the best.” All I did was give an example of something you can't make Lisp do. Okay, but I didn't get it, because I'm still not sure what it was... >In any case, I really didn't want to turn this into a debate about types. My original objection was that Lisp doesn't have compound values. A dynamically typed language can have compound values. Do you mean ADTs? because if not, I'm not sure what you mean.
- catnaroek 10y ago
  > Okay, but I didn't get it, because I'm still not sure what it was... Manipulate compound values directly! > Do you mean ADTs? because if not, I'm not sure what you mean. A compound value is built from simpler values. Examples of compound values include lists, trees, graphs, etc. To clarify, by “list”, I mean the actual sequence of elements, not object identity of the first cons cell.
  - qwertyuiop924 10y ago
    >Manipulate compound values directly! I fail to see how Lisp can't do this. What does set-cdr! do if not directly modify a cons cell, which is a compound value? what about hash-table-set! and vector-set!?
    - catnaroek 10y ago
      > What does set-cdr! do if not directly modify a cons cell, which is a compound value? what about hash-table-set! and vector-set!? These functions are precisely why lists and vectors are not first-class values in Lisp. When you have a “list”, what you actually have is a mutable object whose current state is one list, but a later point in time, its state might be a different list! You can't bind a list value to a variable - you're only binding the identity of an object that temporarily holds the value. As the Buddhist saying goes: “The finger pointing at the moon is not the moon.” The identity and the state of an object are different things. The identity is first-class but it's not compound. And the state is compound, but it's not first-class.
      - qwertyuiop924 10y ago
        >These functions are precisely why lists and vectors are not first-class values in Lisp. When you have a “list”, what you actually have is a mutable object whose current state is one list, but a later point in time, its state might be a different list! You can't bind a list value to a variable - you're only binding the identity of an object that temporarily holds the value. ...And thus we get to the crux of the matter. You seem to think that an object must be immutable to be first class. This is wrong. I usually don't like to say that people are wrong, I just make my case for my opinion, but that is objectively wrong. First-Class objects, as defined most people, have only a few properties: -They can be created anonymously -They act as an lvalue in assignment -They can be given to a function as an argument Lisp's lists, maps, and vectors are ALL first class objects, by that definition, which is the most common one. I give up. You probably have a reasonable idea you're trying to express, by you seem to be at an utter loss to express it in a way people like me can understand.

qwertyuiop924 10y ago

>Yes, `syntax-parse` is good at being compositional - writing macros that don't step on each other's toes, just like normal functions. That's hygene. defmacro COULD have hygene, and indeed, some schemes provide ER macros, which are defmacro with hygene. What I was talking about was the fact that defmacro is imperative, and syntax-parse is declarative. The lack of hygene in defmacro is actually awful. >There's a reason why writing Java programs is so painful. The language is like a third world country's bureaucracy: it doesn't do anything useful by itself, and gets in the way of anyone who wants to do anything useful. I'll agree with that, but pretty much every java program out there is an example of guarantees maintained by the programmer, not the language. Not saying it's a good thing, am saying it's possible. >It's not a matter of what I think. You said: “If it [Lisp] isn't the best at something, you can MAKE it the best.” All I did was give an example of something you can't make Lisp do. Okay, but I didn't get it, because I'm still not sure what it was... >In any case, I really didn't want to turn this into a debate about types. My original objection was that Lisp doesn't have compound values. A dynamically typed language can have compound values. Do you mean ADTs? because if not, I'm not sure what you mean.

catnaroek 10y ago
> Okay, but I didn't get it, because I'm still not sure what it was... Manipulate compound values directly! > Do you mean ADTs? because if not, I'm not sure what you mean. A compound value is built from simpler values. Examples of compound values include lists, trees, graphs, etc. To clarify, by “list”, I mean the actual sequence of elements, not object identity of the first cons cell.
- qwertyuiop924 10y ago
  >Manipulate compound values directly! I fail to see how Lisp can't do this. What does set-cdr! do if not directly modify a cons cell, which is a compound value? what about hash-table-set! and vector-set!?
  - catnaroek 10y ago
    > What does set-cdr! do if not directly modify a cons cell, which is a compound value? what about hash-table-set! and vector-set!? These functions are precisely why lists and vectors are not first-class values in Lisp. When you have a “list”, what you actually have is a mutable object whose current state is one list, but a later point in time, its state might be a different list! You can't bind a list value to a variable - you're only binding the identity of an object that temporarily holds the value. As the Buddhist saying goes: “The finger pointing at the moon is not the moon.” The identity and the state of an object are different things. The identity is first-class but it's not compound. And the state is compound, but it's not first-class.
    - qwertyuiop924 10y ago
      >These functions are precisely why lists and vectors are not first-class values in Lisp. When you have a “list”, what you actually have is a mutable object whose current state is one list, but a later point in time, its state might be a different list! You can't bind a list value to a variable - you're only binding the identity of an object that temporarily holds the value. ...And thus we get to the crux of the matter. You seem to think that an object must be immutable to be first class. This is wrong. I usually don't like to say that people are wrong, I just make my case for my opinion, but that is objectively wrong. First-Class objects, as defined most people, have only a few properties: -They can be created anonymously -They act as an lvalue in assignment -They can be given to a function as an argument Lisp's lists, maps, and vectors are ALL first class objects, by that definition, which is the most common one. I give up. You probably have a reasonable idea you're trying to express, by you seem to be at an utter loss to express it in a way people like me can understand.