Square brackets?
netytan
several scheme sources, but they're not in the R5RS standard - I
don't think. They're not supported by all Scheme implementations
anyway.
Are there any perhaps in some other standard or are they already
standard but optional?
Just for my general knowledge :),
Thanks guys,
Mark.
Pascal Bourguignon
> Possibly a silly question but I've seen square brackets being used in
> several scheme sources, but they're not in the R5RS standard - I
> don't think. They're not supported by all Scheme implementations
> anyway.
>
> Are there any perhaps in some other standard or are they already
> standard but optional?
Some implementations accept them with the same meaning as parentheses.
They're usable interchangeably, but must still match:
([]) is valid, but ([)] is not.
Some people have this silly idea that counting and matching
parentheses is important and like to spend hours on it...
I prefer to use only parentheses and let emacs do the indentation and
parenthesis checking for me.
--
__Pascal Bourguignon__ http://www.informatimago.com/
What is this talk of 'release'? Klingons do not make software 'releases'.
Our software 'escapes' leaving a bloody trail of designers and quality
assurance people in it's wake.
hWnd
answer in a cond expression:
(cond
[(<question>)
(<answer)])
Anton van Straaten
> Possibly a silly question but I've seen square brackets being used in
> several scheme sources, but they're not in the R5RS standard - I
> don't think. They're not supported by all Scheme implementations
> anyway.
>
> Are there any perhaps in some other standard or are they already
> standard but optional?
It's been announced that they'll be standard in R6RS.
The usual convention for use of square brackets is in cases where the
bracketed expressions don't represent a procedure application. Instead,
the brackets are used to delimit groups of expressions in a macro, to
make the groups easier to distinguish visually. They also tend to
reduce ambiguity, which can help an automated paren matcher match more
intelligently.
A couple of typical examples:
(cond
[(foo) (bar)]
[(baz)
(quux ziiy)]
[else (blurk!)])
(let-values ([(f g) (get-two-values)]
[(a b c) (get-three-values)]
[(h) (get-value)])
(list a b c f g h))
--
Anton
Andre
>
> netytan wrote:
> > Possibly a silly question but I've seen square brackets being used in
> > several scheme sources, but they're not in the R5RS standard
>
I find them jarring, but if R6RS passively allows them, I would
not have any complaint. However, I hope that R6RS will not
actively advocate them.
Andre
Pascal Bourguignon
I assume you mean:
(let-values [[(f g) (get-two-values)]
[(a b c) (get-three-values)]
[(h) (get-value)]]
(list a b c f g h))
But let-values is not a procedure applications either. Let's write:
[let-values [[(f g) (get-two-values)]
[(a b c) (get-three-values)]
[(h) (get-value)]]
(list a b c f g h)]
--
__Pascal Bourguignon__ http://www.informatimago.com/
CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.
Jens Axel Søgaard
> Anton van Straaten <an...@appsolutions.com> writes:
>>Instead, the brackets are used to delimit groups of expressions in a
>>macro, to make the groups easier to distinguish visually. They also
------
> But let-values is not a procedure applications either. Let's write:
--
Jens Axel Søgaard
netytan
however a friend of mine was using them in a config file for a program
he was working on. Obviously this would limit which Scheme
implementations the code would run on and it got me curious.
If they're put in R6RS I don't think I'll use them in my code anyway
but still. Does anyone know when R6RS is due?
Actually, is there anywhere that I can read about what's going to be
included in R6RS; I'm hoping a standard FFI but I doubt it.
Thanks a lot for all the replies,
Mark.
Abdulaziz Ghuloum
No, that's not what Anton meant.
> But let-values is not a procedure applications either. Let's write:
>
> [let-values [[(f g) (get-two-values)]
> [(a b c) (get-three-values)]
> [(h) (get-value)]]
> (list a b c f g h)]
and neither is this. You already stated your opinion twice in this
thread and what *you* think about square brackets has nothing to do
with the original question. Anton's response, on the other hand, was
on topic (by mentioning that they're in the upcoming standard and
that their use is a usual convention in such and such situations).
So, please, spare us the ``my parens are better than your brackets''
silliness. Some people like them and you don't. Live with it.
Aziz,,,
Anton van Straaten
I think the main idea is to allow code which uses them to be portable,
so I don't expect there'll be much by way of active advocacy.
Anton
Anton van Straaten
> So, please, spare us the ``my parens are better than your brackets''
> silliness. Some people like them and you don't. Live with it.
Indeed. Besides, the true Schemer ought to be able to see past a
program's textual representation, to the Platonic perfection of the
abstract syntax, which is unaffected by which character set happens to
have been used to serialize the program.
Anton
Anton van Straaten
> Does anyone know when R6RS is due?
>
> Actually, is there anywhere that I can read about what's going to be
> included in R6RS; I'm hoping a standard FFI but I doubt it.
A standard FFI isn't planned. For info on the status of the R6RS, see:
http://www.schemers.org/Documents/Standards/Charter/
...particularly the Editors' Progress Report.
Anton
Bruce Lewis
> Indeed. Besides, the true Schemer ought to be able to see past a
> program's textual representation, to the Platonic perfection of the
> abstract syntax, which is unaffected by which character set happens to
> have been used to serialize the program.
True Schemers don't mind XML? I don't think I'll ever get there.
Thomas Hafner
> Pascal Bourguignon wrote:
> > Anton van Straaten <an...@appsolutions.com> writes:
> >>
> >>The usual convention for use of square brackets is in cases where the
> >>bracketed expressions don't represent a procedure application.
> > [...]
> > [let-values [[(f g) (get-two-values)]
> > [(a b c) (get-three-values)]
> > [(h) (get-value)]]
> > (list a b c f g h)]
> and neither is this. You already stated your opinion twice in this
> thread and what *you* think about square brackets has nothing to do
> with the original question.
I cant's see that Pascal stated his opinion again. He rather showed
how to take Antonins' statement (``The usual convention ...'', see
above) literally. I'd expect Antonins' statement to be criticized, if
Pascal's correct conclusion is disliked - rather than bashing Pascal.
Thomas
Anton van Straaten
Note that I didn't say "in every case", and the fact that the examples
implied exceptions to the stated rule was communicative. The human
ability to usefully extrapolate from examples is profound, and I commend
its use.
Anton
Anton van Straaten
OK, make that "which within reason, is unaffected..."
I wasn't considering syntaxes from the Dungeon Dimensions!
Alex Shinn
>
> Indeed. Besides, the true Schemer ought to be able to see past a
> program's textual representation, to the Platonic perfection of the
> abstract syntax, which is unaffected by which character set happens to
> have been used to serialize the program.
Indeed. I was under the impression that any experienced Schemer
doesn't even see parentheses, but looks solely at the indentation.
At least this is the argument often given to people complaining
about all of Lisp's Irritating Silly Parentheses.
But by this reasoning the brackets are just needless syntactic
sugar. Or possibly worse - my eyes glaze over parentheses without
registering them, but I find it harder to ignore mixed parens and
brackets since it's not uniform.
In a language that prizes minimalism you need a very good argument
to include syntactic sugar, and especially so if many people disagree
as to whether that syntax even makes things any easier to read.
The only advantage I can see for square brackets is it can be less
confusing for rank beginners. The vast majority of beginners are
confused by LET and COND groupings, and using brackets can help them
remember the right syntax. And having a strong history as a
teaching language, we shouldn't ignore beginners. But to me this
still isn't a strong enough reason to add controversial syntax.
--
Alex
Anton van Straaten
> But to me this
> still isn't a strong enough reason to add controversial syntax.
A number of important Scheme implementations already support the syntax,
so you'd need to go back in time to really affect this. One of the
goals of the R6RS is to avoid needless differences which reduce the
portability of code (even beginners' code). No-one is being forced to
use brackets, but the R6RS will allow code which uses brackets to run in
R6RS-compliant Schemes.
Anton
Lauri Alanko
Anton van Straaten <an...@appsolutions.com> wrote:
> The usual convention for use of square brackets is in cases where the
> bracketed expressions don't represent a procedure application.
Although I dislike square brackets, I think that the biggest problem
with Scheme syntax is that function applications and other compound
syntactic forms aren't visually distinguished in any way. If square
brackets were consistently used for everything that's not function
application, I'd view them more favorably. But that would mean that
instead of
> (cond
> [(foo) (bar)]
> [(baz)
> (quux ziiy)]
> [else (blurk!)])
>
> (let-values ([(f g) (get-two-values)]
> [(a b c) (get-three-values)]
> [(h) (get-value)])
> (list a b c f g h))
one would write:
[cond
[(foo) (bar)]
[(baz) (quux ziiy)]
[else (blurk!)]]
[let-values [[[f g] (get-two-values)]
[[a b c] (get-three-values)]
[[h] (get-value)]]
(list a b c f g h)]
I haven'seen this kind of usage anywhere, though.
Lauri
Pascal Bourguignon
As you explain above, mixing brackets and parethenses is hard on the
eyes. I'm not sure it's a favor we're doing to the beginners
proposing them these brackets. I agree that it may be helpful to make
the structure stand out more clearly for beginners, but this is the
IDE should do, not the language itself. The IDE can display external
parentheses in a bigger font than the internal ones, or can use colors
to match open and close parentheses. This would really be helpful to
newbies and let them become proficient faster, IMO, than mixing
brackets and parentheses.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Jorgen Schaefer
> I prefer to use only parentheses and let emacs do the
> indentation and parenthesis checking for me.
For us poor victims of the Bracket Conspiracy there is hope, since
we, the followers of the Church of Emacs, are never alone. And
see, Emacs gives us light, to see the Paren where a Paren should
be seen:
(defun hide-brackets ()
"Show brackets as parens."
(interactive)
(font-lock-add-keywords
nil '(("\\["
(0 (progn (compose-region (match-beginning 0) (match-end 0)
"(")
nil)))
("\\]"
(0 (progn (compose-region (match-beginning 0) (match-end 0)
")")
nil)))))
(font-lock-fontify-buffer))
But HIS wisdom permeates the world, and he sees even the structure
of reality. HE is the lambda and the kappa, the beginning and the
end, and when HE says LET THERE BE PARENS, lo and behold, there
ARE parens!
(defun fix-brackets ()
"Replace brackets outside of strings and comments with parens."
(interactive)
;; This can be called in a hook before font lock mode has a chance
;; to run, but we need its information. So we enforce a font lock
;; run.
(font-lock-fontify-buffer)
(save-excursion
(goto-char (point-min))
(while (re-search-forward "[][]" nil t)
(let* ((bracket (match-string 0))
(face (get-text-property 0 'face bracket)))
(cond
((or (looking-back "#\\\\[][]") ; character literal
(eq face 'font-lock-comment-face)
(eq face 'font-lock-string-face))
;; Do nothing
nil)
((string= "[" bracket)
(replace-match "("))
((string= "]" bracket)
(replace-match ")"))
(t
(error "Bad token: %s (This is a CAN'T-HAPPEN type of error)"
bracket)))))))
Behold HIS powers, for they are endless.
Regards,
-- Jorgen
--
((email . "for...@forcix.cx") (www . "http://www.forcix.cx/")
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
Ray Dillinger
> In article <4E57g.27557$NS6....@newssvr30.news.prodigy.com>,
> Anton van Straaten <an...@appsolutions.com> wrote:
>
>>The usual convention for use of square brackets is in cases where the
>>bracketed expressions don't represent a procedure application.
>
>
> Although I dislike square brackets, I think that the biggest problem
> with Scheme syntax is that function applications and other compound
> syntactic forms aren't visually distinguished in any way. If square
> brackets were consistently used for everything that's not function
> application, I'd view them more favorably.
I definitely agree.
Bear
Alex Shinn
>
> A number of important Scheme implementations already support the
> syntax, so you'd need to go back in time to really affect this.
And several don't. If R6RS included every extension made to
existing Scheme implementations it would be a mess.
> No-one is being forced to use brackets, but the R6RS will allow
> code which uses brackets to run in R6RS-compliant Schemes.
Yes, people _will_ be forced to use brackets. When several people
get together on a project they will have to decide on whether or not
to use brackets, and some people will win and some will lose.
Decades before Python was even conceived of, Lisp code formatting
style was set in stone and without any of the whitespace issues
Python has. There was only one style and there were no decisions to
be made. Now we will be relegated to the bickering and formatting
wars found only in lesser languages.
It's true the damage is already partly done because many
implementations recognize brackets as parens, but this alone is no
reason to make it standard. If it is *not* standard, then any large
collaborative project would by nature stick to the portable syntax.
People who prefer brackets could continue to use them privately on
their own projects with their own Scheme implementations if they so
choose, but there's no room for debate.
Scheme has enough Holy Wars as it is. R6RS does a great disservice
to the Scheme community with this decision.
--
Alex
Abdulaziz Ghuloum
> Anton van Straaten wrote:
>
>>A number of important Scheme implementations already support the
>>syntax, so you'd need to go back in time to really affect this.
>
>
> And several don't. If R6RS included every extension made to
> existing Scheme implementations it would be a mess.
I wouldn't generalize adding [] to adding every extension made to
existing Scheme implementations. The brackets exist not only in
implementations but in many Scheme books as well.
>>No-one is being forced to use brackets, but the R6RS will allow
>>code which uses brackets to run in R6RS-compliant Schemes.
>
> Yes, people _will_ be forced to use brackets. When several people
> get together on a project they will have to decide on whether or not
> to use brackets, and some people will win and some will lose.
I have worked with several people on projects and on large projects
with many developers, coding standards may be established. This is
true no matter what language you choose for the project. As far as
Scheme projects are concerned, developers (or management, etc.) may
choose to standardize on several issues including:
Documentation style: Are comments included on top of a function or
in a docstring style? Do you use three-semi comments, or one-semi
etc.? Do you use external documentation tools? ...
Declaration style: Do you (define (foo . args) [...]) or do you have
to use an explicit lambda?
Macros: Can you use macros? |syntax-rules| only? |syntax-case|?
|def-syntax|?
Case/Naming: Is there a convention for using lower-case, ALL-CAPS,
CamelCase, lowCamelCase, *parameters*, +constants+, etc.? Are
lists of things identified by name (foo-list, foo*, foo-ls, foos,
...)? Are there any ``reserved'' names that you cannot use?
Indentation: There are many ways to indent forms (special forms
and function applications):
(head arg1
arg2
...
argn)
(head arg1
arg2
...
argn)
(head
arg1
...
argn)
Implementation-dependent features: Can you use nonstandard features
such as module systems, object systems, contracts, units, FFI, ...?
How is testing/QA performed? ...
And the list goes on and on. For each of these decisions, "some
people will win and some will lose." I don't see how brackets
aggrivate the situation really.
> Decades before Python was even conceived of, Lisp code formatting
> style was set in stone and without any of the whitespace issues
> Python has. There was only one style and there were no decisions to
> be made. Now we will be relegated to the bickering and formatting
> wars found only in lesser languages.
Formatting wars are waged by people, not languages. We can still be
civilized even if there are two ways to write nil.
> It's true the damage is already partly done because many
> implementations recognize brackets as parens, but this alone is no
> reason to make it standard. If it is *not* standard, then any large
> collaborative project would by nature stick to the portable syntax.
> People who prefer brackets could continue to use them privately on
> their own projects with their own Scheme implementations if they so
> choose, but there's no room for debate.
Any large collaborative project sticks to whatever standards and goals
they set for themselves. The Scheme standard has nothing to do with
this.
> Scheme has enough Holy Wars as it is. R6RS does a great disservice
> to the Scheme community with this decision.
I don't see the disservice. After-all R6RS is not a holy-[torah, bible,
quran, ...] for all to follow. It's just a standard that, when adopted
by some implementation, sets the record straight of what users would
expect and what the implementation should provide at a minimum. Heck,
most implementations are not even R5RS-compliant, let alone R6RS. So
if someone comes along and writes ``the toy-scheme standard'', ``the
industrial-scheme standard'', ``the embedded-scheme standard'', ``the
pure-scheme-as-steele/sussman-never-intended standard'', etc. and there
are implementations that follow such standards, then that won't be bad
either. And if someone comes and defines a scheme standard that has
infix syntax and no sexprs (like Dylan), then that's good too. This is
Scheme we're talking about: a language where diversity is the norm, a
language where every other person speaks a third dialect, and a language
where half the users are implementors.
Aziz,,,
Rob Thorpe
> Anton van Straaten wrote:
> >
> > Indeed. Besides, the true Schemer ought to be able to see past a
> > program's textual representation, to the Platonic perfection of the
> > abstract syntax, which is unaffected by which character set happens to
> > have been used to serialize the program.
>
> Indeed. I was under the impression that any experienced Schemer
> doesn't even see parentheses, but looks solely at the indentation.
> At least this is the argument often given to people complaining
> about all of Lisp's Irritating Silly Parentheses.
This is definitely the best way to read scheme and lisps in general.
It suffers from two flaws though
1) It becomes difficult to handle when there is a lot of indentation.
I.e. things indented say 50 columns across the screen. The normal
Scheme usage of indentation means this happens quite often. More
parens give you the opportunity to do things to avoid this. For
example when indentation must wrap around, changing the type of braces
used.
2) When you finish a line you must do two things:-
A. Finish the parens for that line
B. Finish the parens for all enclosing blocks
I do A by counting parens from the left of the current line and typing
them on the right. Or more normally, by just typing them and using
show-paren mode.
I do B by closing the number of parens the expression is indented by,
ie if it's indented 6 times, typing 6 closing parens, and looking at
where they close with show-paren mode.
I expect other people do something similar.
The problem with this is that it means you end lines with something
like:-
0))))))))
Which is fine, but all the information found by the above process is
lost. To avoid this you can write:-
0]]]]))))
Using [] to close expression on the same line and () to close
expressions spanning lines.
This makes it obvious that you insert code at the end of the "]]]" to
change the block and before their end to change the current line.
Overall the benefit is that it gives you more scope to lay data out in
an informative way.
MJ Ray
> A number of important Scheme implementations already support the syntax,
I would, but I broke the time machine next week.
Square brackets are jarring. The unusual implementations should
get back in line and not do a "browser wars" on RnRS like this.
Abdulaziz Ghuloum
Come on people! Nobody is going to war over such a silly thing.
Or let me ask this: Are there any *implementors* of major (i.e. more
than 10 users) R5RS-conforming implementations who feel so strongly
against brackets that they won't adopt R6RS because of it?
Aziz,,,
Abdulaziz Ghuloum
> Square brackets are jarring. The unusual implementations should
> get back in line and not do a "browser wars" on RnRS like this.
Oh yes, forgot to ask: What's your definition of "unusual
implementations"?
Out of the five implementations I have on my machine (Chez, MzScheme,
Guile, Chicken, Scheme48), four support square brackets already. None
of these implementations is "unusual" as far as the dictionary definion
goes (i.e not usual : UNCOMMON, RARE according to
http://www.m-w.com/dictionary/unusual )
Aziz,,,
Alex Shinn
>
> I have worked with several people on projects and on large projects
> with many developers, coding standards may be established. This is
> true no matter what language you choose for the project.
Coding standards is a very broad term, and you render it meaningless
for useful discussion by applying it to every decision a programmer
could possibly make. But then, I started it :)
I should have been a little more clear about where I was coming
from. I was thinking specifically of the following article:
http://www.artima.com/weblogs/viewpost.jsp?thread=74230
There's a certain level of base coding style, usually things handled
automatically by your editor, that pretty much everyone standardizes
on when collaborating in a project. Some groups may also go to the
further extent of things like variable naming conventions, and
languages like Python take it as a philosophy to provide only one
way to do anything, but that's less common and not what I'm talking
about.
Brackets vs. non-brackets is one of those things that people fairly
universally will standardize on when starting a large project
together. I've _already_ been forced to use brackets when patching
other people's code, and know at least one other person who has had
to consent to use brackets starting a new project even though he
dislikes them.
This alternative gains you nothing. It's entirely subjective
whether brackets or parens looks better, just as it is whether K&R C
style looks better than GNU or any of the other half dozen common C
styles. By introducing a choice here you do nothing to help
Scheme's "diversity" in any useful way, and introduce for the first
time a real style difference in Scheme code.
--
Alex
Bruce Lewis
> MJ Ray wrote:
>
> > Square brackets are jarring. The unusual implementations should
> > get back in line and not do a "browser wars" on RnRS like this.
>
> Come on people! Nobody is going to war over such a silly thing.
I'll fight as a mercenary for whichever side pays me more. Until the
check clears I'm firmly neutral on whether this should be part of R6RS.
Paypal accepted too. No refunds.
MJ Ray
> MJ Ray wrote:
> > Square brackets are jarring. The unusual implementations should
> > get back in line and not do a "browser wars" on RnRS like this.
>
> Come on people! Nobody is going to war over such a silly thing.
Please go look up what the browser wars were. They were not literal
wars, hence the quoting. They were the dark days where browser makers
tried to one-up each other and the standards track tried to make sense
of the mess it helped make. http://www.webstandards.org/about/mission/
> Oh yes, forgot to ask: What's your definition of "unusual
> implementations"?
Ones that support bizarre extensions.
> Out of the five implementations I have on my machine (Chez, MzScheme,
> Guile, Chicken, Scheme48), four support square brackets already. None
> of these implementations is "unusual" as far as the dictionary definion
> goes (i.e not usual : UNCOMMON, RARE according to
> http://www.m-w.com/dictionary/unusual )
M-W is not an English dictionary. Try dictionary.cambridge.org :-
unusual - adjective,
different from others of the same type in a way that is surprising ...
--
MJR/slef
Emilio Lopes
> For us poor victims of the Bracket Conspiracy there is hope, since
> we, the followers of the Church of Emacs, are never alone. And
> see, Emacs gives us light, to see the Paren where a Paren should
> be seen:
> (defun hide-brackets ()
> "Show brackets as parens."
> [...]
Amen, brother! :-)
--
Emílio C. Lopes
Munich, Germany
Emilio Lopes
> As you explain above, mixing brackets and parethenses is hard on the
> eyes. I'm not sure it's a favor we're doing to the beginners
> proposing them these brackets. I agree that it may be helpful to make
> the structure stand out more clearly for beginners, but this is the
> IDE should do, not the language itself. [...]
Hear, hear! This reminds me of stupid German MUAs which not only show
"AW:" instead of "Re:" in e-mail replies, but also actually put this
string in the headers. One should clearly differentiate presentation
from content.
Thomas Hafner
> Declaration style: Do you (define (foo . args) [...]) or do you have
> to use an explicit lambda?
I prefer without explicit lambda, if the procedure has no state, but
with explicit lambda, if it has one, e.g.:
(define foo
(let ((state #f))
(lambda args
...)))
Regards
Thomas
Abdulaziz Ghuloum
> Possibly a silly question but I've seen square brackets being used in
> don't think. They're not supported by all Scheme implementations
> anyway.
>
> Are there any perhaps in some other standard or are they already
> standard but optional?
>
> Just for my general knowledge :),
>
> Thanks guys,
>
> Mark.
As you can see Mark, when it comes to the color of the bikeshed[1],
everyone has an opinion.
Aziz,,,
Rob Thorpe
> Jorgen Schaefer writes:
>
> > For us poor victims of the Bracket Conspiracy there is hope, since
> > we, the followers of the Church of Emacs, are never alone. And
> > see, Emacs gives us light, to see the Paren where a Paren should
> > be seen:
> > (defun hide-brackets ()
> > "Show brackets as parens."
> > [...]
>
> Amen, brother! :-)
Since the author of the code has tried to give more information to the
reader of the code by using more varied puncutation it seems foolish to
me to throw the information away.
Also, if you do this then you won't be able to replace the brackets and
parens in the right places when changing the code. This would make it
incomprehensible to the next person reading it because the placement of
the brackets would make no sense.
Rob Thorpe
> Abdulaziz Ghuloum wrote:
> >
> > I have worked with several people on projects and on large projects
> > with many developers, coding standards may be established. This is
> > true no matter what language you choose for the project.
>
> universally will standardize on when starting a large project
> together. I've _already_ been forced to use brackets when patching
> other people's code, and know at least one other person who has had
> to consent to use brackets starting a new project even though he
> dislikes them.
>
> This alternative gains you nothing. It's entirely subjective
> whether brackets or parens looks better, just as it is whether K&R C
> style looks better than GNU or any of the other half dozen common C
> styles. By introducing a choice here you do nothing to help
> Scheme's "diversity" in any useful way, and introduce for the first
> time a real style difference in Scheme code.
The issue is not one of whether one style looks better than the other.
Personally I think that using brackets looks horrible. The issue is
about the information that can be displayed by using brackets.
An extra set of parentheses allows useful labels to be embedded in code
showing where things go.
For example in the code given earlier:-
(let-values [[(f g) (get-two-values)]
[(a b c) (get-three-values)]
[(h) (get-value)]]
(list a b c f g h))
It becomes obvious where to add things into the let-values block
without having to count parens.
The issue is really about how people read code. Some people say they
do not need brackets because they can look at something like (((((((
and know between exactly which parens to insert their code. Some other
people, such as me, find this more difficult.
Raffael Cavallaro
> Some people say they
> do not need brackets because they can look at something like (((((((
> and know between exactly which parens to insert their code. Some other
> people, such as me, find this more difficult.
I think it is more commonly asserted that one's editor knows between
exactly which parens to insert code. That said, fwiw - precisely
nothing unless I'm seriously mistaken since this is all a matter of
individual preference - I like having the option to use square brackets
in addition to parens, not because they make modifying code easier - I
think editors take care of this quite nicely - but because they make
reading code easier - one can see the overall structure of the
component parts at a single glance.
Rob Thorpe
> On 2006-05-09 05:21:30 -0400, "Rob Thorpe" <robert...@antenova.com> said:
>
> > Some people say they
> > do not need brackets because they can look at something like (((((((
> > and know between exactly which parens to insert their code. Some other
> > people, such as me, find this more difficult.
>
> I think it is more commonly asserted that one's editor knows between
> exactly which parens to insert code.
Well, Emacs does know where the matching paren for any paren is. If
you ask it, and the only way to ask it is by actually moving the cursor
to where you think is the right place. Other editors may do more I
don't know.
> That said, fwiw - precisely
> nothing unless I'm seriously mistaken since this is all a matter of
> individual preference - I like having the option to use square brackets
> in addition to parens, not because they make modifying code easier - I
> think editors take care of this quite nicely -
That's almost how I see it, if you want to find a place to put
something it helps to be able to see it by looking at the code, rather
than by running the cursor through it to look for the place.
>but because they make
> reading code easier - one can see the overall structure of the
> component parts at a single glance.
Yes, that's also helpful.
Jorgen Schaefer
> (defun hide-brackets () ...)
> (defun fix-brackets () ...)
To whom it may concern: Those definitions are buggy. A much
cleaner implementation is now available at
http://www.emacswiki.org/cgi-bin/wiki/download/bracketphobia.el
That file even allows for the addition of `bracketphobia-auto' to
`find-file-hook', which will then ask the user to clean up any
brackets in the file before loading it.
Rob Thorpe
> Jorgen Schaefer <for...@forcix.cx> writes:
>
> > (defun hide-brackets () ...)
> > (defun fix-brackets () ...)
>
> To whom it may concern: Those definitions are buggy. A much
> cleaner implementation is now available at
>
> http://www.emacswiki.org/cgi-bin/wiki/download/bracketphobia.el
>
> That file even allows for the addition of `bracketphobia-auto' to
> `find-file-hook', which will then ask the user to clean up any
> brackets in the file before loading it.
I don't think this is very helpful. Let's someone X has written some
scheme like this:-
(define (make-sum a1 a2)
(cond [(and (number? a1) (number? a2)) (+ a1 a2)]
[(number? a1) (if (= a1 0) a2 (list '+ a1 a2))]
[(number? a2) (if (= a2 0) a1 (list '+ a1 a2))]
[else (list '+ a1 a2)])) ;; Code nicked of the web somewhere
Then someone else Y reads it using this mode and all the brackets
disappear. Which means Y doesn't know where they are and can't add
them in in the same way.
So when Y edits it he adds another case, but uses parentheses because
he can't tell the difference. The code then is something like this:-
(define (make-sum a1 a2)
(cond [(and (number? a1) (number? a2)) (+ a1 a2)]
[(number? a1) (if (= a1 0) a2 (list '+ a1 a2))]
((number? a2) (if (= a2 0) a1 (list '+ a1 a2)))
[else (list '+ a1 a2)]))
Now, to either X or Y this is very confusing, because there is no logic
behind the placement of the brackets anymore.
It could be worse. I think many scheme programmers add things to the
end of a function by deleting all the parens at the end of a line, then
replacing them all using the editor to guide how many to use. If
programmer Y did that here, then he can't see how to replace them
correctly any more. If he uses parens the function becomes incorrect.
Personally I'd prefer it if scheme programmers who don't like brackets
either 1) put up with them and put them in the right places or 2)
change all the brackets in the code to parens. It would take me, for
one, longer to read the code that way, but it would be preferable to
code with brackets and parens placed in non-sensical ways.
Abdulaziz Ghuloum
> (define (make-sum a1 a2)
> (cond [(and (number? a1) (number? a2)) (+ a1 a2)]
> [(number? a1) (if (= a1 0) a2 (list '+ a1 a2))]
> ((number? a2) (if (= a2 0) a1 (list '+ a1 a2)))
> [else (list '+ a1 a2)]))
>
> Now, to either X or Y this is very confusing, because there is no logic
> behind the placement of the brackets anymore.
Sure there is. You can now tell who wrote each line without resorting
to lame tools like reversion control. :-)
Aziz,,,
Rob Thorpe
A friend of mine - a student of medieval languages - is writing a long
fantasy novel. He has no version control system for the drafts of the
chapters he's written. Instead they are versioned by linguistic drift.
He says things like "Ah this must have been from 2 month ago, just
before I removed the umlauts and changed the names of places in the
west to be more saxon". When challenged that this was "chaotic" he
replied something to the effect that it was supposed to be.
Regarding the brackets. Perhaps the mode would be more useful if it
applied a different face to the brackets. So brackets appear as, say,
green parens.
Pascal Bourguignon
In Common Lisp, I do this using upcase/downcase. From time to time, I
M-x upcase-lisp my lisp sources, and then on, new edits stand out in
low-case ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
Kjetil S. Matheussen
> Alex Shinn wrote:
>> But to me this
>> still isn't a strong enough reason to add controversial syntax.
>
> A number of important Scheme implementations already support the syntax, so
> you'd need to go back in time to really affect this. One of the goals of the
> R6RS is to avoid needless differences which reduce the portability of code
> (even beginners' code). No-one is being forced to use brackets, but the R6RS
> will allow code which uses brackets to run in R6RS-compliant Schemes.
>
Yes, but you could do the complete opposite. Specify that using
square brackets will give an error for R6RS-compliant Schemes. ;-)
Kjetil S. Matheussen
I think the shape of the square brackets is visually disturbing
compaired to the smooth shape of the paranthesis. However, square brackets
will be easier for emacs and other editors to use different colors for
cond blocks and other places one would choose to use different colors.
And that would be nice, I think. Haven't tried it yet.
I also think it would be stupid not to allow ([([(...)))), because
right paranthesis are something you just add mindlessly, and forcing
the programmer to think about which type to use would break that.
Förster vom Silberwald
Pascal Bourguignon wrote:
> Some implementations accept them with the same meaning as parentheses.
> They're usable interchangeably, but must still match:
> ([]) is valid, but ([)] is not.
If not already give by others. In Bigloo both of them will get
accepted:
(define (a b] [+ b))
will not raise an error.
Schneewittchen
Taylor R. Campbell
package of commands for editing Lisp code, or indeed any parenthesized
expressions, preserving the balance and structure of the parentheses,
along with a minor mode that binds a number of keys to these commands.
Under this minor mode, for example, typing an opening parenthesis will
cause the closing parenthesis to be inserted, and typing a closing
parenthesis will simply move over the next closing parenthesis in the
buffer; deleting characters and killing words ignore parentheses; and
there are also higher-level operations on list structures, such as
moving an object into or out of a list, splicing the contents of a list
into the enclosing one, joining two lists, &c.
Paredit.el is available at
<http://mumble.net/~campbell/emacs/paredit.el>;
I'm also looking at getting it into GNU Emacs.
To editorialize a bit, I think that if you have more than fifty columns
of indentation for much code, you are doing something wrong anyway.
But with paredit.el the point, along with all the necessary closing
parentheses, is moved to the proper indentation on the next line after
you close one parenthesis. Many of the commands automatically reindent
locally, so you can see whether you have made any errors in
indentation; or, using Emacs's built-in commands, you can always just
do C-M-a C-M-q (beginning-of-defun, indent-sexp) to check this
manually, since all S-expressions will have balanced parentheses with
paredit.el. It's easy to see what's wrong from the indentation, and
then to fix it using various paredit.el commands.
One can also use other commands built-in to Emacs for S-expression
navigation, like C-M-b (backward-sexp), C-M-f (forward-sexp), C-M-u
(backward-up-list), and C-M-d (down-list); and if in paredit-mode, also
C-M-p (backward-down-list) and C-M-n (up-list).
And this will be the first and last thing I say on the subject of
square brackets, but I find them distracting when trying to look at
Scheme code; my eyes avoid the parentheses, while brackets attract
unnecessary attention. Show-paren-mode and high-level S-expression
navigation commands work much better for me than visual distractions.
(Some people I know even set up Emacs to show parentheses in a dim,
grey colour, so that they blend into the background better, and I'm
considering doing this myself.)
Jorgen Schaefer
> Then someone else Y reads it using this mode and all the
> brackets disappear. Which means Y doesn't know where they are
> and can't add them in in the same way.
You're completely right of course. The option of _displaying_
brackets as parens - which is somewhat broken - is only useful if
you are only viewing the source code, as is stated in the
documentation.
Usually, bracketphobia will _change_ brackets to parens.
This solves the problem of inconsistent coding styles you
mentioned.