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