beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
seninha has quit [Quit: Leaving]
clacke has joined #picolisp
<abu[m]> Puh! What was that yesterday?
Regenaxer has joined #picolisp
rob_w has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
rob_w has quit [Quit: Leaving]
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
<beneroth> abu[m], hahaha hi :)
<abu[m]> Yeah, strange an funny
<abu[m]> I have no idea what *really* was the question, but I learned that in any case I'm wrong and fbytez is correct
<beneroth> yes, that's the important point, you got that part right.
avocadoist has quit [Remote host closed the connection]
avocadoist has joined #picolisp
seninha has quit [Quit: Leaving]
seninha has joined #picolisp
z4k4ri4 has quit [Ping timeout: 246 seconds]
z4k4ri4 has joined #picolisp
seninha_ has joined #picolisp
<fbytez> Is that really what you both take away from this?
seninha has quit [Ping timeout: 260 seconds]
<abu[m]> I must confess that I take away nothing from this
<abu[m]> What could I?
<abu[m]> Again: What was the question in the first place?
<fbytez> This part of our chat history contains most of it, I feel: http://pb1n.de/?e22aaa
<fbytez> Because I found '(char)' couldn't be used for this, I wrote some example code using '(rd)' instead.
<fbytez> At that point, *I* didn't understand *why* I couldn't use '(char)'.
<abu[m]> And this is all wrong! You *can* do it with (char)
<abu[m]> You can do any parsing with Pil stream I/O
<fbytez> I've shown multiple times how and why it doesn't work.
<fbytez> I'm perfectly open to being shown otherwise.
<abu[m]> I did write the fix yesterday. Seems you did not notice
<abu[m]> 21:19 <abu[m]> So you can (peek) at the next char to see if it is \r
<abu[m]> Wrong is: ("\r" (if (= (char) "\n") (throw 'success
<abu[m]> Correct is: ("\r" (if (= (peek) "\n") ...
<fbytez> The problem with that is then the "\n" isn't discarded and will be read on it's own in the next iteration.
<abu[m]> Then please handle it
<abu[m]> It is your program!
<fbytez> I have done. I use (rd) because I can't use (char) and (peek). As I've been saying the whole time.
<abu[m]> Sigh. You can and must use the stream. (rd) is wrong here
<abu[m]> What do you want from us then?
<fbytez> You keep saying that I can but so far you're wrong unless able to prove otherwise.
<abu[m]> Just complaining that your program does not work.
<fbytez> No, I just don't know why you keep insisting that (char) will work where it will not.
<abu[m]> It is simply wrong that you cannot handle it
<abu[m]> Again: *What* is your question?
<fbytez> I'm not asking you anything.
<abu[m]> All PicoLisp input works this way
<fbytez> " I just don't know why you keep insisting that (char) will work where it will not."
<abu[m]> Your code is wrong, yes
<abu[m]> Did you try to use (peek) to look ahead?
<abu[m]> This is exactly what (line) does internally
<abu[m]> and all other input like (read)
<abu[m]> They all have the problem to stop reading at the right place
<abu[m]> Using (char) upon \r is wrong in your case, because it causes another fetch
<abu[m]> I think you misunderstand (peek)
<abu[m]> (peek) does *not* any I/O
<abu[m]> It looks at the next character which is already pre-fetched at that moment
<fbytez> No, I know, but it also will leave the "peeked" "\n" in the stream.
<abu[m]> Yes, but this is the purpose
<abu[m]> You can (skip) it the next time
<abu[m]> Look at other parsing stuff in Pil
<abu[m]> The reader, or @lib/xm.l
<fbytez> (skip) doesn't simply skip a single char though.
<fbytez> It says it will skip all white space.
<abu[m]> Then do (char) next time and ignore a single return
<abu[m]> A parser like that is always a state machine. Usually you need a look ahead anyway, it makes certain things possible
<abu[m]> e.g. reading abc()
<abu[m]> the symbol parsing needs to stop when the *next* char is not part of a symbol. Here the "("
<abu[m]> you definitely can handle *any* input this way
<abu[m]> If *you* cannot do it, you should not blame us
<abu[m]> I'll have a whisky now, and dedicate it to you, wishing you success! :)
<abu[m]> BTW, with (rd) you have the same problem
<abu[m]> It also buffers internally, so it might have read many more bytes already, which you'll get with the next (rd)
<fbytez> As already demonstrated, it's not the same.
<abu[m]> I do not have the time to run your code.What is not the same?
<fbytez> Using `(rd)`.
<abu[m]> In your case it is not the same, because you do not have the look ahead on this level, yes.
<abu[m]> But logically it is the same
clacke has quit [Remote host closed the connection]
z4k4ri4 has quit [Ping timeout: 276 seconds]
z4k4ri4 has joined #picolisp
z4k4ri4 has quit [Ping timeout: 255 seconds]
<beneroth> (state) is great for parser.
<beneroth> bye bye
beneroth has quit [Quit: Leaving]
drakonis has joined #picolisp
<abu[m]> indeed
z4k4ri4 has joined #picolisp