[racket] REPL input chunking for non-sexp language

I don't think I need to. The DrRacket EOF insertion isn't (or wasn't)
documented, so I just hacked and experimented until I got it working.
There's probably a better way to do it (which is what my comment on the
code says.)


On Mon, Dec 10, 2012 at 10:09 AM, Robby Findler <robby at eecs.northwestern.edu
> wrote:

> Why do you need a weird two-phase reading system to deal with the EOF
> issue?
>
> Robby
>
>
> On Monday, December 10, 2012, Jay McCarthy wrote:
>
>> The datalog language tries to do this too.
>>
>> There's a repl-submit? predicate you can use and I have weird two-phase
>> reading system to deal with the EOF issue:
>>
>>
>> https://github.com/plt/racket/blob/master/collects/datalog/lang/configure-runtime.rkt
>>
>> https://github.com/plt/racket/blob/master/collects/datalog/tool/submit.rkt
>>
>> Jay
>>
>>
>> On Mon, Dec 10, 2012 at 8:04 AM, Matthew Flatt <mflatt at cs.utah.edu>wrote:
>>
>>> When you run plain `racket', the REPL is `read-eval-print-loop', which
>>> uses `(current-prompt-read)', `(current-eval)', and `(current-print)'.
>>>
>>> Any line-editing capability is whatever the terminal does, which
>>> normally means that input is sent to the reader when you hit Return.
>>> Even if you load `readline' or `xrepl', a Return commits a line of
>>> characters to be sent off to the reader.
>>>
>>> The delivery of an expression to the evaluator, however, is determined
>>> by the reader. That is, if your reader sees a "fun" that should match
>>> an "end", then it should keep reading input characters until it sees
>>> the "end". When the reader returns a datum, then it's passed off to the
>>> evaluator.
>>>
>>> (If an interactive EOF is needed to terminate a form for your reader,
>>> that shouldn't necessarily make the REPL quit. The REPL should quit
>>> only when the reader returns an EOF. So, a reader might consume an
>>> interactive EOF as a terminator, and then it can continue reading the
>>> next time around.)
>>>
>>> If I remember correctly, DrRacket is a little different. A Return in
>>> DrRacket takes the text so far and implicitly adds an EOF to the end.
>>> If the reader applied to that text raises `exn:fail:read:eof', then
>>> DrRacket it as an indication that the expression isn't finished, and so
>>> it lets the user keep editing on the next line. Meanwhile, an
>>> `exn:fail:read' exception other than the subtype `exn:fail:read:eof'
>>> means that the read error should be reported to the user.
>>>
>>>
>>> At Sun, 9 Dec 2012 19:03:44 -0500, Daniel Patterson wrote:
>>> > I'm working (with sk and jpolitz) on a non-sexp language built on top
>>> > of racket.
>>> >
>>> > We have basic support for it in the repl inside DrRacket, but none at
>>> > all from the racket commandline repl (which also means no support for
>>> > embedding inside other editors) - and the former seems to be using
>>> > s-exps to figure out when to send the input to our eval (I think - I
>>> > haven't found documentation describing how this works).
>>> >
>>> > So my question is:
>>> >
>>> > Is there a way to specify how input is split before sending to eval,
>>> > both so that DrRacket could follow our conventions (which might, for
>>> > example, match a "fun" with matching "end"), and so that the
>>> > commandline repl knows how to split input at all (as right now it just
>>> > keeps waiting for input until EOF - and EOF also causes the repl to
>>> > quit!) Is there something that read/read-syntax should signal, or
>>> another
>>> > handler to use?
>>> >
>>> > Thanks!
>>> > Daniel
>>> > ____________________
>>> >   Racket Users list:
>>> >   http://lists.racket-lang.org/users
>>> ____________________
>>>   Racket Users list:
>>>   http://lists.racket-lang.org/users
>>>
>>
>>
>>
>> --
>> Jay McCarthy <jay at cs.byu.edu>
>> Assistant Professor / Brigham Young University
>> http://faculty.cs.byu.edu/~jay
>>
>> "The glory of God is Intelligence" - D&C 93
>>
>


-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121210/fc83b6ed/attachment.html>