3 ms·

No syntax has intrinsic semantics. I don't think 'intrinsic semantics' is a meaningful combination of words. Explicitly, in lisp, everything is a stack of ins

by ohyes 13y ago

No syntax has intrinsic semantics. I don't think 'intrinsic semantics' is a meaningful combination of words. Explicitly, in lisp, everything is a stack of instructions arranged in a tree. The instructions are either functions that manipulate the input data, or functions that manipulate the underlying tree of instructions. By naming convention and documentation, we give the various functions semantics. ("With" macros being an example).

catnaroek 13y ago
> No syntax has intrinsic semantics. I don't think 'intrinsic semantics' is a meaningful combination of words. I was just refuting the assertion that "S-expressions are about as semantically sane as you can get". > Explicitly, in lisp, everything is a stack of instructions arranged in a tree. I do not particularly care what data structure is internally used. That is the compiler's business, not mine. I want to reason about my code in terms of the semantics of the language I am using. > By naming convention and documentation, we give the various functions semantics. ("With" macros being an example). Names may be misleading, documentation may be incomplete, but types never fail to accurately guarantee properties about my code. Hence my preference for types. http://tmorris.net/posts/2013-07-18-identifier-names.html http://tmorris.net/posts/2013-07-18-identifier-names.html
- ohyes 13y ago
  > I was just refuting the assertion that "S-expressions are about as semantically sane as you can get". His comment was equally nonsensical. S-expressions are consistent and easy to parse, that is all. > I do not particularly care what data structure is internally used. That is the compiler's business, not mine. I want to reason about my code in terms of the semantics of the language I am using. >I do not particularly care what data structure is internally used. That is the compiler's business, not mine. I want to reason about my code in terms of the semantics of the language I am using. Good, that data structure generally isn't used internally in the compiler (not efficient enough). I'm talking about the data structure that is used for the programmer's brain. The semantics and way of reasoning about the code is in terms of a very simple data-structure. My business is the compiler's business. > Names may be misleading, documentation may be incomplete, but types never fail to accurately guarantee properties about my code. Hence my preference for types. Why would you write such shitty code? There are many ways of skinning that cat. You can use types, you can use tests, you can use assertions. You could make it overly complicated and long. A stupid person is going to have a bad time writing code, no matter what language you hand them. Shitty code is shitty. This is a tautology comparing the language I'm currently into to a language I'm not currently into. Don't use it. You're good at writing Haskell, good for you.
  - JackMorgan 13y ago
    I'm curious then what you mean by semantics, like the words used for library function names? I've always equated semantics and syntax, perhaps to my detriment.
    - wonderzombie 13y ago
      Syntax is the presentation layer for semantics. Semantics are the content, meaning, and/or implications for what you convey via syntax. They're largely orthogonal. def add(x, y): return x + y (define (add x y) (+ x y)) These are similar semantically -- they each define a procedure that takes two parameters, adds them, and returns that result. Hand-waving how the language is actually implemented, they're morally equivalent, anyway. But syntactically they're fairly different. Another example: https://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously https://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_fu.... That sentence is semantically meaningless, but it has the correct syntax. edit: fixed code formatting.

by ohyes 13y ago

catnaroek 13y ago

> No syntax has intrinsic semantics. I don't think 'intrinsic semantics' is a meaningful combination of words. I was just refuting the assertion that "S-expressions are about as semantically sane as you can get". > Explicitly, in lisp, everything is a stack of instructions arranged in a tree. I do not particularly care what data structure is internally used. That is the compiler's business, not mine. I want to reason about my code in terms of the semantics of the language I am using. > By naming convention and documentation, we give the various functions semantics. ("With" macros being an example). Names may be misleading, documentation may be incomplete, but types never fail to accurately guarantee properties about my code. Hence my preference for types. http://tmorris.net/posts/2013-07-18-identifier-names.html http://tmorris.net/posts/2013-07-18-identifier-names.html

ohyes 13y ago
> I was just refuting the assertion that "S-expressions are about as semantically sane as you can get". His comment was equally nonsensical. S-expressions are consistent and easy to parse, that is all. > I do not particularly care what data structure is internally used. That is the compiler's business, not mine. I want to reason about my code in terms of the semantics of the language I am using. >I do not particularly care what data structure is internally used. That is the compiler's business, not mine. I want to reason about my code in terms of the semantics of the language I am using. Good, that data structure generally isn't used internally in the compiler (not efficient enough). I'm talking about the data structure that is used for the programmer's brain. The semantics and way of reasoning about the code is in terms of a very simple data-structure. My business is the compiler's business. > Names may be misleading, documentation may be incomplete, but types never fail to accurately guarantee properties about my code. Hence my preference for types. Why would you write such shitty code? There are many ways of skinning that cat. You can use types, you can use tests, you can use assertions. You could make it overly complicated and long. A stupid person is going to have a bad time writing code, no matter what language you hand them. Shitty code is shitty. This is a tautology comparing the language I'm currently into to a language I'm not currently into. Don't use it. You're good at writing Haskell, good for you.
- JackMorgan 13y ago
  I'm curious then what you mean by semantics, like the words used for library function names? I've always equated semantics and syntax, perhaps to my detriment.
  - wonderzombie 13y ago
    Syntax is the presentation layer for semantics. Semantics are the content, meaning, and/or implications for what you convey via syntax. They're largely orthogonal. def add(x, y): return x + y (define (add x y) (+ x y)) These are similar semantically -- they each define a procedure that takes two parameters, adds them, and returns that result. Hand-waving how the language is actually implemented, they're morally equivalent, anyway. But syntactically they're fairly different. Another example: https://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously https://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_fu.... That sentence is semantically meaningless, but it has the correct syntax. edit: fixed code formatting.