[Brain-list] I am still alive ... :-) [LONG]

[Clemens H. <c.h...@gm...>]

Manuel Tomis writes:
> Hi Clemens
> 

Hi Manuel,

sorry for not answering such a long time. You must already though,
that I am not interested in Brain any longer. But nothing could be
more wrong! :-)

I was very busy with my daily work. We had to match an nearly
impossible deadline and I had to do some wired and tiresome mission
critical tasks to do. It has really burned out my brain.

But now I have holidays for some week and I can come to rest and think
more about Brain again.

Although I was so busy, I had followed all you have written, and I had
regulary tried to update the CVS snapshots. I was really very fond of
all your changes you've made so far. Especially your switching back to
the global namespace instead of having 'system' all the source along. 
And I also like your name changings to ThatStyle. Your changes to the
exception handling are also very nice! Only that 'traits' is vanished
makes me feeling a bit unease, IMO.

I have also has some thoughts during these weeks that I would like to
tell you now. But let me first comment some of the older postings from
the list ...

(...)

> BTW. Do you think it is better to have one namespace for both
> delegates and prototypes or should each of them have it's own
> namespace?

I have thought long about this. I would tend to use only one namespace. 
If I would have to select namespace every time would become tiresome
would it?

(...)

> > Do you remember, you want (probably) implementing the
> > parser/compiler into Brain. Why not allow to install special
> > handlers (written in Brain) that could handle arbitrary
> > #... construct? How this?
> After some thought I think I like your idea. Allthough the
> Smalltalkish syntax of brain should be flexible enough for
> expressing nice interfaces to a variety of things, we might aswell
> provide a 'metaprogramming handler' feature like the one you
> propose, for the sake of completeness and because sometimes it may
> be usefull (but hopefully not overdone).

Do that means we get the ':symbol' syntax instead of '#symbol' one? It
would really be more consistent to be able to build all symbols in
equal manner like :() instead of "()" to-symbol.

> I don't like the 'use:' feature you propose, because it would be
> compicated to implement, and would break the semantics of brain.
> But no problem :-) Instead we can have two much simpler solutions.
> 1> For programs with many files we can have the main file let's say do:

This sounds reasonable. I am very interested in hearing more about it!

(...)

> But if you have any questions, or something you think I should talk
> about in the 'hacking guide', tell me so that I know what to talk
> about :-)

Mainly about how Brain works? What I have to pay attention to, to
write extensions for Brain? How objects are builded? How is this all
with Frame to be supposed to work with? How do I work together with
the GC? ... All such things. A simply README file could be enough
first. Not only for me as as beginner's guide for later guys joining
us as well :-)

(...)

Manuel Tomis writes:
> Hi
> 
> The following is a list of stuff left to do for brain-core before
> the next release.  (plus a few more complicated things that will be

(...)

> I will write a HACKER'S GUIDE after I clean up the internals a bit
> (do the caching, remove as many 'friends' and hacks as possible, and

This one would be very important at least for me. Although I am
already very comfortable with Brain, there are still a lot of things
that escape me right now.

> other stuff), which may take 2-3 weeks because right now it's
> midterm season in my college and I can't seem to find much time
> right now.

Do not hurry. We will have time! :-)

Now we are coming to some of my questions/remarks/proposals.

o PROPOSAL: Signal-Slot concept
  Do you know this? During my work these weeks, I learned some new
  things. Among these were the QT toolkit. Although I did not like it
  too much, I very like its Signal-Slot concept. I think it could be
  very valuable also for non-GUI programming. The concept propose,
  that one object could simply emit some signals, and other objects
  (one or more) could connect to some or all of these signals to be
  informed whenever such a signal was emitted.

  Others seem also to think, that this concept is very valuable. They
  have written a library libsigc++ which do realize that concept for
  C++ without having to use a special preprocessing tool like the
  'moc' in QT. 

  This concept could be very valuable for having equivalents to the
  Java Beans. It could looks like that in Brain:

    obj1 = Object new;
      prototype-is: Signaling;
      signal: #foo;
      signal: #bar:;
    .
    obj2 = Object new;
      method: #slot-foo is: { ... };
    .
    obj3 = Object new;
      method: #slot-bar: is: { |arg| ... };
    .
    obj1 connect: #foo with: obj2 slot: #slot-foo;
         connect: #bar: with: obj3 slot: #slot-bar:;
    .
    obj1 disconnect: #foo from: obj2 slot: #slot-foo.
    obj4 = Object new;
      prototype-is: Signaling;
      signal: #foo2 emitted-from: obj1 signal: #foo;
    .
  
  So whenever obj1 emit a signal 'foo' the slot (method) slot-foo of
  obj2 is called. Furthermore the signal foo2 of obj4 is emitted and
  all slots connected to that will also be called.

  The advantage is, that I could write a component that stands for
  itself and use only signals and slots to communicate to the outside
  of the world. Any third party could connect one object's signals to
  other object's slots and so forth.  

o Variables only assigned once in a scope? I think I have found an
  exception! I still like that behavior, but we should also think
  about this:

  - Block parameters constitute a new scope. They should be allowed to
    have same name than variables outside of that block.
    Please consider following code:

      a = 12.   # GOTCHA!
      blk = { |a| a println }.
      blk(13).

    The line GOTCHA! makes the difference. If it is commented out all
    compiles well. If not, a syntax error is the result.

  The sense was, that we wouldn't like to let variable in the same
  scope be overwritten by someone, because of potential source of
  errors. But here it is very clear that |a| is used as a
  block/closure parameter, as such it happens to be local to the
  closure's scope anyway! Therefore that kind of assignment should be
  allowed, IMHO! What do you think?

o Bug during IO?
  Following works different interactively or if started via file.

    myerr1 = Exception new: "myerr1";
      property: #arg is: nil;
      method: "()" to-symbol is: { |a| self arg: a. self signal };
    .
    myerr1_1 = myerr1 new: "myerr1-1".

    myobj = Object new;
      method: #wrong1 is: { myerr1 arg: "myerr1 thrown"; signal };
      method: #wrong1_1 is: { myerr1_1("myerr1-1 thrown") };
    .

    { myobj wrong1.
      "Not thrown" println.
    } on: myerr1 do: { |e| (e arg +  " catched") println }.

    { myobj wrong1_1.
      "Not thrown" println.
    } on: myerr1_1 do: { |e| (e arg + " catched") println }.

    { myobj wrong1_1.
      "Not thrown" println.
    } on: myerr1 do: { |e| (e arg + " catched") println }.

  Once I got an output (interactively) or via:

    System load: "<filename>".

  but not if started via:

    brain <filename>.brn

o Error during re-use of prototyped methods?

    s = "hello".
    s2 = Object new; 
      prototype-is: String;
      method: #greeting: is: { |a| (self + " " + a) println }.
    s2 greeting: "world".
  
    Error!!! TypeError
  
    ???:4:Parameter ? should be string instead of ?

o Consider to have special syntax for methods like on:do:on:do... to
  avoid such really long and ugly names. I very like the solution you
  have chosen for the scope object's when:do: method. Could we have
  such for on:do: also?

    blk on: ... do: ... ;
        on: ... do: ... .

  Or perhaps something like (on:do:) matches all on:do:'s regardless how
  often it occurs. That means, if my selector is named

    on:do:(or-on:do:)

  it would match all on:do:or-on:do:, on:do:or-on:do:or-on:do:... and
  so on. The parameters for the part of the selector in parenthese
  could be passed as lists. So it would look like this:

    ... method: :on:do:(or-on:do:) is: { |p1 p2 list1 list2| ... }

  So list1 and list2 would contain all collected arguments of the
  repeated or-on:do: part.

  That would avoid ugly on:do:on:do:on:do... methods, and could allow
  methods with infinite argument lists.

This would be all for now! Please keep up your nice work and remain so
patient to me as in the past. :-)


Ciao,
Clemens.


BTW: Please have a look at http://sources.redhat.com/sourcenav/ it is
     really a nice tool. Perhaps you will like it!

-- 
Clemens Hintze  mailto: c.h...@gm...