Menu
▾
▴
[Jscheme-devel] Re: new quasi-string was Re: [Jscheme-user] using JScheme ....
|
From: Timothy J. H. <tim...@ma...> - 2004-05-24 12:34:11
|
If forgot to remark earlier that I've run into the same problem as
Rahul with having to quote curly braces
(in the context of writing webpages containing CSS in the head).
There is a relatively simple approach to this problem that doesn't
require backquoting...
The idea is just to escape into a regular quoted string with [" ..... "]
e.g.
{<html>
<head> <title>CSS test</title>
<style><!-- ["
body {background:rgb(255,255,240); padding:0.5in}
ln {margin-top:0.1in; margin-bottom:0.1in}
"] -->
</style>
</head>
<body>
<h1>CSS Test</h1>
</body>
</html>
Its a little messy but not too bad. If you want to insert into such a
quoted string you have to use
"][ inserted-scheme-expr-here ]["
e.g.
(servlet (X Y Z)
{<html>
<head> <title>CSS test</title>
<style><!-- ["
body {background:rgb(255,255,240); padding:"][ X ]["in}
ln {margin-top:"][Y]["in; margin-bottom:"][(+ Z 0.1)]["in}
"] -->
</style>
</head>
<body>
<h1>CSS Test</h1>
</body>
</html>
This is certainly simpler than my early proposal with curly-curly-delim
... {{" ......"[...]"......"}}
On May 23, 2004, at 5:11 PM, Ken Anderson wrote:
> Here are two proposals:
>
> P1: Use as the quasistring delimiter {{ also inside a quasistring
> expression {{ starts an escape to Scheme. I think i found this
> approach in another web application and sent email to the group.
Interesting approach and quite easy, but it doesn't seem to buy as much
as the other proposals.
>
> The advantage is
> - you can keep the current syntax, if you only see { and use the new
> one if you see {
> - Only one character #\{ becomes special.
> - I'm guessing that "{{" is uncommon.
>
> P2: Common Lisp has a very flexible reader controlled by a read-table.
> (Once i sat down to work on a Lisp Machine that was reading in ALGOL
> syntax, boy was i suprised.) One way to extend CL was to add
> reader-macros that had the form
> #name where name was the name of a macro, typical one character, like
> #?. These are extensions of #t #f #(). Providing this facility would
> let anyone add a way of swithching syntax. For example, Rahul could
> have solved his javascript problem by using #js{....}, say.
This is an interesting idea. It seems quite powerful and relatively
simple to understand but it has a delimiter
problem unless we say,e.g. the first non-alphanumeric character after
the # is the string delimiter, e.g.
#js@ ...... @
or #js#.......#
or #js$.......$
with the exception that parenthesis type operators match as expected
#js(.....)
#js[.....]
#js{...}
#js<.....>
How does one define a reader and install it in Common Lisp?
Is it just a function from strings to sexpr?
How does it interact with error reporting
(.e.g error in proc F in file g.scm on line 5 char 16, which JScheme
doesn't do anyway...)
It would be nice to have a modular lexical syntax mechanism so that
one could write lexical macros as well as procedural macros...
Currently we use # in several instances ..
#'a'
#'\uFFE6' unicode characters
#(1 2 3 4) vectors
#t #f boolean (ahh this breaks the pattern....)
Maybe we need prefix to indicate it is a reader.
Another problem with this notation, is that it would be nice to use #
notation for typed arrays,
e.g.
#int(1 2 3 4 5)
#double(1 2 3 4 5)
#int[](#int(1 2) #int(3 4))
#String("abcd" "efgh")
But we can always use (list->array TYPE LIST) to get the same effect
(or ([] TYPE LIST))
>
> This proposal is just to add #... extension capability.
>
> P3: I've been interested in rewriting the JScheme (read) in Scheme as
> a finite state machine, and compile it into Java. This should be
> relatively easy because we only have a relatively small number of
> types and operations. This could either implement P2 or the full
> read-table approach.
This would have the advantage of speeding up the reader and providing a
model for writing
read-macros
>
> I guess i've vote for P1 as the easiest thing to do at this point.
Lets keep thinking about it.....
---Tim---
> k
>
>
> At 07:12 PM 5/21/2004 -0400, Timothy John Hickey wrote:
>> That shouldn't be too hard. What delimiters would you suggest?
>>
>>
>> What would you think about some kind of general string delimiter say
>> like this
>>
>> {{+ Here is "some" {javascript} or {CSS} or arrays A[x] or ...
>> and here is a Scheme escape +[(Date.)]+
>> hmmmm? +}}
>>
>> where the character following the
>> {{
>> indicates the stop character for the string, in this case
>> +
>> and
>> +[ ]+
>> would delimit the quasi-string escapes.....
>>
>> So you could equivalently use a period
>>
>> {{. Here is "some" {javascript} or {CSS} or arrays A[x] or ...
>> and here is a Scheme escape .[(Date.)].
>> hmmmm? .}}
>>
>> or a double quote
>>
>> {{" Here is "some" {javascript} or {CSS} or arrays A[x] or ...
>> and here is a Scheme escape "[(Date.)]"
>> hmmmm? "}}
>>
>> and you could switch midway with each [...] providing an opportunity
>> to switch delimiters. For example, here we switch from " to * to @
>>
>>
>> {{" Here is "some" {javascript} or {CSS} or arrays A[x] or ...
>> and here is a Scheme escape "[(Date.)]*
>> hmmmm? here is a square bracket "[" see?
>> maybe just switch for fun *[]@ hmmmm.. @}}
>>
>> What do you think? Would this have helped make the code cleaner
>> and the developers happy?
>>
>> What do other JSchemer's think of this notation?
>> Any other ideas for handling the string delimiter problem?
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>
|
