Re: [racket-users] Scribbling documentation for a module beginning with _

2017-04-13 Thread Leif Andersen
Oooh...that is an interesting case.

FWIW, you could always cheat, and have the docs use a different name
for the module for defmodule's, and manually typeset the correct name
out. Its kind of a kludge though:

```
@defmodule[@racketmodfont{_-exp}
   #:module-paths (secret_-exp)
   #:lang]

@racketmodlink[secret_-exp]{_-exp}
```

This also has the major downside that anyone else wanting to link to
your module will have to know the `secret_-exp` name you chose. I
guess that _could_ be worked around by making helper functions for
them, but that seems kind of silly to me.


~Leif Andersen


On Thu, Apr 13, 2017 at 8:44 PM, Philip McGrath
 wrote:
> I'm trying to write documentation for a module named _-exp, and I'm running
> into a problem because (I think) of the way underscores are treated by
> racketblock.
>
> Using @defmodule[_-exp #:lang] or @racketmodname[_-exp] typesets the name as
> -exp .
>
> I can work around this for defmodule by doing
>
> @defmodule[@racketmodfont{_-exp}
>#:module-paths (_-exp)
>#:lang]
>
> but I haven't found a solution for linking to the definition. I'm currently
> trying @racketmodlink[_-exp @racketmodfont["_-exp"]], but this causes raco
> setup to complain:
>
> WARNING: undefined tag in /_-exp/scribblings/_-exp.scrbl:
> raco setup:  (mod-path "_-exp")
>
> and indeed the link does not work.
>
> In my local documentation search results, _-exp  language shows up as
> expected, so I think the problem is with the link, not the definition, but
> I'm not sure how to fix this.
>
> Philip
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


[racket-users] Scribbling documentation for a module beginning with _

2017-04-13 Thread Philip McGrath
I'm trying to write documentation for a module named _-exp, and I'm running
into a problem because (I think) of the way underscores are treated by
racketblock

.

Using @defmodule[_-exp #:lang] or @racketmodname[_-exp] typesets the name
as *-exp .*

I can work around this for defmodule by doing

@defmodule[@racketmodfont{_-exp}
   #:module-paths (_-exp)
   #:lang]

but I haven't found a solution for linking to the definition. I'm currently
trying @racketmodlink[_-exp @racketmodfont["_-exp"]], but this causes raco
setup to complain:

WARNING: undefined tag in /_-exp/scribblings/_-exp.scrbl:
raco setup:  (mod-path "_-exp")

and indeed the link does not work.

In my local documentation search results, _-exp  language shows up as
expected, so I think the problem is with the link, not the definition, but
I'm not sure how to fix this.

Philip

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


[racket-users] Racket summer school

2017-04-13 Thread Robby Findler
  The Racket Summer School of Semantics and Languages

Imagine yourself confronted with a Mystery Programming Language and
charged with the task of figuring out its semantics. What would you do?

What if you have a formal executable semantics and want to build a
production language for it?

If these questions intrigue you, attend the Racket Summer School:

   http://summer-school.racket-lang.org/2017/

This is not your run-of-the-mill summer school. We will do our best
to make it exciting, entertaining, and useful to a broad spectrum of
attendees, both academic and industrial.

P.S. As soon as you get accepted, we will send you your first problem
set. Get ready.

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


Re: [racket-users] Names for flat-contract-with-explanation contracts

2017-04-13 Thread Robby Findler
Probably it would be good to make rename-contract and
flat-named-contract cooperate better with
flat-contract-with-explanation, but for now I've just added a #:name
argument, whose value defaults to the name of the procedure that's
passed in.

Robby

On Tue, Apr 11, 2017 at 12:06 PM, Philip McGrath
 wrote:
> Is it possible to give a name to a contract created with
> contract-with-explanation?
>
> To illustrate, this example:
>>
>> #lang racket
>> (define has-explanation/c
>>   (flat-contract-with-explanation
>>(λ (val)
>>  (λ (blame)
>>(raise-blame-error blame val
>>   '(expected:
>> "nothing would pass this"
>> given: "~e")
>>   val)
>> (define/contract sample-violation
>>   has-explanation/c
>>   42)
>
> prints this error message:
>>
>> sample-violation: broke its own contract
>>   promised: nothing would pass this
>>   produced: 42
>>   in: anonymous-flat-contract
>>   contract from: (definition sample-violation)
>>   blaming: (definition sample-violation)
>>(assuming the contract is correct)
>
> which is wonderful, except for the "anonymous-flat-contract" part.
>
> If I try to give it a name with rename-contract, it loses the custom error
> reporting: e.g. this example:
>>
>> (define/contract sample-violation/renamed
>>   (rename-contract has-explanation/c
>>'renamed:has-explanation/c)
>>   42)
>
> prints this:
>>
>> sample-violation/renamed: broke its own contract
>>   promised: renamed:has-explanation/c
>>   produced: 42
>>   in: renamed:has-explanation/c
>>   contract from:
>>   (definition sample-violation/renamed)
>>   blaming: (definition sample-violation/renamed)
>>(assuming the contract is correct)
>
>
> The same thing happens with flat-named-contract: e,g, this
>>
>> (define/contract sample-violation/flat-named
>>   (flat-named-contract 'flat-named:has-explanation/c
>>has-explanation/c)
>>   42)
>
> prints this:
>>
>> sample-violation/flat-named: broke its own contract
>>   promised: flat-named:has-explanation/c
>>   produced: 42
>>   in: flat-named:has-explanation/c
>>   contract from:
>>   (definition sample-violation/flat-named)
>>   blaming: (definition sample-violation/flat-named)
>>(assuming the contract is correct)
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


Re: [racket-users] Announcing Leibniz, a new language in the Racket universe

2017-04-13 Thread Shriram Krishnamurthi
Yes, this clarifies everything, thanks!

Some more comments/thoughts.

I would suggest adding a @(table-of-contents) to the top of every page: it
helps the reader know what is coming ahead. For instance, it's good for me
to know up front that I don't have to understand sec 1 all by myself,
because you will explain it to me in sec 2. This is very helpful when you
have biggish sections: e.g.,

http://papl.cs.brown.edu/2017/set-representations.html

[Yes, this is what the gutter at hte left says. Me, somehow, I always
ignore that gutter, because on most Web sites it's irrelevant.]

(Not exclusively, the text could also just have a forward reference in the
prose of sec 1 itself.)

Your (lack of) op precedence I find a little confusing, a bit curiously
given that I'm designing a language with the same op precedence. In Pyret
we have no op precedence, but we allow a sequence of the same binop to not
need parens; everything else needs to be parenthesized. We've used this for
years now with students and it has been received well because it's simple
and consistent. For instance, if I write

fun D1(prey):
  (prey-growth-rate * prey) - predation-rate * predators * prey
end

fun D2(predators):
  (predator-growth-rate * predators * prey) - predator-loss-rate * predators
end

I get the error, in both D1 and D2,

  The * operation is at the same level as the - operation.

  Use parentheses to group the operations and to make the order of
operations clear.

so I'd instead have to write

fun D1(prey):
  (prey-growth-rate * prey) - (predation-rate * predators * prey)
end

fun D2(predators):
  (predator-growth-rate * predators * prey) - (predator-loss-rate *
predators)
end

My concern is that in your case, position really matters, with two
consequences:

1. The reader has to internalize the rule, which (if they're coming from
just having programmed in something else) they may not even realize — these
kinds of rules are a form of mode-switching, and we know from HCI that
humans are really bad at it.

2. Refactoring becomes annoying: if I add something to the left of an
existing expression, suddenly its parsing might have changed. So it's safer
to just parenthesize things.

The last line above drove the design of Pyret. It *is* safer to just
parenthesize, but long chains of the same operator do happen a fair bit,
and they're annoying to fully parenthesize. So we struck a compromise that
has worked very well.

Shriram

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


Re: [racket-users] Announcing Leibniz, a new language in the Racket universe

2017-04-13 Thread Konrad Hinsen
Shriram Krishnamurthi  writes:

> The Lotka-Volterra example is very helpful, thanks. It is still a bit
> unclear from the formatting which part is the Leibniz code. Is it the two
> lines marked pp1 and pp2? Are they literal code? I guess I prefer to use a
> typewriter face to make verbatim code clear, though that may be at odds
> with the script-D.

My current typesetting conventions use a light blue background for code.
The main reason is that this convention can be extended to other uses,
such as (in my current version) a green background for computed results.

> Of more consequence, it would be helpful to know what “happens”. I can
> *write* this in Leibniz; that's good. Can I do anything more/else? Maybe
> now, or at least perhaps in the future? Can I do a numeric simulation? Will
> there be a Runge-Kutta solver? What about discretization issues? Etc. Put
> differently, why write it in Leibniz instead of writing it as just a
> regular Racket `reactor` program?

These are all very good questions, which I hope to have answered in my
updated example:

  http://khinsen.net/leibniz-examples/examples/leibniz-by-example.html

> Btw, I'm not entirely sure what the notation ℝp means.

Positive real numbers - that's now explained as well. I have been
looking at this stuff for too long to notice such oversights.

Thanks again for your very useful feedback!

- Konrad.

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


Re: [racket-users] [racket][draw] some APIs should be more open

2017-04-13 Thread WarGrey Gyoudmon Ju
Sorry I didn't describe my idea clearly before.

Actually, in my framework (I've been writing a CSS Engine), all those
objects are immutable and singular by design. The problem is, there is no
way for client application to tell those primary classes "The object is
already immutable".

(define rgba%
  (class inspectable-color%
(init [red  (random 255)]
   [green (random 255)]
   [blue (random 255)]
   [alpha 1.0])

(init-field [immutable? #true])

(super-make-object red green blue alpha)

(define/override (set red green blue [alpha 1.0])
  (when immutable? (error 'rgba% "color is immutable"))
  (super set red green blue alpha))

(define/override (copy-from src)
  (set (send this red) (send this green) (send this blue) (send this
alpha))
  this)

(define/override (is-immutable?)
  immutable?)

(define/override (inspect)
  (list (send this red) (send this green) (send this blue) (send this
alpha)


In this example, inspectable-color% is a subclass of color% and implements
`printable<%>` whose methods use the value of (inspect) to print its
instance. Here I have to add an extra field `immutable?` for overriding all
setter methods(This is what I meant "wordy code"), this is okay for client
application, but racket/draw still thinks the color is mutable since the
only way to make immutable color is calling (make-color) which use the
hidden public method (set-immutable).  Every time passing a custom color
object to Pen% and Brush%, it is copied.

For these simple object what I exactly asked for is to make (set-immutable)
method usable.

Font is the most complicated among them, even Pango cannot handle the
complexity well, this is a long term plan I will keep an eye on. For now,
since CSS Specification defines lots of font-relative units, and
racket/draw does not provide all the interface to obtain them(this is the
so-called "in-practical" situation mentioned by the spec). Just like
(get-handler)  exists widely in racket/draw and racket/gui, I wonder if it
is possible for font% to provide a same method, so that these duplicate
code are avoided:

(define make-desc+extent
(lambda [font-face font-size font-style font-weight]
  (define font-desc
(let ([face-is-family? (regexp-match #rx"," font-face)])
  (cond [(not face-is-family?) (pango_font_description_from_string
font-face)]
[else (let ([desc (pango_font_description_new)])
(pango_font_description_set_family desc font-face)
desc)])))
  (unless (eq? font-style 'normal) (pango_font_description_set_style
font-desc (~style font-style)))
  (unless (eq? font-weight 'normal) (pango_font_description_set_weight
font-desc (~weight font-weight)))
  (pango_font_description_set_absolute_size font-desc (* font-size
PANGO_SCALE))

  (define layout (or (unbox ) (and (set-box! 
(pango_cairo_create_layout cr)) (unbox 
  (pango_layout_set_font_description layout font-desc)

  (let ([baseline (pango_layout_get_baseline layout)])
(values font-desc baseline (λ [hint-char] (~extent layout baseline
hint-char))

  (define ~extent
(lambda [layout baseline hint-char]
  (pango_layout_set_text layout hint-char)
  (pango_layout_get_extents layout  )

  (define-values (x y width height) (~rectangle ))
  (define layout-height (PangoRectangle-height ))

  (values x y width height layout-height)))

or, just allow (get-text-extent) functions and methods returning the ink
metrics instead of the logical one.

I prefer the former.


On Wed, Apr 12, 2017 at 10:23 PM, George Neuner 
wrote:

>
> On 4/11/2017 10:41 PM, WarGrey Gyoudmon Ju wrote:
>
>> This is a little awkward, there are lots of simple classes defined in
>> racket/draw, font%, color%, pen%, brush% and so on. They just hold a group
>> of plain data, hence opportunities to be inspected easily. However by
>> default all classes are opaque, the easiest (and perhaps unique) way to
>> handle this is to inherit them and implement the `printable<%>` or
>> `writable<%>`.
>>
>> Despite the wordy code and wasting little runtime space, the major
>> problem is all those classes hide their (set-immutable) methods, even
>> worse, the immutability is checked through the private field. As a
>> consequence, subclasses of Pen% and Brush% copy color instances every time
>> to make them immutable (and opaque) again...
>>
>> So is it okay to open that interface?
>>
>
> A lot of graphic APIs - Windows, X, Display Postscript, etc. - discourage
> modifying a resource while the resource is selected in a drawing context.
>  Of course, you aren't actively prevented from doing it ... but bad things
> - including serious crashes - may happen if you touch something at exactly
> the wrong time.  Colors and pens are degenerate examples - the bitmaps
> associated with brushes and raster(ized) fonts are more representative of