Re: main and Re: C strings and other things!

[Keith Hopper]

In article <address@hidden>,
   Lars Hupfeldt Nielsen <address@hidden> wrote:

> You have previously spoken about Sather libraries, which would need to allow
> compilation without specifying a main routine, is this something you have been
> working on?

     Since this is purely an implementation issue it should appear in the
new compiler (when that is 'eventually' produced!!).  I believe that  we
must, repeat must, xupport a shared library concept - a separate one for
each 'section' of library (ie one for Required, one for Networks, one for
Windowing, etc).

     The main problem from an implementation view-point is that all
constants must be generated at compile time - not load time - or even bind
time.  This is in the bowels of the compiler and is not really practical
with the existing compiler.

> 3) Executables were huge!
> Has the size gone down?

     New compiler - and new RTE - and shared libraries - are needed for
this to happen.
     
> Keith, did you ever get around to reading the Sather-K specification? 

     I have looked at this, but there is, in my opinion, no point in
modifying the language until we have a production quality implementation
which will permit any such modification to be done without the significant
compiler overhead needed at present.  There is no point in patching on
patches on patches on patches ...  Changes should use replacement code -
not a patch - which has been properly designed from scratch to achiver the
necessary changes.

     By the way, I am not in favour of changing a language design for neat
features if it breaks the language consistency.  At present the language is
not quite consistent - particularly in respect of some of the concurrency
things!!

> As far as I remember, in the old STR class there was no method converting an 
> STR to
> a C_CHAR_PTR, but handing an STR to a function taking a '\0' terminated 
> char[] would
> work. This was very ugly. May I suggest something like STR.byte_str_z?

     No!  For all 'array'-based (well, AREF in particular) classes there is
a feature specified as

array_ptr : REFERENCE

which does what you are intending.  It is a perfectly ordinary feature and
is used, for example in the library IO sub-section - for both binary and
text IO!

     I wrote -

> >      (1)  I am slowly coming to the conclusion that there is a need for a
> > class we may call ORD 

to which you replied -

> I don't really get it. When indexing array elements directly, how are
> iterators involved?

     They are a necessary part of the functionality required of an ordinal
number - 1st, 2nd, 3rd, 4th, 5th, ...

     A result yielding times! iter yields in turn 1, 2, 3, 4, 5, ... in
this kind of way.

     My minimalist version of class ORD would be something like this

immutable class ORD < $LIMITED_NUMBER{ORD}, $OPTION is

minval : SAME is       -- returns one!

     return priv_minval
end ;


maxval : SAME is

     return priv_maxval
end ;


create(
       val : CARD
       ) : SAME

     pre val > 0

     is

     return (val)
end ;

....... followed by similar creation routines from all simple numeric
classes (excluding complex number classes).

card : CARD is

     return CARD::create(self)
end ;

...... followed by similar conversion operations to all simple classes.

succ : SAME is

     builtin!
end ;

pred : SAME 

     pre self > minval

     is

     builtin!
end ;

times! : SAME is

     start : SAME := minval ;
     loc_end : SAME := self ;

     loop
          if start > loc_end then
               quit
          end ;

          yield start ;
          start := start + 1
     end
end ;

end ; -- ORD

     Things like nils, str, equality, etc will also be needed.  I would
recommend, however, that in addition to the times! iter without yielded
value, there by succ and pred with an ordinal argument indicating which
successor/predecessor is wanted.

     Note no plus/minus/div/times/pow, etc, etc since this is not an
arithmetic number - it is merely a counter  - 1st, 2nd, 3rd, ...

> > While I could 'go public' with a partially
> > fixed version before Christmas, I would prefer to talk about the end of
> > February (I am away for six weeks in China just after Christmas).

> Please do make a release before Christmas, as long as it is progress from the 
> last
> release. How is the new runtime coming along?

     Mmmmmmm!  As I type this I am chasing a memory bound error somewhere
in the library - at its latest revision!  If I find this in the next couple
of days I could provide an updated release, but I would not like to be held
accountable for remaining subtle bugs.  Additionally there would be some
documentation update - but not nearly as much as I would like to have added
- due to the specification problems.

     The new RTE?  Well! Befor he dashed off to gainful employment a month
before he expected my RTE writer dashed in to give me the latest version
which needs some tidying up (he said!) but basically does all required of
it!  Once that has been thrashed to death then a revised Sathre to RTE
interface needs constructing - solely as compiler generated calls to its
facilities - NOT additional wodges of code!!! The current size of the new
RTE (as loaded) is just over 20kbytes for exceptions, threads, garbage
collection and (as yet only tested with two machines) distributed
communication primitives.

     Anyone interested in simplifying/polishing this??

     Well!  There is the current state of the art - me debugging a
revised/fixed library!

Keith

PS The library functionality has been rationalised rather than altered - in
respect of a number of newly introduced abstractions (which have actually
added a few features here and there for consistency).

-- 
City Desk
Waikato University
[PGP key available if desired]