Re: [racket-users] IO in racket is painful

[Gustavo Massaccesi]

IIRC the previous discussion, one way to fix this problem is to make a
package that can parse strings easily using a C like format, like the
expected in the contests. Something like

#lang racket
(require compatibility/scanf)

(let-values ([(x y) (scanf "%d %d" (read-line))])
  (display (+ x y)))

It's not very idiomatic, but it may be helpful for this particular use.

IIRC another problem is that in the contest you are not allowed to
install the packages you wish, you can only use the default
installation. But I think that the idea is not to allow everything in
the default installation.


So my proposal is to add another installation mode for Racket

* minimal: Only the core and some minimal packages
* main: The normal set of packages, (only idiomatic) batteries included.
* community (new): everything in the ring 1, including the kitchen
sink. With a minimal curation and a minimal baseline of features (like
no breaking the installation). (And a compatible license.) The
packages may disappear/change/reappear from version to version. All
the additional packages may be experimental/unstable/unsuported.

Is this acceptable in a competition?
Is this acceptable as another "official" Racket distribution?

Gustavo



On Fri, Jul 21, 2017 at 4:35 PM, Brian Mastenbrook
 wrote:
> On 07/21/2017 12:49 PM, Matthias Felleisen wrote:
>>
>>
>>> On Jul 21, 2017, at 1:56 AM, Sorawee Porncharoenwase
>>>  wrote:
>>>
>>> Sorry for reviving an old thread. As someone who did a lot of programming
>>> competition in the past, I can totally see why IO in Racket is difficult. As
>>> mark.engelberg said, the goal is to solve as many problems as possible.
>>> After the competition is over, it's over. No one is going to care about
>>> maintainability or good coding practice if it makes coding slower.
>>
>>
>> Which is why I think programming competitions are a direct attempt to
>> undermine computer science and computer-science education.
>>
>> Having said that, if you want to use Racket for competitions, you and Mark
>> Engelberg should get together and produce a high-utility IO library. We can
>> then include it in the distribution.
>
>
> Just as a counterpoint, I have this kind of ad-hoc parse-this-produce-that
> problem all the time in the "real" world. When the logic of the problem is
> sufficiently complex I'll swallow the overhead of doing it in Racket, or
> I'll use Perl to transform the input into something I can read in Racket. It
> would be nice to have an I/O library that made it easy, but I don't have any
> specific thoughts about how to do that.
>
> I don't think computer science education should ignore this kind of problem
> though. It's very important to teach students how to solve problems
> methodically with a design recipe, how to collaborate with others, and how
> to reason about their programs. But it's also important that programmers
> (and also or even especially those who don't program for a living) be
> comfortable with using the machine to solve or automate the solution to
> one-off problems that would otherwise require a lot of manual fiddling with
> data. Being fluent with this kind of programing gives people the confidence
> they need to solve smaller problems or explore potential solutions to large
> problems in an unstructured manner before tackling the methodical, "right"
> solution.
>
> --
> Brian Mastenbrook
> br...@mastenbrook.net
> https://brian.mastenbrook.net/
>
>
> --
> 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] IO in racket is painful

[Brian Mastenbrook]

On 07/21/2017 12:49 PM, Matthias Felleisen wrote:



On Jul 21, 2017, at 1:56 AM, Sorawee Porncharoenwase 
 wrote:

Sorry for reviving an old thread. As someone who did a lot of programming 
competition in the past, I can totally see why IO in Racket is difficult. As 
mark.engelberg said, the goal is to solve as many problems as possible. After 
the competition is over, it's over. No one is going to care about 
maintainability or good coding practice if it makes coding slower.


Which is why I think programming competitions are a direct attempt to undermine 
computer science and computer-science education.

Having said that, if you want to use Racket for competitions, you and Mark 
Engelberg should get together and produce a high-utility IO library. We can 
then include it in the distribution.


Just as a counterpoint, I have this kind of ad-hoc 
parse-this-produce-that problem all the time in the "real" world. When 
the logic of the problem is sufficiently complex I'll swallow the 
overhead of doing it in Racket, or I'll use Perl to transform the input 
into something I can read in Racket. It would be nice to have an I/O 
library that made it easy, but I don't have any specific thoughts about 
how to do that.


I don't think computer science education should ignore this kind of 
problem though. It's very important to teach students how to solve 
problems methodically with a design recipe, how to collaborate with 
others, and how to reason about their programs. But it's also important 
that programmers (and also or even especially those who don't program 
for a living) be comfortable with using the machine to solve or automate 
the solution to one-off problems that would otherwise require a lot of 
manual fiddling with data. Being fluent with this kind of programing 
gives people the confidence they need to solve smaller problems or 
explore potential solutions to large problems in an unstructured manner 
before tackling the methodical, "right" solution.


--
Brian Mastenbrook
br...@mastenbrook.net
https://brian.mastenbrook.net/

--
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] (seventh RacketCon): Do You Have Your Ticket?

[Vincent St-Amour]

Racketeers,

(seventh RacketCon) is getting closer!

To whet your appetite, you can find details about some of the talks
we're looking forward to on the RacketCon website [1].

Also don't forget to register [2] and take advantage of our group rate
[3] at the very nice Hotel Deca [4].

If you would like to speak about something cool you've built, please get
in touch! Our schedule is already packed with rackety goodness, but we
can still squeeze more in!

---

RacketCon[1] is a yearly event where members of the Racket community get
together, featuring talks and demos about the things you do with Racket.
Racketeer Office Hours is a free-form day for Racketeers to get together
and collaborate on ongoing projects, start new ones, and get help and
advice from other members of the community.

(seventh RacketCon) will be held on October 7th, followed by Racketeer
Office Hours on October 8th. This year, RacketCon will be in Seattle, WA,
with support from the Racket group at the University of Washington.

See you in Seattle!

Vincent, for the RacketCon team


[1] http://con.racket-lang.org/
[2] https://www.eventbrite.com/e/racketcon-2017-tickets-34928590354
[3] 
https://gc.synxis.com/rez.aspx?Hotel=76675=10069=10/6/2017=10/8/2017=1=0=4AM98Y
[4] http://www.hoteldeca.com/

-- 
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] IO in racket is painful

[Neil Van Dyke]

Racket's underlying I/O seems sophisticated to me, and contest-friendly 
parsing conveniences can be layered atop that.


IIRC, a long time ago, Olin Shivers made some parsing stuff for Scheme, 
which you might want to steal or at least look at.  I'm not sure where 
it all went, or who else was involved, but I'd start looking here:


https://scsh.net/docu/html/man-Z-H-7.html#node_chap_6
https://scsh.net/docu/html/man-Z-H-8.html#node_chap_7
https://scsh.net/docu/html/man-Z-H-9.html#node_chap_8

The Racket package catalog is also worth a look.  I mostly know my own 
old packages, so I'll mention a few parsing-related ones:


For the broad category of CSV format data files (in addition to lots of 
quoting and escaping conventions, can also handle inputs like ASCII 
tables with columns separated by vertical bars, for example):

http://www.neilvandyke.org/racket/csv-reading/

For JSON parsing, you probably want to use the core Racket JSON stuff, 
but at one point I accidentally made a folding JSON parser 
(unfortunately, not using `syntax-parse`) that might come in handy for 
big data:

http://www.neilvandyke.org/racket/json-parsing/

For HTML parsing and rewriting, an ancient Scheme library probably still 
works (but you'll want to get comfortable with SXML ahead of time, 
especially if you're new to old-school list processing):

http://www.neilvandyke.org/racket/html-parsing/
http://www.neilvandyke.org/racket/sxml-intro/

If a contest ever requires that your program modify its own source file, 
we got yo back:

http://www.neilvandyke.org/racket/progedit/

Aside on programming contests: I see them as a good *side* thing, kept 
in perspective.  It's an alternative way that some people get excited 
about programming and problem-solving, and then put in the work and 
learn things along the way.  Two provisos:


(1) We have to be aware that contests can be anti-engineering, and 
remember to also learn engineering.  Know when to be in contest mode, 
vs. normal engineering mode, vs. somewhat sloppier mode, vs. urgent yet 
it must work perfectly and resiliently the first time or the asteroid 
will destroy Earth engineering mode, vs. the asteroid mode plus it might 
also need keep deflecting asteroids for years after mode.


(2) Don't let the existence of programming contests discourage people 
from learning programming or other STEM stuff.  The contests are 
artificial, and only loosely related to programming/STEM goals. Some 
people have a big head start on being good at contests, but, if you want 
to do programming and other STEM stuff, you can get good at that without 
ever having to be good at contests, nor even try contests.  (Related: 
try to find and remember a balance between humility and confidence -- in 
school, immediately post-school, and later.  If we're always thinking 
that we have more to learn, but that we do know some things, and can 
build upon that to help tackle goals that seem hard, I think that's a 
good starting point for finding this balance.)


--
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] [ANN] New package: disposable

[Jack Firth]

I recently published `disposable`, an experimental package for safely handling 
external resources.

Features:

- representation of a "disposable", a producer of values with external 
resources that must be disposed
- safe handling of disposables for multiple usage patterns, including:
  - for a series of expressions, `(with-disposable ([v disp]) body ...)`
  - for the lifetime of the program with the resource cleaned up on program 
exit, `(acquire-global disp)`
  - for the lifetime of the current thread, with a single resource reused 
automatically in the same thread, `(acquire-virtual disp)` (heavily inspired by 
virtual connections in the `db` library)
  - until an arbitrary event is ready for synchronization, `(acquire disp 
#:dispose-evt (alarm-evt 1000))`
- abstractions over disposables and combinators for extending disposables, 
including:
  - creating a pool of disposable values with reuse, `(disposable-pool disp)`
  - asynchronously deallocating disposables, `(disposable/async-dealloc disp)`
  - monadically composing disposables with concurrent allocation and 
deallocation, `(disposable-apply f disp ...)` and `(disposable-chain disp f)`
- temporary files and directories as disposables
- utilities for testing disposables, including observing when allocation and 
deallocation occur

If you're familiar with AutoClosable in Java or IDisposable in C#, think of 
disposables as thunks that produce AutoClosable or IDisposable values.

The API is still in the early stages, and there's a few concurrency bugs to 
work out but the features above should work as advertised. Feedback strongly 
welcomed.

Docs: http://docs.racket-lang.org/disposable/
Source code: https://github.com/jackfirth/racket-disposable

-- 
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] A bug in the Typed Racket system?

[Sourav Datta]

On Friday, July 21, 2017 at 9:06:16 PM UTC+5:30, Ben Greenman wrote:
> Type inference is failing you again.

Yes, well, that seems to be a common theme whenever I hover around the these 
type of areas which are uncommon but works perfectly fine in untyped Racket.

> 
> 
> If you instantiate `foo/s`, you get the type you expect:
> 
> 
> 
> #lang typed/racket
> 
> 
> (struct (a) Foo ([val : (-> a a)]))
> 
> 
> (: foo/s (All (a b)
>               (-> (-> a b)
>                   (-> (Foo a)
>                       (Foo b)
>                       (Foo b)
> (define (foo/s f)
>   (λ ([f1 : (Foo a)]
>       [f2 : (Foo b)])
>     f2))
> 
> 
> 
> 
> (define r1 (#{foo/s @ Integer String} (λ ([x : Integer]) (format "~a" x
> 
> ;> r1
> ;- : (-> (Foo Integer) (Foo String) (Foo String))

Yes, that works fine. For my personal use it is good enough, but exporting that 
function as a library would require every user to annotate the type whenever 
they want to call it, even for very simple types - which is not a very good 
experience for a typed language.

> 
> 
> 
> 
> I wouldn't call this a bug, but it's definitely a program that a better type 
> inferencer should accept.

In other cases where type inference fails, the compiler bails out with an error 
(even though that is a confusing one like `expected: (Seq a) given: (Seq 
Integer)`). But here:

1. The inference did not fail but assumed it's Nothing just because I changed 
the function signature from (-> a) to (-> a a). I can't understand why the 
inference fails for this change. And on top of this,

2. The function type is clearly specified as (-> (Foo a) (Foo b) (Foo b)) and 
it can unify a = Integer, b = String, from the first argument alone. So, even 
though a is Integer, it still produces a = Nothing, without a compile error. 
Integer =/= Nothing. Seems very close to a bug in the type deduction algorithm.


> 
> 
> On Fri, Jul 21, 2017 at 5:19 AM, Sourav Datta  wrote:
> Consider this program,
> 
> 
> 
> #lang typed/racket
> 
> 
> 
> (struct (a) Foo ([val : (-> a)]))
> 
> 
> 
> (: foo/s (All (a b)
> 
>               (-> (-> a b)
> 
>                   (-> (Foo a)
> 
>                       (Foo b)
> 
>                       (Foo b)
> 
> (define (foo/s f)
> 
>   (λ ([f1 : (Foo a)]
> 
>       [f2 : (Foo b)])
> 
>     f2))
> 
> 
> 
> 
> 
> (define r1 (foo/s (λ ([x : Integer]) (format "~a" x
> 
> 
> 
> The type of r1 is correctly deduced as:
> 
> 
> 
> - : (-> (Foo Integer) (Foo String) (Foo String))
> 
> #
> 
> 
> 
> However, if I slightly change the struct Foo and do the same, like this:
> 
> 
> 
> #lang typed/racket
> 
> 
> 
> (struct (a) Foo ([val : (-> a a)]))
> 
> 
> 
> (: foo/s (All (a b)
> 
>               (-> (-> a b)
> 
>                   (-> (Foo a)
> 
>                       (Foo b)
> 
>                       (Foo b)
> 
> (define (foo/s f)
> 
>   (λ ([f1 : (Foo a)]
> 
>       [f2 : (Foo b)])
> 
>     f2))
> 
> 
> 
> 
> 
> (define r1 (foo/s (λ ([x : Integer]) (format "~a" x
> 
> 
> 
> Now, r1 has this type:
> 
> 
> 
> - : (-> (Foo Nothing) (Foo String) (Foo String))
> 
> #
> 
> 
> 
> Surprisingly (Foo Integer) has changed to (Foo Nothing)! Is this a possible 
> bug in the type system? Or, may be I'm missing something?
> 
> 
> 
> Thanks!
> 
> 
> 
> --
> 
> 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...@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] IO in racket is painful

[Matthias Felleisen]

> On Jul 21, 2017, at 1:56 AM, Sorawee Porncharoenwase 
>  wrote:
> 
> Sorry for reviving an old thread. As someone who did a lot of programming 
> competition in the past, I can totally see why IO in Racket is difficult. As 
> mark.engelberg said, the goal is to solve as many problems as possible. After 
> the competition is over, it's over. No one is going to care about 
> maintainability or good coding practice if it makes coding slower. 


Which is why I think programming competitions are a direct attempt to undermine 
computer science and computer-science education. 

Having said that, if you want to use Racket for competitions, you and Mark 
Engelberg should get together and produce a high-utility IO library. We can 
then include it in the distribution. 


-- 
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] A bug in the Typed Racket system?

[Ben Greenman]

Type inference is failing you again.

If you instantiate `foo/s`, you get the type you expect:

#lang typed/racket

(struct (a) Foo ([val : (-> a a)]))

(: foo/s (All (a b)
  (-> (-> a b)
  (-> (Foo a)
  (Foo b)
  (Foo b)
(define (foo/s f)
  (λ ([f1 : (Foo a)]
  [f2 : (Foo b)])
f2))


(define r1 (#{foo/s @ Integer String} (λ ([x : Integer]) (format "~a" x
;> r1
;- : (-> (Foo Integer) (Foo String) (Foo String))


I wouldn't call this a bug, but it's definitely a program that a better
type inferencer should accept.

On Fri, Jul 21, 2017 at 5:19 AM, Sourav Datta  wrote:

> Consider this program,
>
> #lang typed/racket
>
> (struct (a) Foo ([val : (-> a)]))
>
> (: foo/s (All (a b)
>   (-> (-> a b)
>   (-> (Foo a)
>   (Foo b)
>   (Foo b)
> (define (foo/s f)
>   (λ ([f1 : (Foo a)]
>   [f2 : (Foo b)])
> f2))
>
>
> (define r1 (foo/s (λ ([x : Integer]) (format "~a" x
>
> The type of r1 is correctly deduced as:
>
> - : (-> (Foo Integer) (Foo String) (Foo String))
> #
>
> However, if I slightly change the struct Foo and do the same, like this:
>
> #lang typed/racket
>
> (struct (a) Foo ([val : (-> a a)]))
>
> (: foo/s (All (a b)
>   (-> (-> a b)
>   (-> (Foo a)
>   (Foo b)
>   (Foo b)
> (define (foo/s f)
>   (λ ([f1 : (Foo a)]
>   [f2 : (Foo b)])
> f2))
>
>
> (define r1 (foo/s (λ ([x : Integer]) (format "~a" x
>
> Now, r1 has this type:
>
> - : (-> (Foo Nothing) (Foo String) (Foo String))
> #
>
> Surprisingly (Foo Integer) has changed to (Foo Nothing)! Is this a
> possible bug in the type system? Or, may be I'm missing something?
>
> Thanks!
>
> --
> 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] Putting everything in a single monolithic source file

[WarGrey Gyoudmon Ju]

If the code is written in Typed Racket, the compilation time will drive you
mad
since every one-byte-modification forces the entire project being
typed-checked...

On Fri, Jul 21, 2017 at 5:07 PM, Erich Rast  wrote:

> I'm using mostly racket-mode in emacs for development and even with helm
> and projectile mode greping info from the source directory is
> cumbersome. So I was thinking about putting my entire project into one
> source file with lots of explicit (module ...) declarations. This
> doesn't break modularity, I'm the only developer, and I can still
> factor out specific modules as packages later.
>
> But I'm  wondering whether this has any other disadvantages e.g. for
> compilation or optimization, or might even break in future?
>
> Best,
>
> Erich
>
> --
> 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] Olin Shivers's loop is supposed to be around somewhere

[Sanjeev Sharma]

anyone have a working implemntation?

Just a little while ago I read something to the effect that Shivers thought 
error handling would be a huge mess but there's a Racket implementation that 
does a lot of error handling cheaply.  

-- 
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] A bug in the Typed Racket system?

[Sourav Datta]

Consider this program,

#lang typed/racket

(struct (a) Foo ([val : (-> a)]))

(: foo/s (All (a b)
  (-> (-> a b)
  (-> (Foo a)
  (Foo b)
  (Foo b)
(define (foo/s f)
  (λ ([f1 : (Foo a)]
  [f2 : (Foo b)])
f2))


(define r1 (foo/s (λ ([x : Integer]) (format "~a" x

The type of r1 is correctly deduced as: 

- : (-> (Foo Integer) (Foo String) (Foo String))
#

However, if I slightly change the struct Foo and do the same, like this:

#lang typed/racket

(struct (a) Foo ([val : (-> a a)]))

(: foo/s (All (a b)
  (-> (-> a b)
  (-> (Foo a)
  (Foo b)
  (Foo b)
(define (foo/s f)
  (λ ([f1 : (Foo a)]
  [f2 : (Foo b)])
f2))


(define r1 (foo/s (λ ([x : Integer]) (format "~a" x

Now, r1 has this type:

- : (-> (Foo Nothing) (Foo String) (Foo String))
#

Surprisingly (Foo Integer) has changed to (Foo Nothing)! Is this a possible bug 
in the type system? Or, may be I'm missing something?

Thanks!

-- 
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] Putting everything in a single monolithic source file

[Erich Rast]

I'm using mostly racket-mode in emacs for development and even with helm
and projectile mode greping info from the source directory is
cumbersome. So I was thinking about putting my entire project into one
source file with lots of explicit (module ...) declarations. This
doesn't break modularity, I'm the only developer, and I can still
factor out specific modules as packages later.

But I'm  wondering whether this has any other disadvantages e.g. for
compilation or optimization, or might even break in future?

Best,

Erich

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