gmane.comp.lang.racket.devel

Abort behavior different in DrRacket & Racket

Asumu Takikawa — 2012-05-23T21:42:25

Hi all,

In the Guide entry on control[1], there's a section detailing prompts
and abort. Here's an example from that section:

    (abort-current-continuation
     (default-continuation-prompt-tag)
     (lambda () v)))

If you run this in the command-line REPL, it'll produce 0 as the Guide
claims.  However, if you run it in DrRacket, it will not return.

It turns out that the abort handler for DrRacket is just:
  (lambda args (void))

while the abort handler for Racket is this:
  (lambda results (for-each (current-print) results))

Was this intentional or should both REPLs behave the same way for
aborts?

[1]: http://pre.racket-lang.org/docs/html/guide/prompt.html

Cheers,
Asumu
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

New https certificate

Eli Barzilay — 2012-05-22T17:46:04

Note that I installed a new certificate for the https domains.

(I've tried two new things now: it should be valid for two years, and
it should work for all *.racket-lang.org domains.)

Re: [plt] Push #24721: master branch updated

Matthias Felleisen — 2012-05-18T21:37:19

Anyone else? 


On May 18, 2012, at 5:22 PM, Jon Rafkind wrote:



_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [plt] Push #24721: master branch updated

Jon Rafkind — 2012-05-18T21:22:12

yea it was, I have a command line tool that prints out all the imports and exports of a module. you wanted it to show contracts and maybe types too eventually so I started on this 'module-interface' thing but I didn't work on it much since the initial import..

On 05/18/2012 02:07 PM, Matthias Felleisen wrote:

_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [plt] Push #24721: master branch updated

Matthias Felleisen — 2012-05-18T20:07:48

Was this an attempt to show the interfaces of a module? I do wish we had one inside of DrRacket. 


On May 18, 2012, at 4:05 PM, asumu-GvBox1K3Ixw1Q5oZIJT9Xw< at >public.gmane.org wrote:



_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: scribble/srcdoc

Jay McCarthy — 2012-05-16T04:48:53

This is awesome.

My OpenCL planet package, which used srcdoc heavily, used to take over
4 hours to compile on my machine. (I actually don't know how long it
took, because I didn't have the patience. At some point in the past,
it only took about an hour.)

Now, it takes 60 seconds.

Go Matthew! You're the best!

Jay

On Sat, May 12, 2012 at 1:47 AM, Matthew Flatt <mflatt< at >cs.utah.edu> wrote:

Re: did something happen to the git web server?

Danny Yoo — 2012-05-15T21:36:00

Thank you!  Ok, more evidence that my memory needs error correction.  ;)
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: did something happen to the git web server?

Eli Barzilay — 2012-05-15T18:59:01

This never worked -- you should use http://...

But I just pushed a new version that serves the same contents for both
http and https for the git server and the bug server, so you can use
https now if you want to for whatever reason.  This isn't doing much
for gitweb pages since it generates links to http:// either way...

I also made all of the important servers redirect https to http, so if
you go to https://racket-lang.org/ you get redirected to
http://racket-lang.org/ instead of seeing the same empty page.

Re: [plt] Push #24692: master branch updated

Eli Barzilay — 2012-05-15T14:43:01

Maybe a more practical solution is to make `module+' drop its contents
if the module name is `test' unless some parameter is unset?  (IOW,
use `module+' as a configuration point for this stripping.)  It's true
that the resulting modules would not be executable in DrRacket, but
that would happen anyway with zo-level stripping.

Re: match syntax-parse

2012-05-14T12:02:41





I think that this has to do with the evaluation structure in my 
implementation for guile. I think that I got it now, basically the 
syntax-classes
syntax structures in the racket version is defined before the parsers  are 
defined and inside those there is a check for syntax classes to be 
defined. 
Tricky I really need to talk with the guile dev's about  this in order to 
do the same as well for the guile version. I wrongly assumed that in order 
to get 
the interface you would need the interface of the used syntax classes.

syntax/parse/private/minimatch.

Yes now I remembered that this is the case, I had used guiles (ice-9 
match) for those in the guile version.
then it can makes more sense to implement the matcher with an extensive 
use of syntax-parse.


cool, syntax-parse in guile is kind of heavy right now and splitting the 
parser into mutual files can save
some dev pain. (On the other hand I should fix the code to be faster)



It's just an idea. I think it would be fun to try it out though.
/Stefan




Ryan Culpepper <ryan-sDh8Nw2yj/+Vc3sceRu5cw< at >public.gmane.org> 
2012-05-12 09:01

To
Stefan Israelsson/SECRC/ABB< at >ABB_SECRC
cc
dev-GvBox1K3Ixw1Q5oZIJT9Xw< at >public.gmane.org
Subject
Re: [racket-dev] match syntax-parse






On 05/11/2012 06:45 AM, stefan.israelsson-VNh8X+XCloDQT0dZR+AlfA< at >public.gmane.org wrote:

I don't understand your comment. Racket supports mutually recursive 
syntax classes. Here's a little toy example:

#lang racket
(require (for-syntax syntax/parse))

(begin-for-syntax
   (define-syntax-class x
     (pattern i:id
              #:with (flat ...) #'(i))
     (pattern l:xlist
              #:with (flat ...) #'(l.flat ...)))
   (define-syntax-class xlist
     (pattern (a:x ...)
              #:with (flat ...) #'(a.flat ... ...))))

(define-syntax (m stx)
   (syntax-parse stx
     [(_ x:x)
      #'(quote (x.flat ...))]))

(m (a (b c) ((d) ((e)))))
;; => '(a b c d e)


Ah, I see now. You want mutual recursion across modules, which Racket 
doesn't support in general.

One way to do this with Racket's syntax-parse is to define the two 
syntax classes as thin wrappers around reified syntax classes (see the 
syntax/parse/experimental/reflect module and ~reflect). Then you can 
create procedures that mutate the variables holding the reified syntax 
classes.

Those are the mechanics. I'll see about adding more syntactic support 
around it, so that you don't have to do things like declare attributes 
in multiple places. But I'd prefer not to add mutability to syntax 
classes themselves.

http://gitorious.org/guile-syntax-parse/guile-syntax-parse/blobs/master/compat/racket/match.scm


As Neil mentioned, syntax-parse does not use racket/match; it has its 
own separate (far simpler) implementation in 
syntax/parse/private/minimatch.

syntax-parse?

A few parts actually are. But for the syntax-parse core, figuring out 
how to bootstrap it seems like more trouble than it's worth. (Unless, of 
course, the rest of Racket goes that way...)

--

Thanks for the feedback, and thanks for the work you've done porting 
syntax-parse to Guile. It's great to hear that other people have found 
it useful enough to port to other systems.

Ryan


_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: match syntax-parse

2012-05-14T12:06:41

syntax parse. 

attention to performance, especially widely used features. 

need to measure the performance impact of ripping out match from 
syntax-parse and of > > implementing match via syntax-parse. It doesn't 
seem a straightforward case for one or the other. 


This is valid concerns, indeed. And you should see my implementation for 
list-no-order it's neat, simple and horribly inefficient.

/Stefan
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: scribble/srcdoc

Danny Yoo — 2012-05-14T16:11:20

Do the submodules then have a specific name that the external tools
know about?  Let me look at the implementation... ah, ok, so it uses a
submodule named 'srcdoc' to store that information.  I should take the
same approach in Whalesong to attach JavaScript implementations to
bindings.  Cool!  I'll take a closer look at scribble/srcdoc.
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

did something happen to the git web server?

Danny Yoo — 2012-05-14T16:04:28

I could have sworn that:

    https://git.racket-lang.org/

took me to a nice HTML view of the git repository, but at the moment,
I see an empty page.
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

scribble/srcdoc

Matthew Flatt — 2012-05-12T07:47:11

If you use `scribble/srcdoc', please check that the latest version
still works on your code.

I've changed the implementation to use submodules. In the old
implementation, `require/doc' and `provide/doc' expanded to
syntax-quoted constants that the compiler would drop when creating
bytecode (so that there would be no documentation overhead for a
module), and so `include-extracted' would use `expand' on the module
source to find the information. Submodules solve the problem of having
extra information in a module that is not loaded with the module's
code, so the `expand' approach is not longer necessary.

Instead of `require/doc', you can use the new `for-doc' sub-form within
`require'. Instead of `provide/doc', just use `provide'; `proc-doc',
etc., are all `provide' sub-forms.

The new forms are different in many subtle ways. Mostly, the new
implementation should work in corners where the old implementation
wouldn't.

There is at least one pattern, however, that no longer works by
default. Suppose that modules `a' and `b' refer to each other in
documentation. That is, `a' contains `(require (for-doc (for-label
a)))' and `b' contains `(require (for-doc (for-label b)))'. With the
old implementation, `for-doc' requires (via `require/doc') were
effectively copied to the module that uses `include-extracted'; with
the new implementation, `for-doc' requires turn into `require's within
a submodule, so that cycle would not be allowed. To get delayed
`require's more like the old implementation, use the
`generate-delayed-documents' declaration (which is still not
implemented with expand', but instead with relatively simple macro
juggling).

_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: A few suggestions on indentation and DrRacket graphical syntax

Laurent — 2012-05-12T07:34:38


Probably. But how can the user specify its own rules then?
(genuine question, I don't know where the language info lies, and how it
can be extended)




Interesting idea.
Could sub-namespaces be loaded independently from the main identifier, in
case you don't need it?
Anyway, submodules already exists, hence my suggestion.

 Eg, think about providing it as `bar' -- if the rules

Unless `bar' knows its real name is `foo'? (which it does, maybe?)
Currently, DrRacket does not seem to be able to do this anyway
(which may be why you proposed sub-namespaces?):

#lang racket
(require (rename-in racket [define gabuzomeu]))

(gabuzomeu (foo bar)
           (list bar))


So probably sub-moduled indentation rules would be a less important change
than adding sub-namespaces,
and thus requires less work which makes it more probable to appear in a
near future?

Laurent
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: match syntax-parse

Ryan Culpepper — 2012-05-12T07:01:27

I don't understand your comment. Racket supports mutually recursive 
syntax classes. Here's a little toy example:

#lang racket
(require (for-syntax syntax/parse))

(begin-for-syntax
   (define-syntax-class x
     (pattern i:id
              #:with (flat ...) #'(i))
     (pattern l:xlist
              #:with (flat ...) #'(l.flat ...)))
   (define-syntax-class xlist
     (pattern (a:x ...)
              #:with (flat ...) #'(a.flat ... ...))))

(define-syntax (m stx)
   (syntax-parse stx
     [(_ x:x)
      #'(quote (x.flat ...))]))

(m (a (b c) ((d) ((e)))))
;; => '(a b c d e)


Ah, I see now. You want mutual recursion across modules, which Racket 
doesn't support in general.

One way to do this with Racket's syntax-parse is to define the two 
syntax classes as thin wrappers around reified syntax classes (see the 
syntax/parse/experimental/reflect module and ~reflect). Then you can 
create procedures that mutate the variables holding the reified syntax 
classes.

Those are the mechanics. I'll see about adding more syntactic support 
around it, so that you don't have to do things like declare attributes 
in multiple places. But I'd prefer not to add mutability to syntax 
classes themselves.


As Neil mentioned, syntax-parse does not use racket/match; it has its 
own separate (far simpler) implementation in syntax/parse/private/minimatch.


A few parts actually are. But for the syntax-parse core, figuring out 
how to bootstrap it seems like more trouble than it's worth. (Unless, of 
course, the rest of Racket goes that way...)

--

Thanks for the feedback, and thanks for the work you've done porting 
syntax-parse to Guile. It's great to hear that other people have found 
it useful enough to port to other systems.

Ryan
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: A few suggestions on indentation and DrRacket graphical syntax

Eli Barzilay — 2012-05-11T22:49:08

That kind of indentation specification is more fitting in the language
info, together with coloring etc.

For specific macros in some random file something that I suggested in
the past could work better: have an ability to use "sub-namespaces"
where an identifier can have a number of related bindings -- so you
could define `foo' and some `foo< at >indent' (or whatever) which specifies
indentation.  The reason that this would work better is that any
context that receives the `foo' binding would also get its
indentation.  Eg, think about providing it as `bar' -- if the rules
are in a sub-module, then it won't work unless you construct your own
sub-module.

Re: match syntax-parse

Neil Toronto — 2012-05-11T18:01:20

This Wednesday, we had the PLT luminaries from University of Utah visit 
our humble group at BYU. I can swear that Ryan told us syntax/parse 
doesn't actually use match. It has its own slower-but-simpler 
implementation.

We also talked about bootstrapping syntax/parse. And then bootstrapping 
everything. It was heady stuff.

Neil ⊥
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: A few suggestions on indentation and DrRacket graphical syntax

Neil Toronto — 2012-05-11T17:37:05

That would be awesome for Typed Racket macros in particular. Its `for' 
macros are great examples of forms that should have fairly complex 
indentation rules. Optional type declarations make it difficult to 
classify them as "begin-like", "define-like" or "lambda-like".

Neil ⊥
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: match syntax-parse

Matthias Felleisen — 2012-05-11T16:59:41

On May 11, 2012, at 9:45 AM, stefan.israelsson-VNh8X+XCloDQT0dZR+AlfA< at >public.gmane.org wrote:


This is really good to hear. 



"set!" is a means to implement recursion but it is an ugly sledge hammer. Instead of hitting the nail, you are sooner or later going to flatten your thumb with it. 

letrec or compound-unit fit the bill better than class-set! because they bring across the intent of declaring mutually recursion entities, possibly located in distinct files. 

So while I welcome the idea, I think we should find a better way to express it. 


It does. 



I usually argue for clarity of code over speed. BUT we must pay attention to performance, especially widely used features. 

Have you measure the performance of the two versions? Indeed you really need to measure the performance impact of ripping out match from syntax-parse and of implementing match via syntax-parse. It doesn't seem a straightforward case for one or the other.

Re: Very quick poll re `string-trim'

Neil Toronto — 2012-05-11T16:54:33

I would say yes. Isn't this primarily a string function?

How about a #:repeated? argument that defaults to #t?

Neil ⊥

On 05/11/2012 08:38 AM, Matthias Felleisen wrote:

_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev