2 ms·

I can understand this argument. However, at the same time, S-expressions do allow for rather expressive function names not usually available in other languages.

by bmitc 4y ago

I can understand this argument. However, at the same time, S-expressions do allow for rather expressive function names not usually available in other languages. various arrows, question and other punctuation makes, etc. can make for some nice function names. I do agree with the sentiment to some degree though that it all looks the same. In an aesthetic sense, there is something I do like about it though. Being a fan of both ML and Scheme, I have actually been experimenting with a syntax that is a hybrid of the two. I’m still in the experimentation phase, but it’s an interesting exercise.

layer8 4y ago
> expressive function names Yes, but those are effectively library conventions, not fixed properties of the language. Maybe more importantly, names aren’t a structural construct, like a for loop or a class definition. And, arguably, you can have similar syntax in other languages, like e.g. `!` in Rust or the type sigils ($, @) in Perl, except that here you can be sure of their semantics.
- bmitc 4y ago
  The naming is enabled by the way S-expressions work and aren't merely convention. Handling such syntax in non-parenthetic languages is difficult because of the overlap with the other meaning of those infix operators in the language. For example, in F#, if I have a function named `string->number`, then the parser doesn't know if I mean `(string) - (>number)`, `(string-) > (number)`, `(string) -> (number)`, or the function `string->number`.
  - layer8 4y ago
    I totally understand. What I meant was that the meaning of such names, or the names chosen for a given meaning, is a convention of the library (or set of libraries) that defines the names, and not a semantics the language guarantees, like keywords and punctuation do in other languages. (In Lisp I don't know what `string->number` does any more than I know what `stringToNumber` does.) So S-expressions give you more freedom in the syntax of your function names, but they don't provide more kinds of constructs in the language.

by bmitc 4y ago

layer8 4y ago

> expressive function names Yes, but those are effectively library conventions, not fixed properties of the language. Maybe more importantly, names aren’t a structural construct, like a for loop or a class definition. And, arguably, you can have similar syntax in other languages, like e.g. `!` in Rust or the type sigils ($, @) in Perl, except that here you can be sure of their semantics.

bmitc 4y ago
The naming is enabled by the way S-expressions work and aren't merely convention. Handling such syntax in non-parenthetic languages is difficult because of the overlap with the other meaning of those infix operators in the language. For example, in F#, if I have a function named `string->number`, then the parser doesn't know if I mean `(string) - (>number)`, `(string-) > (number)`, `(string) -> (number)`, or the function `string->number`.
- layer8 4y ago
  I totally understand. What I meant was that the meaning of such names, or the names chosen for a given meaning, is a convention of the library (or set of libraries) that defines the names, and not a semantics the language guarantees, like keywords and punctuation do in other languages. (In Lisp I don't know what `string->number` does any more than I know what `stringToNumber` does.) So S-expressions give you more freedom in the syntax of your function names, but they don't provide more kinds of constructs in the language.