Syntactic errors when compiling from a ved buffer 
Author Message
 Syntactic errors when compiling from a ved buffer

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Over a year ago I posted a message about the problem of syntactic error
messages (i.e. compile-time error messages) being displayed on the
status line rather than in an output buffer, when compiling from a Ved
buffer.

I offered a redefined version of vederror to overcome this:
=======================================================================
define vederror(string);

    edit('output.p');

    vedendfile();

    if vedusewindows and wved_is_live_window(wvedwindow) then
        ;;; make sure error message file is visible,
        ;;; de-iconising if necessary
        wved_open_window(wvedwindow)
    endif;

    dlocal
        cucharout = vedcharinsert,
        cucharerr = vedcharinsert,
        vedbreak;

    true -> vedbreak;

    mishap(string, []);

enddefine;
=======================================================================

I have now produced a new library file LIB newvederror, which is
available here
    http://www.*-*-*.com/

and includes the following code:

=======================================================================

;;; Save old version of vederror
global constant oldvederror = vederror;

define vars vederror(string);

        if iscaller(ved_lmr) then
                ;;; compiling from marked range,
        ;;; so put mishap message in output file.

                if vedlmr_print_in_file then
                        ;;; redirect output to that file
                        vedlmr_print_in_file -> ved_chario_file
                endif;

                printf('\n;;; MISHAP %p\n', [^string]);
                vedscreenbell();
                vedscr_flush_output();
        else
                oldvederror(string)
        endif;
enddefine;

global vars newvederror = vederror;

=======================================================================
I am thinking of changing the system version of vederror to act like
this.

This new version is included in the file I have prepared for people who
want linux poplog configured as we have it here in Birmingham.
(As announced about two weeks ago).

See
    http://www.*-*-*.com/

This contains a short text file and a 21 Mbyte gzipped tar file, with
linux poplog (for use with motif) has been packaged with various other
things for our students.

It now includes a much simplified installation script.

Comments welcome.

Aaron
====
Aaron Sloman, ( http://www.*-*-*.com/ ~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.*-*-*.com/ (And free book on Philosophy of AI)
FREE TOOLS: http://www.*-*-*.com/



Mon, 03 May 2004 12:02:55 GMT  
 Syntactic errors when compiling from a ved buffer
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Quote:

> I have now produced a new library file LIB newvederror, which is
> available here
>     http://www.*-*-*.com/

It turned out that I forgot that the command to compile the whole of
the current file (ENTER l1) uses the procedure ved_l1, which is not
defined in terms of ved_lmr, unlike most other commands to
compile from the Ved buffer.

Consequently the new behaviour for syntactic errors did not work if
you used ENTER l1 to compile a file.

The fix was fairly simple and has now been installed at the above
site and included in the various downloadable packages. Since it
depended on the fact that ved_l1 is a closure, I give a
mini-tutorial on closures below.

Here is the revised version of vederror, which can be installed in
one of the library directories or in your personal vedinit.p file.

===================================================================
;;; Save old version of vederror
global constant oldvederror = vederror;

define vars vederror(string);

        ;;; ved_l1 is a closure of an inaccessible system procedure.
        ;;; we can get at the procedure like this
        lconstant l1_compiler = pdpart(ved_l1);

        if iscaller(ved_lmr) or iscaller(l1_compiler) then
                ;;; compiling from marked range, so put mishap message in output file.

                if vedlmr_print_in_file then
                        ;;; redirect output to that file
                        vedlmr_print_in_file -> ved_chario_file
                endif;

                printf('\n;;; MISHAP %p\n', [^string]);
                vedscreenbell();
                vedscr_flush_output();
        else
                oldvederror(string)
        endif;
enddefine;

===================================================================

MINI-TUTORIAL ON CLOSURES:

A closure is a combination of a procedure with some data "frozen" in
it, for it to operate on whenever it is run.

E.g. this

    member(%[red orange yellow green blue violet indigo]%)

combines the procedure member(item, list) with a list of words to
produce a closure that behaves like a one-argument procedure that
recognizes colour names. If applied to an argument, e.g. x
it is equivalent to
    member(x, [red orange yellow green blue violet indigo])

When the closure is run it puts the frozen values (frozvals) on the
stack and then invokes the procedure (the pdpart of the closure).

For anyone who wants to know why I could not simply use

    iscaller(ved_l1)

by analogy with

    iscaller(ved_lmr)

the reason is that ved_l1 is a closure of an inaccessible system
procedure Compile_files, defined in

    $usepop/pop/ved/src/vdcompile.p

thus
    define vars ved_l1 = Compile_files(%false, true%) enddefine;

This means that when ved_l1 is run, only the "pdpart" of the
closure, i.e. Compile_files, is on the procedure call-stack, not the
closure itself.

So iscaller(ved_l1) will ALWAYS be false.

However, extracting the pdpart of ved_l1, enables that procedure to
be used as the argument to iscaller.

The extraction is done in this line:

        lconstant l1_compiler = pdpart(ved_l1);

which is done once, at compile time, because of the lconstant
declaration, If I had used lvars, it would be done every time the
procedure runs.

So iscaller(l1_compiler) is equivalent to but more efficient than

    iscaller(pdpart(ved_l1))

Actually, in this context, the efficiency gain is *miniscule* compared
with the overhead of writing to a Ved buffer, updating the screen, etc.
etc. I merely used the more efficient version from habit!

A corollary of the above is that the new behaviour in vederror will
work in all procedures that invoke Compile_files.

For more information on partial application and different sorts of
closures in Pop-11 see

    HELP CLOSURES
    HELP PERCENT

Both available within poplog and also here

    http://www.*-*-*.com/
    http://www.*-*-*.com/

There is also information in TEACH PRIMER, e.g. in the section
headed
    -- Using "partial application" to create a closure

also available in chapter 4 of the html version

    http://www.*-*-*.com/

For more{*filter*}detail see REF procedure, or

    http://www.*-*-*.com/

Even more{*filter*}detail on lexical closures can be found in REF vmcode

NOTE
Old pop-11 experts who have not studied the HELP NEWS file may be
interested to know that in the more recent versions of poplog
(since V15.5) there is a procedure

    sys_grbg_closure

which allows the space allocated to closures to be re-used without
having to rely on the garbage collector.

This means that the cost of using closures can be significantly reduced
in some contexts, which is great since they are such a useful and
powerful programming construct in connection with procedures that take a
procedure as one of their arguments.

For example

    define apptree(tree, proc);
        ;;; recursively apply proc to every atom (non-list) in tree

        if islist(tree) then

            ;;; create closure of this procedure with proc
            lvars recurse = apptree(%proc%);

            ;;; use it with applist to scan the list
            applist(tree, recurse);

            ;;; reclaim the space used by the closure
            sys_grbg_closure(recurse);

        else
            ;;; tree is not a list, so it is an atom, and proc can be
            ;;; applied to it
            proc(tree)
        endif
    enddefine;

    ;;; EXAMPLE
    ;;; Here is a tree (a list-structure of varying depth).
    vars tree
        = [big [red [hard soft green]] [[violet]] [orange square [blue circle]]];

    ;;; We want to find every item that satisfies a membership condition.
    ;;; A closure of this procedure can be used to test individual items.
    define getmember(item, list);
        ;;; return item if it is in list, otherwise do nothing
        if member(item, list) then item endif
    enddefine;

    ;;; To find all colour words in the tree:
    ;;; Use apptree to search the tree with a closure of getmember,
    ;;; and use [% ... %] to make a list of all the results

    [% apptree(tree, getmember(%[red orange yellow green blue indigo violet]%) ) %] =>

    ;;; That produces this:
    ** [red green violet orange blue]

Aaron
====
Aaron Sloman, ( http://www.*-*-*.com/ ~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.*-*-*.com/ (And free book on Philosophy of AI)
FREE TOOLS: http://www.*-*-*.com/



Wed, 05 May 2004 19:44:52 GMT  
 Syntactic errors when compiling from a ved buffer
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Regarding the previously announced modification to error handling
when compiling in Ved's text buffer, here

Quote:
>     http://www.cs.bham.ac.uk/research/poplog/lib/newvederror.p

it now turns out that if a compile time error occurs while ved_l1 is
running Ved's text cursor is not left where the error was detected,
unlike compilation using ved_lmr and its derivatives. I don't know
why.

Anyhow, my most recent change to newvederror.p fixes that problem.

So if you use it

(a) the syntactic error messages go into the output buffer not on
the status line, and

(b) it not only shows the line number but moves the Ved cursor to
where the compiler had got to in the source file when the error was
detected.

Sorry to have taken so long to get there.

Another thing that may be found useful, announced previously, is
this file:

    http://www.cs.bham.ac.uk/research/poplog/lib/prwarning.p

This redefines prwarning so that compiler "Declaring variable"
messages also specifies the file and the line number, where
possible. I don't know why it was not done like that originally.
(This has nothing to do with compiling from the Ved buffer.)

Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.cs.bham.ac.uk/research/cogaff/ (And free book on Philosophy of AI)
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html



Sun, 09 May 2004 07:12:26 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. VED sometimes overwrites current buffer when reading in file

2. programs writing to multiple VED buffers

3. Running Ved from Ved

4. Error when loading files in ved

5. Compiling Tk4.1: "cross-compiling" error

6. problems compiling LVDS buffers in ModelSim

7. C5PE Compile Error: err.$$$(1) #6: Error: cif$filewrite The handle is invalid

8. error compile when VIs are good (Windows error)

9. Error VEEXT700: Linker Failed Error 511 when trying to compile project for DM 2.6

10. SmallTalk Express - error writing file buffers

11. error 10403:AO Buffer Config (i just want to command an analog output)

12. Clipper 5.01 C3002 Input Buffer Overflow error

 

 
Powered by phpBB® Forum Software