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

['Lindsey Kuper' via users-redirect]

 PACMPL issue ICFP 2018
Call for Papers 

accepted papers to be invited for presentation at
 The 23rd ACM SIGPLAN International Conference on Functional Programming 
St. Louis, Missouri, USA 
   http://icfp18.sigplan.org/

### Important dates 

Submissions due:16 March 2018 (Friday) Anywhere on Earth 
https://icfp18.hotcrp.com 
Author response:2 May (Wednesday) - 4 May (Friday) 14:00 UTC
Notification:   18 May (Friday)
Final copy due: 22 June (Friday)
Conference: 24 September (Monday) - 26 September (Wednesday)

### 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 issue ICFP 2018 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 2018 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 16, 2018, 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 27 pages for a full paper or 14 pages for an Experience 
Report; in either case, the bibliography will not be counted against these 
limits. These page limits have been chosen to allow essentially the same amount 
of content with the new single-column format as was possible with the 
two-column format used in past ICFP conferences. Submissions that exceed 

[racket-users] OS X: DrRacket leaking windows?

['John Clements' via Racket Users]

Looks to me like DrR is leaking… windows. 

Specifically:

On up-to-date DrR (just rebuilt from repo, version 6.11.0.5--2017-12-20), 
pretty much up-to-date OS X (10.13.1 (17B1003)), I notice something very 
strange. I’ve seen it on two computers, so I think it should be reproducible on 
any computer:

1) Open a DrR Window, nice and big.
2) Grab the right edge of the window, and slowly drag it to the left, shrinking 
the window horizontally. Watch the area of the GC box.
3) You should see a little trail of white left behind the lower right corner of 
the window.
4) After about 1.5 seconds of slowly dragging, let go.
5) The trail is still there. What is it?
6) to find out, use a three-finger upward wipe; this separates all of the 
windows on the screen, so you can see them separately. Here’s what it looks 
like, for me:

https://www.brinckerhoff.org/tmp/many-windows-1.png

There are *hundreds* of the little buggers.

This seems like it’s clearly a Bad Thing. I can’t really say whether it’s a DrR 
or a Racket thing, though.

Opinions?

John



-- 
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: using vim to play with racket

[HiPhish]

> Maybe it is because of the fact that my daily job requires me to do manual
> compilation frequently but I don't find this very difficult.
Yeah, I use a package manager and only compile manually when I absolutely 
have
to because I don't like dealing with dependencies. A matter of perspective I
guess.


> In fact, opex works well with neovim as well for languages with providers
> (e.g. lua, python, ruby, shell and vim). I don't know much about remote
> plugins in neovim but I feel like they have a distinction between 
providers
> and remote plugins, because I can't seem to find some of the interfaces in
> vim (perl, tcl and mzscheme).
Right, providers and remote plugins are two different things. The idea 
behind
providers is that some functionality should not be implemented in Neovim, 
but
instead there should be a place to hook an application into. Take for 
example
the `:make` command: make is not built into Vim, instead you can set the
`makeprg` variable to a binary of you choice. Providers take this idea 
further,
offloading for example the clipboard support to an external program.

Remote plugins on the other hand are plugins written in a foreign language.
Where it might get confusing is that sometimes there is both: you can write 
a
plugin in Python as a remote plugin (new style) or you can write it in the 
old
style. When writing it the old style there needs to be a provider to supply 
a
Python implementation for the `:python` command to work (since there is none
built into Neovim itself).

There is no provider for the old `:mzscheme` command yet. I am planning to 
get
around to it, but it has very low priority. If anyone wants to help out I'm
open to that.

> If a remote plugin can provide such an interface with a similar command, 
then
> I think opex can simply be configured with something like the following:
>
>autocmd Filetype scheme let b:opex_cmd = 'RacketEval'

Right, that's the idea. Keep in mind that there is no difference between
functions defined in VimScript and those defined in remote plugins, so you
could also create a function reference like `funciton('RacketEval')`.

> I think the biggest problem is that the community more often talks about 
the
> possibilities rather than showing existing work. End users may simply 
prefer
> something that exists and simply works.
Many projects start with the idea of rewriting Vim, so you get someone who 
says
"I'm going to rewrite Vim in Python, and it will be much better code". Then 
he
starts implementing features one by one, and eventually he reaches the point
where he himself is satisfied with the result because it fits his own 
needs. He
never gets around implementing the rest and so you end up with a clone that
isn't compatible with anything from the Vim ecosystem. Neovim is a fork, so 
it
starts with full Vim compatibility and the developers can surgically remove 
and
replace the bits that need to be changed.

> In fact, I was already aware of neovim.rkt and I'm very glad you're here 
to
> give some feedback. It would be nice if you can give some information 
about
> the current situation in neovim and neovim.rkt.
Neovim.rkt is something I do on the side and it was my first time doing
something with asynchronicity and message passing, so progress is slow. It 
does
work though, but don't expect graceful error handling. I also haven't yet
committed to the public interface, but what I have now looks promising in my
opinion.

As for Neovim, that project is doing great. I have completely replaced Vim 
and
there are already plugins making use of its new features. Externalising
language support also makes it easier to maintain when you can just swap out
components. My personal killer feature is the terminal emulator. I thing the
fact that Vim has been copying features from Neovim instead of the other way
around should be telling enough.

-- 
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: using vim to play with racket

[Greg Hendershott]

> Try giving `eval` a namespace that includes `racket/base`:
>
> (define ns (make-base-namespace))
> (eval '(+ 1 2) ns)

p.s. If you don't supply the second, namespace argument to `eval`, it
defaults to `(current-namespace)` -- which by default is an empty
namespace.

So, you can also change the value of the `current-namespace`
parameter, around one or more calls to `eval`:

(parameterize ([current-namespace (make-base-namespace)])
  (eval '(+ 1 2))
  (eval '(+ 1 41)))

-- 
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: using vim to play with racket

[Greg Hendershott]

> This won't actually work with an argument like "(+ 2 3)", Racket complains
> that
> the '+ is an undefined identifier, but that's a problem on the Racket side
> (I
> don't know that much about Racket yet to be able to do eval magic), not on
> the
> editor side. The RacketEval function is like any other Neovim function,

Instead of `eval` using a default, empty namespace:

(eval '(+ 1 2))

Try giving `eval` a namespace that includes `racket/base`:

(define ns (make-base-namespace))
(eval '(+ 1 2) ns)

See https://docs.racket-lang.org/guide/eval.html#%28part._namespaces%29

-- 
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: using vim to play with racket

[gokcehankara]

I agree manual compilation can be quite a hassle. I have tried to avoid 
such configurations for many years myself. Then I decided I could just do 
it once for all supported languages in vim and be done with it. For racket, 
if you have it installed you most likely just need something along the line:

./configure --enable-mzschemeinterp && make && sudo make install

Maybe it is because of the fact that my daily job requires me to do manual 
compilation frequently but I don't find this very difficult. Having the 
correct packages installed is the difficult part but if you're working on 
racket then it is likely already installed on your machine. I would say 
racket is only obscure to those that are not using it. If I were to develop 
a vim plugin using mzscheme interface but has nothing to do with racket 
language itself then it would really be a problem.

I'm aware of neovim project. In fact, opex works well with neovim as well 
for languages with providers (e.g. lua, python, ruby, shell and vim). I 
don't know much about remote plugins in neovim but I feel like they have a 
distinction between providers and remote plugins, because I can't seem to 
find some of the interfaces in vim (perl, tcl and mzscheme). Or they may 
have simply removed these in the account that nobody is using them. If a 
remote plugin can provide such an interface with a similar command, then I 
think opex can simply be configured with something like the following:

autocmd Filetype scheme let b:opex_cmd = 'RacketEval'

Neovim indeed suggests good engineering solutions to some of the problems 
in vim. I think the biggest problem is that the community more often talks 
about the possibilities rather than showing existing work. End users may 
simply prefer something that exists and simply works. In fact, I was 
already aware of neovim.rkt and I'm very glad you're here to give some 
feedback. It would be nice if you can give some information about the 
current situation in neovim and neovim.rkt.

Regarding opex, it is a tiny plugin that consists of a few hundreds lines 
of codes. It is an iteration of a very simple idea that uses the existing 
work . It is finished and I doubt I will change anything except for maybe 
small bug fixes. It already works well for myself and I frequently use it 
to prepare lecture notes or do simple literate programming. This is all 
that matters for me. I put the source to public and announced it in a few 
places so that maybe a few other people on the planet may find it useful as 
well.

Gokcehan

On Wednesday, December 20, 2017 at 1:49:29 PM UTC+3, HiPhish wrote:
>
> Having to re-compile Vim with support for a language is one of its bigger
> drawbacks. It's fine for a common language like Python, but the more 
> obscure it
> gets, the less likely it is that your plugin will be of any use to other
> people. You should take a look at Neovim:
> https://neovim.io/
>
> Neovim is a fork of Vim which aims to bring the code up to modern 
> standards. It
> is not a rewrite, so all existing plugins should work and the Neovim 
> developers
> keep up with new Vim patches.
>
> One of the innovations in Neovim is its remote API. In Vim you have to 
> compile
> Vim with support for a foreign language, but in Neovim that support can be
> retrofitted to the editor as an external process. So for example, if you 
> want
> to write Neovim plugins in Python you install the Python client via pip. 
> And if
> you want to write plugins in Racket you install my Racket client:
> https://gitlab.com/HiPhish/neovim.rkt
>
> You could then write an "evaluator" plugin in Racket like this:
>
> #lang racket
> ;; Save in a file like '~/.config/nvim/rplugin/racket/eval.rkt'
> (require nvim)
> (nvim-function "RacketEval"
>   (λ (args)
> (define str (vector-ref args 0))
> (call-with-input-string str (λ (in) (eval (read in))
>
> This won't actually work with an argument like "(+ 2 3)", Racket complains 
> that
> the '+ is an undefined identifier, but that's a problem on the Racket side 
> (I
> don't know that much about Racket yet to be able to do eval magic), not on 
> the
> editor side. The RacketEval function is like any other Neovim function, 
> except
> that it offloads the work to an external process behind the scene, but the 
> user
> never notices that.
>
> The Racket client is still under development, I have not yet committed 
> fully to
> the public interface and I need to take care of some edge cases when 
> something
> goes wrong. Other than that, the client fully works.
>
>
> On Sunday, December 17, 2017 at 2:33:26 PM UTC+1, gokceh...@gmail.com 
> wrote:
>>
>> ...
>>
>

-- 
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: using vim to play with racket

[HiPhish]

Having to re-compile Vim with support for a language is one of its bigger
drawbacks. It's fine for a common language like Python, but the more 
obscure it
gets, the less likely it is that your plugin will be of any use to other
people. You should take a look at Neovim:
https://neovim.io/

Neovim is a fork of Vim which aims to bring the code up to modern 
standards. It
is not a rewrite, so all existing plugins should work and the Neovim 
developers
keep up with new Vim patches.

One of the innovations in Neovim is its remote API. In Vim you have to 
compile
Vim with support for a foreign language, but in Neovim that support can be
retrofitted to the editor as an external process. So for example, if you 
want
to write Neovim plugins in Python you install the Python client via pip. 
And if
you want to write plugins in Racket you install my Racket client:
https://gitlab.com/HiPhish/neovim.rkt

You could then write an "evaluator" plugin in Racket like this:

#lang racket
;; Save in a file like '~/.config/nvim/rplugin/racket/eval.rkt'
(require nvim)
(nvim-function "RacketEval"
  (λ (args)
(define str (vector-ref args 0))
(call-with-input-string str (λ (in) (eval (read in))

This won't actually work with an argument like "(+ 2 3)", Racket complains 
that
the '+ is an undefined identifier, but that's a problem on the Racket side 
(I
don't know that much about Racket yet to be able to do eval magic), not on 
the
editor side. The RacketEval function is like any other Neovim function, 
except
that it offloads the work to an external process behind the scene, but the 
user
never notices that.

The Racket client is still under development, I have not yet committed 
fully to
the public interface and I need to take care of some edge cases when 
something
goes wrong. Other than that, the client fully works.


On Sunday, December 17, 2017 at 2:33:26 PM UTC+1, gokceh...@gmail.com wrote:
>
> ...
>

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