Re: [racket-users] Re: IO in racket is painful
On Fri, Mar 25, 2016 at 11:28:25PM -0600, Richard Cleis wrote: > "Lurking thresholds" are fun: The Lurker at the Threshold is, of course, a classic horror story written by August Derleth and H.P. Lovecraft. -- hendrik -- 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: IO in racket is painful
"Lurking thresholds" are fun: I used pre-Racket to read files of numerical data, created by different agencies across the country. The code looked for something that looked like a date (out of about 10 formats), and moved on from there to read a few hundred lines of gradually changing groups of numbers. The code was quite good at rummaging beyond various useless headers that were created over the years by new programmers attempting to improve the world... until one day, when someone actually made a truly useful header with an example that contained representative data. rac On Mar 24, 2016, at 2:14 PM, Hendrik Boom wrote: > On Thu, Mar 24, 2016 at 08:59:50PM +0100, Jos Koot wrote: >> Hi >> >> In all computer languages it is more difficult to read data than to write >> them, I think. > > Perhaps because when you write data you know what you are writing and > are in control. But when you are reading, who knows what might be > lurking at the threshold of the file? > > -- hendrik > > -- > 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. On Mar 24, 2016, at 2:14 PM, Hendrik Boom wrote: > On Thu, Mar 24, 2016 at 08:59:50PM +0100, Jos Koot wrote: >> Hi >> >> In all computer languages it is more difficult to read data than to write >> them, I think. > > Perhaps because when you write data you know what you are writing and > are in control. But when you are reading, who knows what might be > lurking at the threshold of the file? > > -- hendrik > > -- > 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] Re: IO in racket is painful
On Thu, Mar 24, 2016 at 08:59:50PM +0100, Jos Koot wrote: > Hi > > In all computer languages it is more difficult to read data than to write > them, I think. Perhaps because when you write data you know what you are writing and are in control. But when you are reading, who knows what might be lurking at the threshold of the file? -- hendrik -- 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: IO in racket is painful
Hi In all computer languages it is more difficult to read data than to write them, I think. Racket (like more lisp-like languages) is rather easy on this: give it sexprs to read and you have no problems. If you want to accept other types of input, you need a parser. In the past I have made programs accepting a specific language for its input, often in Fortran. In Fortran even reading a Fortran-like expression is cumbersome! Designing the forms input may have includes the necessarity to design a procedure that transforme the input to data that can be handled within the language used for the procedures that have to handle these data. Moreover, Racket provides elaborated tools to define and implement the language of the input you want to read. my2cents, or may be 1 only. Jos -Original Message- From: racket-users@googlegroups.com [mailto:racket-users@googlegroups.com] On Behalf Of rom cgb Sent: jueves, 24 de marzo de 2016 13:38 To: Racket Users Subject: [racket-users] Re: IO in racket is painful A possible case study: there a scanf procedure in slib, a pseudo standard library for Scheme[1][2]. It does mutate the passed arguments like with C's scanf which i think is not the idiomatic way to do things in Racket[3] doc: http://people.csail.mit.edu/jaffer/slib/Standard-Formatted-Input.html#Standa rd-Formatted-Input code: http://cvs.savannah.gnu.org/viewvc/slib/slib/scanf.scm?view=markup [1] https://en.wikipedia.org/wiki/SLIB [2] http://people.csail.mit.edu/jaffer/SLIB.html [3] http://blog.racket-lang.org/2007/11/getting-rid-of-set-car-and-set-cdr.html -- 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] Re: IO in racket is painful
Right, that's the library that I borrowed for the code I posted. Fortunately the code didn't need to mutate pairs so it seems to work. Sam On Thu, Mar 24, 2016, 8:38 AM rom cgb wrote: > A possible case study: there a scanf procedure in slib, a pseudo standard > library for Scheme[1][2]. It does mutate the passed arguments like with C's > scanf which i think is not the idiomatic way to do things in Racket[3] > > doc: > http://people.csail.mit.edu/jaffer/slib/Standard-Formatted-Input.html#Standard-Formatted-Input > code: http://cvs.savannah.gnu.org/viewvc/slib/slib/scanf.scm?view=markup > > [1] https://en.wikipedia.org/wiki/SLIB > [2] http://people.csail.mit.edu/jaffer/SLIB.html > [3] > http://blog.racket-lang.org/2007/11/getting-rid-of-set-car-and-set-cdr.html > > -- > 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: IO in racket is painful
A possible case study: there a scanf procedure in slib, a pseudo standard library for Scheme[1][2]. It does mutate the passed arguments like with C's scanf which i think is not the idiomatic way to do things in Racket[3] doc: http://people.csail.mit.edu/jaffer/slib/Standard-Formatted-Input.html#Standard-Formatted-Input code: http://cvs.savannah.gnu.org/viewvc/slib/slib/scanf.scm?view=markup [1] https://en.wikipedia.org/wiki/SLIB [2] http://people.csail.mit.edu/jaffer/SLIB.html [3] http://blog.racket-lang.org/2007/11/getting-rid-of-set-car-and-set-cdr.html -- 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: IO in racket is painful
> I use racket for hackerrank and coding contests all the time, and I find it's > read syntax really useful. For instance, I would parse this into a list of > lists by doing > (for/list ([i (in-range (read))]) > (map (lambda (x) (if (list? x) (cadr x) x)) (read))). > > Then, to print out results, I normally do > (define (main n) > (unless (= 0 n) > (begin (printf "~a ... ~a\n", args...) > (main (sub1 n. > > Another really useful helper is > (define (read->list n) > (if (= 0 n) '() > (cons (read) (read->list (sub1 n. > > You can customize these by doing for/vector, for/fold, etc., and there hasn't > been a hackerrank contest I've run into that I haven't been able to do with > some technique like this. Correction, not "read syntax". My PL professor would fail me for that. I'd say that there are very few hackerrank and other contests input format that can't be parsed as an s-expression in some way (unless they do weird things with parentheses, in which case you have to use read-line/char/byte). Just note that a value with a comma in front of it is parsed as a list where the first item in the list is the unquote, and the second item is the value itself. Regardless, it's fairly easy to use the common list functions to extract the data you want. -- 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: IO in racket is painful
On Wednesday, March 23, 2016 at 12:35:26 PM UTC-4, rom cgb wrote: > Thanks all for the interesting replies. > > About using an external package, there also the case like on > www.hackerrank.com where you have to run the code in their own environment > (eg: http://i.imgur.com/iSSPLGy.png). I use racket for hackerrank and coding contests all the time, and I find it's read syntax really useful. For instance, I would parse this into a list of lists by doing (for/list ([i (in-range (read))]) (map (lambda (x) (if (list? x) (cadr x) x)) (read))). Then, to print out results, I normally do (define (main n) (unless (= 0 n) (begin (printf "~a ... ~a\n", args...) (main (sub1 n. Another really useful helper is (define (read->list n) (if (= 0 n) '() (cons (read) (read->list (sub1 n. You can customize these by doing for/vector, for/fold, etc., and there hasn't been a hackerrank contest I've run into that I haven't been able to do with some technique like this. -- 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: IO in racket is painful
Thanks all for the interesting replies. About using an external package, there also the case like on www.hackerrank.com where you have to run the code in their own environment (eg: http://i.imgur.com/iSSPLGy.png). -- 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: IO in racket is painful
On Tue, 22 Mar 2016 21:06:14 -0700, Alexis King wrote: >Would anyone object to a scanf-like function in Racket itself? No. But the question is how to specify input patterns to make it really useful. Racket's native printf is pretty basic. Should scanf mirror the native printf? Or should it mirror something like SRFI-48 format, which has more functionality? Or should it work with predicates that mirror racket/format output functions? Or, in general, should it accept any suitable predicate? [e.g., string->number] >The >obvious point of difficulty is how to handle errors, given that parsing >can fail but printing cannot. Should it throw an exception, or should it >return #f? I’m not sure there is great precedent set here, though >throwing seems to be the Racket way in other places. Printing can fail both for formatting and I/O errors. C's scanf returns the count of patterns matched (in order from the beginning of the string), but I don't recall offhand whether that includes patterns that use '*' to suppress assignment to an argument. C's scanf also allows to limit expected field widths. And an I/O error does not lose matches that preceded the error. Any arguments that were bound to values before the error occurred retain their values. Not that a Racket scanf necessarily has to work anything like C's. Returning multiple values presents a problem if there is a mistake in the input unless you have a distinct *unbound* value for unmatched patterns (which #f is not). I suppose # works for an unbound indicator, but parsing functions are expected to fail due to mistakes in the input. Returning (values ...) from such functions ranks rather high on my offense meter because I see little value to expecting, e.g., 10 return values and getting back 8 of them set to #. And returning too few values results in an program error. Perhaps the best thing would be just to return a list of the successful matches. I would only throw I/O errors, not match failures ... similar to the way regex-match et al work. George -- 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.
