[racket-users] Converting a list to a syntax object non-recursively?

[Alexis King]

Is there any way to create a new syntax object containing a list without
recursively converting the list’s elements to syntax objects as well? I
have some code where I wanted to use syntax objects as a convenient
mechanism to tag arbitrary datums with source location information (and
they will be used as syntax objects later), but that code expects
datum->syntax followed by syntax-e to return the original datum, which
obviously isn’t the case if datum->syntax recursively wraps datums as
well.

Is there any way to construct a new syntax object without this recursive
behavior? If not, is there any reason something like that does not
exist? Nothing intuitively comes to mind as a reason why that would
violate someone to violate any guarantees, unless some code for some
reason always assumes syntax objects will always be recursively wrapped.

To be perfectly clear: I am not intending to use this “shallow syntax
object” as the result of a syntax transformer, or even during expansion
at all. These are syntax objects I’m manipulating purely at read-time,
not expansion-time.

Alexis

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Running racket on a #lang-less module-less file?

[Jack Firth]

William's remark is spot on about my use-case. There exists a language that 
wasn't initially designed with racket in mind, but could easily be a racket 
#lang. To interop with code already written in this language, I wanted an easy 
way to run files that don't have the #lang line. If I were designing the 
language Racket-first, I wouldn't need this feature.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] HTTP Headers use byte->string/utf-8

[Eli Barzilay]

On Fri, May 6, 2016 at 11:49 AM, Tim Brown  wrote:
>
> 1. I think Eli points out in issue where \277 and \276 are not ci=?
>to each other.

No -- my comment there is about \277 and \277 (itself), which are
neither `bytes-ci=?` nor not because the implementation assumes that the
two bytes to compare are both in utf-8 and therefore we get an exception
instead of an answer.  The source of the comment is that this was (I
think) at some point in unstable, as a candidate to move to racket/bytes
(hence my comment about the memory requirement, which is relevant in
that context).

[BTW, looking at that SO answer and the RFC it seems to me that latin-1
is wrong too for the values, which should remain opaque...]

-- 
((x=>x(x))(x=>x(x)))   Eli Barzilay:
http://barzilay.org/   Maze is Life!

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] HTTP Headers use byte->string/utf-8

[Jay McCarthy]

You should not be using request-headers or request-bindings if you
don't want them to be interpreted as UTF-8. The documentation for
web-server/http/bindings explicitly says, "We recommend against their
use, but they are provided for compatibility with old code."

Jay

On Fri, May 6, 2016 at 11:49 AM, Tim Brown  wrote:
> Sorry, Jay; I’ve just tested this and I hit:
>
> Servlet (@ /...) exception:
> bytes->string/utf-8: string is not a well-formed UTF-8 encoding
>   string: #"timmeh \351"
>
>   context...:
>
> /usr/local/racket/extra-pkgs/web-server/web-server-lib/web-server/http/bindings.rkt:9:7
>loop
>
> /usr/local/racket-6.5/share/racket/collects/racket/contract/private/arrow-val-first.rkt:357:18
>
>
> This is in web-server/http/bindings.rkt (where I count no less than five
> `bytes->string/utf-8`s); and I really do think that that should be
> bytes->string/latin-1 both because it covers all 256 code points AND
> it is what HTTP asks for.
>
> That would fix my issue (I hope).
>
>
>
> Also, looking at byte-upcase / bytes-ci=? in
> web-server-lib/web-server/private/util ; can I make a couple of
> suggestions:
>
> 1. I think Eli points out in issue where \277 and \276 are not ci=?
>to each other. I’m not sure of his specific example; because in
>Latin-1, they are "3/4" and an upside down "?" -- which I wouldn’t
>personally consider ci=? But further up the character set; I would
>say that \311 E' and \350 e' ARE ci=? : but only in Latin-1.
>
>So should there not be a byte-upcase/latin-1 and byte-upcase/ascii-7
>and a bytes-ci=?/latin-1 and bytes-ci=?/latin-1
>
> 2. Since this is implemented in a web-server / HTTP context (and for the
>reasons I set out above w.r.t. the bindings); should util.rkt not use
>bytes-ci=?/latin-1 ?
>
>
> Since I have an ISO-8859-1 table in front of me:
>
> (define (byte-upcase/latin-1 b)
>   (if ((or (<= 97 b 12)   ; ascii-7: a-z range
>(<= 224 b 246) ; latin-1: a` to o"
>   ; latin-1: -:- is not the lower case of x
>(<= 248 254))  ; latin-1: o/ to |p
> (- b 32)) ; 97 - 65 = 32
>b))
>
>
> On 05/05/16 18:46, Jay McCarthy wrote:
>> Hi Tim,
>>
>> I consider this an error. The Web server tries to avoid interpreting
>> anything as UTF-8 unless asked by the servlet. Header comparison
>> incorrectly converted to UTF-8 and I just pushed a fix. Can you verify
>> that it works now with your workload?
>>
>> Jay
>   - D 64:33
>
>
> --
> Tim Brown CEng MBCS 
> 
> City Computing Limited · www.cityc.co.uk
>   City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB
> T:+44 20 8770 2110 · F:+44 20 8770 2130
> 
> City Computing Limited registered in London No:1767817.
> Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
> VAT No: GB 918 4680 96



-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

   "Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
  - D 64:33

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] HTTP Headers use byte->string/utf-8

[Tim Brown]

Sorry, Jay; I’ve just tested this and I hit:

Servlet (@ /...) exception:
bytes->string/utf-8: string is not a well-formed UTF-8 encoding
  string: #"timmeh \351"

  context...:

/usr/local/racket/extra-pkgs/web-server/web-server-lib/web-server/http/bindings.rkt:9:7
   loop

/usr/local/racket-6.5/share/racket/collects/racket/contract/private/arrow-val-first.rkt:357:18


This is in web-server/http/bindings.rkt (where I count no less than five
`bytes->string/utf-8`s); and I really do think that that should be
bytes->string/latin-1 both because it covers all 256 code points AND
it is what HTTP asks for.

That would fix my issue (I hope).



Also, looking at byte-upcase / bytes-ci=? in
web-server-lib/web-server/private/util ; can I make a couple of
suggestions:

1. I think Eli points out in issue where \277 and \276 are not ci=?
   to each other. I’m not sure of his specific example; because in
   Latin-1, they are "3/4" and an upside down "?" -- which I wouldn’t
   personally consider ci=? But further up the character set; I would
   say that \311 E' and \350 e' ARE ci=? : but only in Latin-1.

   So should there not be a byte-upcase/latin-1 and byte-upcase/ascii-7
   and a bytes-ci=?/latin-1 and bytes-ci=?/latin-1

2. Since this is implemented in a web-server / HTTP context (and for the
   reasons I set out above w.r.t. the bindings); should util.rkt not use
   bytes-ci=?/latin-1 ?


Since I have an ISO-8859-1 table in front of me:

(define (byte-upcase/latin-1 b)
  (if ((or (<= 97 b 12)   ; ascii-7: a-z range
   (<= 224 b 246) ; latin-1: a` to o"
  ; latin-1: -:- is not the lower case of x
   (<= 248 254))  ; latin-1: o/ to |p
(- b 32)) ; 97 - 65 = 32
   b))


On 05/05/16 18:46, Jay McCarthy wrote:
> Hi Tim,
> 
> I consider this an error. The Web server tries to avoid interpreting
> anything as UTF-8 unless asked by the servlet. Header comparison
> incorrectly converted to UTF-8 and I just pushed a fix. Can you verify
> that it works now with your workload?
> 
> Jay
  - D 64:33


-- 
Tim Brown CEng MBCS 

City Computing Limited · www.cityc.co.uk
  City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB
T:+44 20 8770 2110 · F:+44 20 8770 2130

City Computing Limited registered in London No:1767817.
Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
VAT No: GB 918 4680 96

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.