brain-list

[Brain-list] I need help.

[Shadowman XP <sha...@ya...>]

Hello, I'm new here. I need help from you guys. Where can you get a Windows version for brain, and a tutorial or documentation for it? I need this very badly for one of my projects at college. Thank you very much!


---------------------------------
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.

[Brain-list] how to compile and run a sample program using Brain

[Marc S. <mar...@ya...>]

Hi, I would just want to ask how to compile and run a program using Brain because I can not find any documentations on how to do that. Thank you very much and I will appreciate any quick response. Thanks!
 
Regards,
 
Marc


---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

[Brain-list] Could you please post this

[<eca...@co...>]

I'm a resent Recording Arts grad trying to get involved with the audio industry in any way possible. I just moved to the Atlanta area to follow my dream and pursue a career in the industry. If you are or ever in need of a responsible dedicated person wanting to learn and work please contact me, I'm dedicated 24/7.

Elliot Carter
Ec...@co...
843-267-7995

[Brain-list] URGENT ATTENTION

[Johnson N. <joh...@ne...>]

DEAR FRIEND, 

                    BUSINESS TRANSACTION. 

MY NAME IS JOHNSON NDIOVU, THE ELDEST SON OF MR.AKUGA NDIOVU OF ZIMBAWE IT =
MIGHT BE A SURPRISE TO YOU, WHERE I GOT YOUR CONTACT ADDRESS. I GOT IT FROM =
THE NETHERLANDS CHAMBERS OF COMMERCE. 

DURING THE CURRENT CRISIS AGAINST THE FARMERS OF ZIMBABWE BY THE SUPPORTERS =
OF OUR PRESIDENT ROBERT MUGABE TO CLAIM ALL THE WHITE OWNED FARMERS IN OUR =
COUNTRY, HE ORDERED ALL WHITE FARMERS TO SURRENDER THEIR FARMS TO HIS PARTY =
MEMBERS AND THEIR FOLLOWERS. 

MY FATHER WAS ONE OF THE BEST FARMERS IN THE COUNTRY AND KNOWING THAT HE DID =
NOT SUPPORT THE PRESIDENT POLITICAL IDEOLOGY, THE PRESIDENT'S SUPPORTERS =
INVADED MY FATHER'S FARM AND BURNT DOWN EVERYTHING, SHOT HIM AND AS A RESULT =
OF THE WOUNDS SUSTAINED,HE BECAME SICK AND DIED AFTER TWO DAYS. AFTER HIS =
DEATH, MY MOTHER AND I TOGETHER WITH MY YOUNGER BROTHER DECIDED TO MOVE OUT =
OF ZIMBABWE FOR THE SAFETY OF OUR LIVES IN SOUTH AFRICA, WHERE I LATER MOVE =
TO HOLLAND. 

BUT BEFORE MY FATHER DIED, HE WROTE A WILL, WHICH READS. MY BELOVED SON, I =
WISH TO DRAW YOUR ATTENTION TO THE SUM OF US$12.5 (MILLION DOLLARS) WHICH I =
DEPOSITED WITH A SECURITY COMPANY IN HOLLAND IN CASE I WANT TO INVEST THE =
MONEY, I DEPOSITED THE MONEY IN A SECURITY COMPANY WITH MY NAME (JOHNSON =
DIOVU)AND IT CAN BE CLAIM BY ME ALONE WITH THE DEPOSIT CODE, MY MOTHER HAS =
ALL THE DOCUMENT. TO TAKE GOOD CARE OF MY MOTHER AND BROTHER. 

FROM THE ABOVE, YOU WILL UNDERSTAND THAT THE LIVES OF MY FAMILY DEPEND ON =
THIS MONEY. AS SUCH,I WILL BE VERY GRATEFUL IF YOU CAN ASSIST US I AM NOW =
LIVING IN HOLLAND AS POLITICAL ASYLUM AND THE FINANCIAL LAWS OF NETHERLANDS =
DO NOT ALLOW ASYLUM SEEKERS CERTAIN FINANCIAL RIGHTS TO SUCH HUGE AMOUNT OF =
MONEY. 

IN VIEW OF THIS, I CANNOT INVEST THIS MONEY IN NETHERLANDS HENCE I AM SEEKING =
FOR YOUR ASSISTANCE TO TRANSFER THIS MONEY OUT OF NETHERLANDS FOR INVESTMENT =
PURPOSE. FOR YOUR EFFORTS, I AM PREPARED TO OFFER YOU 20% OF THE TOTAL FUNDS, =
10% FOR ANY EXPENSES THAT MAY BE INCURRED IN THE COURSE OF THIS TRANSACTION, =
WHILE 70% WILL BE KEPT FOR MY FAMILY AND I. 

FINALLY, MODALITIES ON HOW THE TRANSFER WILL BE DONE WILL CONVEYED TO YOU =
ONCE WE ESTABLISH TRUST AND CONFIDENCE BETWEEN OURSELVES. LOOKING FORWARD TO =
YOUR URGENT REPLY, FOR MORE INFORMATION, YOU CAN CONTACT ME ON THIS E-MAIL =
ADDRESS.

NOTE, THE KEY WORD TO THIS TRANSACTION IS ABSOLUTE CONFIDENTIALITY AND =
SECRECY, THIS TRANSACTION IS 100% RISK FREE, YOUR URGENT RESPONSE WILL BE =
HIGHLY APPRECIATED. 

ALL THE BEST, 

JOHNSON NDIOVU 

(For the Family). 

  

Re: [Brain-list] Still alive?

[Manuel T. <ma...@sp...>]

Hi Clemens

It's nice to hear from you after all this time.

Unfortunately I would say that brain is pretty much dead. One reason is that I 
don't have much time these days, because I work long hours for my job.

The main reason is that as always I can never make up my mind about how I want 
the perfect language to be. So in the meantime I changed my mind on a lot of 
issues about brain.

One thing is that alltough I still find a Smalltakish syntax aesthetically 
appealing, I also find that I am so used to programming in languages with C 
like syntaxes that I feel much more productive in them. So If I were to start 
from scratch I would choose a more 'mainstream' syntax.

Another issue is that I decided I prefer programming in statically typed 
languages. I like the feeling of 'order' of a statically typed language and I 
find it helpful that I can play with my code, change method names, signatures 
etc and be sure that the type system will tell me if I forgot to change a 
method call somewhere in my code. So now my ideal language would be 
statically typed but with a type system and standard libraries that are very 
flexible and high level so that the language can be as easy to use as any 
scripting language (maybe a statically-typed prototype-based language). Of 
course I have yet to decide how all of this can be...

I still like to talk about this and read articles and mailing lists about 
language design, and sometimes I think about maybe one day cannibalising 
brain's runtime and starting a new language, but for the monent... wo meiyou 
shijian.

Manuel

On Wednesday 07 May 2003 09:27, Clemens Hintze wrote:
> Hello Manuel,
>
> after some very busy years (switching the field of work from
> telecommunication to railway technik) and learning and mudding with other
> languages, I have asked myself if Brain did still live?
>
> In one of you last emails, I remember you have told, that you have played
> with the thought of totally abandon the further development of Brain. But
> you have also stated that you have changed you mind and continue ...
>
> For some time after this event, I had still regulary looked into CVS to
> view, whether you have made some changes. But all was silence ...
>
> Will it revive ... or rest in peace? ;-)
>
>
> Best wishes,
> Clemens.
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Brain-list mailing list
> Bra...@li...
> https://lists.sourceforge.net/lists/listinfo/brain-list

[Brain-list] Still alive?

[Clemens H. <cle...@al...>]

Hello Manuel,

after some very busy years (switching the field of work from telecommunication to railway technik) and learning and mudding with other languages, I have asked myself if Brain did still live?

In one of you last emails, I remember you have told, that you have played with the thought of totally abandon the further development of Brain. But you have also stated that you have changed you mind and continue ...

For some time after this event, I had still regulary looked into CVS to view, whether you have made some changes. But all was silence ...

Will it revive ... or rest in peace? ;-)


Best wishes,
Clemens.

Re: [Brain-list] Building brain under cygwin...

[Manuel T. <ma...@sp...>]

Hi

The number bug is now fixed. Thanks Clemens for the hints at where the problem
was.

BTW. You may have noticed that there was nothing much going on with Brain for 
the last few months. Basically due to various reasons I had stopped working 
on Brain and was thinking of dropping the whole project alltogether, but I 
have changed my mind (I do that a lot...). So now that I have holidays I have 
time again and have started hacking Brain again.

Manuel

Re: [Brain-list] Building brain under cygwin...

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

Clemens Wyss wrote:

Hello Clemens,

fine to meet you here ... :-)

> When building brain under cygwin (latest greatest with the latest greatest
> gcc) I get the follwoing errors:

(...)

> Any hints

Indeed! I would guess you have no useable GMP library or at least the
Brain configure thinks so. If so, the define BRN_WITH_GMP will not be
set and some of the code in Number.cpp is not compiled properly. So the
linker complains.

I had not found this before, as I ever compile with GMP library/option
installed.

Until Manuel fixed that bug, you should try to build/install proper
(means at least 3.1) version of GMP. That should help then!

> Clemens

Indeed, indeed ... 

Clemens (the other; \cle of Ruby ;-)

[Brain-list] Building brain under cygwin...

[Clemens W. <cl...@es...>]

When building brain under cygwin (latest greatest with the latest greatest
gcc) I get the follwoing errors:

"
Making all in src
make[1]: Entering directory `//d/Projekte/brain-core/src'
/bin/sh ../libtool --mode=link
c++  -I- -Wall -Wpointer-arith -pedantic-errors -ansi -g -O2  -o brain
brain.o libbrain.la -lm
c++ -I- -Wall -Wpointer-arith -pedantic-errors -ansi -g -O2 -o brain brain.o
.libs/libbrain.a
.libs/libbrain.a(Number.o): In function `brain::Any::gc_finalize(void)':
//d/Projekte/brain-core/src/Any.h(.data$_vt$Q25brain7Integer+0x74):
undefined reference to `brain::Integer::to_long(void)'
//d/Projekte/brain-core/src/Any.h(.data$_vt$Q25brain7Integer+0x7c):
undefined reference to `brain::Integer::to_rational(void)'
//d/Projekte/brain-core/src/Any.h(.data$_vt$Q25brain7Integer+0x84):
undefined reference to `brain::Integer::to_string(void)'
collect2: ld returned 1 exit status
make[1]: *** [brain] Error 1
make[1]: Leaving directory `//d/Projekte/brain-core/src'
make: *** [all-recursive] Error 1
"

Any hints
Clemens

[Brain-list] New stuff

[Manuel T. <ma...@sp...>]

Hi

Just to tell you that there is some new stuff in CVS if you want to check it out:

* Processes
* Signals

  an example:
  
  s = Signal new.
  s connect: {"Hello" println}.
  s connect: {"Goodbye" println}.

  {"Here" println. s wait. "There" println}.
  10 do: {"nothing" print}.
  s signal.

* Sockets
  Example of server:  
    connection = Socket TCPServer port: 7000; accept.

  Example of client:
    connection = Socket TCPSocket host: "localhost" port: 7000.

* Hashtables & Sets

  example:
  t = Hashtable new.
  t at: "me" put: "it".
  t at: "me"; println

* Bound Methods

  example:
  g = 1 method: :+ .
  g (4); println

(But a warning, all of the above have bugs and some are incomplete :-( but I am
working on that...)

Manuel

Re: [Brain-list] New ideas ... (and a happy new year!)

[Manuel T. <ma...@sp...>]

Hi Clemens

> > All good ideas! So this is kind of your christmas present to me :-)
BTW The new number syntax and the Native thing is now in CVS.
For the numbers I chose to have a <base>#<digits> rather than <base>r<digits>
format, to avoid confusion when with large bases 'r' is considered as a digit
like: 36rrrrr would look confusing while 36#rrrr is clear (not that such
bases will really be used often). Because a base will always preceed
such a number, it will not interfere with a possible future implementation
of you extensible syntax proposal.

> Hey! Do not tell me anything about that topic. Now as I have 'holidays'
> I have more to do than on some 'working' days :-(
Teachers/bosses/etc all seem to think like this: "All that free time you
have and nothing to do; so let me spare you from boredom and give you
a ton of things to do; no need to thank me!!!" :-(

> Let you time! I will try to spare my comments/remarks/ideas and
> summarize them later on :-)
You don't have to wait (unless you can't find time to write).
I am always happy to read mail, as reading doesn't take much time;
on the contrary it feels nice to be reminded that other people care about and 
are involved with this project.

The problem is coding; I need to be able to concentrate to code and 
I can't do that when I am thinking that I have 3-4 projects to do and I am late,
or when I wake up at 14:30 (Ok I could try to train myself to have more normal
sleeping hours...) and have to go to college at 17:00, ... ,
you get the picture. In fact when my mind is overloaded with too many projects
I don't want to do, my mind gets blocked and in the end I spend all my time worrying
and do nothing. I think I need to train myself in the arts of 
"guerilla programming", that is to be able to switch my mind into and
outof "brain-mode" quickly and so be able to code in the above 
mentioned situations :-)

> Ah! That is an impressing fact. Thanks you told me. After all, I had
> thought about asking you to write down your experiences after switching
> to C++, when first public release of Brain would be available. I think
> your experiences could be of value for others too!
I can't think more specific stuff to say right now, so I will say more on
the topic at a later point. One thing I can remember now is about internal
interfaces. With the C++ version, because we use inheritance, brain objects
are either passed as Any*, or we dynamic_cast it to a specific brain type
ex String* and only then can we operate on that object as a 'native' string.
Methods will take the most specific type of a parameter, for example if it
wants a String, it will be 'void foo(String* param)' so internal interfaces
are statically typed as much as possible. 

With the C version because we used the cell model thing, we could only pass
brain objects around as brn_t. Often for efficiency reasons I knew that
a function would only take a specific type ex string, but because it was
an internal function for efficieny it took the brn_t and did not do any validation
to see if it is really that type, but just casted to what it wanted and started
work. So if for some reason, I passed the wrong type to that function I would
get a coredump. I think this problem is faced by a few other interpreters in C
that use cell like model (for example in the guile mailing-list archives I 
noticed talk of having two separate interfaces, a fast-one and a safe-one,
but that was long time ago, so maybe things are different now). Of course
C interpreters that use different object-model implementations do not face
the above problem (but probably still need more casts due to lack of inheritance).

Manuel

Re: [Brain-list] New ideas ... (and a happy new year!)

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

On 31 Dec, Manuel Tomis wrote:
> Hi Clemens
> 
> All good ideas! So this is kind of your christmas present to me :-)

(((-: Thanks for the flowers :-)))

(...) 

> The only problem is that I lately have too much college projects to
> finish
> (it is a sick thing to have more stress during my so-called "holidays",
> than during working college days, isn't it? It drives me MAAAADDDDD....).
> So I may be a bit unresponsive until the end of my exams in 3 weeks,
> and will probably be very slow in doing anything new in Brain...

Hey! Do not tell me anything about that topic. Now as I have 'holidays'
I have more to do than on some 'working' days :-(

Let you time! I will try to spare my comments/remarks/ideas and
summarize them later on :-)

(...)

>> Perhaps calling the C-Brain a Brain study and let the new one begin
>> with 0.1 as it should?

I agree with your versioning thoughts. Your point of view seems cleaner
than my one :-)

(...)

> But you are right that CBrain was like a brain study :-) At that point
> I was happy to do a little language that just works, while now with
> your help, we have much higher goals :-) C++ has already helped, by
> having much stronger typing, and therefore making the internals much
> more secure. (I got a lot fewer coredumps while writing Brain in C++
> that in C, but that probably also has to do with the experience gained
> from the first implementation).

Ah! That is an impressing fact. Thanks you told me. After all, I had
thought about asking you to write down your experiences after switching
to C++, when first public release of Brain would be available. I think
your experiences could be of value for others too!

> Everybody do: {|person| person send: :BestWishes} #! :-)
> Manuel

Thanx and same too you!
Clemens.

Re: [Brain-list] New ideas ... (and a happy new year!)

[Manuel T. <ma...@sp...>]

Hi Clemens

All good ideas! So this is kind of your christmas present to me :-)

> o Introduce <base>r<digits> style for denoting numbers...
Agreed!

> o Introduce a method that enables me to determine if some object is a
>   native one or not...
Maybe we can have a Native prototype object, and so you can ask:
  foo is: Native

> o Bound methods...
Also nice!

The only problem is that I lately have too much college projects to finish
(it is a sick thing to have more stress during my so-called "holidays",
than during working college days, isn't it? It drives me MAAAADDDDD....).
So I may be a bit unresponsive until the end of my exams in 3 weeks, and
will probably be very slow in doing anything new in Brain...

> You are right! But do I have to use a new Handler instance for
> this. Would a singleton Handler object enough?
A Handler is like a container of exception handlers, so each time you 
have to create a new one and fill it up with the exception/handler pairs
suitable for the case. But you can store a handler in a variable and reuse
it in various places if you want.

> Another issue: I think we really should thinking about some
> nameswitching. Not necessarily for new Brain, but for old one. I never
> liked the idea that C-Brain is version 0.5.2 whereas C++-Brain become
> version 0.6. That is a bit cheating IMHO, as nearly all was new
> implemented. That should deserve an own version-number-chain.
>  
> Perhaps calling the C-Brain a Brain study and let the new one begin
> with 0.1 as it should?
Well when I started I was not sure about what kind of version number scheme
I would follow, so up to mow numbers are a bit messed up, for example
the first public release was 0.5 (don't ask why...)
Anyway from now on version numbers will be as follows:
Unstable versions will go like 0.6, 0.7, 0.8, ...  0.99
and will go like this (not necessarily until 0.99 :-) until Brain is ready
and stable enough to be considered as Version 1.0. After 0.6, which depending
on my college chore load, should come out somewhere in spring 2001, I will
make more frequent releases. So 0.6 does not mean half ready, it only means
unstable release that comes after 0.5. So I don't think this is much of a problem,
I mean other projects have also occasionaly done rewrites/reorganisations,
or have weird version numbers.
On the other hand if we start again from 0.1 without changing our name, 
that might cause some questions. 

But you are right that CBrain was like a brain study :-) At that point I was
happy to do a little language that just works, while now with your help,
we have much higher goals :-) C++ has already helped, by having much stronger
typing, and therefore making the internals much more secure. (I got a lot
fewer coredumps while writing Brain in C++ that in C, but that probably also
has to do with the experience gained from the first implementation).

Everybody do: {|person| person send: :BestWishes} #! :-)
Manuel

[Brain-list] New ideas ... (and a happy new year!)

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

Hi Manuel,

after some thinking and playing with Brain, I have got some new
ideas:

o Introduce <base>r<digits> style for denoting numbers. That was
  coming from Smalltalk, I believe. I like this more than the leading
  zero means octal, 0x means hex and so on. It would be more
  consistent and could work with *every* number base:

    2r01001101     #! Binary number
    8r1234567      #! Octal number
   16rABC001C      #! Hex number

o Introduce a method that enables me to determine if some object is a
  native one or not. That one should be easy: Every object derived
  from Object or one of its child should return 'false' on
  e.g. is-native? Others would returning 'true'.

o Bound methods
  This thought I got while thinking about realisation of callbacks. My
  thoughts: It should be possible to get implementation of a certain
  method. But as we have to differ native methods from Brain methods I
  would propose following.

  - Introduction of a new object Method or Message
  - I can get a bound Method object via e.g.
  
      method = anyobject method: :foo.
  
  - A bound Method object is associated with the object it was taken
    from. I can simply call it via :() that would invoke the method as
    it would be sended to the object. Like this:

      m = 1 method: :+.
      m(2).              #! equivalent to 1 + 2 => 3
      m(3).              #! equivalent to 1 + 3 => 4

  - From a non-native method, I could extract/get the block that
    implements this method:

      blk = (anObj method: :anMethod) block

    for native methods this should return 'nil'.

  - I can rebind bound Method objects to another receiver of same
    type:

      m = 1 method: :+.
      m(3).              #! equivalent to 1 + 3 => 4
      m rebind-to: 2.
      m(3).              #! rebound so equiv to 2 + 3 => 5

    This could be used for fine callback tricks ...

  I think this would be nice, as we could assign some bound Method
  objects as e.g. callbacks. We would not have to assign object *and*
  method name then. In an example of signal-slot in one of my last
  mails I have proposed:

    obj1 connect: :foo with: obj2 slot: :slot-foo.

  Due to my proposal, this could be changed then to:

    obj1 connect: :foo with: (obj2 method: :slot-foo).
  
What do you think about this all?

Ciao,
Clemens.


PS: A happy new year to you, your family and all friends-of-Brain.

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

Merry Christmas (was Re: [Brain-list] I am still alive ... :-)

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

Manuel Tomis writes:
> Hi Clemens

Hi Manuel,

> > o If I try to access a method of slot that is not in the common
> >   hashtable a left-to-right depth-first lookup will be performed.
> What I was thinking of is to try to find a more explicit way of
> resolving conflicts, rather that them being resolved by the order in
> which parents are defined (which is what is being done right now),
> maybe something along the redirect:to: proposal you once
> mentioned. But I am not sure yet.  Do you think that the
> implicit/order-of-definition style of resolution would be
> satifactory and clean enough?

Hmmm ... the best would be if you could find that there are ambiquity
during message lookup you issue an error! To resolve this one would
have to use redirect:to: message.

But I remember you once said that you could easily find out such
issues. So I thought to propose left-to-right depth-first. I still
think, my first proposal would be better. Perhaps caches could help
here. If you build the cache not if message lookup takes place but if
prototype is assigned?

That should not happen too often, and therefore there should be no
performance penalty, should it?

(...)

> But leaving the above comments aside, I decided I like your :symbol
> proposal, for the reasons you have put(ability to have some more
> kinds of symbols as literals, and the freeing up of # for future
> use).
> Also it is now possible to define any symbol, by following the :
> with a string literal like this (could have been done with old
> syntax too but for some reason I had forgotten to do it):
>   :"foo bar +" println
>   =>foo bar +
>   
> Updated version is in CVS.

Woa! Thanks for it. It is like Xmas, isn't it? ;-)

I have checked out and had a look onto it! I find the syntax very nice
now. Message selectors with parameters become really eye catching
now ... I like this. :-)

> > I understand! But could we find a way to fake this. IMHO s2 should
> > behave like a String although it is not a String. Perhaps if
> > prototype is native one, a cloned copy should be stored together
> > with the object so that such messages could be send to the native
> > object (a bit like your old prototype concept of the old Brain)?
> 
> There are problems:

(... problem description deleted ...)

Hmmm ... perhaps I have not properly described my solution. But I have
thought more about it. Perhaps we should say, that Brain objects can
serve both as prototypee and delegatee, whereas native objects could
only be used as delegatee? Would that solve the problems you've
mentioned above?

This and the fact that you use a cache for message lookup that would
be filled via prototype/delegate assignment could be promising
solution of our problems, couldn't it?

> > Just a quick thought! I do not know if it is a clever idea! But if it
> > is, that native object should be hidden and inaccessible from the
> > outside.
> I am not sure exactly what you mean here, can you tell me more?

Nearly the same as I described above in this mail. But if I use a
native object as prototype, perhaps turning this to delegation to an
instantiation of the prototypee. But that would be hidden so that I
couldn't even see that this happen. I would still believe that
e.g. String became a prototype of my object whereas in reality an
instance of it becames a delegatee.

But with my proposal above with the 'native objects only delegatees'
this would perhaps not necessary anymore?

(...)

> If I understand correctly you are suggesting that we put the on:do:
> method in the Exception objects here? Does that mean that when an
> exception is raised, every handler block should be evaluated until a
> match is found? If so then I think there are two problems:
> o May be slower that alternative
> o No one restricts what kind of code can be in the handling block,
>   which means that if for example we put a 'println' in the first
>   line before 'exception' it will be executed whether any of the
>   handlers below match the thrown exception or not, which is
>   probably not such a clean solution.

You are right! But do I have to use a new Handler instance for
this. Would a singleton Handler object enough?

> Anyways, I have implemented the scheme I proposed in my last mail,
> and it is in CVS.  As always if any problems arise, we will just
> change everything :-)

:-) :-) :-)

> > BTW: We should try to decide whether Brain works with methods or
> > messages. I would vote for the last, whereas e.g. on:do: would be a
> > selector or message name.
> Forgive my ignorance, but could you tell me the difference?

Not too much. But perhaps this proposal is already to late anyway, as
you call it:

   obj method: :foo is: { ... }.

So you implicitly have already decided to call the whole stuff
'method'. The true difference is not to big, IMHO. For me, a method is
more like a subroutine in C++ or Ruby or even Python. 

A message would be a name, that is associated with some code! That
would be more like Smalltalk, Objective-C or Brain, IMHO. It is really
difficult for me to tell the difference. A message has code associated
to it, whereas a method *is* code. Ahhh too confusional, sorry about
it. Perhaps better forget it.

But to speak the truth, something like:

  obj message: :foo do: { ... }.

looks also not ugly! ;-)

But be it as it be, we should not intermixing these both terms. Either
we use methods *or* we use messages. But not both.

Another issue: I think we really should thinking about some
nameswitching. Not necessarily for new Brain, but for old one. I never
liked the idea that C-Brain is version 0.5.2 whereas C++-Brain become
version 0.6. That is a bit cheating IMHO, as nearly all was new
implemented. That should deserve an own version-number-chain.

Perhaps calling the C-Brain a Brain study and let the new one begin
with 0.1 as it should?


> Manuel
Clemens.


PS: Merry Xmas for you, your family and friends and all
    friends-in-Brain!

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

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

[Manuel T. <ma...@sp...>]

Hi Clemens

> Perhaps I have an idea:
Let me think about this some more and I will get back to you on it.

> o If I try to access a method of slot that is not in the common
>   hashtable a left-to-right depth-first lookup will be performed.
What I was thinking of is to try to find a more explicit way of resolving conflicts,
rather that them being resolved by the order in which parents are defined
(which is what is being done right now), maybe something along the
redirect:to: proposal you once mentioned. But I am not sure yet.
Do you think that the implicit/order-of-definition style of resolution would
be satifactory and clean enough?

> I would not insisting on the meta parsing feature, but I still think I
> would like to have :symbol instead of #symbol. It would be more
> consistent as all symbols should be able to build then. () would not
> being an exception then.
It is not so much that () is an exception, but more that the current symbol syntax
allow only a restricted set of symbols to be defined as literals. Any string can
be symbolified with the to-symbol method. And the slot manipulation methods
like method:is: slot:is: accept symbols as well as strings (so it is not necessary to
call to-symbol yourself when passing an 'unusual' symbol to them).

But leaving the above comments aside, I decided I like your :symbol proposal,
for the reasons you have put(ability to have some more kinds of symbols as literals, 
and the freeing up of # for future use).
Also it is now possible to define any symbol, by following the
: with a string literal like this (could have been done with old syntax too but for
some reason I had forgotten to do it):
  :"foo bar +" println
  =>foo bar +
  
Updated version is in CVS.

> I understand! But could we find a way to fake this. IMHO s2 should
> behave like a String although it is not a String. Perhaps if prototype
> is native one, a cloned copy should be stored together with the object
> so that such messages could be send to the native object (a bit like
> your old prototype concept of the old Brain)?

There are problems:
o s2 is an Object and String is a prototype here, not a delegate, which means use it's
  methods with s2 as self. There is no way here in which we can treat s2 as a String.

o Even if String was a delegate it would still not work (assuming the way things are right now)
  because String is what used to be the traits object,
  and is defined as an Object with some methods, not a String.
  (Although maybe that is wrong and maybe I should define the traits
   to be some kind of "empty"/"null" instances of the native class
   whose behaviour they represent, so that they could accept methods sent to them)

o I have been thinking about having the old brain's prototype behaviour for delegates,
  that is when an object is passed as a parameter to a native method, if it has a delegate
  of the expected C++ class then that delegate is used by the native method.
  That would mean that we will not be able to use dynamic_cast directly to determine the class
  of an object in C++ methods, but instead we will need some methods that lookup the
  parent hierarchy to find if the object or one of it's delegates match the wanted class.
  Also to remove ambiguity we will need some restrictions about having more than one
  delegates of the same C++ class for an object.
  I will think about this and say more when I figure out solutions. Any ideas?

> Just a quick thought! I do not know if it is a clever idea! But if it
> is, that native object should be hidden and inaccessible from the
> outside.
I am not sure exactly what you mean here, can you tell me more?

> Would it be possible to simplify your idea to:
> 
>   { ... }
>     if-error: { |exception|
>       exception 
>         on: foo do: bar;
>         on: bla do: yada;
>         ...
>     }
> 
> That means that the exception could establish such a scope-like object
> and handle the several on:do: messages?
If I understand correctly you are suggesting that we put the on:do: method
in the Exception objects here? Does that mean that when an exception is raised,
every handler block should be evaluated until a match is found? If so then I think there
are two problems:
o May be slower that alternative
o No one restricts what kind of code can be in the handling block,
  which means that if for example we put a 'println' in the first line before 'exception'
  it will be executed whether any of the handlers below match the thrown exception or not,
  which is probably not such a clean solution.

Anyways, I have implemented the scheme I proposed in my last mail, and it is in CVS.
As always if any problems arise, we will just change everything :-)

> BTW: We should try to decide whether Brain works with methods or
> messages. I would vote for the last, whereas e.g. on:do: would be a
> selector or message name.
Forgive my ignorance, but could you tell me the difference?

Manuel

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

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

Manuel Tomis writes:
> Hi Clemens

Hi Manuel,

(...)

> Anyway since my last mail, I have mostly been working on cleaning up
> and refactoring Brain.  Most of the stuff I changed are still not
> complete.

but we can see it evolving more and more ... :-)

> Right now I am working on Method lookup caches.  Also I will add the
> ability to have constant slots and private slots.  But this brings a
> problem of how to define them. It will not be fun to have a million
> methods like: foo final-private-method: #bla is: ...

(...)

> therefore we will not pollute the general object namespace, plus it
> can keep state between calls so that maybe we can say:
>   foo meta;
>     private  #! private will be remembered and will apply to below calls
>     method: .. is: ..;
>     method: .. is: ..;
>     public   #! public will also be remembered and apply to below calls
>     ....
> 
> But I am not sure yet. Ideas?

Hmmm ... it sounds a bit uncommon. But also promising and interesting. 
Perhaps try it out? Nothing that cannot be changed it it does not fit,
yes? But I would propose a more convenient name like 'slots' instead
of 'meta' to indicate, that we are dealing with object's slots right
now.

> I am still not sure how to handle conflicts when inheriting slots
> with the same name from different parents.

Perhaps I have an idea:

o I assume you will store the slot ids in a hashtable per object or
  so. Why not putting slots inherited by prototypes into a per
  prototype hashtable? So that if myobj has two prototypes it will
  have three hashtables one for every prototype and one for
  itself.

o All data slots and private methods would be stored into these per
  prototype hashtables. If a method of the prototype is invoked, it
  will look for data slots and private methods into the corresponding
  hashtable for that prototype. If a public method is called, it will
  look into the common hashtable.

o If I try to access a method of slot that is not in the common
  hashtable a left-to-right depth-first lookup will be performed.

o Of course it has not to be several hashtables but perhaps grouping
  within one hashtable would also be ok.

> Also lately I have been busting my head trying to find some way to
> have at least partial static type checking in brain. I am not yet

Please do not bother to much at first. I am sure we could add this
later. First Brain should work dynamically and then such typechecks
could be added.

(...)

> Also about iterators maybe instead of ListIterator, SetIterator I
> will have List Iterator, Set Iterator etc. But so far this is just a
> thought.

Sounds a good idea at the first glance. Try it!

(...)

> > 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.
> When I first read your proposal I thought I liked it. But now after
> thinking about it some more I am not so sure any more. Basically my
> philosophy so far has been to keep the syntax extremely simple, but

I would not insisting on the meta parsing feature, but I still think I
would like to have :symbol instead of #symbol. It would be more
consistent as all symbols should be able to build then. () would not
being an exception then.

(...)

> have a negative meaning)). So right now I am thinking maybe we can
> keep your idea at the back of our heads, but not implement it yet
> until we come up with a really good use of it, and I make up my
> mind. What do you think?

Fine with me! But please consider to change #symbol --> :symbol
anyway.

(...)

> > o PROPOSAL: Signal-Slot concept
> ....
> Looks great!!! (Has been added to TODO queue) This is basically a
> more generic implementation of the Observer pattern, isn't it?

I have to confess that I do not know it. Unfortunately I never had
read that Design Pattern thingy. But it is still on *my* TODO list :-)

I have learned it using QT and I found it a great idea to encapsulate
objects that are only sending signals to communicate with the outer
world. If slots are connected, fine they will be called with
concerning arguments. If not, the signal emitting would go into the
emptyness! Also fine :-))))

And the best is, that a third component could connect the two other
objects then. And more than one slot could be connected to any given
signal. Great concept!

> > 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:
> The point is that shadowing a variable in an outer scope with one
> defined in an inner scope is a bad idea; instead one should give
> different names to different things. Can you give an example of
> where allowing it would be usefull?  (hmmm I just thought of one
> use: Shadowing builtin global objects (ex List,String,Monitor,
> Scope), so that if we add new ones we won't breaks programs that are
> unaware of them and use the same name, but this still does not
> justify allowing this for any scope, only for builtins)

After some thinking I feel you are right! Do not change current
behavior. It is more important to remain consistent. Also no
overloading of buildin, IMHO!

(...)

> > o Error during re-use of prototyped methods?
> > 
> >     s = "hello".
> >     s2 = Object new; 
> >       prototype-is: String;
> >       method: #greeting: is: { |a| (self + " " + a) println }.
>                                      ^^^^^^^^^^^
> The problem here is: self + " " self is not a string therefore the
> C++ method cannot use it as a string and concatenate it with " ".

I understand! But could we find a way to fake this. IMHO s2 should
behave like a String although it is not a String. Perhaps if prototype
is native one, a cloned copy should be stored together with the object
so that such messages could be send to the native object (a bit like
your old prototype concept of the old Brain)?

Just a quick thought! I do not know if it is a clever idea! But if it
is, that native object should be hidden and inaccessible from the
outside.

What do you think?

(...)

> statement :-).  The solution to this will have to be something
> (similar to Scope as you also say) like:

Would it be possible to simplify your idea to:

  { ... }
    if-error: { |exception|
      exception 
        on: foo do: bar;
        on: bla do: yada;
        ...
    }

That means that the exception could establish such a scope-like object
and handle the several on:do: messages?

BTW: We should try to decide whether Brain works with methods or
messages. I would vote for the last, whereas e.g. on:do: would be a
selector or message name.

(...)

> used...  or maybe not. I will think about the details and say
> more. Also I will add something like the 'finally' thingy in Java
> (probably called 'ensure:' as I think is the Smalltalk
> tradition). With the above solution we should still keep the old
> on:do: methods for maybe up to 4 handlers or something for
> convenience, but any more can be done with the above generic
> solution.

Give it a try ;-)

> I wish you Happy Holidays + any Seasonal Wishes that may apply ;-)

Thank you and same to you! :-)


> Manuel

Clemens.

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

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

[Manuel T. <ma...@sp...>]

Hi Clemens

>   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| ... }

Sorry, I misread your actual proposal about this, so here is an amendment to my last reply.

A small problem with this is that when you are sending a message there is no way to tell between
a normal method and a 'variable-length' one as defined in your proposal.

So if you have

  foo me: ... you: ... me: ... you: ... me: .. you: ...

then the compiler will generate code sending the method: me:you:me:you:me:you: to
the receiver foo. Normally the evaluator will lookup that symbol and if not found give
and error.

But if we had such variable methods, then after the initial failure the evaluator would
have to see if the receiver (and it's parents) have any variable methods, and then
generate strings that are possible matches and do some string comparisons for each of these
to try to find a match. This could be a bit slow (but of course these variable methods would not
be so common, so if we really need this we could do it, and my solution isn't exactly that fast,
maybe we could even find a faster imlpementation that the one I just mentioned).

But I prefer the Scope style solution (and the Handler one proposed in my last mail)
for such problems, because it kind of feels a bit more clean and more 'Object-Oriented'.
One advantage of my solution is that you can interleave different kinds of calls like:
  Foobar
    on: ... do:...;
    on: ... do: ...;
    whatever: .. do: ...;
    on: ... do: ..;
    ensure: ...;
    something: ...;
    ....

But if we find any problem that can only be solved in a way such as
the one you propose, then we will have an idea to implement.

Manuel

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

[Manuel T. <ma...@sp...>]

Hi Clemens

I am really glad you are still there!!! :-)
But I understand that you were busy. Actually I was also kind of busy
with college projects, and that is why I have not achieved much progress with
Brain lately. My holidays are coming up, but it seems that
I will have to spend a large part of them finishing my college projects, and
therefore will not be able to dedicate all of them to fun and relaxing activities
like developing brain :-( But I hope to at least devote some days to Brain.

Anyway since my last mail, I have mostly been working on cleaning up and refactoring Brain.
Most of the stuff I changed are still not complete.

Right now I am working on Method lookup caches.
Also I will add the ability to have constant slots and private slots.
But this brings a problem of how to define them. It will not be fun to have a million methods
like: foo final-private-method: #bla is: ...
especially if in the future we find more kinds of attributes that a slot can have
(like maybe 'persistent' or who knows what). One solution I am thinking about
it to remove all the method:is: property:is: etc methods from all the objects and instead
add a method 'meta' that will return a MetaObject (something like an Iterator but for
slots, no relation to a Class or anything). So this meta object will have all the
slot manipulation methods and therefore we will not pollute
the general object namespace, plus it can keep state between calls so that maybe we can
say:
  foo meta;
    private  #! private will be remembered and will apply to below calls
    method: .. is: ..;
    method: .. is: ..;
    public   #! public will also be remembered and apply to below calls
    ....

But I am not sure yet. Ideas?

I am still not sure how to handle conflicts when inheriting slots with the 
same name from different parents.

Also lately I have been busting my head trying to find some way to have
at least partial static type checking in brain. I am not yet sure what restrictions
will be required to make such a thing possible, what kinds of syntax changes will
be necessary (for type annotations for example), or even what should be considered as a type,
if we can have type inference etc.
At the very least though I think that such mixed typing systems exist, for example
some Lisp/Scheme compilers. But this will not be done anytime soon in Brain if at all,
but I would appreciate any ideas on the subject. 

> 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.
These may not be the final changes to the namespace. For example I am thinking
to put some related objects as slots of more general objects. For example
instead of having(these are not there yet so don't look for them :-) :
DatagramSocket ServerSocket etc I am thinking to have Socket Datagram, Socket Server etc.

Also about iterators maybe instead of ListIterator, SetIterator I will have
List Iterator, Set Iterator etc. But so far this is just a thought.

Right now the global objects such as String/List/etc are what used to be in the traits.
This is so that you can create new stuff like: List new: 10 and at the same time be able to 
ask the 'type' of something like  (something is: List) in a convenient manner.
But things could still change if we find any better ways.

> > 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?
After posting that I had a change of mind. I now think I will just have one
namespace per object, just like Self, and like you proposed, 
which will include slots/methods/prototypes/delegates/whatever.


> > > 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.
When I first read your proposal I thought I liked it. But now after thinking
about it some more I am not so sure any more. Basically my philosophy so far has
been to keep the syntax extremely simple, but very flexible and implement all
the features in the library. (your proposal of course is also part of the 'library',
but still it 'messes' with the syntax (please don't take the word 'messes' to have a negative
meaning)). So right now I am thinking maybe we can keep your idea at the back of our
heads, but not implement it yet until we come up with a really good use of it,
and I make up my mind. What do you think?

> 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 :-)

The only reason I have not written this yet (besides lazyness and relative lack of time)
is that I may do some changes to the object model and it's implementation, so I am
waiting a bit to finish the cleaning of the sources.
But as I said the HACKERS' GUIDE is coming soon to a theater near you.... :-)

> o PROPOSAL: Signal-Slot concept
....
Looks great!!! (Has been added to TODO queue)
This is basically a more generic implementation of the Observer pattern, isn't it?

> 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:
The point is that shadowing a variable in an outer scope with one defined
in an inner scope is a bad idea; instead one should give different names to
different things. Can you give an example of where allowing it would be usefull?
(hmmm I just thought of one use: Shadowing builtin global objects (ex List,String,Monitor,Scope),
so that if we add new ones we won't breaks programs that are unaware of them and use
the same name, but this still does not justify allowing this for any scope, only for builtins)

> o Bug during IO?
<Still investigating...>

> o Error during re-use of prototyped methods?
> 
>     s = "hello".
>     s2 = Object new; 
>       prototype-is: String;
>       method: #greeting: is: { |a| (self + " " + a) println }.
                                     ^^^^^^^^^^^
The problem here is: self + " " 
self is not a string therefore the C++ method cannot use it as a string and
concatenate it with " ".

> 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: ... .
I agree that it is ugly, but I don't like the idea to  make 'on:do:' 
be special syntactically (REASON: See above mentioned philosophy statement :-). 
The solution to this will have to be something (similar to Scope as you also say) like:

  {.....}   
    if-error:  #! this name fits with List at:if-error: and similar stuff
      (Handler new;
        on: foo do: bar;
        on: bla do: yada;
        ...
        ...
      )

Maybe a generic kind of object rather that a specific Handler can be used...
or maybe not. I will think about the details and say more. Also I will add
something like the 'finally' thingy in Java (probably called 'ensure:' as I think is
the Smalltalk tradition). With the above solution we should still keep the old 
on:do: methods for maybe up to 4 handlers or something for convenience,
but any more can be done with the above generic solution.


I wish you Happy Holidays + any Seasonal Wishes that may apply ;-)

Manuel

[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...

[Brain-list] TODO - list

[Manuel T. <ma...@sp...>]

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 done at a later stage)
(Disclaimer: The status percentage is not computed in any accurate way,
it is just a number off the top of my head just to get a picture of what is
going on. ??% means I am not really sure what percentage to assign to it, but
basically means really really unfinished)

Task                                                    Status
-------------------------------------------------------------------------------
* Compiler                                              100%
* GC                                                    100%
* Evaluator                                             90%
  (TODO: Hash/Set literals)
* Objects                                               70%
  (TODO: unknown:with-list:, cache objects)
* C++ API                                               ??%
* Finalization                                          ??%
  (Will change after writing new GC)

* Loading of native libs                                0%
* Rewriting of compiler in Brain                        20%
  (which should also try to do optimisations, unlike the 
   simplistic current compiler)
* Bytecode saving/loading                               0%
* Security stuff for running untrusted code             0%
* Serialisation (to XML?)/Persistence                   0%
* Generational Copying GC                               0%
* JIT compiler back-end using GNU lightning             0%
* Brain component architecture (like Javabeans)         0%
* Debugging stuff                                       0%

* Symbol                                                100%
* Char                                                  80%
  (But will be replaced by Unicode Characters, and so
   will have to be rewritten)
* Numbers/Math                                          50%
  (TODO: Trigonometric functions, pow, exp, log ...)
* String                                                80%
  (TODO: Search/replace)
* File/Socket                                           60%
  (TODO: seek/tell, socket opening, maximum blocking delay, buffering)
* Buffer                                                80%
* List                                                  70%
* Exceptions                                            70%
  (TODO: Fix serious bugs, cleaner implementation,
   detecting if we leave a monitor due to exception)
* Thread/Monitor/Port/Generator/Continuations           65%
* Scope control structure object                        80%
* Iterators                                             30%
* Folder                                                0%
* Range                                                 0%
* Unicode/Localisation                                  0%
* Dates                                                 0%
* Process                                               0%
* Hash/Set/Bag                                          0%
* Regular Expressions                                   0%


* Tutorial                                              0%
* Library Reference                                     0%
* C++ API Reference                                     0%
* Hacker's Guide                                        0%


You may notice a lot of ZERO's but do not be alarmed, many of these tasks are minor
tasks (range, process, date, folder etc). If you feel you like any of the above tasks
and want to do them tell me about it. If you feel there are things that belong to
the core of brain that are not mentioned (and are not there already) then again tell
me about it.

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 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.

Manuel

Re: [Brain-list] Some thoughts!

[Manuel T. <ma...@sp...>]

Hi matju

> but: do you do any malloc()/free() to allocate the above bytes? if yes,
> then you are using more than that amount, and, depending on the number of
> allocations and the allocator used, maybe much more than that. OTOH, if
> you are doing your stuff via fixed-size cons cells, then you have a much
> slimmer overhead.
You are right about the malloc/new overhead, and actually my equation is not 
entirely accurate because:
1> I forgot 3 more words used by the hashtable (for size, capacity and ptr to an array) and
2> The 4 words per slot are an approximation because the hashtable uses an array
of linked nodes. 3 words come from the node and 1 from the array. But the size
of the array can be more or less that the number of entries in the table.

But the point of this really was just a rough comparison between the current and the
new objects implementation's memory footprints.

Later I may be able to optimise things further (ex by writing a copying GC).

Manuel

Re: [Brain-list] Some thoughts!

[Mathieu B. <ma...@ca...>]

> which right now is so ineffcient memory-wise that brain looks like a toy language.
> Right now the size of an object is about :
>   4 * sizeOfWord + (numberOfParents * 2 * sizeOfWord) + (numberOfSlots * 4 * sizeOfWord)
>   whereby: sizeOfWord = size of machine word (pointer or integer)

this is usually called wordsize; besides, since everything in your
expression is words, let's factor it out:

wordsize * (4 + 2*numberOfParents + 4*numberOfSlots)

but: do you do any malloc()/free() to allocate the above bytes? if yes,
then you are using more than that amount, and, depending on the number of
allocations and the allocator used, maybe much more than that. OTOH, if
you are doing your stuff via fixed-size cons cells, then you have a much
slimmer overhead.

> I am thinking about a new implementation of objects where the size of an
> object will be: 
>   5 * sizeOfWord + (numberOfSlots * sizeOfWord)

wordsize * (5 + numberOfSlots)

> Also each cache object will have a hashtable which will map slot-names
> -> indexes. The slot values will then be stored in an ARRAY in the
> objects themselves rather than each object having it's own hashtable. 

I approve this idea :-) At that point, Brain will have a chance of being
more memory-efficient than Perl/Python/Ruby. AFAIK, the latter three use
one big hashtable per object, though they have inheritance (so 1 Ruby
object = N Brain objects)

matju

Re: [Brain-list] Add-on to my last proposal ... and a new one ;-)

[Manuel T. <ma...@sp...>]

Hi Clemens

> But it seems not the 'unknown:with-list' method, yes?
Nope, not yet....

> This IS really nice ... what a coincidence. :-) I want to propose that
> idea also (seen in Perl and Tcl). BTW: How do I load/require a certain
> module right now? 'system load:' will abort if I try to load a script,
> and there is no 'system require'.
The normal ways to load modules/scripts etc should be.

  "module" load
or  
  system load: "module"

or    
  "module" import
or 
  system import: "module"

The difference between load and import is that import will only load the file
the first time and cache it's result, and then just give the return value of the
module to further requests. load on the other hand will load and execute the file
each time, and then return the value. (Right now though they both behave like load, 
because I haven;t done the hashtable object yet, which will be used for caching).
I will also do a 'load-config:' or whatever I will call it. This will load a file
execute it and return a hashtable of all the top level identifiers and their values.
This should be used to load configuration files.

The autoloading is kind of a trick to load stuff one demand that 'logically' is
already considered 'imported'. (Some examples are in the last lines of prelude.brn)

The aborting thing is a bug...

>   variable = system object new;
>     method: #<- is: { |v| self delegate: #value is: v };
>     method: #get is: { self slot: #value };
>   .
> 
> But unfortunately the #get seems not to return the right thing!
Oops! Sorry, I forgot to tell you that the delegates/prototypes have a different
namespace from normal slots, and that I haven't done yet the method which
allows you to read the value of a parent. 
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?


> And here I will fit in. Let me tell you some thoughts of mine. Let me
> assume you could accept the ':word' syntax for symbol fetching
> ... For me the '#...' is a kind of special syntax, something special
> happens here: object will created with #(); comments will indicated
> via #!, ... Only (* ... *) and #symbol will not fit here too smooth
> IMHO. But let (* ... *) remain as it fits too well so we could take
> this as exception here. But if we would use ':symbol' we would free
> the '#' token for other, futural use.
> 
> 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). 

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:

    .....
  "compiler-extension1" load.       #! Load and install handler
  "my-file-using-extension1" load.  #! Load and run program that uses new syntax
    .....
  
2> For single file scripts we can have a command line argument that loads and
  executes some files before running our main file:

  #! /usr/bin/brain --load extension1  my-program.brn
  #! Rest of script next:
    .....

I don't have time now, so I will tell you more later. In another mail I will
send something like a TODO list, and some info about hacking brain.
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 :-)
    
Manuel

[Brain-list] Add-on to my last proposal ... and a new one ;-)

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

Manuel Tomis writes:
> Hi Clemens

Hi Manuel,

> > how are you (school?)? Sorry for not writing for a long time! You
> > must already got the impression I have already left Brain ... but
> > I am far from that.
> Nice to hear from you!  Actually I must apologise, because I have
> also not been working much on brain for the last couple of weeks,
> mostly due to stupid college stuff taking my time.

Same to me but for earning money :-(

> Anyway I have just uploaded some more minor changes to CVS I had
> worked on in the last few days but not commited, which includes the
> 'send:with-list:' method,

But it seems not the 'unknown:with-list' method, yes?

(... <nice url handling> ...)

> a file-like object and is returned. Maybe I should change the name
> of 'file-handler-is:' to 'open-handler-is:' or something that fits
> better. Any ideas?).

Why do not calling it 'url-handler-is:'? At least it seems to deal
with URLs, isn't it?

(...)

> The prelude is indeed kind of messy right now :-) One thing I am
> going to do is to have some parts in separate files and then
> "autoload" them. For example I will have a date object in
> date.brn. Inside prelude I will define 'system date' and 'system
> traits date' to be methods which load the date.brn module, which in
> turn redefines these slots to what they should actually mean.  So
> inside programs, when you use 'my-date = system date new: blabla' or
> something the date object will actually be loaded on demand.

This IS really nice ... what a coincidence. :-) I want to propose that
idea also (seen in Perl and Tcl). BTW: How do I load/require a certain
module right now? 'system load:' will abort if I try to load a script,
and there is no 'system require'.

(... <cache & private> ...)

> This is just an idea and I would appreciate any comments :-)

This all sounds very reasonable. I am really eagerly waiting to see
it. But at the moment I really have no comment on it as it seems
flawless.

(...)

> It is nice! But we will need to have a 'value' method (like in your
> previous example) that returns the value of the variable, used when
> we pass the object as a paramter, so that the value of the variable
> is not changed

That is true! So I have changed it into:

  variable = system object new;
    method: #<- is: { |v| self delegate: #value is: v };
    method: #get is: { self slot: #value };
  .

But unfortunately the #get seems not to return the right thing!

(...)

> Unless there is a bug somewhere there should be infinite anonymous
> parents (both prototypes and delegates) allowed. When you give nil
> as the name instead of a symbol, it is treated specially and you can
> have as many such parents as you want.

Sorry, it seems I have misinterpreted your code, forget about it!

> > blk = { |a| "hello " + a }.  
> > blk("world") println.  #! -> Error: (...)
> This is not a bug  because the precedence of messages is
> unary -> () -> binary -> keyword.

Of course ... forgotten that! :-(

(...)

> I will think about your proposals and try to fix the bugs you
> report, and say more in another mail :-)

And here I will fit in. Let me tell you some thoughts of mine. Let me
assume you could accept the ':word' syntax for symbol fetching
... For me the '#...' is a kind of special syntax, something special
happens here: object will created with #(); comments will indicated
via #!, ... Only (* ... *) and #symbol will not fit here too smooth
IMHO. But let (* ... *) remain as it fits too well so we could take
this as exception here. But if we would use ':symbol' we would free
the '#' token for other, futural use.

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?

First let me propose another feature, I think you should have another
keyword like 'use:' that works like 'system require:' but will include
AND EXECUTE the corresponding script DURING compilation of the current
one. Assume you have two scripts: appl.brn and module.brn. If there
would be a 'use: module' in appl.brn, the compiler should load/compile
and execute the module.brn (or module.so) BEFORE it go forth in
compiling the appl.brn. The module.brn could be able to do things with
appl.brn before the compiler may work forth ... for example, it could
install some special handler for the #... constructs. A comment
handler could move the filepointer to the next line and returns to the
caller (the parser) so the comment would be effectively ignored by the
parser.

Of course I tell you this not for comments, but for other
purposes. Right now, I am writing a C++ package for handling Perl like
formats. Do you know them? If not type: 

   perldoc perlform

to inform yourself. These formats are an very easy way to output data
in a nice report format. If all works well I would like to implement
them for Brain too. Perhaps also in Brain or wrapping the C++
solution, I do not know right now. As sometime it could be very
tiresome to write such formats as strings, I could imagine a new
special syntax so that a Brain script could looks like:

  #!/bin/env brain

  use: formats

  #format PWD =
  @<<<<<<<<<<<<<<<<<< @||||||| @<<<<<<@>>>> @>>>> @<<<<<<<<<<<<<<<<<
  name,               login,   office,uid,  gid,  home
  .

  pwd = format at: :pwd.
  pwd feed-from: (system open: "file:/etc/passwd").
  :
  :

To produce a nice report for the /etc/passwd file! The special handler
'format' would read-in and parse the format description and e.g. store
it into some location for future usage. If the handler finished its
work it would have moved the filepointer after the lonesome '.' so
that the Brain parser could go on ...

BTW: By writing this, I could imagine that 'use:' could also be a
special construct like: '#use <module>'. Another special handler would
be able to do its work ...

Or think for embedded documentation handler, or debugging hints, ...

What do you think?

> Because I want to hurry up but my time is kind of limited lately due
> to college, but also because it would be more fair, I will be happy
> to allow you and other people to contribute code to brain.
> Therefore in another mail, I think I will make a list of what is
> done so far, and things that I think should be done for the
> brain-core (which should remain small), so that there is some kind
> of roadmap, and also will write a small hackers guide about the
> internals of brain. For the moment patches will do; later maybe I
> can give you CVS write-access.

This roadmap about internal would be A MUST for me. Although some
things seem clear to me, but others I really do not too much
understand them. I often guess, because I hve no time to look at all
places of the code to fiddle out how things work.

So I will also eagerly waiting for that too. Perhaps a kind of README
would be enough on the first step. Explaining the base things ... not
a complete reference guide or such ...

> But a warning: I have a tendency to change my mind all the time, and
> I am rarely satisfied, so I often do changes all around the
> code. Also about every two months I get into an existential crisis
> and question everything from the basic design of brain to the
> reasons to live. During those periods I often make fundamental
> changes to brain, and once in a while I do complete rewrites!!! Just
> so you know what kind of trouble you are getting into ;-)

I know, did you already forgot? ;-) Remember our discussion about
coroutines, threading, contextes and threads that, at least, have lead
us to a completely new Brain ;-)))))))))


> Manuel

Clemens.

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