[racket-users] First Call for Papers: PACMPL issue ICFP 2019

['Sam Tobin-Hochstadt' via users-redirect]

PACMPL Volume 3, Issue ICFP 2019

Call for Papers



accepted papers to be invited for presentation at

 The 24th ACM SIGPLAN International Conference on Functional Programming

 Berlin, Germany

   http://icfp19.sigplan.org/



### Important dates



Submissions due:1 March 2019 (Friday) Anywhere on Earth

https://icfp19.hotcrp.com

Author response:16 April (Tuesday) - 18 Apri (Friday) 14:00 UTC

Notification:   3 May (Friday)

Final copy due: 22 June (Saturday)

Conference: 18 August (Sunday) - 23 August (Friday)



### About PACMPL



Proceedings of the ACM on Programming Languages (PACMPL 
) is a Gold Open Access journal publishing research on 
all aspects of programming languages, from design to implementation and from 
mathematical formalisms to empirical studies. Each issue of the journal is 
devoted to a particular subject area within programming languages and will be 
announced through publicized Calls for Papers, like this one.



### Scope



[PACMPL](https://pacmpl.acm.org/) issue ICFP 2019 seeks original papers on the 
art and science of functional programming. Submissions are invited on all 
topics from principles to practice, from foundations to features, and from 
abstraction to application. The scope includes all languages that encourage 
functional programming, including both purely applicative and imperative 
languages, as well as languages with objects, concurrency, or parallelism. 
Topics of interest include (but are not limited to):



  * *Language Design*: concurrency, parallelism, and distribution; modules; 
components and composition; metaprogramming; type systems; interoperability; 
domain-specific languages; and relations to imperative, object-oriented, or 
logic programming.



  * *Implementation*: abstract machines; virtual machines; interpretation; 
compilation; compile-time and run-time optimization; garbage collection and 
memory management; multi-threading; exploiting parallel hardware; interfaces to 
foreign functions, services, components, or low-level machine resources.



  * *Software-Development Techniques*: algorithms and data structures; design 
patterns; specification; verification; validation; proof assistants; debugging; 
testing; tracing; profiling.



  * *Foundations*: formal semantics; lambda calculus; rewriting; type theory; 
monads; continuations; control; state; effects; program verification; dependent 
types.



  * *Analysis and Transformation*: control-flow; data-flow; abstract 
interpretation; partial evaluation; program calculation.



  * *Applications*: symbolic computing; formal-methods tools; artificial 
intelligence; systems programming; distributed-systems and web programming; 
hardware design; databases; XML processing; scientific and numerical computing; 
graphical user interfaces; multimedia and 3D graphics programming; scripting; 
system administration; security.



  * *Education*: teaching introductory programming; parallel programming; 
mathematical proof; algebra.



Submissions will be evaluated according to their relevance, correctness, 
significance, originality, and clarity. Each submission should explain its 
contributions in both general and technical terms, clearly identifying what has 
been accomplished, explaining why it is significant, and comparing it with 
previous work. The technical content should be accessible to a broad audience.



PACMPL issue ICFP 2019 also welcomes submissions in two separate categories 
 Functional Pearls and Experience Reports  that must be marked as 
such at the time of submission and that need not report original research 
results.  Detailed guidelines on both categories are given at the end of this 
call.



Please contact the principal editor if you have questions or are concerned 
about the appropriateness of a topic.



### Preparation of submissions



**Deadline**: The deadline for submissions is **Friday, March 1, 2019**, 
Anywhere on Earth ().  This 
deadline will be strictly enforced.



**Formatting**: Submissions must be in PDF format, printable in black and white 
on US Letter sized paper, and interpretable by common PDF tools. All 
submissions must adhere to the "ACM Small" template that is available (in both 
LaTeX and Word formats) from 
.  For authors using 
LaTeX, a lighter-weight package, including only the essential files, is 
available from .



There is a limit of **25 pages for a full paper or Functional Pearl** and **12 
pages for an Experience Report**; in either case, the bibliography will not be 
counted against these limits. Submissions that exceed the page limits or, for 
other reasons, do not meet the requirements for formatting, will be 

Re: [racket-users] Racket Guide, REs, section 9.5

[Matthew Flatt]

At Tue, 6 Nov 2018 09:53:38 -0800 (PST), Jussi Salmela wrote:
> At the end of section 9.5 there is the sentence:
> 
>The non-greedy quantifiers are respectively: *?, +?, ??, {m}?, {m,n}?. 
> 
> I don't understand what {m}? is supposed to match because {m} means 'match 
> exactly the previous pattern'.

I think you're right that `{m}?` is always the same as `{m}`, and I'll
add a clarification to the Guide.

-- 
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] Creating truly unique instances of structure types?

[Matthew Flatt]

At Mon, 5 Nov 2018 16:26:16 -0600, Alexis King wrote:
> To provide an example, `racket/contract` exports a value called 
> `the-unsupplied-arg`, which is created using the usual structure type 
> generativity trick:
> 
> (define-struct the-unsupplied-arg ())
> (define the-unsupplied-arg (make-the-unsupplied-arg))
> (provide the-unsupplied-arg)
> 
> The constructor is not exported, and this value is intended to be unique. 
> However, if we can arrange for the contract library to be loaded on our 
> terms, 
> we can thwart this encapsulation by supplying it with a weaker inspector:
> 
> #lang racket/base
> 
> (define the-unsupplied-arg
>   (parameterize ([current-inspector (make-inspector)])
> (dynamic-require 'racket/contract 'the-unsupplied-arg)))
> 
> (define-values [info skipped?] (struct-info the-unsupplied-arg))
> 
> (define another-unsupplied-arg ((struct-type-make-constructor info)))
> 
> (equal? the-unsupplied-arg another-unsupplied-arg) ; => #t
> (eq? the-unsupplied-arg another-unsupplied-arg); => #f

Later parts of the thread have touched on this, but the general rule is
that if you control the environment where code is loaded, then you can
do anything to that code. After all, if you get to pick the
environment, then you could use an interpreter that you wrote from
scratch and that gives you whatever capabilities you want.[*]

If you don't control the environment of `racket/contract`, then you
might not be able to break in this way. It depends on how the
environment is set up, though. If `racket/contract` is loaded before
your code, then it's too late to change the inspector, but maybe you
can load `ffi/unsafe` and still do whatever you want. Or maybe your
code is prevented from loading `ffi/unsafe` directly due to a
code-inspector change, but some sandbox bug or a bug in a trusted
library lets you get access to unsafe operations anyway.

Chaperones and inspectors provide a set of ground rules for access, and
`the-unsupplied-arg` is unique for a setting that respects those rules.
A program can subvert the rules through outside control or through
environment weaknesses. We've tried to build mechanisms that absolutely
enforce the rules, and it works well enough for some purposes, but
offering real guarantees turns out to be impractical for now.

It seems possible that if a sandbox is working right and if unsafe
operations are truly inaccessible, then maybe currently a chaperone is
enough to guard against even a superior inspector. But that doesn't
seem like a good solution to me. Instead, it makes me think that there
should be an operation that lets a sufficiently powerful inspector pull
apart chaperones.

[*] There's some work on encrypted computation where the environment
executing some code can't know everything about the code. I'm guess
that's not where you're trying to go, though.

-- 
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] unit testing output

[Neil Van Dyke]

David Storrs wrote on 11/8/18 11:10 AM:
Will test successes show output as well?  For me that's the hard stop 
on using RackUnit -- the fact that it shows nothing on success means 
that there's no way to tell the difference between "everything ran and 
passed", "some things ran and passed but some things that should have 
run did not", and "nothing ran".


I've felt the same about this -- it still bothers me a little. 
(Examples: In DrRacket, there's always a possibility that test-running 
has been disabled in a preference setting that's buried in a 
nonintuitive place, several hops deep in UI navigation, not a top-level 
indicator, but that someone might turn off accidentally when trying to 
adjust a different behavior.  Or, on the command line, you might not 
realize you're in the wrong directory to pick up the tests you're 
expecting.  Or maybe you'd like at least a crude idea of how much tests 
are running for a bit of unfamiliar code.)


Perhaps the difference between "test failures" and "code errors" here 
(neither of which you'll see in DrRacket, if there's not a problem) is 
that, when you run code as a program, there is usually some other 
behavior you can see, to know that at least some code has been 
processed.  Not so for passing tests.


My original portable Scheme test framework always printed a full log, 
including ending with a summary like:


    ;;; END "Foo Station" TESTS: FAILED
    ;;; (Total: 4  Passed: 3  Failed: 1)

My later Racket-specific test framework, Overeasy, used the logger for 
non-test-failure messages.  But probably the Racket logs are not 
normally visible to most programmers, so this isn't great.


Absent a richer test metadata mechanism in DrRacket and `raco test`, I'm 
not sure how to do this better for both DrRacket and command line.


So... Would the following simple two-part approach (special-casing 
DrRacket) work, or does someone have a better idea?


* When tests are under current DrRacket, we could use stdout for a 
one-line successful tests summary message, and stderr for a one-line 
tests failure summary message of the same format.  The different streams 
are so that we avoid misusing the HCI effect that DrRacket achieves when 
it colors errors in angry red.  (I think this doesn't break much, since 
programs under DrRacket won't be using stdout and stderr for old Unix 
"software tools" composition anyway.)


* When tests are run under `raco test`, we could use either stdout or 
stderr for the one-line summary message.  The question then is whether 
any CI-like frameworks that run tests like `raco test` currently 
treating any output as failure (I'm not certain, offhand).  We could 
always kludge an environment variable to inhibit the summary for unusual 
situations, but I'd like to keep this kind of thing simple and clean.


An alternative to the above would be to expose test metadata from the 
`test` submodules somehow, such as with "push" calls out akin to how 
`error-display-handler` works, or by a convention of `test` submodules 
providing a "pull" interface for programs like DrRacket to query.  
Making that work requires changes to core Racket code. (And, as usual 
with this kind of facility, probably half of everyone will think it's 
being done wrong.)  The simple stdout/stderr convention above, 
special-casing DrRacket, OTOH, can be done easily, in a distributed and 
non-disruptive way.


--
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] unit testing output

[David Storrs]

On Wed, Nov 7, 2018 at 3:45 PM Neil Van Dyke  wrote:

> Greg Hendershott wrote on 11/6/18 9:56 AM:
> > I'd suggest writing to stderr the same location format used by rackunit.
>
> OK, thank you (and David Storr).  I looked at the current RackUnit. How
> about the following proposal?
>
> Proposal: A test failure message is a one-line message that:
> * in DrRacket, includes the clickable error icons; and
> * on the command line (or in Emacs, Vim, etc.), is to stderr, and
> includes the filename+line+column in a conventional non-Racket-specific
> format.
>
> Details...
>
> The reason I don't want to use the RackUnit message format exactly is
> that it has some excess stuff in it that won't work great with reporting
> many tests, like I tend do them in Overeasy.  Consider, for example, a
> dozen tests failing, and you can eyeball the dozen one-line messages at
> once to see whether they appear all related.
>
> To implement the DrRacket clickable icons, it looks from
> "racket-7.1/share/racket/pkgs/rackunit-lib/rackunit/private/format.rkt"
> like I can do something like this simplified demo:
>
>  #lang racket/base
>  (with-handlers ((exn:fail? (lambda (exn)
>   ((error-display-handler) (exn-message
> exn) exn
>(error "TEST-FAILURE: [foomodule barproc empty-string] Expected
> 42, got 0."))
>
> In DrRacket, that demo displays a concise single-line message, with the
> clickable icons:
>
>   TEST-FAILURE: [foomodule barproc empty-string] Expected 42,
> got 0.
>
>  From the command line, that demo displays multi-line, which I don't
> want (mainly for the dozen-failures-eyeballing reason):
>
>  TEST-FAILURE: [foomodule barproc empty-string] Expected 42, got 0.
>context...:
> "/home/user/paddle-test-play.rkt": [running body]
> temp37_0
> for-loop
> run-module-instance!125
> perform-require!78
>
> So, how about the command line format omits the calling stack context,
> and instead uses a simple conventional one-line format that works out of
> the box with most tools, like one of:
>
>  PROGRAM:FILE:LINE:COL: MESSAGE
>  PROGRAM:FILE:LINE: MESSAGE
>  FILE:LINE:COL: MESSAGE
>  FILE:LINE: MESSAGE
>
> where "PROGRAM" (if present) *might* be something like "TEST" or
> "TEST-FAILURE", instead of "my-racket-test-engine" or "raco test" or
> whatever Racket program invoked the tests.
>
> BTW, that "[foomodule barproc empty-string]" part of the failure message
> is Overeasy's `test-section` symbolic way of identifying tests, which is
> complementary to source location, and meaningful to programmers/testers:
> https://www.neilvandyke.org/racket/overeasy/#%28part._.Test_.Sections%29
>
> BTW, the "Expected ___, got ___." message would also have other forms,
> for different test pass criteria or ways that tests could fail.  That
> simple form is just for the most common case, of two sets of normal
> expression result values failing a equivalence check by `equal?`.
>
>
Will test successes show output as well?  For me that's the hard stop on
using RackUnit -- the fact that it shows nothing on success means that
there's no way to tell the difference between "everything ran and passed",
"some  things ran and passed but some things that should have run did not",
and "nothing ran".


-- 
> 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] plot library: legend outside plot?

[Dmitry Pavlov]

Hello,

Is it possible to render a plot with the legend outside the plotting 
area, like gnuplot does with "set key outside" option?


I see only (plot-legend-anchor) parameter for placement of the legend in 
different places inside the plot area.


Best regards,

Dmitry


--
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] Re: 2HTDP "Mice and Characters/Keys" link broken

[Matthias Felleisen]

  http://felleisen.org/matthias/HtDP2e/

[[ htdp.org will be repaired shortly. ]]


> On Nov 8, 2018, at 8:48 AM, Scott  wrote:
> 
> Is there another location for the information I assume resided within the 
> broken link? Thanks!
> 
> On Wednesday, November 7, 2018 at 4:58:14 PM UTC-5, Scott wrote:
> The online version has a broken link to recommended reading. 
> 
> -- 
> 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] Re: 2HTDP "Mice and Characters/Keys" link broken

[Scott]

Is there another location for the information I assume resided within the 
broken link? Thanks!

On Wednesday, November 7, 2018 at 4:58:14 PM UTC-5, Scott wrote:
>
> The online version has a broken link to recommended reading. 
>

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