Re: [racket-dev] [racket] newbie: foreign C structure definition question
Two hours ago, Sam Tobin-Hochstadt wrote: > > Python's 'ctypes' library, which also uses libffi under the hood, has arrays: > http://docs.python.org/library/ctypes.html#arrays > and also unions, which we don't have: > http://docs.python.org/library/ctypes.html#structures-and-unions > > So it seems like this should be possible, and maybe we can even use > their code. They guy who did ctypes knows how to deal with the libffi internals. (He did the msvc version of the code.) If you look through the libffi documentation you'll see no mention of arrays, and an explicit mention of "no special support for unions". -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Getting commits from other repositories
Recently there was a "pull request" that someone did via github. We can't use github to get it, since the plt repo there is just a mirror from our server. But it's easy for anyone to do it through your own clone -- here's how to do so: 1. Get a plt clone, or use your own (it's safe to do the latter, no need for a new clone unless you're paranoid): git clone pltgit:plt cd plt 2. Get the foreign repository's `master' branch (or any other branch) into a local branch: git fetch git://github.com/4z3/racket.git master:foo This pulls the `master' branch of the remote repository into a local `foo' branch. (It's possible to add the remote repository as a known remote, but I'm skipping that since it's a one-time operation.) 3. Look at the changes as usual: git log master..foo git diff master...foo Note the ".." on the first, vs the "..." on the second. If you use ".." in the second, you'll see all changes between the two. You can also see the commits and their changes with git log -p master..foo (One thing to check is that the commits are just a simple line against the plt repo. If there's a bunch of merges etc, mail me and I'll help sorting things out.) 4a. If you're happy with the change and want to get it as-is, you can rebase it against the current `master': git checkout foo git rebase master then get the rebased changes to your `master': git checkout master git merge foo (This last merge will be a fast-forward.) 4b. If you *want* a merge commit (for example, when there are a bunch of commits), you can skip the rebasing: git merge foo 5. You no longer need the `foo' branch: git branch -d foo 6. And you can now push as usual. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Fwd: Q. about "Directly Reflective" paper
Well, he's generous about it; here's what he had to say. John Begin forwarded message: > From: Aaron Stump > Date: November 16, 2010 5:58:42 PM PST > To: John Clements > Subject: Re: Q. about "Directly Reflective" paper > Reply-To: ast...@cs.uiowa.edu > > Hi, John. > > I think you are right about this. Lambda abstractions evaluate to > #procedures in Scheme R5RS, and so it is not possible to take a cdr or car of > one of these. I have no idea why I wrote this (four years ago -- there was a > major lag between acceptance and publication at HOSC). I will add a note to > my web page about this, and possibly upload a revised version of the paper > without this incorrect statement. > > Aaron > > On Tue, Nov 16, 2010 at 4:18 PM, John Clements > wrote: > I'm reading your paper, "Directly Reflective Meta-Programming," and I got > stuck early on a remark of yours about Scheme: > > > A meta-programming language is scope safe (or hygienic) iff variables may > > not be captured or escape their scopes during computation. Dynamic > > variables in Emacs LISP and Common LISP are a good example of a violation > > of scope safety [30, 24]. Scheme R5RS’s macro language is designed to be > > scope safe [21]. Other constructs in Scheme R5RS, however, enable violation > > of scope safety, even though the language does not have dynamic variables. > > For a violation of scope safety in spirit, though not technically, we have > > that (caddr ’(lambda (x) x)) evaluates to x. According to the R5RS language > > definition, ’(lambda (x) x) is a literal expression, and hence the > > occurrences of x in it are not variables at all, but just (unscoped) > > literal data. So in this example, a variable has been created (namely, the > > resulting unquoted x), but not by means of removing it from its scope. > > Using quasiquotation, however, the example may be modified to give a true > > violation of scope safety. The following expression extracts the variable x > > from its scope, by transforming the binding lambda expression into a piece > > of literal data, and then extracting and evaluating the quoted variable. > > > ((lambda (y) (eval ‘(car (cdr (cdr ’,y) (lambda (x) x)) > > > This looks pretty goofy to me. Do you know of R5RS implementations that > actually allow you to peel apart a 3d value like this? Racket (nee MzScheme) > certainly doesn't. > > Thanks! > > > John Clements > > smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] newbie: foreign C structure definition question
[redirected to d...@] On Tue, Nov 16, 2010 at 11:28 PM, Eli Barzilay wrote: > 20 minutes ago, Jay McCarthy wrote: >> >> I've complained about this before, which is why I was able to >> quickly answer your question. I don't endorse the current behavior. > > (Just a reminder: this is something that libffi doesn't have AFAICT.) Python's 'ctypes' library, which also uses libffi under the hood, has arrays: http://docs.python.org/library/ctypes.html#arrays and also unions, which we don't have: http://docs.python.org/library/ctypes.html#structures-and-unions So it seems like this should be possible, and maybe we can even use their code. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
- "Jay McCarthy" wrote: > If... Was that a McCarthy conditional? Dave _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
Three minutes ago, Robby Findler wrote:
> On Tue, Nov 16, 2010 at 4:19 PM, Eli Barzilay wrote:
> >
> > Sounds to me like the classic problem that some "symbolic" people
> > have when they don't "get" hygiene (usually ending up in
> > `defmacro' nostalgia where "symbols are symbols", possibly
> > together with `eval' abuse).
>
> That example in the end of the quoted region is somehow turning a
> procedure back into a datum by passing it to car/cdr. (strange!)
Yeah, that's part of why it looked even more confused than I initially
thought. I don't remember ever seeing a real scheme where functions
were represented as lists that way. (Not counting reflective toys, of
course.) His lack of `caddr' also makes me think that he's not a
native speaker...
Two minutes ago, Shriram Krishnamurthi wrote:
> You know, it's not inconceivable such a thing could happen if you
> had a PURELY syntactic *interpreter*.
>
> I remember when I got to Brown, they were using one of those weirdo
> Scheme interpreters, and had come to conclusions about the semantics
> of Scheme on the basis of its behavior. Things like you could run
>
> ('(lambda (x) x) 3)
>
> and it would evaluate to 3 because of the way the interpreter was
> structured.
And an obvious question is what would
(let ([x 1]) ('(lambda () ,x)))
evaluate to?
In any case, if you swallow that pill and take a dose of dynamic scope
too, you end up with newlisp. (Which I think makes perfect sense in
that world.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] proposed clarification to "async-apply" docs
FWIW I agree with John and disagree with Jay. On 11/16/2010 03:45 PM, Jay McCarthy wrote: > The typesetting on async-apply clearly refers to the argument rather > than to a well-known function. This is a convention of the docs that I > don't think merits special attention here, although this case may > indicate we should make a "how to read the documentation" section that > points out these conventions. > > Jay > > On Tue, Nov 16, 2010 at 1:26 PM, John Clements > wrote: >> My quick reading of the documentation for the #:async-apply argument to the >> _fun form led to a misunderstanding; the docs seemed to be suggesting that >> some built-in 'async-apply' procedure was doing all of these magical things, >> whereas the point was to indicate that the *user* must provide an >> async-apply that behaves correctly. I wound up going through and replacing >> 'async-apply' with 'the given async-apply procedure' in about five places. I >> think the text is clearer now; let me know if I shouldn't commit these >> changes. Otherwise, I'll commit them locally and push them sometime soon. >> >> John >> >> >> >> pcp062767pcs:~/plt/collects/scribblings/foreign clements$ git diff >> types.scrbl >> diff --git a/collects/scribblings/foreign/types.scrbl >> b/collects/scribblings/foreign/types.scrbl >> index 9d753ac..233f48d 100644 >> --- a/collects/scribblings/foreign/types.scrbl >> +++ b/collects/scribblings/foreign/types.scrbl >> @@ -401,19 +401,22 @@ procedure with the generated procedure type can be >> applied in a >> foreign thread (i.e., an OS-level thread other than the one used to >> run Racket). The call in the foreign thread is transferred to the >> OS-level thread that runs Racket, but the Racket-level thread (in the >> -sense of @racket[thread]) is unspecified; the job of >> -...@scheme[async-apply] is to arrange for the callback procedure to be >> -run in a suitable Racket thread. The @scheme[async-apply] function is >> +sense of @racket[thread]) is unspecified; the job of the provided >> +...@scheme[async-apply] procedure is to arrange for the callback procedure >> to be >> +run in a suitable Racket thread. The given @scheme[async-apply] procedure is >> applied to a thunk that encapsulates the specific callback invocation, >> and the foreign OS-level thread blocks until the thunk is called and >> completes; the thunk must be called exactly once, and the callback >> -invocation must return normally. The @scheme[async-apply] procedure >> +invocation must return normally. The given @scheme[async-apply] procedure >> itself is called in atomic mode (see @scheme[atomic?] above). If the >> callback is known to complete quickly, requires no synchronization, >> and works independent of the Racket thread in which it runs, then >> -...@scheme[async-apply] can apply the thunk directly. Otherwise, >> -...@racket[async-apply] must arrange for the thunk to be applied in a >> -suitable Racket thread sometime after @racket[async-apply] itself >> +it is safe for the given >> +...@scheme[async-apply] procedure to apply the thunk directly. Otherwise, >> +the given @racket[async-apply] procedure >> +must arrange for the thunk to be applied in a >> +suitable Racket thread sometime after the given >> +...@racket[async-apply] procedure itself >> returns; if the thunk raises an exception or synchronizes within an >> unsuitable Racket-level thread, it can deadlock or otherwise damage >> the Racket process. Foreign-thread detection to trigger >> pcp062767pcs:~/plt/collects/scribblings/foreign clements$ >> >> >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] proposed clarification to "async-apply" docs
The typesetting on async-apply clearly refers to the argument rather than to a well-known function. This is a convention of the docs that I don't think merits special attention here, although this case may indicate we should make a "how to read the documentation" section that points out these conventions. Jay On Tue, Nov 16, 2010 at 1:26 PM, John Clements wrote: > My quick reading of the documentation for the #:async-apply argument to the > _fun form led to a misunderstanding; the docs seemed to be suggesting that > some built-in 'async-apply' procedure was doing all of these magical things, > whereas the point was to indicate that the *user* must provide an async-apply > that behaves correctly. I wound up going through and replacing 'async-apply' > with 'the given async-apply procedure' in about five places. I think the text > is clearer now; let me know if I shouldn't commit these changes. Otherwise, > I'll commit them locally and push them sometime soon. > > John > > > > pcp062767pcs:~/plt/collects/scribblings/foreign clements$ git diff types.scrbl > diff --git a/collects/scribblings/foreign/types.scrbl > b/collects/scribblings/foreign/types.scrbl > index 9d753ac..233f48d 100644 > --- a/collects/scribblings/foreign/types.scrbl > +++ b/collects/scribblings/foreign/types.scrbl > @@ -401,19 +401,22 @@ procedure with the generated procedure type can be > applied in a > foreign thread (i.e., an OS-level thread other than the one used to > run Racket). The call in the foreign thread is transferred to the > OS-level thread that runs Racket, but the Racket-level thread (in the > -sense of @racket[thread]) is unspecified; the job of > -...@scheme[async-apply] is to arrange for the callback procedure to be > -run in a suitable Racket thread. The @scheme[async-apply] function is > +sense of @racket[thread]) is unspecified; the job of the provided > +...@scheme[async-apply] procedure is to arrange for the callback procedure > to be > +run in a suitable Racket thread. The given @scheme[async-apply] procedure is > applied to a thunk that encapsulates the specific callback invocation, > and the foreign OS-level thread blocks until the thunk is called and > completes; the thunk must be called exactly once, and the callback > -invocation must return normally. The @scheme[async-apply] procedure > +invocation must return normally. The given @scheme[async-apply] procedure > itself is called in atomic mode (see @scheme[atomic?] above). If the > callback is known to complete quickly, requires no synchronization, > and works independent of the Racket thread in which it runs, then > -...@scheme[async-apply] can apply the thunk directly. Otherwise, > -...@racket[async-apply] must arrange for the thunk to be applied in a > -suitable Racket thread sometime after @racket[async-apply] itself > +it is safe for the given > +...@scheme[async-apply] procedure to apply the thunk directly. Otherwise, > +the given @racket[async-apply] procedure > +must arrange for the thunk to be applied in a > +suitable Racket thread sometime after the given > +...@racket[async-apply] procedure itself > returns; if the thunk raises an exception or synchronizes within an > unsuitable Racket-level thread, it can deadlock or otherwise damage > the Racket process. Foreign-thread detection to trigger > pcp062767pcs:~/plt/collects/scribblings/foreign clements$ > > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
On Tue, Nov 16, 2010 at 3:25 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Nov 16, 2010 at 5:22 PM, Shriram Krishnamurthi
> wrote:
>> You know, it's not inconceivable such a thing could happen if you had
>> a PURELY syntactic *interpreter*.
>>
>> I remember when I got to Brown, they were using one of those weirdo
>> Scheme interpreters, and had come to conclusions about the semantics
>> of Scheme on the basis of its behavior. Things like you could run
>>
>> ('(lambda (x) x) 3)
>>
>> and it would evaluate to 3 because of the way the interpreter was structured.
>>
>> Now if Aaron ran one of those to test his code...
>
> I'm pretty sure that this is also how the original Lisp interpreter
> from McCarthy's paper worked.
If so, it was a bug on my part.
:P
> --
> sam th
> sa...@ccs.neu.edu
> _
> For list-related administrative tasks:
> http://lists.racket-lang.org/listinfo/dev
>
--
Jay McCarthy
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
"The glory of God is Intelligence" - D&C 93
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
If you knew his background, you would not expect him to at all be a native speaker of (). (Further OT amusement: He, Stephanie, and Tim Sheard had a paper at last week's FOSER workshop entitled "Language-Based Verification Will Change the World". Apparently, dependent types are both necessary and sufficient.) Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
Three minutes ago, Sam Tobin-Hochstadt wrote:
> On Tue, Nov 16, 2010 at 5:22 PM, Shriram Krishnamurthi
> wrote:
> > ('(lambda (x) x) 3)
> >
> > and it would evaluate to 3 because of the way the interpreter was
> > structured.
> >
> > Now if Aaron ran one of those to test his code...
>
> I'm pretty sure that this is also how the original Lisp interpreter
> from McCarthy's paper worked.
(And in elisp too, btw: (funcall '(lambda (x) x) 3).)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
Good point. I never thought of it this way, but this is another
argument in favor of dynamic scope. [tongue in cheek]
Shriram
On Tue, Nov 16, 2010 at 5:25 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Nov 16, 2010 at 5:22 PM, Shriram Krishnamurthi
> wrote:
>> You know, it's not inconceivable such a thing could happen if you had
>> a PURELY syntactic *interpreter*.
>>
>> I remember when I got to Brown, they were using one of those weirdo
>> Scheme interpreters, and had come to conclusions about the semantics
>> of Scheme on the basis of its behavior. Things like you could run
>>
>> ('(lambda (x) x) 3)
>>
>> and it would evaluate to 3 because of the way the interpreter was structured.
>>
>> Now if Aaron ran one of those to test his code...
>
> I'm pretty sure that this is also how the original Lisp interpreter
> from McCarthy's paper worked.
> --
> sam th
> sa...@ccs.neu.edu
>
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
On Tue, Nov 16, 2010 at 5:22 PM, Shriram Krishnamurthi
wrote:
> You know, it's not inconceivable such a thing could happen if you had
> a PURELY syntactic *interpreter*.
>
> I remember when I got to Brown, they were using one of those weirdo
> Scheme interpreters, and had come to conclusions about the semantics
> of Scheme on the basis of its behavior. Things like you could run
>
> ('(lambda (x) x) 3)
>
> and it would evaluate to 3 because of the way the interpreter was structured.
>
> Now if Aaron ran one of those to test his code...
I'm pretty sure that this is also how the original Lisp interpreter
from McCarthy's paper worked.
--
sam th
sa...@ccs.neu.edu
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
Yep, that's exactly what was happening with the thing they ran at Brown. It was that system by that guy in Nice -- Erik Galliseo or something like that. Shriram On Tue, Nov 16, 2010 at 5:21 PM, Robby Findler wrote: > On Tue, Nov 16, 2010 at 4:19 PM, Eli Barzilay wrote: >> 5 minutes ago, John Clements wrote: >>> I'm reading Aaron Stump's "Directly Reflective Meta-Programming," >>> and it appears to me that either he misunderstands Scheme, or that I >>> misunderstand it. >> >> Sounds to me like the classic problem that some "symbolic" people have >> when they don't "get" hygiene (usually ending up in `defmacro' >> nostalgia where "symbols are symbols", possibly together with `eval' >> abuse). > > That example in the end of the quoted region is somehow turning a > procedure back into a datum by passing it to car/cdr. (strange!) > > Robby > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
You know, it's not inconceivable such a thing could happen if you had
a PURELY syntactic *interpreter*.
I remember when I got to Brown, they were using one of those weirdo
Scheme interpreters, and had come to conclusions about the semantics
of Scheme on the basis of its behavior. Things like you could run
('(lambda (x) x) 3)
and it would evaluate to 3 because of the way the interpreter was structured.
Now if Aaron ran one of those to test his code...
Shriram
On Tue, Nov 16, 2010 at 5:19 PM, Eli Barzilay wrote:
> 5 minutes ago, John Clements wrote:
>> I'm reading Aaron Stump's "Directly Reflective Meta-Programming,"
>> and it appears to me that either he misunderstands Scheme, or that I
>> misunderstand it.
>
> Sounds to me like the classic problem that some "symbolic" people have
> when they don't "get" hygiene (usually ending up in `defmacro'
> nostalgia where "symbols are symbols", possibly together with `eval'
> abuse).
>
>> Are there many Scheme dialects in which his use of quasiquote to
>> embed a 3d value would successfully pry open the syntactic term?
>
> (That lookes much more confused on a more basic level...)
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://barzilay.org/ Maze is Life!
> _
> For list-related administrative tasks:
> http://lists.racket-lang.org/listinfo/dev
>
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
On Tue, Nov 16, 2010 at 4:19 PM, Eli Barzilay wrote: > 5 minutes ago, John Clements wrote: >> I'm reading Aaron Stump's "Directly Reflective Meta-Programming," >> and it appears to me that either he misunderstands Scheme, or that I >> misunderstand it. > > Sounds to me like the classic problem that some "symbolic" people have > when they don't "get" hygiene (usually ending up in `defmacro' > nostalgia where "symbols are symbols", possibly together with `eval' > abuse). That example in the end of the quoted region is somehow turning a procedure back into a datum by passing it to car/cdr. (strange!) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
5 minutes ago, John Clements wrote: > I'm reading Aaron Stump's "Directly Reflective Meta-Programming," > and it appears to me that either he misunderstands Scheme, or that I > misunderstand it. Sounds to me like the classic problem that some "symbolic" people have when they don't "get" hygiene (usually ending up in `defmacro' nostalgia where "symbols are symbols", possibly together with `eval' abuse). > Are there many Scheme dialects in which his use of quasiquote to > embed a 3d value would successfully pry open the syntactic term? (That lookes much more confused on a more basic level...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
On Nov 16, 2010, at 2:17 PM, Shriram Krishnamurthi wrote: > Though also cycle back to us. I'm curious to hear what he has to say. Will do. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
Though also cycle back to us. I'm curious to hear what he has to say. Shriram On Tue, Nov 16, 2010 at 5:13 PM, Robby Findler wrote: > That expression at the end is somehow turning a procedure back into > its quoted form. I have no idea if a Scheme that did that would be R5 > or not, but Racket definitely does not allow that (and neither did any > other programming language that I've ever worked on). > > Overall, I'd say, you should contact Aaron directly, instead of asking here. > > Robby > > On Tue, Nov 16, 2010 at 4:07 PM, John Clements > wrote: >> I'm reading Aaron Stump's "Directly Reflective Meta-Programming," and it >> appears to me that either he misunderstands Scheme, or that I misunderstand >> it. Are there many Scheme dialects in which his use of quasiquote to embed a >> 3d value would successfully pry open the syntactic term? >> >> (Excerpt below) >> >> Sorry for the OT post, >> >> John >> >> >> >> 2.1.2 Variables in Meta-Programming >> >> A meta-programming language is scope safe (or hygienic) iff variables may >> not be captured or escape their scopes during computation. Dynamic variables >> in Emacs LISP and Common LISP are a good example of a violation of scope >> safety [30, 24]. Scheme R5RS’s macro language is designed to be scope safe >> [21]. Other constructs in Scheme R5RS, however, enable violation of scope >> safety, even though the language does not have dynamic variables. For a >> violation of scope safety in spirit, though not technically, we have that >> (caddr ’(lambda (x) x)) evaluates to x. According to the R5RS language >> definition, ’(lambda (x) x) is a literal expression, and hence the >> occurrences of x in it are not variables at all, but just (unscoped) literal >> data. So in this example, a variable has been created (namely, the resulting >> unquoted x), but not by means of removing it from its scope. Using >> quasiquotation, however, the example may be modified to give a true >> violation of scope safety. The following expression extracts the variable x >> from its scope, by transforming the binding lambda expression into a piece >> of literal data, and then extracting and evaluating the quoted variable. >> >> ((lambda (y) (eval ‘(car (cdr (cdr ’,y) (lambda (x) x)) >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
On Nov 16, 2010, at 2:13 PM, Robby Findler wrote: > That expression at the end is somehow turning a procedure back into > its quoted form. I have no idea if a Scheme that did that would be R5 > or not, but Racket definitely does not allow that (and neither did any > other programming language that I've ever worked on). > > Overall, I'd say, you should contact Aaron directly, instead of asking here. OKTHX smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] OT: stump misunderstands Scheme?
That expression at the end is somehow turning a procedure back into its quoted form. I have no idea if a Scheme that did that would be R5 or not, but Racket definitely does not allow that (and neither did any other programming language that I've ever worked on). Overall, I'd say, you should contact Aaron directly, instead of asking here. Robby On Tue, Nov 16, 2010 at 4:07 PM, John Clements wrote: > I'm reading Aaron Stump's "Directly Reflective Meta-Programming," and it > appears to me that either he misunderstands Scheme, or that I misunderstand > it. Are there many Scheme dialects in which his use of quasiquote to embed a > 3d value would successfully pry open the syntactic term? > > (Excerpt below) > > Sorry for the OT post, > > John > > > > 2.1.2 Variables in Meta-Programming > > A meta-programming language is scope safe (or hygienic) iff variables may not > be captured or escape their scopes during computation. Dynamic variables in > Emacs LISP and Common LISP are a good example of a violation of scope safety > [30, 24]. Scheme R5RS’s macro language is designed to be scope safe [21]. > Other constructs in Scheme R5RS, however, enable violation of scope safety, > even though the language does not have dynamic variables. For a violation of > scope safety in spirit, though not technically, we have that (caddr ’(lambda > (x) x)) evaluates to x. According to the R5RS language definition, ’(lambda > (x) x) is a literal expression, and hence the occurrences of x in it are not > variables at all, but just (unscoped) literal data. So in this example, a > variable has been created (namely, the resulting unquoted x), but not by > means of removing it from its scope. Using quasiquotation, however, the > example may be modified to give a true violation of scope safety. The > following expression extracts the variable x from its scope, by transforming > the binding lambda expression into a piece of literal data, and then > extracting and evaluating the quoted variable. > > ((lambda (y) (eval ‘(car (cdr (cdr ’,y) (lambda (x) x)) > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] OT: stump misunderstands Scheme?
I'm reading Aaron Stump's "Directly Reflective Meta-Programming," and it appears to me that either he misunderstands Scheme, or that I misunderstand it. Are there many Scheme dialects in which his use of quasiquote to embed a 3d value would successfully pry open the syntactic term? (Excerpt below) Sorry for the OT post, John 2.1.2 Variables in Meta-Programming A meta-programming language is scope safe (or hygienic) iff variables may not be captured or escape their scopes during computation. Dynamic variables in Emacs LISP and Common LISP are a good example of a violation of scope safety [30, 24]. Scheme R5RS’s macro language is designed to be scope safe [21]. Other constructs in Scheme R5RS, however, enable violation of scope safety, even though the language does not have dynamic variables. For a violation of scope safety in spirit, though not technically, we have that (caddr ’(lambda (x) x)) evaluates to x. According to the R5RS language definition, ’(lambda (x) x) is a literal expression, and hence the occurrences of x in it are not variables at all, but just (unscoped) literal data. So in this example, a variable has been created (namely, the resulting unquoted x), but not by means of removing it from its scope. Using quasiquotation, however, the example may be modified to give a true violation of scope safety. The following expression extracts the variable x from its scope, by transforming the binding lambda expression into a piece of literal data, and then extracting and evaluating the quoted variable. ((lambda (y) (eval ‘(car (cdr (cdr ’,y) (lambda (x) x)) smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21533: master branch updated
Oh, yes. in-queue would be better than that! I use for/list a bunch
too, but for these simple things map is pretty hardwired for me ...
Robby
On Tue, Nov 16, 2010 at 4:02 PM, Jon Rafkind wrote:
> On 11/16/2010 03:00 PM, Robby Findler wrote:
>> On Tue, Nov 16, 2010 at 3:41 PM, Jon Rafkind wrote:
>>> On 11/16/2010 02:39 PM, Robby Findler wrote:
I added (but have not pushed, apprently) queue-map. Mind if we keep
that one instead?
>>> Instead of what.. queue->list? I guess you can implement queue->list in
>>> terms of queue-map as (queue-map values queue), but I'd rather not write
>>> that in user code.
>> Yes. I assume that you didn't do a map right after queue->list in
>> whatever you were doing?
>>
>> I added it for debugging purposes, so I was doing (queue-map
>> eq-hash-code q) and printing that out.
>>
>
> I was using the list in a for loop. Probably I should have added a new
> sequence type, `in-queue', but its non-trivial to get those sorts of
> macros working properly.
>
> (for ([item (queue->list x)]) ...)
>
> {as a side note, I tend to use for/list instead of map these days :p}
>
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21533: master branch updated
On 11/16/2010 03:00 PM, Robby Findler wrote:
> On Tue, Nov 16, 2010 at 3:41 PM, Jon Rafkind wrote:
>> On 11/16/2010 02:39 PM, Robby Findler wrote:
>>> I added (but have not pushed, apprently) queue-map. Mind if we keep
>>> that one instead?
>>>
>> Instead of what.. queue->list? I guess you can implement queue->list in
>> terms of queue-map as (queue-map values queue), but I'd rather not write
>> that in user code.
> Yes. I assume that you didn't do a map right after queue->list in
> whatever you were doing?
>
> I added it for debugging purposes, so I was doing (queue-map
> eq-hash-code q) and printing that out.
>
I was using the list in a for loop. Probably I should have added a new
sequence type, `in-queue', but its non-trivial to get those sorts of
macros working properly.
(for ([item (queue->list x)]) ...)
{as a side note, I tend to use for/list instead of map these days :p}
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21533: master branch updated
On Tue, Nov 16, 2010 at 3:41 PM, Jon Rafkind wrote: > On 11/16/2010 02:39 PM, Robby Findler wrote: >> I added (but have not pushed, apprently) queue-map. Mind if we keep >> that one instead? >> > > Instead of what.. queue->list? I guess you can implement queue->list in > terms of queue-map as (queue-map values queue), but I'd rather not write > that in user code. Yes. I assume that you didn't do a map right after queue->list in whatever you were doing? I added it for debugging purposes, so I was doing (queue-map eq-hash-code q) and printing that out. >> Also, I think that a rename like the below is a bad idea if the queues >> have been released already. >> > > I added queue-count yesterday or so, so its fairly fresh. (The rename > was not my idea) Ah, sorry. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21533: master branch updated
On 11/16/2010 02:39 PM, Robby Findler wrote: > I added (but have not pushed, apprently) queue-map. Mind if we keep > that one instead? > Instead of what.. queue->list? I guess you can implement queue->list in terms of queue-map as (queue-map values queue), but I'd rather not write that in user code. > Also, I think that a rename like the below is a bad idea if the queues > have been released already. > I added queue-count yesterday or so, so its fairly fresh. (The rename was not my idea) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [plt] Push #21533: master branch updated
I added (but have not pushed, apprently) queue-map. Mind if we keep
that one instead?
Also, I think that a rename like the below is a bad idea if the queues
have been released already.
Robby
On Tue, Nov 16, 2010 at 3:37 PM, wrote:
> rafkind has updated `master' from b8bbed6eb4 to 7b24eaf58e.
> http://git.racket-lang.org/plt/b8bbed6eb4..7b24eaf58e
>
> =[ 2 Commits ]==
>
> Directory summary:
> 22.4% collects/data/scribblings/
> 35.6% collects/data/
> 41.8% collects/tests/data/
>
> ~~
>
> 73be679 Jon Rafkind 2010-11-16 12:02
> :
> | add queue->list
> :
> M collects/data/queue.rkt | 20 +++-
> M collects/data/scribblings/queue.scrbl | 12
> M collects/tests/data/queue.rkt | 12 +++-
>
> ~~
>
> 7b24eaf Jon Rafkind 2010-11-16 14:36
> :
> | rename queue-count to queue-length
> :
> M collects/data/queue.rkt | 6 +++---
> M collects/data/scribblings/queue.scrbl | 8
> M collects/tests/data/queue.rkt | 14 +++---
>
> =[ Overall Diff ]===
>
> collects/data/queue.rkt
> ~~~
> --- OLD/collects/data/queue.rkt
> +++ NEW/collects/data/queue.rkt
> @@ -31,7 +31,24 @@
> (set-queue-head! q (link-tail old))
> (link-value old)))
>
> -(define (queue-count queue)
> +(define (queue->list queue)
> + (let loop ([link (queue-head queue)]
> + [out '()])
> + (if (not link)
> + (reverse out)
> + (loop (link-tail link) (cons (link-value link) out)
> +
> +;; queue->vector could be implemented as (list->vector (queue->list q))
> +;; but this is somewhat slow. a direct translation between queue's and
> +;; vector's should be fast so the ideal situation is not to use a list
> +;; as an intermediate data structure.
> +;; maybe add the elements to a gvector and use gvector->vector?
> +
> +;; could use (length (queue->list q)) here but that would double
> +;; the time it takes to get the length
> +;; probably if `queue->vector' gets implemented it would be better to
> +;; do (vector-length (queue->vector q))
> +(define (queue-length queue)
> (let loop ([link (queue-head queue)]
> [count 0])
> (if (not link)
> @@ -56,6 +73,7 @@
> [queue? (-> any/c boolean?)]
> [make-queue (-> queue/c)]
> [queue-empty? (-> queue/c boolean?)]
> - [queue-count (-> queue/c integer?)])
> + [queue-length (-> queue/c integer?)]
> + [queue->list (-> queue/c (listof any/c))])
>
> (provide enqueue! dequeue!)
>
> collects/data/scribblings/queue.scrbl
> ~
> --- OLD/collects/data/scribblings/queue.scrbl
> +++ NEW/collects/data/scribblings/queue.scrbl
> @@ -34,17 +34,29 @@ thread-unsafe way.
> (dequeue! q)]
> }
>
> -...@defproc[(queue-count [queue queue/c]) integer?]{
> +...@defproc[(queue->list [queue queue/c]) (listof any/c)]{
> + Returns an immutable list containing the elements of the queue
> + in the order the elements were added.
> +
> + �...@defexamples[#:eval qeval
> + (define queue (make-queue))
> + (enqueue! queue 8)
> + (enqueue! queue 9)
> + (enqueue! queue 0)
> + (queue->list queue)]
> +}
> +
> +...@defproc[(queue-length [queue queue/c]) integer?]{
> Returns the number of elements in the queue.
>
> @defexamples[#:eval qeval
> (define queue (make-queue))
> - (queue-count queue)
> + (queue-length queue)
> (enqueue! queue 5)
> (enqueue! queue 12)
> - (queue-count queue)
> + (queue-length queue)
> (dequeue! queue)
> - (queue-count queue)]
> + (queue-length queue)]
> }
>
> �...@defproc[(queue-empty? [q queue/c]) boolean?]{
>
> collects/tests/data/queue.rkt
> ~
> --- OLD/collects/tests/data/queue.rkt
> +++ NEW/collects/tests/data/queue.rkt
> @@ -34,21 +34,21 @@
> (dequeue! q)
> (dequeue! q)
> (check-true (queue-empty? q)
> - (test-suite "count"
> - (test-case "count empty"
> + (test-suite "length"
> + (test-case "length empty"
> (let* ([queue (make-queue)])
> - (check-equal? (queue-count queue) 0)))
> - (test-case "count enqueue once"
> + (check-equal? (queue-length queue) 0)))
> + (test-case "length enqueue once"
> (let* ([queue (make-queue)])
> (enqueue! queue 5)
> - (check-equal? (queue-count queue) 1)))
> - (test-case "count enqueue thrice dequeue once"
> + (check-equal? (queue-length queue) 1)))
> + (test-case "length enqueue thrice dequeue once"
> (let* ([queue (make-queue)])
> (enqueue! queue 5)
> (enqueue! queue 9)
> (enqueue! queue 12)
> (dequeue! queue)
> - (check-equal? (queue-count queue) 2
> + (check-equal? (queue-length queue) 2
> (test-suite "dequeue!"
> (test-case "make-queue"
> (check-exn exn:fail? (lambda () (dequeu
[racket-dev] proposed clarification to "async-apply" docs
My quick reading of the documentation for the #:async-apply argument to the _fun form led to a misunderstanding; the docs seemed to be suggesting that some built-in 'async-apply' procedure was doing all of these magical things, whereas the point was to indicate that the *user* must provide an async-apply that behaves correctly. I wound up going through and replacing 'async-apply' with 'the given async-apply procedure' in about five places. I think the text is clearer now; let me know if I shouldn't commit these changes. Otherwise, I'll commit them locally and push them sometime soon. John pcp062767pcs:~/plt/collects/scribblings/foreign clements$ git diff types.scrbl diff --git a/collects/scribblings/foreign/types.scrbl b/collects/scribblings/foreign/types.scrbl index 9d753ac..233f48d 100644 --- a/collects/scribblings/foreign/types.scrbl +++ b/collects/scribblings/foreign/types.scrbl @@ -401,19 +401,22 @@ procedure with the generated procedure type can be applied in a foreign thread (i.e., an OS-level thread other than the one used to run Racket). The call in the foreign thread is transferred to the OS-level thread that runs Racket, but the Racket-level thread (in the -sense of @racket[thread]) is unspecified; the job of -...@scheme[async-apply] is to arrange for the callback procedure to be -run in a suitable Racket thread. The @scheme[async-apply] function is +sense of @racket[thread]) is unspecified; the job of the provided +...@scheme[async-apply] procedure is to arrange for the callback procedure to be +run in a suitable Racket thread. The given @scheme[async-apply] procedure is applied to a thunk that encapsulates the specific callback invocation, and the foreign OS-level thread blocks until the thunk is called and completes; the thunk must be called exactly once, and the callback -invocation must return normally. The @scheme[async-apply] procedure +invocation must return normally. The given @scheme[async-apply] procedure itself is called in atomic mode (see @scheme[atomic?] above). If the callback is known to complete quickly, requires no synchronization, and works independent of the Racket thread in which it runs, then -...@scheme[async-apply] can apply the thunk directly. Otherwise, -...@racket[async-apply] must arrange for the thunk to be applied in a -suitable Racket thread sometime after @racket[async-apply] itself +it is safe for the given +...@scheme[async-apply] procedure to apply the thunk directly. Otherwise, +the given @racket[async-apply] procedure +must arrange for the thunk to be applied in a +suitable Racket thread sometime after the given +...@racket[async-apply] procedure itself returns; if the thunk raises an exception or synchronizes within an unsuitable Racket-level thread, it can deadlock or otherwise damage the Racket process. Foreign-thread detection to trigger pcp062767pcs:~/plt/collects/scribblings/foreign clements$ smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] enum returns #f on c->racket no match?
An hour and a half ago, John Clements wrote: > > Okay the existing behavior was bothering me because (post-conversion > to #f) there's no way to recover the problematic integer. I > therefore changed it so it signals an error instead, like this: [...] It might still be useful to have the old behavior, or just use some default value to be used for unknown numbers. I've committed that now. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] enum returns #f on c->racket no match?
I guess using 'from a known integer' could be slightly misleading since
the base type for the enum could be something other than an _int. I
would prefer the error to mention the enum in the text (I see its in the
error, but its at the front).
"expected a known _my-enum from C"
or something like that
On 11/16/2010 12:02 PM, John Clements wrote:
>
> On Nov 15, 2010, at 3:02 PM, John Clements wrote:
>
>> The documentation for '_enum" says this:
>>
>> 3.8 Enumerations and Masks
>>
>> Although the constructors below are describes as procedures, they are
>> implemented as syntax, so that error messages can report a type name where
>> the syntactic context implies one.
>>
>> (_enum symbols [basetype]) → ctype?
>> symbols : list?
>> basetype : ctype? = _ufixint
>> Takes a list of symbols and generates an enumeration type. The enumeration
>> maps between a symbol in the given symbols list and corresponding integers,
>> counting from0.
>> The list symbols can also set the values of symbols by putting '= and an
>> exact integer after the symbol. For example, the list '(x y = 10 z) maps 'x
>> to 0, 'y to 10, and 'z to11.
>>
>> The basetype argument specifies the base type to use.
>>
>>
>> This says nothing about what happens when using racket->C on a symbol that's
>> not mentioned by the enumeration, or what happens when using C->racket on a
>> number that's not mentioned in the enumeration.
>>
>> Based on my tests, it appears that the conversion signals an error in the
>> racket->C direction, but simply returns #f in the C->racket direction.
>>
>> Should I document the current behavior, or would it make more sense to
>> change it to signal an error rather than returning #f?
> Okay the existing behavior was bothering me because (post-conversion to #f)
> there's no way to recover the problematic integer. I therefore changed it so
> it signals an error instead, like this:
>
> . . . plt/collects/racket/private/more-scheme.rkt:265:2: enum:int->_my-enum:
> expected a known integer from C, got: 6
>
> That error comes from linking to a file with this C function:
>
> int tester(int x){
> return x+2;
> }
>
> ... using this racket program:
>
> #lang racket
>
> (require ffi/unsafe)
>
> (define lib (ffi-lib "/tmp/tester.dylib"))
>
> (define _my-enum
> (_enum
>'(chicken = 3
> monkey = 4
> duck = 5)))
>
> (define tester
> (get-ffi-obj "tester" lib (_fun _my-enum -> _my-enum)))
>
>
> (tester 'monkey)
>
>
> ... and finally, here's the diff:
>
> pcp062767pcs:~/plt/collects/ffi clements$ git diff unsafe.rkt
> diff --git a/collects/ffi/unsafe.rkt b/collects/ffi/unsafe.rkt
> index 66fd34a..99e0d7f 100644
> --- a/collects/ffi/unsafe.rkt
> +++ b/collects/ffi/unsafe.rkt
> @@ -765,6 +765,8 @@
>(define int->sym '())
>(define s->c
> (if name (string->symbol (format "enum:~a->int" name)) 'enum->int))
> + (define c->s
> +(if name (string->symbol (format "enum:int->~a" name)) 'int->enum))
>(let loop ([i 0] [symbols symbols])
> (unless (null? symbols)
>(let-values ([(i rest)
> @@ -784,7 +786,11 @@
> (if a
>(cdr a)
>(raise-type-error s->c (format "~a" (or name "enum")) x
> -(lambda (x) (cond [(assq x int->sym) => cdr] [else #f]
> +(lambda (x) (cond [(assq x int->sym) => cdr]
> + [else
> + (error c->s
> + "expected a known integer from C, got: ~s"
> + x)]
>
> ;; Macro wrapper -- no need for a name
> (provide _enum)
>
>
> Let me know if it's okay to commit this. If I don't hear back in a couple of
> days, I'll just go ahead :).
>
> John
>
>
>
> _
> For list-related administrative tasks:
> http://lists.racket-lang.org/listinfo/dev
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] enum returns #f on c->racket no match?
On Nov 15, 2010, at 3:02 PM, John Clements wrote:
> The documentation for '_enum" says this:
>
> 3.8 Enumerations and Masks
>
> Although the constructors below are describes as procedures, they are
> implemented as syntax, so that error messages can report a type name where
> the syntactic context implies one.
>
> (_enum symbols [basetype]) → ctype?
> symbols : list?
> basetype : ctype? = _ufixint
> Takes a list of symbols and generates an enumeration type. The enumeration
> maps between a symbol in the given symbols list and corresponding integers,
> counting from0.
> The list symbols can also set the values of symbols by putting '= and an
> exact integer after the symbol. For example, the list '(x y = 10 z) maps 'x
> to 0, 'y to 10, and 'z to11.
>
> The basetype argument specifies the base type to use.
>
>
> This says nothing about what happens when using racket->C on a symbol that's
> not mentioned by the enumeration, or what happens when using C->racket on a
> number that's not mentioned in the enumeration.
>
> Based on my tests, it appears that the conversion signals an error in the
> racket->C direction, but simply returns #f in the C->racket direction.
>
> Should I document the current behavior, or would it make more sense to change
> it to signal an error rather than returning #f?
Okay the existing behavior was bothering me because (post-conversion to #f)
there's no way to recover the problematic integer. I therefore changed it so
it signals an error instead, like this:
. . . plt/collects/racket/private/more-scheme.rkt:265:2: enum:int->_my-enum:
expected a known integer from C, got: 6
That error comes from linking to a file with this C function:
int tester(int x){
return x+2;
}
... using this racket program:
#lang racket
(require ffi/unsafe)
(define lib (ffi-lib "/tmp/tester.dylib"))
(define _my-enum
(_enum
'(chicken = 3
monkey = 4
duck = 5)))
(define tester
(get-ffi-obj "tester" lib (_fun _my-enum -> _my-enum)))
(tester 'monkey)
... and finally, here's the diff:
pcp062767pcs:~/plt/collects/ffi clements$ git diff unsafe.rkt
diff --git a/collects/ffi/unsafe.rkt b/collects/ffi/unsafe.rkt
index 66fd34a..99e0d7f 100644
--- a/collects/ffi/unsafe.rkt
+++ b/collects/ffi/unsafe.rkt
@@ -765,6 +765,8 @@
(define int->sym '())
(define s->c
(if name (string->symbol (format "enum:~a->int" name)) 'enum->int))
+ (define c->s
+(if name (string->symbol (format "enum:int->~a" name)) 'int->enum))
(let loop ([i 0] [symbols symbols])
(unless (null? symbols)
(let-values ([(i rest)
@@ -784,7 +786,11 @@
(if a
(cdr a)
(raise-type-error s->c (format "~a" (or name "enum")) x
-(lambda (x) (cond [(assq x int->sym) => cdr] [else #f]
+(lambda (x) (cond [(assq x int->sym) => cdr]
+ [else
+ (error c->s
+ "expected a known integer from C, got: ~s"
+ x)]
;; Macro wrapper -- no need for a name
(provide _enum)
Let me know if it's okay to commit this. If I don't hear back in a couple of
days, I'll just go ahead :).
John
smime.p7s
Description: S/MIME cryptographic signature
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
