Re: [Readable-discuss] using t-expressions

[Jörg F. Wittenberger]

Am 27.11.2013 02:22, schrieb David A. Wheeler:

On Tue, 26 Nov 2013 15:11:39 +0100, Jörg F. Wittenberger wrote:

I changed it's signature to match srfi-23 (for know)

(: read-error (string rest * - *)

Okay, but you'll need to modify the procedure definition to match.
Sure.  I just did not want to clutter the list with some imature, 
temporary code.





But I tend to prefer a more restrictive, though compatible, syntax in
this case

(: read-error (string input-port string rest * - *)

Please don't.  The intent was to be syntactically consistent
with error as defined in srfi-23 and R7RS.
Someone can always modify the error port to change where it goes.
Oh, I presume you mean output-port not input-port there.


No, I meant input-port - or rather the fake input port we're reading 
from.
Iff the latter supports getting the position or something, the 
read-error could report them too.  For the moment I just used peek-char 
to show the problematic character.


This signature is compatible with srfi-23 error.  It's just a little 
more specific and should probably itself rely on plain error in the 
implementation.





Whereby I'd require all calls to read-error to pass the port and the
last successfully read token in an effort to further improve error messages.

Why not just pass last successfully read token as a parameter after the 
string?


That was the intent behind the string after the (fake) input-port.




The ONLY procedure that catches an exception is t-expr-catch:
(define (t-expr-catch port)
  (init-sweet)
  (guard
(exception
  ((eq? exception 'readable)
   (read-to-unindented-line port) (t-expr-catch port)))
(t-expr port)))


Is there actually any scheme implementation which benefits from this
catching?  I can't image.

Our processing program does, because it tries to process as well as it can.
But we could change the interface.


I'd feel it might be good to provide a clean up read like
`read-to-unindented-line` to help the implementor of a repl.  But for
the default it just does not feel right to me.

Okay.  An easy approach would be to raise an exception on error,
and add an option to permit the current behavior (catch and retry).
That's an interface change, but the SRFI doesn't define specifics on how
to handle errors (since Schemes vary in this matter), and it makes sense
that people will want to get errors.

Guile 1.8 doesn't support srfi-23 or R7RS, so that would need to be
implemented separately on guile.



This one does not look to bad to me:
https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Error-Reporting.html#Error-Reporting

/Jörg
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library

[Jörg F. Wittenberger]

Am 27.11.2013 02:28, schrieb David A. Wheeler:
 I said:
 At the least, I could put things in different files, and then use cat
 to create files usable to different systems.
 On Tue, 26 Nov 2013 14:47:36 +0100, Jörg F. Wittenberger:
 Not too bad and idea.  While it might not scale to whole programs, it's
 certainly a valid way to get things done for something the size of a
 srfi's implementation.
 Right.  This thing is small.

 I don't see anything good for trivial preprocessing:
 * scmxlate appears too complex to get going.

Probably.  A few bullet point about my take on this.

1)  Whatever we do here, it's not necessarily going to be used for 
real but merely to show how things would have to be processed in users 
build.
2) From (1) I conclude: the least amount of commonly available tools is 
the best.
3) When pre-processing LISP code, the best language for the job is 
actually LISP, since it has easily access to the structure of the code 
to be rewritten.  Other languages are forced to go through axillary 
properties of the code.
cpp, as you said, is a disaster for LISP and m4 is a disaster in itself.
4) Point (3) is mostly incompatible with (2).  The only exception might 
be recent GNUmake.  I did not yet have the time to check it out, but I 
read it would support guile.  Maybe one could trick it into running a 
guile pre-process.
5) Coming back once more to my desire to have a Scheme reader which 
would allow to deliver a modified AST including comment nodes: such a 
beast could be used to write back-and-forth (round-trip-safe) code to 
code transformations.  One could work with any flavor when porting to 
new implementations and easily roll the result back into the generic 
form. All this should need would be the generic base and a 
guile-as-in-gnumake specialized version.

Let me add: I'm not entirely sold to (5) but I'd like to see how this 
would work in reality before I judge.

 * cpp is a disaster for Lisp (it wants to parse '...' as character 
 constants)
 * m4 is easy to get wrong, and has too much functionality.

 I think I could create a simple #ifdef ... #elifdef... #else... #endif
 preprocessor in awk (which is in the POSIX standard)
 that would do the job.

If I dug deep enough into the code I ever wrote, I guess I could come 
back with at least two such things in KR C.
;-)

I'm not sure it's worth to write a special tool just for this special case.

Then the whole thing could be in one file,
 and generate variations for different purposes.  For those Schemes with
 cond-expand, we could put them in one file, so we wouldn't have to
 generate too many files.



Since the single-file approach would still require some pre-processing, 
let me suggest yet another single file approach: shar.  A shell 
archive including several files a little sh-script to glue the pieces 
together.  Still one file.  ;-)

Irony aside: any tool will do.  Simplicity for the end user should be 
the trumping argument.


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss