Re: [slang-users] Re: unicode (was Re: Minor error message change)

["John E. Davis" <davis@xxxxxxxxxxxxx>]

David Somers <dsomers@xxxxxxxxxxxx> wrote:
>Can you provide an idea of the changes that will happen when S-Lang 2.x
>arrives?
>
>Also, can you clarify the situation regarding the license for S-Lang 2.x?

Version 2 will no longer be distributed under the perl artistic
license.  It will be distributed under the GPL, not the LGPL.

As far as the changes go, the most extensive one involved the addition
of UTF-8 support throughout the library, including the interpreter.
Up to four combining characters are supported (5 characters per cell).
As you can imagine the SLsmg interface has changed a bit with
SLsmg_Char_Type no longer represented by a short, but now a structure:

#define SLSMG_MAX_CHARS_PER_CELL 5
typedef struct
{
   unsigned int nchars;
   SLwchar_Type wchars[SLSMG_MAX_CHARS_PER_CELL];
   SLsmg_Color_Type color;
}
SLsmg_Char_Type;

A number of the interfaces have changed to allow for future
improvements without breaking future binary compatibility.  These
include the SLsearch, SLregexp, and SLrline interfaces.  Previously,
slang.h contained the structure definitions for these objects allowing
applications full access to them.  Now they are represented by opaque
pointers with additional functions to manipulate them.  This means
that if you are currently using one of these interfaces, then you will
have to make some changes to use version 2.  I think that you will
find that your code will look a bit cleaner afterwards.  For example,
code in slrn that looked like:

   static unsigned char compiled_pattern_buf [512];
   static SLRegexp_Type re;
   
   re.pat = (unsigned char *) pat;
   re.buf = compiled_pattern_buf;
   re.buf_len = sizeof (compiled_pattern_buf);
   re.case_sensitive = 0;
   
   if (0 != SLang_regexp_compile (&re)) ...

has changed to:

   SLRegexp_Type *re;
   unsigned int flags = SLREGEXP_CASELESS;

   if (Slrn_UTF8_Mode) flags |= SLREGEXP_UTF8;
   if (NULL == (re = SLregexp_compile (pat, flags))) ...

The interpreter has undergone many changes but should be mostly
backward compatible.  The changes include small syntactic improvements
such as:

    _for X (1,10,1) {....}
    foreach X [1:10] {....}

The interpreter now supports a List_Type object:

     x = {1, 2.7, "foo", [1:10], {"bar", 3}};

with functions to manipulate the lists:

   list_delete
   list_reverse
   list_insert
   list_append
   list_pop
   list_new

Exception handling has improved with the addition of
try/catch/throw/finally handling.  Unlike version 1, any exception may
be caught in version 2.  New exceptions may also be created.

Operator overloading is now supported by user-defined structures.  For
example, if s and t are user-defined structures, then s+1 and s+t may
be given a meaning.  If the structure has fields that contain a
function reference, then it is no longer necessary to use the @
operator to call the function.  This can lead to much more readable
code when using such constructs to simulate class methods.  For
example, consider:

   static define get_x (s) { return s.x }
   static define set_x (s, x) { s.x = x; }
   static define negate_x (s) { s.x = -s.x }
   define new_S (x)
   {
      s = struct { get, set, negate, x };
      s.get = &get_x, s.set = &set_x, s.negate = &negate_x;
      return s;
   }

   S = new_S(1);

In version 1, to call the negate method required:

   (@S.negate)(S);

But now it may be called using simply:

    S.negate ();

(The older syntax is still supported).

I hope this gives you an idea of some of the things to expect in the
next version.

--John

_______________________________________________
To unsubscribe, visit http://jedsoft.org/slang/mailinglists.html