[racket] REPL and read-line

291 views
Skip to first unread message

Alexandre Moreira

unread,
Jan 6, 2011, 1:09:49 PM1/6/11
to us...@racket-lang.org
Hello, everyone. I'm trying to use the (read-line) function in
racket's REPL and I'm having a weird problem. Whenever I type
(read-line) in the REPL prompt it returns the empty string. It's as if
it is receiving the linefeed character I use to enter the command on
the REPL.

Is this a known limitation or a bug or some stupidity on my part? If
it's something with racket, do you guys know of any workaround? I plan
on making a read-line wrapper that checks to see if the first attempt
is an empty line and if so, calls read-line again taking whatever it's
result is, but I'd rather live without those hacks if at all possible.

Am I missing some sort of configuration for the REPL?

Thanks,
Alexandre Moreira.

--
"Bad programming is easy. Idiots can learn it in 21 days, even if they
are dummies."
- As seen in 'How to Design Programs'
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users

Jos Koot

unread,
Jan 6, 2011, 1:42:20 PM1/6/11
to Alexandre Moreira, us...@racket-lang.org
I do not see this problem on version 5.0.99.6 (in windows 7)
If the current-input-port parameter has not been altered, read-line shows a
bar in the repl in which you can enter your line followed by any newline
char. The bar also shows the option to return an eof.
Jos

Jos Koot

unread,
Jan 6, 2011, 2:03:07 PM1/6/11
to Jos Koot, Alexandre Moreira, us...@racket-lang.org
My comment is related to DrRacket.
wIth Racket I see the problem too.

Matthew Flatt

unread,
Jan 6, 2011, 2:20:16 PM1/6/11
to Alexandre Moreira, us...@racket-lang.org
At Thu, 6 Jan 2011 16:09:49 -0200, Alexandre Moreira wrote:
> I'm trying to use the (read-line) function in
> racket's REPL and I'm having a weird problem. Whenever I type
> (read-line) in the REPL prompt it returns the empty string. It's as if
> it is receiving the linefeed character I use to enter the command on
> the REPL.
>
> Is this a known limitation or a bug or some stupidity on my part?

A known limitation. The REPL implemented by plain `racket' does not
separate the input stream for REPL expressions from the program's input
stream.

> If it's something with racket, do you guys know of any workaround?

DrRacket splits the expression and program-input streams, as Jos has
noted.

Offhand, I'm not aware of a tool that similarly splits input streams
within a terminal.

Hendrik Boom

unread,
Jan 6, 2011, 5:00:36 PM1/6/11
to us...@racket-lang.org
On Thu, Jan 06, 2011 at 04:09:49PM -0200, Alexandre Moreira wrote:
> Hello, everyone. I'm trying to use the (read-line) function in
> racket's REPL and I'm having a weird problem. Whenever I type
> (read-line) in the REPL prompt it returns the empty string. It's as if
> it is receiving the linefeed character I use to enter the command on
> the REPL.

You could try to call (read-line) twice and see if the secone one
returns what you want. This would confirm your suspicions,

-- hendrik

Alexandre Moreira

unread,
Jan 6, 2011, 9:01:27 PM1/6/11
to Hendrik Boom, us...@racket-lang.org
Thanks everyone for your responses. Unfortunately I planned on using
the REPL as a kind of shell for a little utility I need, so I guess
I'll only have to live with it. Is it possible to run DrRacket in a
"REPL-only" mode? I'm making a shell to deal with some data I save on
a S-Expr "database". Is there any sort of repl (even graphical ones,
but simple) that I can work much like I work on racket repl without
loading a full fledged DrRacket environment?

On Thu, Jan 6, 2011 at 8:00 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:
> On Thu, Jan 06, 2011 at 04:09:49PM -0200, Alexandre Moreira wrote:
>> Hello, everyone. I'm trying to use the (read-line) function in
>> racket's REPL  and I'm having a weird problem. Whenever I type
>> (read-line) in the REPL prompt it returns the empty string. It's as if
>> it is receiving the linefeed character I use to enter the command on
>> the REPL.
>
> You could try to call (read-line) twice and see if the secone one
> returns what you want.  This would confirm your suspicions,

Hendrik, I already do that. My workaround so far is to write a functon
somewhat like this
(define (my-read-line)
(let ([contents (read-line)])
(if (string=? contents "")
(read-line)
contents)))

It works, but it's kinda annoying to need that.


>
> -- hendrik
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>

--

"Bad programming is easy. Idiots can learn it in 21 days, even if they
are dummies."
- As seen in 'How to Design Programs'

Jos Koot

unread,
Jan 7, 2011, 2:50:46 AM1/7/11
to Hendrik Boom, us...@racket-lang.org
I tried that, and it may work on my windows 7 system, but may not on another
system.
In addition the return characters at the end of each string should be
removed.
I find this so uggly and error prone that I did not post this idea.
Jos

> -----Original Message-----
> From: users-...@racket-lang.org
> [mailto:users-...@racket-lang.org] On Behalf Of Hendrik Boom
> Sent: 06 January 2011 23:01
> To: us...@racket-lang.org
> Subject: Re: [racket] REPL and read-line
>

Noel Welsh

unread,
Jan 7, 2011, 5:32:05 AM1/7/11
to Alexandre Moreira, us...@racket-lang.org
On Fri, Jan 7, 2011 at 2:01 AM, Alexandre Moreira <alexa...@gmail.com> wrote:
> Thanks everyone for your responses. Unfortunately I planned on using
> the REPL as a kind of shell for a little utility I need, so I guess
> I'll only have to live with it.

What additional functionality do you need beyond in your shell beyond
the REPL? Why not just type commands into the REPL directly? I'm a bit
confused by this use case. If you expand on it perhaps we can come up
with an alternative.

N.

Alexandre Moreira

unread,
Jan 7, 2011, 9:57:22 AM1/7/11
to Noel Welsh, us...@racket-lang.org
Noel, it's just that a few of my commands ask for more input.
It's not the correct domain, but it's something like the difference,
in a linux system of useradd to adduser. I have those that receive a
lot of arguments, and other commands that do the same but build the
arguments by asking the user some questions (with read-line).
Problem is, when I call the command, the first (read-line) inside it
will return always "" because of the newline I used to call the
command itself.

I wonder if it'd be easy (and not break anything) to make the REPL
consume whitespaces between datums.

As of now I they are working with the hack I posted before: The only
problem is that at times, if the user truly wants to give a blank
line, he needs to press enter twice.

On Fri, Jan 7, 2011 at 8:32 AM, Noel Welsh <noel...@gmail.com> wrote:
> On Fri, Jan 7, 2011 at 2:01 AM, Alexandre Moreira <alexa...@gmail.com> wrote:
>> Thanks everyone for your responses. Unfortunately I planned on using
>> the REPL as a kind of shell for a little utility I need, so I guess
>> I'll only have to live with it.
>
> What additional functionality do you need beyond in your shell beyond
> the REPL? Why not just type commands into the REPL directly? I'm a bit
> confused by this use case. If you expand on it perhaps we can come up
> with an alternative.
>
> N.
>

--

"Bad programming is easy. Idiots can learn it in 21 days, even if they
are dummies."
- As seen in 'How to Design Programs'

Hendrik Boom

unread,
Jan 7, 2011, 10:48:47 AM1/7/11
to us...@racket-lang.org
On Fri, Jan 07, 2011 at 12:57:22PM -0200, Alexandre Moreira wrote:
> Noel, it's just that a few of my commands ask for more input.
> It's not the correct domain, but it's something like the difference,
> in a linux system of useradd to adduser. I have those that receive a
> lot of arguments, and other commands that do the same but build the
> arguments by asking the user some questions (with read-line).
> Problem is, when I call the command, the first (read-line) inside it
> will return always "" because of the newline I used to call the
> command itself.
>
> I wonder if it'd be easy (and not break anything) to make the REPL
> consume whitespaces between datums.
>
> As of now I they are working with the hack I posted before: The only
> problem is that at times, if the user truly wants to give a blank
> line, he needs to press enter twice.

It sounds to me that the big problem is that the behaviour is different
on different systems. If it were consistent either way, you could
adapt?

-- hendrik

Alexandre Moreira

unread,
Jan 7, 2011, 11:31:23 AM1/7/11
to Hendrik Boom, us...@racket-lang.org
On Fri, Jan 7, 2011 at 1:48 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:
> It sounds to me that the big problem is that the behaviour is different
> on different systems.  If it were consistent either way, you could
> adapt?

Hendrik, the only problem is that I find it unlikely that a consistent
behaviour can be found without "solving" the problem in the first
place (that is, making it so that my kind of hack is not needed).
Because there's (as far as I can see) a clear reason why the read-line
fails (the newline that is left on the stream after the user enters
one (or more?) datum on the REPL), and it'll ensure that only the
first read-line will fail. To be more precise, not only read-line, any
read-char will also fail and get only the newline.

So, if this char were to be stripped out of the input (but I'm not
sure it's a viable change, nor if it'd break more things that depend
on the behaviour), no workaround would be necessary, if it's not
stripped, it's pretty much impossible to change it the otherway so
that it'll always be there.

Please, don't think that by these messages I'm implying that something
"should be done" in racket or anything like that. I only want to
understand what the limitations are so I can decide on how to act on
them in my app. Considering English is not my main idiom, I might be
sounding more rude than I mean to.


>
> -- hendrik
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>

--

"Bad programming is easy. Idiots can learn it in 21 days, even if they
are dummies."
- As seen in 'How to Design Programs'

Reply all
Reply to author
Forward
0 new messages