#115 Use the '.' operator as an array accessor

open
nobody
None
5
2004-06-16
2004-06-16
Tony Balinski
No

This allows you to view NEdit macro language arrays as
records (both are aggregates of heterogeneously typed
objects). The only constraint is that the accessor must
appear like a valid symbol name, although internally it is
handled as a string. Thus the following statements are
equivalent:
array["member"] = array["field"]
array.member = array.field
This makes some common (fixed-index-string) array
expressions a lot easier to write and read, and makes
them look like records (which they resemble anyway).

This implementation suffers from the slight
inconvenience of creating extraneous symbols in the
macro function's symbol table: for the expression above,
extra symbols member and field will have corresponding
variables on the stack. (It should be possible to work
around this in future.)

Discussion

  • Uwe Lehnert
    Uwe Lehnert
    2004-06-17

    Logged In: YES
    user_id=794103

    Looks like the attached file belongs to patch [970487]
    "Add \x?? and \0??? to macro strings" ? ;-)

     
  • Tony Balinski
    Tony Balinski
    2004-06-17

    Logged In: YES
    user_id=618141

    This patch has nothing to do with patch [970487] "Add \x??
    and \0??? to macro strings", which just changes processing
    in the nedit macro tokeniser, written in C.

    It actually changes the syntax of the language in the way
    described. It only adds a tiny amount of non-yacc code,
    which takes a symbol name and uses it as a string; but
    essentially the change is one of "syntactic sugar".

    Also note that it has nothing to do with [ 971477 ] Perform
    faster macro concatenation, which modifies the yacc syntax
    rules to handle concatenation differently (the CONCAT
    operator becomes a n-ary operator rather than a binary one),
    although the actual syntax you write doesn't change.

    In short these three patches are independent and can be
    applied separately. Naturally I'd like to see all three of
    them in the main source tree!

     
  • Uwe Lehnert
    Uwe Lehnert
    2004-06-18

    Logged In: YES
    user_id=794103

    You got me wrong:
    The file "ParseStringEscapes.diff" in the "attached file"
    section of this patch "974211" is almost identical with
    file "ParseStringEscapes.diff" in the "attached file"
    section of patch "970487".

    I guess this was not the intention but just a kind of
    "technical" mistake when uploading the patch file.

    I'm aware that all this patches are independent and
    can be applied separately.

    I'm very interested especially by this " '.' operator"
    patch of course :-). Hope to see the right patch file
    soon ;-)

     
  • Tony Balinski
    Tony Balinski
    2004-06-18

     
    Attachments
  • Tony Balinski
    Tony Balinski
    2004-06-18

    Logged In: YES
    user_id=618141

    Talk about getting egg on your face! I should read my own
    patches! Sorry about that: I'm correcting it now.

     
  • Uwe Lehnert
    Uwe Lehnert
    2004-06-21

    Logged In: YES
    user_id=794103

    Tried your patch during weekend on my RH9 box. Works fine,
    except the above described drawback (means: there will be
    an undefined "member" variable stored on stack, which can
    still be used i.e. "member = 1" still works before or
    after "array.member").

    Do you plan to update your patch to avoid this drawback
    in near future ?

    Anyway: i like this kind of array access, due to
    a.) it saves some characters inside a macro (e.g.
    'array["member"]' = 15 char, while 'array.member' =
    12 char; 3 chars less to type :-)
    b.) its similar to "structure field" access in C resp.
    "instance member" access in JAVA, C ++, ...

    Hope to see this patch committed in main line in near
    future (with or without the known drawback :-)

     
  • Uwe Lehnert
    Uwe Lehnert
    2004-06-21

    Logged In: YES
    user_id=794103

    This patch is really useful for macro debugging.

    What about switching "Stack trace" / "Disassemble trace"
    "on" | "off" during NEdit session is active ? I've
    installed corresponding menu items in "Macro Menu" in
    addition to your patch. Also added some command line
    switches to enable stack trace / disassemble trace with
    startup of NEdit (so i don't need to keep an extra "macro
    debug NEdit binary").

    If you are interested in this additional functionality i
    can perpare & provide a corresponding patch of course.

     
  • Uwe Lehnert
    Uwe Lehnert
    2004-06-21

    Logged In: YES
    user_id=794103

    Damned. Comment against wrong patch. Just forget comment
    #6 (was for patch 970501, "Provide NEdit Macro stack
    traces"; you are submitting to much patches these days
    ;-).

     
  • Tony Balinski
    Tony Balinski
    2004-06-21

    Logged In: YES
    user_id=618141

    Too many patches eh? Sorry! Well, I've got them confused too...

    Getting rid of the superfluous variable creation when you
    use the "member/field" array access syntax would make
    matters a bit more complicated. In the meanwhile, I don't
    think it's much of an issue. You get a number of unused
    variable entries on the call stack, that's all. (You
    probably spotted them when using the stack trace stuff.)

    I'm looking into a rather deep overhaul of the interpreter.
    (I hope I'll have the time and stamina to complete it!) The
    main ideas are to have reference-counted, copy-on-write
    allocated data values; "uninterruptible" lvalue calculation
    following rvalue evaluation in assignments (for
    dereferencing array entries without allowing a macro context
    switch); faster access to stack data; distinction between
    static (hard-wired) strings, GC strings and short strings
    rather than having just one string type; simplified parse.y
    file; source-level debugging etc.

    I would hope this could lead us to a state which makes
    JavaScript-like objects possible.

    Anyway, I'm glad you're trying things out and that you like
    them.

    Tony

     
  • Tony Balinski
    Tony Balinski
    2004-06-22

     
    Attachments
  • Tony Balinski
    Tony Balinski
    2004-06-22

    Logged In: YES
    user_id=618141

    I have managed to avoid the creation of unnecessary
    variables with this new version: it uses a flag, set when a
    '.' is scanned, to determine whether the next identifier is
    a field - if so, it doesn't make a symbol out of the
    identifier (leading to a variable in the resultant macro),
    but instead returns a field token, which is just a constant
    string value used as an index into the array.