I had assumed that since x.'y was read as two distinct symbols, x.`y would be too, but it's not the case:
arc> 'x.'y
x.
arc> y ; still evaluating previous expr
arc> 'x.`y
|x.`y|
Any idea why these are treated differently? Whatever the reason, it means I can use x.`y without hacking the reader. So, thanks for pointing this out to me! ^_^
I'm currently torn about whether to do
x!y => (x 'y) => (fncall x 'y) => x('y')
x.`y => (x `y) => (objref x 'y) => x['y']
as you suggested, or the reverse. Leaning toward your way so that functions are totally normal and objects special, rather than having functions with a single quoted arg be some exception.
This example works particularly well because the $("a") jQuery selector can be compiled from $!a. A challenge arises with more complex selectors, as in this snippet from the Find Me: Using Selectors and Events tutorial:
Since $("#ordered list") has the special character #, we're unable to compile it from $!#orderedlist. Either most of the ssyntax has to be sacrificed for parens, as in
Not quite sure (I suspect it's a bug), but it seems like it has to do with the implementation of make-readtable (which brackets.scm uses).
$ mzscheme
Welcome to MzScheme v4.2.1 [3m], Copyright (c) 2004-2009 PLT Scheme Inc.
> (parameterize ((current-readtable #f)) (read))
x`y ; read in as two items
x
> y
> (parameterize ((current-readtable (make-readtable #f))) (read))
x`y ; read in as one symbol
|x`y|