On Sun, 2012-05-06 at 12:54 -0700, Steve Haflich wrote:

I'm mildly opposed to trying to impose syntax extensions on the language if the only motivation is slight convenience. ANSI CL is 20 years old, and there are a lot mostly-conforming but old and unsupported implementations out there, and this syntax won't work out of the box.

I personally don't care about about modern code being able to run on old implementations, only(if slightly) about old code running on modern implementations, so continuously adding features is fine.

Besides, I find that feature expressions like #+never #+notyet # +nomore or #+bug456 provide useful self documentation about conditionals, while we programmers are often lazy about adding real documentation about changes.

It's difficult to put all necessary explanation inside a single symbol, even a Haiku requires two verses

But if you really like this syntax, there is nothing in the ANS that would preclude a source module from including the necessary read-time set-dispatch-macro-char call early in its own source.

Module-local syntax would be nice, but there is currently no editor(Emacs) and ASDF support for that so I won't use it

And if all you are concerned about is that someone might have pushed :NIL onto the features list, the syntax #+(or) is logically and portably unscrewable. I know programmers who use it, although I find it lexographically tedious. If God had intended me to spend so much time and energy engaging the shift key, he would have given me three thumbs or he would have given all computers Lispm keyboards.

Many Europeans(like me) manage to write CL even if #( is shifted, and ## is on AltGr

On 7 May 2012, at 00:54, Faré wrote:

...

...

But if you really like this syntax, there is nothing in the ANS that would preclude a source module from including the necessary read-time set-dispatch-macro-char call early in its own source.

Module-local syntax would be nice, but there is currently no editor(Emacs) and ASDF support for that so I won't use it

1- Since ASDF 2.019, there is support for :around-compile, that allows you to effectively redefine syntax around a module. Combined with reader-interception, you can portably redefine your syntax to be that of e.g. python, or whatever you fancy. You know where to find emacs modes.

This seems to suggest that this only works for compiled code. What about interpreted code?

2- Since well before that, there is named-readtables. I recommend you make your #; syntax available as a named readtable.

3- You can always define a new subclass of cl-source-file, that gets compiled within proper syntax redefinition.

Yes, there are a lot of ways to implement this. But that's my primary interest (the implementation is trivial).

Pascal

-- Pascal Costanza

Pascal Costanza pc-99OXBJU6cIpeoWH0uzbU5w@public.gmane.org writes:

...

Yes, there are a lot of ways to implement this. But that's my primary interest (the implementation is trivial).

Pressed the send button too fast: That's _not_ my primary interest…

The implementation may be trivial, but its effects are not.

(prog1 #; #-(and) 42 11)

(prog1 #; #; 42 11)

depending on how it's specified may return a surprising result. Ie. the specification of #; would need more than the given one-liner.

Since commenting-out an expression is not meant as a comment, but merely disabling TEMPORARILY the experession (while debugging/developping), IMO, it should not use a comment syntax. #; is too close to the ; character used for real comments.

I'd even argue that those "commented-out" expressions should not stay in the sources. If we used them it's only because of a deffect of our IDEs/VCS. (You could just delete them, and use the VCS to recover them when needed).

With that in mind, #-(and) or #+(or) are not bad: they stand out and they make you wonder if you should not just delete the expression.

...

1- Since ASDF 2.019, there is support for :around-compile, that allows you to effectively redefine syntax around a module. Combined with reader-interception, you can portably redefine your syntax to be that of e.g. python, or whatever you fancy. You know where to find emacs modes.

This seems to suggest that this only works for compiled code. What about interpreted code?

I don't know what you call "compiled code", but if that's what you mean, the perform method of load-source-op also does call that hook.

...

2- Since well before that, there is named-readtables. I recommend you make your #; syntax available as a named readtable.

3- You can always define a new subclass of cl-source-file, that gets compiled within proper syntax redefinition.

Yes, there are a lot of ways to implement this. But that's my primary interest (the implementation is trivial).

The question is how to provide a modular interface to this and other extensions. So far, named-readtables is your best bet for simple reader macros, and reader-interception if you need a complete syntax redesign.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org What is mind? No matter! What is matter? Never mind! — Bertrand Russell's Grand Mother, In Karl Popper, The Unended Quest

On Mon, May 7, 2012 at 2:01 PM, David McClain dbm@refined-audiometrics.comwrote:

To be clean, you'd need to update the CL editors so that they don't see the entire remainder of the line as a comment if the Sexpr occupies less than the remainder of the line, and do see whatever following lines are contained in Sexpr as a comment. But otherwise, I'm in favor of whatever makes life easier in programming.

So am I, but then, this particular plan does not seem to make life much easier at the expense of creating work for IDE implementers. I'm not saying that it is a lot of work, but then, I think #+(or) or #+(and) is clear enough. One can always create some editor macro that expands #; one of that and be done with that.

-Hans

On 6 May 2012 21:54, Steve Haflich shaflich@gmail.com wrote:

And if all you are concerned about is that someone might have pushed :NIL onto the features list, the syntax #+(or) is logically and portably unscrewable.  I know programmers who use it, although I find it lexographically tedious.

FWIW, I personally use #-(and) and #+(and) -- the #+ and #- signs are pretty easy to relate to the semantics.

-- Jānis

On 6 May 2012, at 21:26, Willem Broekema wrote:

On Sun, May 6, 2012 at 8:57 PM, Pascal Costanza pc@p-cos.net wrote:

...

Currently, if you want to comment out a form from CL code, there is no standard way of doing this. Many people use something like #+nil, or similar tricks, but this is not 100% reliable. R6RS Scheme introduced #; as a solution, and this seems to become somewhat popular in CL as well.

How would

#; expression

differ from

#+(or) expression

which is 100% reliable and standard?

It's probably just me, but I find #+(or) and #-(and) confusing - I always have to stop at such a place for a minute to think about what the actual outcome is...

Pascal

-- Pascal Costanza

In my view, #; would be handy: #+(or) trips me up visually and is an idiom. I would rather remember that #; is a nulled/commented out form (like ; is for lines), and reserve #+(or) for connoting other things.

I would not be horrified if it did not get implemented, but I think I would be prone to use it.

I don't remember seeing a reference implementation link. I would like to experiment with using one if it exists.

Regards, Paul Nathan

On Tue, May 8, 2012 at 12:49 PM, Steve Haflich shaflich@gmail.com wrote:

Assuming you are a Common Lisp programmer, implementation is a two liner.

The question under discussion in this thread is not about implementation difficulty. It's about whether this syntax is attractive enough, unambiguously understandable enough, and would likely become widely enough adopted to become part of the portable understood-by-everyone-at-sight language.

A more important question, to me, is how would such a language relate to Common Lisp.

Is the point to just write a .asd system that exports the functionality through named-readtables? If so, there is nothing to discuss here. Just do it and announce your system.

Is the point to evolve the Common Lisp standard into some kind of CLtL4, and leave behind other implementations as only being ansi-common-lisp? I just don't see that happening, what with 9 active implementations to coordinate.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Moderation in temper is always a virtue; but moderation in principle is always a vice. — Thomas Paine

On 8 May 2012, at 20:02, Alessio Stalla wrote:

On topic: the proposed syntactic addition is nice, but imho too trivial and too easily provided as a library to bother with a CDR (that would need to be included in each implementation).

Interesting discussion so far. (Alessio, I'm not responding to you directly, just as a stub for the discussion, so to speak… ;)

I can perfectly understand those who voiced their opinion that the existing mechanisms for commenting out s-expressions are good enough. (I especially liked the #+| here is a bug | variant that puts a comment in the feature expression.)

However, the suggestion that #; could just be put in a library is not a valid counter argument. The main reason for adding #; to a specification (and thus suggesting it as a quasi-standard for the language) is that it should be straightforward and simple to use it. Adding #; in any way makes only sense if it can be used in a considerably faster way than any other of the existing options. If I want to comment out an s-expression, I probably want to do this during development because I quickly want to try out a variant of my code. I don't want to be interrupted in my flow of thinking about the problem at hand when doing so. That's the very reason why I never use the #+(and) and #-(or) options, because they require me to think at least for a few seconds which way the operators go, and that disrupts what I'm actually interested in [1]. Likewise, I think, with the other options. I already find that placing a pair of #| |# around the s-expression in question takes far too much time than necessary.

I haven't decided yet whether I should go forward with the CDR or not...

Pascal

[1] They are intentionally chosen wrong in this sentence, and if you missed that, it proves my point.

-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.

On 13 May 2012 19:47, Pascal Costanza pc@p-cos.net wrote:

On 8 May 2012, at 20:02, Alessio Stalla wrote:

...

On topic: the proposed syntactic addition is nice, but imho too trivial and too easily provided as a library to bother with a CDR (that would need to be included in each implementation).

Interesting discussion so far.

I'm sorry I'm contributing to this boring discussion. But I think it is turning from boring into entertaining.

I can perfectly understand those who voiced their opinion that the existing mechanisms for commenting out s-expressions are good enough. (I especially liked the #+| here is a bug | variant that puts a comment in the feature expression.)

However, the suggestion that #; could just be put in a library is not a valid counter argument. The main reason for adding #; to a specification (and thus suggesting it as a quasi-standard for the language) is that it should be straightforward and simple to use it.

That's exactly the reason why it should not be added to the specification since it already provides means of addressing the issue.

Adding #; in any way makes only sense if it can be used in a considerably faster way than any other of the existing options.

I already use a single key (M-; - paredit-comment-dwim) key for my commenting needs. If I was commenting out single expressions frequently enough, I'd probably assign it to a key, too (probably C-M-; - which would be consistent with other key bindings that act on expressions). Therefore I do not see how using #; as instead of #-(and) or #+(or) would be "considerably faster", since I expect the editor to insert all of them with the same percievable speed.

If I want to comment out an s-expression, I probably want to do this during development because I quickly want to try out a variant of my code. I don't want to be interrupted in my flow of thinking about the problem at hand when doing so.

Yes, the keyboard shortcuts have a tendency to get into the subconscious so we don't think about them at all.

That's the very reason why I never use the #+(and) and #-(or) options, because they require me to think at least for a few seconds which way the operators go, and that disrupts what I'm actually interested in [1].

As I already noted, I personally use #-(and) when I do need/want to comment out a [lengthy] expression. And I will teach you a trick I have learned from other great minds that will allow you to deal with this little inconvenience. It takes two steps:

1. Try to associate the "minus" sign with removing something, and "plus" sign with adding something.

2. Forget about (or), and use only (and).

You're done. Now, if you want to remove an expression, you use #-(and) (notice the minus sign!). If you want to have it back [temporarily], you change that to #+(and) (see, the minus has been changed into plus!).

Also, if the association in step 1 somehow contradicts your experience, and is the other way around, all you have to do is forget about (and) and use (or) instead.

In any case, this is a one time investment, and you think about it only once, and then use for the rest of your life. I accept your advance gratitude on all the hours you will save not thinking about this issue in your future programming endeavours. You are welcome!

Likewise, I think, with the other options. I already find that placing a pair of #| |# around the s-expression in question takes far too much time than necessary.

Yes, using this facility also is troublesome for different reason: in my experience it has confused the editor on too many occasions that I have completely stopped using it. Not that I miss it since I learned of M-; (usually used in together with expression selection commands).

[1] They are intentionally chosen wrong in this sentence, and if you missed that, it proves my point.

Now that I have revealed my secret trick, you yourself can see that your point is not only not proven, but the very existence of it is in question.

-- Jānis

Meta: it's one thing to talk about things some people consider inconsequential. It is another to sidetrack that discussion to be about whether it is inconsequential or not.

Just saying.

There aren't too many CDRs. It doesn't matter if they aren't earth shaking or if they're something that can live in libraries. Let's have some more. Sturgeon's Law applies to everything, even Lisp.

Cheers,

-- nikodemus

(Though if I had to vote on "what sort of CDR should Pascal Costanza write", I would vote on something CLOS or MOP related... :))