gmane.comp.lang.racket.devel

error-message overhaul

Matthew Flatt — 2012-05-25T21:09:22

I've pushed a first cut at overhauling error messages from `racket/base'.

The old error message convention tried to keep everything on one line,
but that sometimes got long and contorted. The old format didn't work
at all for contract errors, for example, and so I've more or less
adopted the contract-error style everywhere.

The new error message convention encourages a short message on the
first line, and then more information in separate "<field>: <detail>"
lines. A multi-line <detail> starts out on its old line and is indented
by an extra space. Where the old format would inline a value or name in
the message, the new format puts the value or name in its own field or
line. A source locations is similarly moved to a field, instead of
prefixing the error message. Finally, instead of a separate " ===
context ===" section for a backtrace, it's added by the default
exception printer as a "context" field.

There's a new `raise-argument-error' function to replace existing uses
of `raise-type-error'. For example

Re: `racket/string' extensions

Laurent — 2012-05-25T08:22:10


Maybe `string-find'?



3b: I think that's over-complicating things, personally.







That this could return "" surprised me. The intuitive behavior to me is the
following: If you remove "aa" from "aaa", you get "a", and if you repeat it
(from either side), you don't match and return "a".
This relies on an occidental left->right preference though.

But as you say, these are rare cases, so it could well be left as
"unspecified" or specified in the simplest way to implement, as long as it
is well documented?




Indeed.





Side comment: If it's possible, formatting the signature like this in the
docs could be a good idea: put all the keyword arguments on another line,
so that the most important and often used options are put forward.  I think
that might help newbies to understand the question (keywords can be a bit
frightening maybe? (not sure)).



That's a good sign that the functions have the correct (default) behavior.

Looking forward to use all these!

Laurent
_________________________
  Racket Dev

Re: `racket/string' extensions

J. Ian Johnson — 2012-05-24T22:01:43

I'm a bit surprised list-index doesn't take an equality function.
-Ian
----- Original Message -----
From: Eli Barzilay <eli-oSK4jVRJLyZg9hUCZPvPmw< at >public.gmane.org>
To: dev-GvBox1K3Ixw1Q5oZIJT9Xw< at >public.gmane.org
Sent: Thu, 24 May 2012 16:45:26 -0400 (EDT)
Subject: Re: [racket-dev] `racket/string' extensions

About a month ago, Eli Barzilay wrote:

This is now almost completely implemented.  If you have any comments
on the below, now would be a good time.

The two things that I didn't do yet are the following (I'm still not
sure about the names and the functionality):

I might start a separate thread on suggestions for this and more
needed functions in `racket/list'.

To summarize the new things:

* (string-join strs [sep " "])

  The new thing here is that the `sep' argument now defaults to a
  space.  This is something that is often done in such functions
  elsewhere (including in srfi-1, IIRC), and with the below functions
  working with spaces by default it seems like the right thing.

* (string-trim s

Re: `racket/string' extensions

Eli Barzilay — 2012-05-24T20:45:26

This is now almost completely implemented.  If you have any comments
on the below, now would be a good time.

The two things that I didn't do yet are the following (I'm still not
sure about the names and the functionality):


I might start a separate thread on suggestions for this and more
needed functions in `racket/list'.


To summarize the new things:

* (string-join strs [sep " "])

  The new thing here is that the `sep' argument now defaults to a
  space.  This is something that is often done in such functions
  elsewhere (including in srfi-1, IIRC), and with the below functions
  working with spaces by default it seems like the right thing.

* (string-trim str [sep #px"\\s+"]
                   #:left? [l? #t] #:right? [r? #t] #:repeat? [+? #f])

  Trims spaces at the edges of the string.  Two notes:

  1. The default for `#:repeat?' is just #f -- an option that I
     suggested at some point would be to have it be true if `sep' is
     given as a string:

       (string-trim str [sep #px"\\s+"] ...

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

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.