This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: brackets


Chris <chris@bitmead.com> writes:

> I would vote for Option 1. Scheme is about keeping it simple.

Option 1 is not quite as simple as you might think.

Kawa does support square brackets used as parens, but since they are
also token constituents they don't work exactly like parens:

#|kawa:7|# [define x (make-vector 5)]
#|kawa:8|# [vector-length x]
#|[---:9|# ]
gnu.mapping.UnboundSymbol: Unbound symbol x]

This is the way it has worked for some time, but people don't notice
because DrScheme-style use of square brackets generally occurs next to
delimiters.

BRL is affected by this, in that I have to make square brackets be
delimiters.  This means you can't use type specifiers like <char[]>
inside a BRL page.  Not a big loss -- Java stuff like that should be
abstracted away from individual pages anyway.  But it's still a wart.

In August, when Felix Klock wrote to the Kawa list about the usage of
square brackets and the readtable API, I posted a patch that would
implement option 3.  The patch has some redundancy that should be
eliminated, but it works.  It passes the test suite, and would make
things nicer for my BRL syntax extensions, Felix's FX, and Jocelyn
Paine's .pfn files.

There is no Schemey way to handle square brackets.  Any handling is an
extension.  I would advocate choosing the option that creates the least
amount of unexpected behavior.

IMO, most extensions will involve treating square brackets as
delimiters; <char[]> is the exceptional extension.  Right now [ is
treated in an exceptional manner; my patch would merely treat < in a
similarly exceptional manner.  Come to think of it, if I had done my
patch right the first time, it wouldn't be much more complex than the
status quo.

What little additional complexity there is would be totally internal to
the code; scenarios where end users would be surprised by option 3 are
IMO far-fetched.

-- 
Bruce R. Lewis  <brlewis@[(if (brl-related? message)
                              "users.sourceforge.net"
                              "alum.mit.edu")]>  http://brl.sourceforge.net/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]