gmane.comp.lang.racket.devel

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.
/

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 modul

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 addin

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

match syntax-parse

2012-05-11T13:45:49

Hi,

I have done two interseting things.

1. Ported syntax-parse over to guile.
2. Implemented racket's match completely with the help of syntax parse.

Comments about 1.

I found that the lack of possibility to define two syntax classes that 
referese to each other inferior to what 
can be done although I understand the choice of to do this and if you 
define one hugh syntax class and use
syntax class parameters you will be able to implement any feature still 
but at the drawback that one need
to define one hugh syntax class.

i propose instead to add syntax-class-set! and syntax-splicing-class-set! 
that has the following logic:
1. Compile all the meta data for the class as before
2. there has to be an already defined syntax class, the declaration, which 
has a logically identical set of meta data except for 
    the parser function
3. If there is no syntax class defined, error about it
4. If there the interfaces miss-matches print out what is different.
5. if everything is ok then set! the old named parse

Re: Very quick poll re `string-trim'

Matthias Felleisen — 2012-05-11T14:38:43

The question you need to ask is whether you want string-trim to be usable by someone who is not familiar with our syntax (or any syntax) of regexp, which is an embedded sublanguage with a definitely complex and somewhat obscure syntax. -- Matthias




On May 11, 2012, at 9:56 AM, Eli Barzilay wrote:



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

Re: Very quick poll re `string-trim'

Eli Barzilay — 2012-05-11T13:56:18

Yes, but it seems that if you're moving from

  (string-trim "stuff" " ")

to some

  (string-trim "stuff" " " #:repeated? #t)

then you could just as well go with

  (string-trim "stuff" #rx" +")

instead.  IOW, a keyword is possible, but doesn't seem useful given
that the intention is for this to be a function that is simple and/or
convenient.

Re: Very quick poll re `string-trim'

Robby Findler — 2012-05-11T12:15:43

Did you consider an optional argument to string-trim?

Robby

On Fri, May 11, 2012 at 6:53 AM, Eli Barzilay <eli< at >barzilay.org> wrote:

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

Very quick poll re `string-trim'

Eli Barzilay — 2012-05-11T11:53:26

Should (string-trim str sep) remove any number of `sep' matches or
just one?  (This makes no difference for the default `sep' since it's
#px"\\s+".)  Possible options below, feel free to mail me off-list to
reduce noise.

1. Yes.
   * Advantage: makes life with string separator a bit easier.  For
     example, remove only newlines with (string-trim str "\n")
   * Disadvantage: can be confusing with strings or regexps like "xy".
     For example:
       (string-trim ", , foo, bar, " #rx", *") => "foo, bar"

2. No.  Flipped dis/advantages.

3. Yes for string separators, no for (p)regexp separators.  Tries to
   get both advantages, but at the cost of non-uniform behavior.

I'm leaning towards #2 since (a) it's less surprising in the regexp
and >=2 string cases, and (b) it'll make similar to other functions
like `string-split' where an implicit repetition is a bad idea (eg,
when you split with "," you'd usually want that to mean #rx"," not
#rx",+").  OTOH, I hate to loose the possibly useful case of
1-character