Merry Christmas, one and all!

Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

Welcome, Friso Elster!

Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

----- Original Message -----
From: "Friso Elster" <daonlyfreez@...>
To: "taorebol" <Al.Bri@...>
Sent: Sunday, August 25, 2002 9:15 PM
Subject: Re: Application to join Oscar-project.


> Hi,
>
> I'm a freelance coder/programmer with interest in
> anything good and free on the internet, whether it's
> software or other services. IMHO the Net is flooded
> with nonsense and therefore I'm pleased with
> everything that is sincere and serves the community. I
> came across the Rebol project and thought it to be a
> positive development. Your Oscar Project takes things
> one step further, and therefore I would like to be
> informed on things to come.
>
> Thanx,
>
> daonlyfreez
>
>
>  --- taorebol <Al.Bri@...> schrieb: > Hi!
> > Recently, you've applied to join the Oscar Project
> > mailing list. Due
> > to persistent spamming, we now ask new members to
> > tell us a little
> > bit more about themselves or the company they work
> > for. This lets us
> > get rid of spammers, and get rid of the "noise".
> > Feel free to reply
> > to this email in your own time and tell us some more
> > about yourself.
> > Once you do this, your application to join the list
> > will be approved.
> > Thank you.
> >
> > Andrew Martin
> >
> >
>
> __________________________________________________________________
>
> Gesendet von Yahoo! Mail - http://mail.yahoo.de
> Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de

Hi, Gerard.
You've been approved to join the list.
Welcome!

Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

----- Original Message -----
From: "gerardcote" <gerardcote@...>
To: <Al.Bri@...>
Sent: Tuesday, June 04, 2002 3:58 PM
Subject: Why I want to subscribe to the Oscar group


> Hello Andrew,
>
> I am just a REBOL newbie that wants to take the most of what is
> available about REBOL.
>
> In fact I already enrolled in another Yahoo group You and Mark are
> driving. The "SENTENCES" DBMS project.
>
> I plan to hear from the 2 groups and sometimes also say something,
> according to my relative progress and knowledge...
>
> Thanks,
> Gerard
>
>

If you're a new member wishing to join this list, please send a email
describing yourself or your company and a sentence describing your desired
to join the list to either myself at Al.Bri@... or to
OSCAR-PROJECT-owner@yahoogroups.com.

Failure to do so means that your application to join this list will be
automatically denied!

I've been forced to come to this decision by the large number of
applications from spammers and noticably suspicious "throw-away" email
addresses of recent applications.

This means that:
          jossph6ys@...
     krambear36@...
     nishs_75@...
have had their applications to join this list denied.

Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

The OSCAR | PRIMO is still very much active offline.

I've not posted here for an enternity because I've been offline at home since
october,

I still very much research programming languages and their implementation
especially Common Lisp and Scheme which are REBOL like and there's lots of free
and quite well documented implementations available for study, have been
pondering these deeply since late last year, also going through a web course on
perl 5 implementation, will post url here later when i can find it.

OSCAR | PRIMO is not dead, it is something I strongly & deeply believe in, and
something I WILL make happen in my life, both for ME and everybody else, there's
a LOT to it though, not just to create a REBOL clone but to also try to fix
somethings in REBOl which bug me or features I consider missing, like a full
numeric range of datatypes.

The tortoise progresses whilst the Hare sleeps by the side of the road.....


Mark Dickson

> is there a source code repository somewhere (sourceforge)?

No, but check out the files section at:
http://groups.yahoo.com/group/OSCAR-PROJECT

Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

is there a source code repository somewhere (sourceforge)?

thedslguy2002 has been banned and his spam deleted.

All new members must now be approved by the moderators.

Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

dslproviders@... has been banned and their spam deleted.

Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

bdavisa has been banned and removed from this list for spamming.
Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

I haven't been able to get a credit card for 6 years. THis site
helped me get two! Check it out!

Click on link Below!

http://apply4creditcard.com

http://www.devincook.com/goldparser/

Hi all .

   Just thought I'd mention that Frank Sievertsen has released the
Java source-code for his package called "Freebell".
  ( http://sf.net/projects/freebell ) .  Note - the source is in CVS -
   there isn't an "all-in-one single file" download package as yet.

  A _very_ nicely done piece of work !  I would like to convey my
thanks to Frank for the _huge_ effort he's put into this package!

  ( ... and thanks also to the developers on this group! )

   I just thought I'd do this post because Reb*l is such a cool
language that it deserves to be more widely used , and Freebell is a
great step in making that happen .... :-)

IN A WORD YES,

I've been buying a new house recntly and re-organizing my life in a big way so
i've not posted anything for a while but I still do LOTS of pertinent research &
studying language implementation / rebol & other related stuff.

Open Source REBOL is still very real & a big ambition of mine but I only have
lots of fragments / puzzle pieces to fit together into a coherent whole, it's a
big project for me , nobody else seems to have anything else to say either
recently.

more to come when I get more free time, promise you.

Mark Dickson


In a message dated Mon, 11 Feb 2002 11:37:42 AM Eastern Standard Time,
"dvandenberg2002" <dvandenberg@...> writes:

> Is this project still active?
>
>
>
> To unsubscribe from this list, send an email to:
>         OSCAR-PROJECT-unsubscribe@yahoogroups.com
> Project mailing list:
>         http://groups.yahoo.com/group/OSCAR-PROJECT
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Is this project still active?

On Fri, 14 Dec 2001 Robbo1Mark@... wrote:

> array datatype! variable size   ; == array datatype! []
> vector datatype! fixed size ; == vector datatype! []

Switch these two and it's fine. I think the term vector is often used to
mean resizable array.

> Array is a constructor for a fixed datatype! series
>
> Array: function [datatype [datatype!] data [block!] size [integer!]] [
> make array! datatype data size

Not sure about these, but I don't have a better suggestion ATM.

> == vector integer! [1 2 4]
> >> poke b 2 #"a"
> ** Script error: vector a is of type integer! not char!.
> ** near: poke b 2 #"a"

This looks good though.

> By the way, have I got my use of Vector and Array the correct
> way round?

Ah, nope. :-)

Marcus
------------------------------------
  If you find that life spits on you
  calm down and pretend it's raining

I've been doing a lot of thinking about the
types of series! PRIMO ought to have available
both for ease of use and efficiency.

Basically series! have three distinct attibutes
which determine their use and suitability for
various purposes.

These three attributes are as follows;

1. SIZE - fixed or variable

Can values be added or removed to the series?

2. TYPE - any-type! or fixed datatype!

Can values in series! be of any-type! as in the
current REBOL block! & paren! implementation or
are the values of a fixed type! as in REBOL's
any-string! types which contain only char! values.

3. MUTABILITY

Can the values in the series! be changed or are
they immutable? An immutable series! by definition
has a fixed length, it's value is it's value - period.

With this is mind I propose the following series
types for PRIMO which allow for creating series!
with meet various combinations of the series attributes
I mentioned above.

Here are the series! I propose with their attributes
and propsed syntax notation & constructors.


block! any-type! variable size  ; == []

array datatype! variable size   ; == array datatype! []

vector datatype! fixed size ; == vector datatype! []

immutable block! any-type! fixed size   ; == .[]

immutable vector datatype!  ; == vector datatype! .[]

string! variable size       ; == "" or {}

unicode-string! variable size   ; == u"" or u{}

immutable string! fixed size    ; == ."" or .{}

ditto for unicode-string!   ; == .u"" or .u{}


Array is a constructor for a fixed datatype! series
which has the possibility of variable size ie values
can be added or removed.

It's notation is as follows,

Array: function [datatype [datatype!] data [block!] size [integer!]] [

make array! datatype data size

]

example usage

>> a: array integer! [1 2 3] 3 ; note zero indexed
== array integer! [1 2 3]
>> pick a 2
== 3

Vector is a constructor for a fixed datatype! series
which has the property of fixed size ie values
cannot be added or removed, but elements can be changed
unless the vector is immutable.

Vector: function [datatype [datatype!] data [block!] size [integer!]] [

make vector! datatype data size

]

example usage

>> a: vector integer! .[1 2 3] 3 ; immutable data
== vector integer! .[1 2 3]
>> pick a 0
== 1
>> poke a 2 4
** Script Error: vector a has immutable data, cannot be changed.
** near: poke a 2 4
>> b: vector integer! [1 2 3] 3 ; data is mutable
== vector integer! [1 2 3]
>> poke b 2 4
== vector integer! [1 2 4]
>> poke b 2 #"a"
** Script error: vector a is of type integer! not char!.
** near: poke b 2 #"a"

I feel by having series! with varying attributes like these
should enable the selection of the most efficient or appropriate
use of storage to suit the program needs with regards to either
polymorphism or repeated operations on fixed or single datatype!

Let me know what you think?

By the way, have I got my use of Vector and Array the correct
way round?

Array - fixed datatype & variable size

Vector - fixed datatype & fixed size

All series! can be either mutable or immutable and identifiable
with the prefix-joined dot notation ie .[] or ."" etc.

Also a mutable? predicate

>> a: .[1 2 3]
== .[1 2 3]
>> type? a
== immutable block!
>> mutable? a
== false

cheers everybody,

Mark Dickson

PRIMO STRAW POLL / New Op!'s

Question:
Should paren!'s be necessary to enforce
correct evaluation order in PRIMO when
using infix operators?


examples of preferable behaviour?

>> a: 4
== 4
>> print (a + 2)
6
== unset
>> a:= (a + 2)
== 6
>> a
== 6
>> a:= add a 2
== 8
>> a
== 8


however is this correct behaviour?

>> a: 4 ; this part is obviously okay
== 4
>> print a + 2
4
** Script error: + expected val1 of type number! not unset!
** near: print a + 2
>> a:= a + 2    ; reset 'a to :a THEN perform addition?
== 6
>> a
== 4
>> a:= add a 2
== 6
>> a
== 6

Let me know what you all think about this.

Ladislav, I do like your idea very much for using
"word::" as syntax for reset-word! types and it does
type much easier, so Iam considering it deeply, however
Iam sticking to my original idea of := for these
examples, I also think := is more visually distinctive
on page / screen than :: and has some historical
precedence from other languages, but I DO like the
ergonomic properties of your suggestion so it is still
up in the air as far as final syntax goes, but.....

I've been using a bit of PIKE recently and it's great
for prototyping C, C++ type programs in an interpretative
manner and it has properties which enable me to play
about with ideas for series! block! arrays vectors etc.
for PRIMO as well as infix operators.

What do you think of additional infix op! functions that
have destructive binding properties like reset-word!'s do.
Iam think of the C like operators that C, C++, Perl, Python
and Pike all share, here's what Iam proposing,

>> a: 4
== 4
>> a += 5
== 9
>> a
== 9
>> a:= 0
== 0
>> a
== 0
>> a:= (a + 1)
== 1
>> preset-add a 5
== 6
>> a
== 6
>> a += 5   ; Infix op! += equivalent to preset-add word value.
== 11
>> a
== 11
>> postset-add a 5
== 11
>> a
== 16
>> a =+ 5   ; Infix op! =+ equivalent to postset-add word value.
== 16
>> a
== 21
>> a:= unset    ; same as to-unset a
== unset
>> a
** Script error: word a is an unset word, define word before use
** near: a
>> unset-word? a ; no need to quote word as func arg is a quoted 'value
== true

Viewed in this light, if these op!'s are acceptable then word:=
for reset-word! seems more in keeping with reset operators like
+= , -= , =+ etc.

Here's a full list of proposed op!'s with optional alternatives in
brackets to help ease people coming from other languages.

current op!'s

+ - * / ** (^) // (%) >= > = == < <= <> (!=) *see note below
and or xor

new op!'s

preset types perform action then return value

+= -= *= /= //= **= (^=) (%=)

postset types return existing word value then reset word
after peforming action.

=+ =- =* =/ =** =// (=^) (=%)

Interesting that the != for inequality is still lurking in REBOL
as anassignable infix op! value, see below.
>> !=: get to-word "<>"
>> 4 != 5
== true
>>

All the proposed new op!'s have their equivalent prefix functions.
+= or preset-add
=+ or postset-add
**= or preset-power
=** or postset-power

Might as well thrown in

Increment [value [word! number!]]
Decrement [value [word! number!]]

increment same as word += 1 or preset-add word 1
decrement same as word -= 1 or preset-subtract 1

note in these examples the :word must be a number!
for these funcs to work properly.

Anybody any comments?

cheers,

Mark Dickson

Surely this is incorrect?

>> a: has [b c] [ print b print c]
>> a
none
none
>> a/local 3 4
3
4

Surely local words default value should be unset
until they are defined?

Also in the second case is it correct to be
able to pass values to local words in this manner?

How is the above different from this....

>> use [b c] [print b print c]
** Script Error: b has no value
** Near: print b print c

Can somebody please explain the wisdom of this
or is it a bug?

cheers,

Mark Dickson

Hi Mark,

1) I would suggest you to dig into the LL languages conference, it is an
interesting reading (see Joe Marshall's posts).

2) Rebol has evolved since its 1.0 days and it is better now. It doesn't
resemble Scheme as much as it did. Its Contexts (having nothing in common
with Scheme) are powerful and useful.

3) My proposal is getting a little bit outdated these days, I should
actualize some things.

4) Tail recursion - this is a useful feature. I would suggest to reintroduce
it to the language, but it is necessary to have either first class errors or
no errors in the language like in Rebol 1.x to be able to do so. Moreover,
first class errors are a feature that is useful on its own, it would surely
make the interpreter less complicated and faster.

5) Unset - there are two possible orthogonal strategies. The first one is
the strategy where Unset is legal with *no* exceptions (like illegality of
get for unset words e.g.). Its advantage is, that it makes the interpreter
less complicated/faster (no built-in checks for Unset needed). This has got
its cost: no typo protection built into the language i.e. typos in words not
checked for.

My preferred strategy, which is orthogonal too, is to use the "back to the
future" possibility to make Unset illegal with *no* exceptions (similarly as
in Rebol 1.x). This has got the advantage/disadvantage of built-in checking
(the interpreter must check for unset words getting like it does now), but
this is a more human-centric approach to the programming - a computer must
do some work for the language to be more reliable. This approach would make
the language simpler for human users than the above.

Any other strategy is non-orthogonal, violates the principle of least
surprise and complicates the language.

6) I do like the approach to the Set-/Reset- and Local-/Global- issues. It
is the safest approach possible IMO. To be honest, there is one disadvantage
to it: it may need more checking - anytime you set/reset a word, the
computer should check, if the operation is legal. OTOH, the laguage will
have a pretty good protection mechanism built in.

7) I suggest to have only functions as word-active values, as opposed to the
current state (see http://www.sweb.cz/LMecir/interpret.html ), when even
paths, lit-paths, set-paths, parens, lit-words and set-words are defined as
word-active. This simplifies the language and removes some nasty crashes
present in the current Rebol interpreter.

8) The issue with the local words definition is, that a code like:

    do [i: 1]

should mean, that 'i wouldn't become global, but rather local to the block.
That is why to set global words, it might mean, that there would be only one
possible solution:

     do [set 'i 1]

After setting a word, the reset would of course work well in either case,
i.e. this would reset a global word:

     do [i:= 2]

(is anything wrong with i:: , I find that faster for typing), while here:

     do [
         i: 1
         do [
             i:= 2
         ]
     ]

we reset a local word.

(This is not the only possibility, but it is the most orthogonal one.)

----- Original Message -----
From: <Robbo1Mark@...>
To: <OSCAR-PROJECT@yahoogroups.com>
Sent: Friday, November 30, 2001 8:14 PM
Subject: [OSCAR Project] Words & Unset


Hello everybody,

Here a few more snippets on PRIMO design I've been
thinking about.

I often read Ladislav's writings on REBOL and share
a lot of concerns and appreciate his deep understanding
about many of the aspects and implications of REBOL
as it currently is.

Here, I would like to address certain aspects which
he pointed out in his excellent REBOL enhancement
proposal, and consider these fixes which address
some of the points he raised there.

First of all words & values.

Some Rules for PRIMO,

1. All words are local to the context they are
created in, including and especially functions.
No need to declare /locals, all local by default.

2. Ways of (re)Defining words.

>> Constant word value ; note value any-type! even unset

; note constants can NOT be changed and are immutable for
; the duration / lifetime of the porgram. Use with caution,
; they are CONSTANT and can not be changed once set.
: there is No contant-word! format, word must be explicitly
; defined as constant with the 'CONSTANT function.

>> set word value   ; note value any-type! even unset
>> word: value      ; set-word! format

; as per existing REBOL behaviour except the word arg
; can be of ordinary word format as it is quoted as a
; lit-word! in the function definition.

>> reset word value ; note value any-type! even unset
>> word:= value     ; reset-word! format

; If you try to 'Set a word that is already defined then
; this will raise an exception or fire an error! hence the
; need for a reset-word! type and 'reset function.
; I got this form from PICO language which defines and
; redefines words / variables in this manner.

>> unset        ; a value of type? == unset!
== unset
>> first reduce [()]
== unset

Proposal is to make UNSET a first class legal value which
can represent itself just as none represents a none! value.

The function UNSET will be replaced with a To-Unset word
function and also words can be Set or Reset to the unset value.

All words which are unset would still raise an exception or
fire an error! except for the special case word 'UNSET which
would represent the unset value of unset! type.

All this would need is an internal function to identify
words with unset values ( except of course for the word Unset)

see example code below for more examples...

unset-word?: func [ 'word ] [ pick [ true false]
(word? word) and (unset? get/any word) and ((mold word) <> "unset")]

>> x: 1
== 1
>> print x
1
>> loop 4 [ print x:= x + 1]
2
3
4
5
>> x: 2
** Script Error! word x already defined in this context
** Near x: 2
>> x:= 2
== 2
>> print x
== 2
>> x:= unset    ; unset is a first class value
== unset
>> type? get/any 'x
== unset!   ; unset! is the datatype
>> get/any 'x
== unset    ; unset the value
>> unset    ; unset used as a word! similar
== unset    ; to the way the word! none denotes itself
>> type? unset
== unset!
>> unset? unset
== true
>> word? unset
== false
>> word? 'unset
== true
>> unset? get/any 'x
== true


let me know what you think,

cheers,

Mark Dickson

Hello everybody,

Here a few more snippets on PRIMO design I've been
thinking about.

I often read Ladislav's writings on REBOL and share
a lot of concerns and appreciate his deep understanding
about many of the aspects and implications of REBOL
as it currently is.

Here, I would like to address certain aspects which
he pointed out in his excellent REBOL enhancement
proposal, and consider these fixes which address
some of the points he raised there.

First of all words & values.

Some Rules for PRIMO,

1. All words are local to the context they are
created in, including and especially functions.
No need to declare /locals, all local by default.

2. Ways of (re)Defining words.

>> Constant word value ; note value any-type! even unset

; note constants can NOT be changed and are immutable for
; the duration / lifetime of the porgram. Use with caution,
; they are CONSTANT and can not be changed once set.
: there is No contant-word! format, word must be explicitly
; defined as constant with the 'CONSTANT function.

>> set word value   ; note value any-type! even unset
>> word: value      ; set-word! format

; as per existing REBOL behaviour except the word arg
; can be of ordinary word format as it is quoted as a
; lit-word! in the function definition.

>> reset word value ; note value any-type! even unset
>> word:= value     ; reset-word! format

; If you try to 'Set a word that is already defined then
; this will raise an exception or fire an error! hence the
; need for a reset-word! type and 'reset function.
; I got this form from PICO language which defines and
; redefines words / variables in this manner.

>> unset        ; a value of type? == unset!
== unset
>> first reduce [()]
== unset

Proposal is to make UNSET a first class legal value which
can represent itself just as none represents a none! value.

The function UNSET will be replaced with a To-Unset word
function and also words can be Set or Reset to the unset value.

All words which are unset would still raise an exception or
fire an error! except for the special case word 'UNSET which
would represent the unset value of unset! type.

All this would need is an internal function to identify
words with unset values ( except of course for the word Unset)

see example code below for more examples...

unset-word?: func [ 'word ] [ pick [ true false]
(word? word) and (unset? get/any word) and ((mold word) <> "unset")]

>> x: 1
== 1
>> print x
1
>> loop 4 [ print x:= x + 1]
2
3
4
5
>> x: 2
** Script Error! word x already defined in this context
** Near x: 2
>> x:= 2
== 2
>> print x
== 2
>> x:= unset    ; unset is a first class value
== unset
>> type? get/any 'x
== unset!   ; unset! is the datatype
>> get/any 'x
== unset    ; unset the value
>> unset    ; unset used as a word! similar
== unset    ; to the way the word! none denotes itself
>> type? unset
== unset!
>> unset? unset
== true
>> word? unset
== false
>> word? 'unset
== true
>> unset? get/any 'x
== true


let me know what you think,

cheers,

Mark Dickson

Continuations are a too highlevel mean to do lowlevel tasks.
Scheme as a teaching language and in it's emphasis on "purity" and
"theoretical elegance" has a use for continuations because it is a good mean
to let students implement more complex control-flow things like exceptions or
threads in a language that is substantially higher than assembler.
In Common Lisp - which is a Lisp dialect coming after Scheme - the designers
(some were former Scheme designers) decided that it is a better idea to
provide such things like exception-handling and multithreading as
special-purpose implementation. Experience shows that if it is done in
specialized efficient code you can easily get a performance boost factor of
somewhere around 100.

ciao,
Jochen

Hello again everybody,

I've been away in Scheme world these last few weeks,
however I've subsequently greatly increased my understanding
of possible PRIMO / REBOL implementation methods.

It all started about a month ago when I was thinking about
REBOL and it language ancestry, Forth & Scheme are obvious
antecedents with lots of similar ideas & features, and indeed
REBOL creator Carl Sassenrath worked on implementations of
of both these language families earlier in his career.

I was also intrigued by certain features of ICON and their
similarity REBOL, but what also caught my attention was
some of the more powerful ICON functions / procedures like
the iterators & generators which have the ability to return
possibly multiple values, it's basis of goal directed evaluation
which our Ladislav is a big fan of if I'm correct? and also it's
co-expressions and co-routines which have the ability to be
suspended & also resume.

There was some synchronicity in this, as I also regularly follow
Python & Perl development, I read items on the new iterator &
generator constructs which are now available in Python 2.2 and
also some work being done on "microthreads" which are a very
lightweight threads implementation, much more lightweight than
other system or language threads, and are used for scalable multiple
concurrency  programming. I delved deeper into this and found out
than this had been partially incorporated into core Python from
some research work & implementations done in STACKLESS Python which
was inspired by certain features in ICON & SCHEME and based on a
programming construct called "CONTINUATIONS" which enable you to
do wierd & wonderful things with the control flow of a program.

Now I remembered that REBOL too had continuations once, back in
REBOL v1.x days, it also had tail-call optimisation too which enable
functional programming and deep recursion. I looked up one of the
early REBOL manuals from the "shoebox" at www.rebolforces.com and
found that this indeed was the case. This heightened my curiosity
and I decided to investigate this much deeper.

My query was / is this; If REBOL is so carefully designed, and as we
are often told Carl spent the best part of two decades formulating
his ideas & designs, IF Continuations were in REBOL originally it
must have been because Carl decided that they were an important
feature of the language, desirable enough that much was made of
REBOL having "first class continuations" and would soon also have
"pre-emptive multitasking", why then were these features dropped
from REBOL versions 2.x onwards?

That is a slightly rhetorical question, because I know the answers
which were given at that time, I started using REBOL either just before
or just after the change which was some time in 1998 if I remember
correctly. It was stated that REBOL was moving from a Scheme based
"Continuations" model of interpretation to be based on a Forth like
stack based engine for reasons of speed and efficiency. Without knowing
the implementation details, we can only speculate that this was because
REBOL Version 1 was comparatively slow and inefficient compared to
some other popular and available languages and RT Inc. being a commercial
company had to make the commercial decision to drop some pretty powerful
features for the sake of speed & efficiency if the language was to gain
any traction and uptake with users / developers.

My perspective is that this was a decision taken with one eye on the
commercial needs & imperatives of RT Inc. which needed to quickly
grow a user base to have any viability. If we divorce ourselves from
the commercial needs of RT Inc. and consider them a non issue on
technical grounds, which pursuing open source as interested parties or
hobbyists, and presumably able to sustain ourselves, we can "afford" to
take the long term view on these matters, are first class continuations
and tail-call optimisation desirable features for a language?

My view is that they are desirable, REBOL's designer obviously thought
so too and hence put them in REBOL in the first place.

My question was {Was it the "continuations model" that made REBOL version
ONE slow?} or was it a combination of the method in which continations
were originally implemented in REBOL as well as some other factors which
needed improved?

Larry Palmiter on the REBOL list, as well as some other people, have done
some benchmarking of REBOL against other languages, one of which was
DR SCHEME, which has first class continuations and tail call optimisation,
and whilst current REBOL performs quite well overall, DR Scheme beat or
equalled REBOL on certain functions / algorithms, and generally faired
quite well overall.  The conclusion that I drew from this was that it
was most probably then the implementation design used that made original
REBOL slower ( as well as probably some other implementation features
which needed fixed. )

I decided I should investigate deeply SCHEME implementations and have
immersed myself in SCHEME world for the past month, reading and studying
everything I can about the language, it's features and implementation.
I've discovered and learned lots of things. Firstly REBOL is indeed a
much prettier language and I'm glad I favoured REBOL style and syntax
over the antiquated LISPish syntax that Scheme has. Also REBOL has richer
datatypes and inbuilt internet capabilities which are a massive plus,
however that's about it. On everthing else SCHEME wins hands down, though
to be fair REBOL is less than five years old whreas Scheme is twenty five
years old and LISP is over forty years old, so much more is understood
and developed in these languages. The SCHEME resources are immense and
I've been reading voraciously and studying code of various aspect of
Scheme features and implementation techniques and standards.

Scheme is also favoured much in academia and much has been written
and implemented, with sources, on lots of the practical (and esoteric)
problems of computer languages and ther implementation.

What I soon learned that best performing SCHEME implementations are
Chez Scheme, PetiteChez Scheme & Dr Scheme / MzScheme. Other useful
implementaions are Systas scheme & R-scheme.

For alittle bit of background;

ChezScheme is a commercial implementation available from Cadence Research
and is based on a very fast incremental compiler, there is also the freely
available PetiteChez scheme which is a token threaded interpreter.
Source code is not available for either of these however their chief
designer and implementer is R. Kent Dibvig, formerly of Indiana University
and who is a leading Scheme luminary and who has written volumes of essays
and example of thier practical implementation, code examples, as well as
in depth analysis of continuations, recursion, macros, garbage collection,
compilers etc. etc. Of special interest are his writings on continuations
and multiple return values and concurrency on stack based interpreters.

Dr Scheme / MzScheme are an exellent open source implementation of a lot
of Kent Dybvig's implementation ideas and writings. Also of interest is
Systas Scheme by Tom Lord which is also open source free software with
implementation documentation. Tom Lord was previously a lead developer
and author on SCM sheme and GUILE the GNU project extension language
which is alos used in GNOME desktops.

So from all this I've learned a lot of useful implementation ideas for
PRIMO and how to bring back first class continuations and tail call
optimisation as useful control structures and language features.
With these all sorts of wonderful things become possible, here's a
short of the sort of functions and concurrency and control features
you can get ;
tail-recursion optimisation, iterators, generators, co-expressions,
co-routines, microthreads, exceptions & error handling, escape procedures,
one shot continuations,first class continuations,co-operative multitasking
pre-emptive multitasking.

As another piece of synchronicity, Joel Neely posted a piece on the REBOL
list about the Little Languages Conference, upon which reading it made
mention of Joe Marshall who helped implement a big part of original
REBOL which was described as Scheme with filed off parenthesis.

Continuations, back to the future............


cheers,

Mark Dickson

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the OSCAR-PROJECT
group.

   File        : /src-for-msdev6.zip
   Uploaded by : ldurigneux@...
   Description : Oscar 0.0.1 srcs and msdev6 pjt, with bin

You can access this file at the URL

http://groups.yahoo.com/group/OSCAR-PROJECT/files/src-for-msdev6.zip

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

ldurigneux@...

--- In OSCAR-PROJECT@y..., "Andrew Martin" <Al.Bri@x> wrote:
> marrowmilo wrote:
> > Revised   -Rebol    Coded/  Diagram
> >
> > |
> > | foreach
> > | example
> > | colors ->
> > |           | [if parse
> > |           | example
> > |           | [to "pink"
> > |           |   to end]->
> > |                           | -
> > |                           | print
> > |                           | example]]
> > |                           | ->
>
> That seems awfully time consuming. What's wrong with simply writing:
>
>         foreach Color Colors [
>             if parse Color [
>                 to "pink" to end
>                 ][
>                 print Color
>                 ]
>             ]
>     ?
>
> Note that I've Title-Cased the important words; changed
your 'example to
> 'Color to better reflect the Many contents of 'Colors and the
single nature
> of 'Color; and used consistent indenting.
>
> I hope that helps!
>
> Andrew Martin
> ICQ: 26227169 http://valley.150m.com/
> -><-


  ------------------------------------------------
H O W   T H E   R E B O L   S C R I P T   W O R K S ?
==================================================
Andrew : Thank you for your reply am now trying pseudcode
          to get some understanding of how the script works.
          Suggestions would be most welcome from you
          and fellow subscribers.
          - - - - - - - - - - - - - - - - - -
-----------------------------------------------------
P O S S I B L E  P S E U D O   C O D E
======================================
  { loop | foreach color in colors }
             if  [ not end color | true ]
                      if [color contains " pink" | true ]
                          print color
   { go to  loop }

--------------------------------------------------------
R E B O L
=========
colors: ["sun is red" "a pink rose" "gold coin" "a pink elephant"]
  foreach color colors [
  if parse color [ to "pink" to end]
  [print color]]
------------------------------------------------
>> colors: ["sun is red" "a pink rose" "gold coin" "a pink elephant"]
== ["sun is red" "a pink rose" "gold coin" "a pink elephant"]
>>  foreach color colors [
[     if parse color [ to "pink" to end]
[     [print color]]
a pink rose
a pink elephant
>>
-------------------------------------------------
foreach Color Colors [
             if parse Color [
                 to "pink" to end
                 ][
                 print Color
                 ]
             ]
  ------------------------------------------------
H O W   T H E   R E B O L   S C R I P T   W O R K S ?
==================================================
                 s o m e
  	  a l t e r n a t i v e s
	 p o s s i b i l i t i e s
	     c h o i c e s
================================================


	 "a pink rose"

	 "pink" 		 length (6 less 2)


	 " 		 start 2nd pass

	 a - p i false

	 - p i n false

	 p i  n k true

	 i n k -

	 n k - r

	 k - r o

	 - r o s

	 r o s e

	 " 		 end 2nd pass


---------------------------------------------------------
ANY SUGGESTIONS MOST WELCOME

TONY MARROW

marrowmilo wrote:
> Revised   -Rebol    Coded/  Diagram
>
> |
> | foreach
> | example
> | colors ->
> |           | [if parse
> |           | example
> |           | [to "pink"
> |           |   to end]->
> |                           | -
> |                           | print
> |                           | example]]
> |                           | ->

That seems awfully time consuming. What's wrong with simply writing:

         foreach Color Colors [
             if parse Color [
                 to "pink" to end
                 ][
                 print Color
                 ]
             ]
     ?

Note that I've Title-Cased the important words; changed your 'example to
'Color to better reflect the Many contents of 'Colors and the single nature
of 'Color; and used consistent indenting.

I hope that helps!

Andrew Martin
ICQ: 26227169 http://valley.150m.com/
-><-

Revised   -Rebol    Coded/  Diagram


|
| foreach
| example
| colors ->
|
|           | [if parse
|           | example
|           | [to "pink"
|           |   to end]->
|                           | -
|                           | print
|                           | example]]
|                           | ->



PART 1-

Sounds good, Daan. We're probably all looking forward to seeing your code.

On Mon, 5 Nov 2001, Daan Oosterveld wrote:

> A small example how I've implemented the datamodel so far in C++.
> The attachment is an PDF document of a class hierachy..

Sorry, but it's too little to give any real clue.

> In this model the values are fixed sizes.
> With exeption to complex or variable size values.

Figured as much. Did you comprehend enough of my "variable-size values"
ramblings to have an opinion about the issue?

Btw, there is a solution to the problem of how to throw away values with
block (which is automatic for contained values, but obviously not for
referenced ones). Just let value tables be local to containers. That's it.
Perhaps this was alreay obvious to others. :-/

I should probably try implementing these reference containers, when you
have released your code.

As for performance of reference blocks: While we lose some access speed
vs value blocks, we might gain some when manipulating (e.g sorting) them.
Also, reference blocks doesn't require as large continuous memory areas,
but on the other hand you need 4 extra ones to store the values in.

Reference blocks should be a win for storing small values (32 - 64 bits)
vs fixed value (128bit) blocks, but a loss for large values. It's hard to
predict which the general case is.

Marcus
------------------------------------
  If you find that life spits on you
  calm down and pretend it's raining

Have just been browsing in Python Land and have seen
how they deal with unicode chars & strings and low
and behold it seems that the "u" prefix is how they
solve the unicode syntax problem.

So to keep as much REBOL compatability as possible
for PRIMO here is my latest suggestions for PRIMO
syntax for chars & strings & unicode * immutables
etc.

>> type? #"A"
== char!

>> type? #'A"
== unicode-char!

>> type? ""     ; or {}
== string!  ; ascii

>> type? .""    ; or .{}
== immutable-string!

>> type? u""    ; or u{}
== unicode-string!


>> type? .u""   ; or .u{}
== immutable-unicode-string!

>> type? []
== block!

>> type? .[]
== immutable-block!

This way deeply quoted strings etc would work just as
they currently do in REBOL and much compatibility could
be retained.

Is everyone agreeable?

cheers,

Mark Dickson