A Great Idea

Hey /prog/, I just had a great idea. Let's use a double space (space space) as the delimiter between identifiers so we can have identifiers with spaces in them.

An example:
(defun  add to deck  (card  deck)
  (cons  card  deck))

>>40
- is more readable and easier to type.
That's subjective.
Someone coming from a language with operator precedence might prefer the underscore.
The underscore on some keyboard layouts is next to the right shift.

>>35
I have shown benefits. It's more attractive and easier to read. And one man's “just look wrong” is another man's “just perfect”. Look at all the idiots who won't use Lisp because of the parens, but love FIOC. 3 or more would be synonymous with two (as would newlines and tabs, obviously).

>>38
I'm sorry, which did you mean:
(defun  add to deck  card  deck
  cons  card  deck)
((defun)  add to deck  card  deck
  cons  card  deck)
(defun  (add to deck)  card  deck
  cons  card  deck)
(defun  add to deck  (card)  deck
  cons  card  deck)
(defun  add to deck  card  (deck)
  cons  card  deck)
(defun  add to deck  (card  deck
  cons)  card  deck)[/m]
Or something else?

>>40
You're missing the point. You can have spaces, but you can't practically use them without putting bars around everything. So we get a bunch of unreadable “-”s instead (better than “_”, but still). I've never seen:
(defun |LOAD DECK| (path)
  (let ((|*READ EVAL*| nil))
    (|WITH OPEN FILE| (f path)
      (read f))))
Terrible! Not to mention it fucks with your readtable case.

>>41
You mean someone coming from a language with insane tokenizing rules, right? Operator precedence has nothing to do with it.

Are there really keyboards with unshifted “_”?

>>42
You'll have to redefine most standard symbols to do that.
What I had in mind for OP was that if he wanted to have some specific function named like that, he could just quote the function name. In your example, you are quoting *read-eval* and with-open-file, why?

Usage would be like this:

(defun |add to deck| (card deck)
  (cons card deck))

(defparameter *a-deck* nil)
(|add to deck| 'king *a-deck*)

(defun |load deck| (path)
  (let ((*read-eval* nil))
    (with-open-file (f path)
      (read f))))

>>43
You mean someone coming from a language with insane tokenizing rules, right?
No, I mean a language where '-' is an operator and can be between two identifiers without mandatory whitespace.

Are there really keyboards with unshifted “_”?
Maybe, but I was talking about keyboards where the row above the space bar looks like (first unshifted, then shifted)
shift [< >] z x c v b n m [, ;] [. :] [- _] shift
Using such a keyboard, using dash or underscore takes the same effort.

>>5
You'dPreferACamelCase
No, I'dPreferAHaskal
:(

>>44
I'd want to fix up the names of standard functions as well. There's not much point to only doing my own function names. Also, your suggestion requires ugly “||”, which also require extra work to type and require backtracking if you forget to begin with them.

>>45
No, I mean a language where '-' is an operator and can be between two identifiers without mandatory whitespace.
So... a language with insane tokenizing rules. Don't make the stupid assumption that being an operator (and having a precedence) means you don't need space around it. Everybody always says that it's best to put spaces around arithmetic operators. It's best to require spaces to enable something people actually want to do (flexible names) rather than not requiring them so you can write in a style everyone agrees is bad.

>>45
Using such a keyboard, using dash or underscore takes the same effort.
Except for the part where it takes a whole extra key to type “_”?

>>47
It's best to require spaces to
Just like it's best to require indentation, right?

a style everyone agrees is bad
Again, subjective. I train my eyes by never using whitespace around operators other than boolean ones no matter how complex the expression becomes.

Except for the part where it takes a whole extra key to type “_”?
Please.

The more I read this thread, the more I think that OP is Mr. Void. By the power of JS, thread away!

>>1 Just start every token woth a $

($defun $add to deck ($card $deck)
  $etc.)

>>51
It's like this is PHP.

Serious answer:
Adding $ or double spaces increase the amount of characters/keys you need to type and decrease readability. It would probably not require too much changes to the reader to implement, but why? Did you just start learning CL that you're so bothered by this? Escaping symbols with |...| is easy if that's what you want, no different from using (). Just rebind the || keys to something else if you use them to often, and make Emacs dim the || and () characters, so you wouldn't pay that much attention to them.

>>49
i was thinking the exact same thing.

>>48
Just like it's best to require indentation, right?
Sigh. No. This is a trade-off, and only an idiot would wreck all variable names in favor of a style that everybody (including me) recommends against.

Again, subjective. I train my eyes by never using whitespace around operators other than boolean ones no matter how complex the expression becomes.
Look at you: willing to train your eyes to do something completely stupid just to justify misfeatures, but unwilling to train them to do something for a good end.

>>51
Escaping symbols with |...| is easy if that's what you want, no different from using ().
If that were what I wanted, would there have been any need for this thread? Maybe you just started learning CL, but that messes with a symbol's case. Plus it's even uglier than using non-spaces to do a space's job.

>>49,52
Ouch. FV doesn't even know how to quote and can barely write in English. Of course, I wouldn't expect someone too dense to see the brilliance of this idea to have noticed.

brilliance of this idea
:)

>>53
but that messes with a symbol's case
A symbol is upcased by default ,because the value of (readtable-case *readtable*) is :UPCASE.
Hyperspec section 23.1.2 describes other values possible for this accessor.
Quoting a symbol's name with || does not affect its case, so all one has to do to use the symbol is to just provide it quoted as it was first defined. What is the problem with that?

I did start to learn CL recently, but I don't see any problem with the way I understand how the reader treats symbols, do you believe I misunderstood something?

I might have used a wrong term here(quoting), I simply meant the || special syntax for denoting symbols.

>>53
This is a trade-off
the brilliance of this idea
It's a trade-off almost no one is willing to make, and it's a stupid idea. Requiring a minimum amount of whitespace around tokens is the worst possible turn any language definition can take. Tomorrow, some idiot will come and say "I want to have identifiers with two spaces". If you're not willing to increase the minimum, it proves that the definition is flawed. Why the arbitrary limit? Why two spaces but not three? Why n but not n+1?
It's a worthless feature and your users will hate you for forcing them to always hit the space bar one more time than necessary (because no one in their right mind would put a space in the middle of an identifier).

Look at you: willing to train your eyes to do something completely stupid just to justify misfeatures, but unwilling to train them to do something for a good end.
Less whitespace==more code on screen.
More whitespace==more clarity
Optional whitespace==I have the choice to add code or add clarity
Mandatory whitespace==I have no choice but to add whitespace even if it's clear

>>57
It's a trade-off almost no one is willing to make, and it's a stupid idea.
Apparently it's a trade-off everyone is willing to make, but I agree it's stupid.

great idea bro you should do it

>>59
Thanks man; I think I will.

HEY GUYS, IM A NEWFAG HERE TO DESTROY 4CHAN

HEY GUYS, IM A NEWFAG HERE TO DESTROY 4CHAN

test

replace () with []

>>64
Would look uglier. Better idea which most Lisp programmers use:
rebind [] to () and use paredit-mode, with some chords adjusted to match new rebinded keys.

<-- check em dubz