[REBOL] Andrew, you beast! - GC too tidy? Re:(9)
[EMAIL PROTECTED] wrote: > I've been informed by Bo, that the GC bug is one of the top ten bugs to fix > in Rebol. Hmm... I reported it sometime in August 1999, so it's taking time to fix it. ;-) Seriously, I'm sure there's some reason for it not being fixed yet; perhaps they'd need a rewrite of the GC to fix it? Jim? Regards, Gabriele. -- Gabriele Santilli <[EMAIL PROTECTED]> - Amigan - REBOL Programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[REBOL] Andrew, you beast! - GC too tidy? Re:(7)
This is the best comparison of Rebol to another language! Will it get turned into a webpage, so it can be put on the www.rebol.org links page? > >JB, you may not be familiar with REBOL history, but the 1.x >versions of REBOL were based on Scheme semantics. REBOL was >much slower back then, and had a larger executable, both the >result of using the Scheme model. I've got a copy of 1.0.3 >for Windows if you're curious. > >I have been using Scheme for about 8 years now and have done >my own Scheme compiler/interpreter, so I know what you mean >when you sing its praises. REBOL and Scheme are more similar >than you realize, though. For the most part you can simply >translate from Scheme to REBOL with no loss of functionality, >and more speed too. For example: > >First-class closures: >- Scheme: (set f (lambda (x) x + 1)) or (define (f x) x + 1) >- REBOL: f: func [x] [x + 1] > >Symbol/Object distinction: >- Both: 'symbol object > >Lexical scoping (other than in functions): >- Scheme: (let ((x 1) (y 2)) x + y) >- REBOL: use [x y] [x: 1 y: 2 x + y] >The "main" REBOL dialect implements lexical scoping as its >default behavior, just in a different way than Scheme does. >Scheme (interpreted) has dynamic binding, so all variables >are mapped to values in a lexical context, but symbols are >bound to variables at runtime, at every reference. With >REBOL the symbols are bound to variables once, before the >code is executed. Direct binding makes REBOL more similar >to compiled Scheme, even when it is interpreted. > >Fluid variables: Scheme needs this as a hack to get around >the limitations of lexical scoping. REBOL doesn't need them >because direct binding is much more powerful. > >Macros: With Scheme, code only looks like data, so it needs >a macro mechanism. With REBOL, code IS data, so there is no >distinction needed between macros and other functions. The >REBOL functions for code-building are more powerful too. > >Language and execution model: >- Scheme: Lisp-like lexically scoped language (conceptually) > built on a continuation engine - pretends to be stack-based > for implementation efficiency, at least if you avoid call/cc. >- REBOL: Unique, two-level language (dialects on data language) > built on a Forth-like stack engine for efficiency that Scheme > only gets after heavy optimization (sometimes not even then). > >Tail-recursion: Scheme has it (side effect of the continuation >engine, hacked when stacks are used); REBOL dropped it when it >switched to 2.x for efficiency reasons (whoops!). I guess you >have to use REBOL's extensive iterative functions instead. > >Continuations: Scheme has them (base of its execution model); >REBOL dropped these too when it switched to a stack engine. >Continuations don't make much sense with a stack engine - they >only work well when the execution model is continuation-based. >If you can't refactor your code to use callbacks or some such, >you probably don't understand it well enough to be programming >with continuations. Take a look at Icon - its goal-directed >evaluation beats continuations any day of the week. > >Numerics: REBOL is comparable to most Schemes, but that is only >because most Schemes don't implement the entire capabilities of >the Scheme standard. Most people don't do much numerics in an >interpreted language anyway, but I miss bignums :( > >List manipulation and data structures: REBOL does all of what >Scheme does, and usually does it faster. The map functions are >missing, but easily replaced, like replacing this: > (set y (map (lamda (x) x + 1) '(1 2 3))) >with this: > y: copy [1 2 3] > forall y [change y (first y) + 1] > y: head y >or if you really want map, you can make it easily yourself. >Other changes (mostly to factor out some recursion) are just >as easy to do. Most data manipulations are easier in REBOL. > >String manipulation and parsing: Throw your Scheme code away - >you'll never regret it. The incredible REBOL parse dialect gets >better every day - you'll wonder how you got by without it in >primitive languages like Scheme :) > >As for unified, formal approaches, well Scheme wins there. >REBOL is easily as unified as Scheme, but Scheme has been >formalized to death - no contest. Hey Gabriele, do you want to >help turn our context argument into a formal paper, tutorial >or something? Any one else up for papers? > >By the way, there is nothing about REBOL's GC problem that is >inherent in its execution model. It can be fixed, and it can >be avoided easily until it is fixed. As GC bugs go, I've seen >much worse than that. I'd still like it fixed, though :( > >Over all, I've found REBOL to be better at almost everything >Scheme is supposed to be good at, with few exceptions. Scheme >has been a great tool for years, but REBOL is much better. > >>Unsolicited $0.02, >> >>jb > >I think I've put in at least $0.04, no less unsolicited :) > >Brian Hawley > >
[REBOL] Andrew, you beast! - GC too tidy? Re:(8)
> b> By the way, there is nothing about REBOL's GC problem that is > b> inherent in its execution model. It can be fixed, and it can > b> be avoided easily until it is fixed. As GC bugs go, I've seen > b> much worse than that. I'd still like it fixed, though :( > > Yup. I assume they have a very good reason for not fixing it > (perhaps the new features promised by Carl?). I've been informed by Bo, that the GC bug is one of the top ten bugs to fix in Rebol. Andrew, Thanks for pointing out the problem with USE values getting recycled. This is already in our bug database and has been reported as one of our Top 10 bugs to development. I really appreciate that you took the time to submit this! Thanks for helping to make REBOL products better! REBOL Support Andrew Martin ICQ: 26227169 http://members.xoom.com/AndrewMartin/ -><-
[REBOL] Andrew, you beast! - GC too tidy? Re:(6)
Hi all! [EMAIL PROTECTED] wrote: >The current discussions of weirdnesses, idiosyncracies, and so forth >related to >scope, garbage collection, protection via USE, etc. are all verging around the >same space. With no disrespect intended to Carl or anyone on the Rebol team >(they're certainly tracing historical mistakes, Cf. McCarthy's early probs. >nailing the scope issue in Lisp) there is at lease one good system, very >similar >in many ways to Rebol, from which they could steal liberally: Scheme. It's >lexically scoped, has first-class closures which are in essence a >stronger, more >formal block, a fundamental symbol / object distinction, and GC... *very* >similar to Rebol indeed, but with a unified formal approach to scope, GC, >and so >on. It's a beautiful, simple, and powerful language that has never really >gone >mainstream due to its Lisp-like legacy and syntax, which most folks don't >grok. >IMO, Rebol could easily be the Scheme for the masses... but every little >idiosyncracy and gotcha -w- scope, GC, and so on will create adoption >friction. JB, you may not be familiar with REBOL history, but the 1.x versions of REBOL were based on Scheme semantics. REBOL was much slower back then, and had a larger executable, both the result of using the Scheme model. I've got a copy of 1.0.3 for Windows if you're curious. I have been using Scheme for about 8 years now and have done my own Scheme compiler/interpreter, so I know what you mean when you sing its praises. REBOL and Scheme are more similar than you realize, though. For the most part you can simply translate from Scheme to REBOL with no loss of functionality, and more speed too. For example: First-class closures: - Scheme: (set f (lambda (x) x + 1)) or (define (f x) x + 1) - REBOL: f: func [x] [x + 1] Symbol/Object distinction: - Both: 'symbol object Lexical scoping (other than in functions): - Scheme: (let ((x 1) (y 2)) x + y) - REBOL: use [x y] [x: 1 y: 2 x + y] The "main" REBOL dialect implements lexical scoping as its default behavior, just in a different way than Scheme does. Scheme (interpreted) has dynamic binding, so all variables are mapped to values in a lexical context, but symbols are bound to variables at runtime, at every reference. With REBOL the symbols are bound to variables once, before the code is executed. Direct binding makes REBOL more similar to compiled Scheme, even when it is interpreted. Fluid variables: Scheme needs this as a hack to get around the limitations of lexical scoping. REBOL doesn't need them because direct binding is much more powerful. Macros: With Scheme, code only looks like data, so it needs a macro mechanism. With REBOL, code IS data, so there is no distinction needed between macros and other functions. The REBOL functions for code-building are more powerful too. Language and execution model: - Scheme: Lisp-like lexically scoped language (conceptually) built on a continuation engine - pretends to be stack-based for implementation efficiency, at least if you avoid call/cc. - REBOL: Unique, two-level language (dialects on data language) built on a Forth-like stack engine for efficiency that Scheme only gets after heavy optimization (sometimes not even then). Tail-recursion: Scheme has it (side effect of the continuation engine, hacked when stacks are used); REBOL dropped it when it switched to 2.x for efficiency reasons (whoops!). I guess you have to use REBOL's extensive iterative functions instead. Continuations: Scheme has them (base of its execution model); REBOL dropped these too when it switched to a stack engine. Continuations don't make much sense with a stack engine - they only work well when the execution model is continuation-based. If you can't refactor your code to use callbacks or some such, you probably don't understand it well enough to be programming with continuations. Take a look at Icon - its goal-directed evaluation beats continuations any day of the week. Numerics: REBOL is comparable to most Schemes, but that is only because most Schemes don't implement the entire capabilities of the Scheme standard. Most people don't do much numerics in an interpreted language anyway, but I miss bignums :( List manipulation and data structures: REBOL does all of what Scheme does, and usually does it faster. The map functions are missing, but easily replaced, like replacing this: (set y (map (lamda (x) x + 1) '(1 2 3))) with this: y: copy [1 2 3] forall y [change y (first y) + 1] y: head y or if you really want map, you can make it easily yourself. Other changes (mostly to factor out some recursion) are just as easy to do. Most data manipulations are easier in REBOL. String manipulation and parsing: Throw your Scheme code away - you'll never regret it. The incredible REBOL parse dialect gets better every day - you'll wonder how you got by without it in primitive languages like Scheme :) As for unified, formal approaches, well Scheme wins there. REBO
[REBOL] Andrew, you beast! - GC too tidy? Re:(6)
Scheme is a great language. It inspired me more than 16 years ago, influenced my early designs... and got me into denotational semantics. But, Scheme was first invented in 1975... so now 25 years later, I suggest that there is a good reason why it is not in widespread use today. REBOL 1.0 was "Scheme". So we've been there, done that. For us, it was a disaster. REBOL 2.0 (non Scheme based) is smaller and 30 times faster. Yes there are some cool things you can do in Scheme. But they cost you too much. Unfortunately, history has also proven the success of a language has nothing to do with the merits of good language design. Look at C++, BASIC, or even HTML as examples. -Carl PS: the scoping rules for REBOL are very simple. Also, the issues around object scoping have not been solved by any language that I know. Not even Scheme. At 6/16/00 03:30 PM -0500, you wrote: > >Good thoughts, Chaz. I think, though, dialects would not be a particularly >helpful. Scoping rules are deeply intrinsic to programming languages and their >implementations. I doubt the problem could be fixed while preserving backwards >semantic compatibility. However, the world of Rebol scripts still to write is >much larger than the world of scripts already written, so now would be the time >to make any fundamental changes. > >The current discussions of weirdnesses, idiosyncracies, and so forth related to >scope, garbage collection, protection via USE, etc. are all verging around the >same space. With no disrespect intended to Carl or anyone on the Rebol team >(they're certainly tracing historical mistakes, Cf. McCarthy's early probs. >nailing the scope issue in Lisp) there is at lease one good system, very similar >in many ways to Rebol, from which they could steal liberally: Scheme. It's >lexically scoped, has first-class closures which are in essence a stronger, more >formal block, a fundamental symbol / object distinction, and GC... *very* >similar to Rebol indeed, but with a unified formal approach to scope, GC, and so >on. It's a beautiful, simple, and powerful language that has never really gone >mainstream due to its Lisp-like legacy and syntax, which most folks don't grok. >IMO, Rebol could easily be the Scheme for the masses... but every little >idiosyncracy and gotcha -w- scope, GC, and so on will create adoption friction. > >Unsolicited $0.02, > >jb > >[EMAIL PROTECTED] wrote: > >> At 07:34 AM 6/16/00 +0200, you wrote: >> > >> > >> >[EMAIL PROTECTED] wrote: >> > >> >> Just a thought most of the "philosophical" questions / discussions >> here >> >> about i.e. object lifecycle, scope, bindings, etc. would be simply, >> >> formally, and workably solved if Rebol had a true lexical scoping model. >> As >> >> it is, it's sort of the worst of both worlds: it's semi-fluid scope with >> >> explicit manipulation coupled with a sort of hybrid object / object >> >> lifecycle model that is never really formally elaborated. Without knowing >> >> the internal nitty gritty of the implementation, it's hard to say if >> this is >> >> endemic to Rebol or not, but looking at i.e. the potential solutions to >> >> similar problems in early Lisps vs. Scheme, I'd say there's a whole lot of >> >> good reasons for solving the problem now. >> > >> >Just a note - isn't it too late, if two book on REBOL are already finished? >> >Elan, Ralph? :-) >> > >> >-pekr- >> >> Not too late, if solution is implemented correctly. Since the strength of >> Rebol is dialecting, then we should maintain backward compatibility through >> dialects. Rebol/Core 2.x scripts would not break if there was a "2.0 >> dialect" included with Rebol/Core 3.x. >> >> RT needs more staff and money, so Core team can focus on philosophical >> issues, and special task forces can focus on integrating Core with other >> technologies (Graphics = /View, OS and Databases = /Command, WebServer = >> /Apache). >> >> By overcoming implementation challenges, the task forces gain knowledge >> that they can bring back to /Core that will empower RT to overcome new >> challenges when integrating into other technologies (imagine >> multiprocessing = /Beowulf, Home Automation = /Base, streaming media and >> telephony = /Yell) >> >> But the real money may be in business-to-business. Imagine your company has >> developed an incredible software product whose functionality can be >> extended through use of a C API. Users would much rather have an easier >> means than going through a write-compile-test cycle to extend the product's >> functionality. If Rebol was integrated into the product, then user >> productivity would skyrocket. >> Case in point, Remedy Corporation has a workflow product called Action >> Request System (ARS). The 2 means of accessing its power are through a GUI >> and the ARS C API. At the State University of New York at Buffalo, users >> created ARSPerl, a perl module that encapsulates the function of the Remedy >> ARS C API. To my way of thinking, they tu
[REBOL] Andrew, you beast! - GC too tidy? Re:(5)
Good thoughts, Chaz. I think, though, dialects would not be a particularly helpful. Scoping rules are deeply intrinsic to programming languages and their implementations. I doubt the problem could be fixed while preserving backwards semantic compatibility. However, the world of Rebol scripts still to write is much larger than the world of scripts already written, so now would be the time to make any fundamental changes. The current discussions of weirdnesses, idiosyncracies, and so forth related to scope, garbage collection, protection via USE, etc. are all verging around the same space. With no disrespect intended to Carl or anyone on the Rebol team (they're certainly tracing historical mistakes, Cf. McCarthy's early probs. nailing the scope issue in Lisp) there is at lease one good system, very similar in many ways to Rebol, from which they could steal liberally: Scheme. It's lexically scoped, has first-class closures which are in essence a stronger, more formal block, a fundamental symbol / object distinction, and GC... *very* similar to Rebol indeed, but with a unified formal approach to scope, GC, and so on. It's a beautiful, simple, and powerful language that has never really gone mainstream due to its Lisp-like legacy and syntax, which most folks don't grok. IMO, Rebol could easily be the Scheme for the masses... but every little idiosyncracy and gotcha -w- scope, GC, and so on will create adoption friction. Unsolicited $0.02, jb [EMAIL PROTECTED] wrote: > At 07:34 AM 6/16/00 +0200, you wrote: > > > > > >[EMAIL PROTECTED] wrote: > > > >> Just a thought most of the "philosophical" questions / discussions > here > >> about i.e. object lifecycle, scope, bindings, etc. would be simply, > >> formally, and workably solved if Rebol had a true lexical scoping model. > As > >> it is, it's sort of the worst of both worlds: it's semi-fluid scope with > >> explicit manipulation coupled with a sort of hybrid object / object > >> lifecycle model that is never really formally elaborated. Without knowing > >> the internal nitty gritty of the implementation, it's hard to say if > this is > >> endemic to Rebol or not, but looking at i.e. the potential solutions to > >> similar problems in early Lisps vs. Scheme, I'd say there's a whole lot of > >> good reasons for solving the problem now. > > > >Just a note - isn't it too late, if two book on REBOL are already finished? > >Elan, Ralph? :-) > > > >-pekr- > > Not too late, if solution is implemented correctly. Since the strength of > Rebol is dialecting, then we should maintain backward compatibility through > dialects. Rebol/Core 2.x scripts would not break if there was a "2.0 > dialect" included with Rebol/Core 3.x. > > RT needs more staff and money, so Core team can focus on philosophical > issues, and special task forces can focus on integrating Core with other > technologies (Graphics = /View, OS and Databases = /Command, WebServer = > /Apache). > > By overcoming implementation challenges, the task forces gain knowledge > that they can bring back to /Core that will empower RT to overcome new > challenges when integrating into other technologies (imagine > multiprocessing = /Beowulf, Home Automation = /Base, streaming media and > telephony = /Yell) > > But the real money may be in business-to-business. Imagine your company has > developed an incredible software product whose functionality can be > extended through use of a C API. Users would much rather have an easier > means than going through a write-compile-test cycle to extend the product's > functionality. If Rebol was integrated into the product, then user > productivity would skyrocket. > Case in point, Remedy Corporation has a workflow product called Action > Request System (ARS). The 2 means of accessing its power are through a GUI > and the ARS C API. At the State University of New York at Buffalo, users > created ARSPerl, a perl module that encapsulates the function of the Remedy > ARS C API. To my way of thinking, they turned to Perl because RT wasn't > there to save them. What other opportunities might RT missing?
[REBOL] Andrew, you beast! - GC too tidy? Re:(6)
> The most detailed documentation for REBOL direct binding and > contexts that I've seen is an argument on the subject that > Gabriele and I had on this mailing list last fall. It is probably in the mailing list archives at rebol.org with the > subject Contexts. If not, tell me and I'll try to bundle them > and send them to you. Brian I would be interested in these as I have not been able to find the messages your referred to. Brett Handley.
[REBOL] Andrew, you beast! - GC too tidy? Re:(5)
[EMAIL PROTECTED] wrote: > >Just a note - isn't it too late, if two books on REBOL are already finished? > >Elan, Ralph? :-) > > > >-pekr- > > Not too late, if solution is implemented correctly. Since the strength of > Rebol is dialecting, then we should maintain backward compatibility through > dialects. Rebol/Core 2.x scripts would not break if there was a "2.0 > dialect" included with Rebol/Core 3.x. > Would be a kludge but why not if we would gain by such change? > RT needs more staff and money, so Core team can focus on philosophical > issues, and special task forces can focus on integrating Core with other > technologies (Graphics = /View, OS and Databases = /Command, WebServer = > /Apache). Exactly. IIRC those were the words of someone from RT - there are many issues that could be implemented/refined for /Core - so why to shut it down and concentrate on higher level eye candy? I think "true rebollers" would be much more interested in things like /shell and /library becoming native part of /Core - so free, tasking/threading, ability to link two even remote rebols thru system object (e.g. system/family, if we have faces, feelings, etc.) Wouldn't it be great? Current aproach of everything-in-one-exe is advantage, but how long for? I hope we will see some /Math, /Draw, /Whatever in the future. I don't think there is the reason to stop ourselves at current point. It would mean just one thing - death to rebol. I know there is time you have to go out with what you have, then sort your thoughts, and make a next logical step. I would like to believe Carl will balance RT's current marketing aproach (just-one-file philosophy) with request of let's say majority of opinions expressed here - so modularity, granularity, openess, etc.etc RT folks are silent, but carefully watching us Just a little test heya, Jeffy, I like your long hair ;-))) > By overcoming implementation challenges, the task forces gain knowledge > that they can bring back to /Core that will empower RT to overcome new > challenges when integrating into other technologies (imagine > multiprocessing = /Beowulf, Home Automation = /Base, streaming media and > telephony = /Yell) > > But the real money may be in business-to-business. Imagine your company has > developed an incredible software product whose functionality can be > extended through use of a C API. Users would much rather have an easier > means than going through a write-compile-test cycle to extend the product's > functionality. If Rebol was integrated into the product, then user > productivity would skyrocket. > Case in point, Remedy Corporation has a workflow product called Action > Request System (ARS). The 2 means of accessing its power are through a GUI > and the ARS C API. At the State University of New York at Buffalo, users > created ARSPerl, a perl module that encapsulates the function of the Remedy > ARS C API. To my way of thinking, they turned to Perl because RT wasn't > there to save them. What other opportunities might RT missing? Yes, we are building CCD camera and I still think our main app will be created in rebol, supplied by modules in native libraries. We will not create scripting environment for some Delphi, VB, C++ project, as we will be complete glue technology powered by rebol - complete freedom in user environment creation (we will just need some specific /View and /Command functionality, but I am not so far yet ...) Cheers, -pekr-
[REBOL] Andrew, you beast! - GC too tidy? Re:(5)
[EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>
> > Hello [EMAIL PROTECTED]!
> >
> > On 16-Giu-00, you wrote:
> >
> > j> Just a thought most of the "philosophical" questions /
> > j> discussions here about i.e. object lifecycle, scope, bindings,
> > j> etc. would be simply, formally, and workably solved if Rebol
> > j> had a true lexical scoping model. As it is, it's sort of the
> >
> > If you by lexical scoping intend that of C/C++ etc. (I'm not very
> > familiar with language theory terms), then I vote AGAINST that.
> > REBOL's static binding is FAR more powerful (and simple!) than
> > lexical scoping.
>
>Cf. Scheme. In particular, check out the flexibility you get in
>building i.e. custom object systems, dispatchers, etc. when you couple
>lexical scoping with first-class closures. (Which we have a base for,
>sort of, in blocks.)
I come from a strong Scheme background, and I've found that
REBOL is already well suited for applying Scheme techniques.
It already has first-class closures (func is a function, you
know), and is much better at the data-as-code trick than you
could ever manage in Scheme.
Lexical scoping is emulated quite well as an intended side
effect of REBOL's direct binding mechanisms. Direct binding
is much more powerful than that though, allowing easy access
to multiple lexical contexts without having to jump through
the hoops that Scheme requires.
The most detailed documentation for REBOL direct binding and
contexts that I've seen is an argument on the subject that
Gabriele and I had on this mailing list last fall. It is
probably in the mailing list archives at rebol.org with the
subject Contexts. If not, tell me and I'll try to bundle them
and send them to you.
Here's an example of a function in REBOL that uses its first
class closure capabilities. It's a replacement for Andrew's
include function that I wrote a while ago when I needed it
to be more robust. Sorry if it's a little long, but it was
easier to cut-and-paste a practical example than to come up
with a trivial example on the fly :)
One of the settings in the header is significant, so save
this script to a file and do it from there.
REBOL [
Title: "Script Requirements Manager"
Date: 18-May-2000
File: %require.r ; Used internally, see source for details.
Author: "Brian Hawley"
Email: [EMAIL PROTECTED]
Rights: "Copyright (C) Brian Hawley 2000, rights under LGPL"
Version: 0.1.0
Purpose: "Manages script dependencies and current versions"
Comment: trim/auto {
Require manages script dependencies in a way similar to
C/C++ #include but limiting inclusion to only a single time,
or optionally when the script has been modified. The list of
included scripts will be carried over if you do or require
%require.r again.
This script demonstrates a technique for implementing static
local variables, initialized using compose, and some other
fun tricks.
See http://www.bigfoot.com/~brian.hawley/rebol/ for updates.
}
Category: [script advanced]
]
unprotect 'require
require: func [
"Runs a script or scripts if not included yet, or perhaps if new."
[catch]
scripts [file! url! block!] "The script(s) required."
/yet? "Check when a script has been included (none if never)."
/new "Update if script has changed."
/list-scripts "Return a copy of the list of included scripts."
/local script-list stime iref itime e
] compose [
comment "The list of included scripts, modified in place."
script-list: (
; Carry over existing list of included scripts, if any
if not all [
; Check for an existing list
block? require: try [require/list-scripts []]
; Test the integrity of the list
even? length? require: head require
foreach [f d] require [
either all [
any [file? :f url? :f] date? :d
] [true] [break/value false]
]
] [require: []]
; Add the current script to the list
use [f d] [
f: clean-path system/script/header/file
if date? d: try [modified? f] [
change any [find/last require f tail require] reduce [f d]
]
]
; Return the list
reduce [require]
)
; Handle list query operations, if any
if yet? [
return either block? scripts [none] [
pick any [
find/last script-list clean-path scripts tail script-list
] 2
]
]
; Deal with the single case
if not block? scripts [scripts: reduce [scripts]]
; Include file/url list
foreach script scripts [
if all [
if any [file? :script url? :script] [script: clean-path script]
date? stime: try [modified? script]
any [
itime
[REBOL] Andrew, you beast! - GC too tidy? Re:(4)
[EMAIL PROTECTED] wrote: > Hello [EMAIL PROTECTED]! > > On 16-Giu-00, you wrote: > > j> Just a thought most of the "philosophical" questions / > j> discussions here about i.e. object lifecycle, scope, bindings, > j> etc. would be simply, formally, and workably solved if Rebol > j> had a true lexical scoping model. As it is, it's sort of the > > If you by lexical scoping intend that of C/C++ etc. (I'm not very > familiar with language theory terms), then I vote AGAINST that. > REBOL's static binding is FAR more powerful (and simple!) than > lexical scoping. Cf. Scheme. In particular, check out the flexibility you get in building i.e. custom object systems, dispatchers, etc. when you couple lexical scoping with first-class closures. (Which we have a base for, sort of, in blocks.) jb > > > Regards, > Gabriele. > -- > Gabriele Santilli <[EMAIL PROTECTED]> - Amigan - REBOL programmer > Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[REBOL] Andrew, you beast! - GC too tidy? Re:(4)
At 07:34 AM 6/16/00 +0200, you wrote: > > >[EMAIL PROTECTED] wrote: > >> Just a thought most of the "philosophical" questions / discussions here >> about i.e. object lifecycle, scope, bindings, etc. would be simply, >> formally, and workably solved if Rebol had a true lexical scoping model. As >> it is, it's sort of the worst of both worlds: it's semi-fluid scope with >> explicit manipulation coupled with a sort of hybrid object / object >> lifecycle model that is never really formally elaborated. Without knowing >> the internal nitty gritty of the implementation, it's hard to say if this is >> endemic to Rebol or not, but looking at i.e. the potential solutions to >> similar problems in early Lisps vs. Scheme, I'd say there's a whole lot of >> good reasons for solving the problem now. > >Just a note - isn't it too late, if two book on REBOL are already finished? >Elan, Ralph? :-) > >-pekr- Not too late, if solution is implemented correctly. Since the strength of Rebol is dialecting, then we should maintain backward compatibility through dialects. Rebol/Core 2.x scripts would not break if there was a "2.0 dialect" included with Rebol/Core 3.x. RT needs more staff and money, so Core team can focus on philosophical issues, and special task forces can focus on integrating Core with other technologies (Graphics = /View, OS and Databases = /Command, WebServer = /Apache). By overcoming implementation challenges, the task forces gain knowledge that they can bring back to /Core that will empower RT to overcome new challenges when integrating into other technologies (imagine multiprocessing = /Beowulf, Home Automation = /Base, streaming media and telephony = /Yell) But the real money may be in business-to-business. Imagine your company has developed an incredible software product whose functionality can be extended through use of a C API. Users would much rather have an easier means than going through a write-compile-test cycle to extend the product's functionality. If Rebol was integrated into the product, then user productivity would skyrocket. Case in point, Remedy Corporation has a workflow product called Action Request System (ARS). The 2 means of accessing its power are through a GUI and the ARS C API. At the State University of New York at Buffalo, users created ARSPerl, a perl module that encapsulates the function of the Remedy ARS C API. To my way of thinking, they turned to Perl because RT wasn't there to save them. What other opportunities might RT missing?
[REBOL] Andrew, you beast! - GC too tidy? Re:(3)
[EMAIL PROTECTED] wrote: > Just a thought most of the "philosophical" questions / discussions here > about i.e. object lifecycle, scope, bindings, etc. would be simply, > formally, and workably solved if Rebol had a true lexical scoping model. As > it is, it's sort of the worst of both worlds: it's semi-fluid scope with > explicit manipulation coupled with a sort of hybrid object / object > lifecycle model that is never really formally elaborated. Without knowing > the internal nitty gritty of the implementation, it's hard to say if this is > endemic to Rebol or not, but looking at i.e. the potential solutions to > similar problems in early Lisps vs. Scheme, I'd say there's a whole lot of > good reasons for solving the problem now. Just a note - isn't it too late, if two book on REBOL are already finished? Elan, Ralph? :-) -pekr- > > > jb > > [EMAIL PROTECTED] wrote: > > > Nicely described Galt :) > > > > > I suppose it means you > > > can bind a block to another block or word > > > and it will share the context of that other > > > block. I wonder what would happen if you > > > unset O at this point. Could you still > > > run Dialect and have it bind and reduce another block > > > to what O was bound to? > > > > Tried it, yup it will and it won't work. > > > > It will for a bit until the garbage collector takes away O. > > > > Try > > > > Create O as in the example. > > > > Dialect [f1 f2] ; --Ok > > Unset 'O ; -- oh oh , could be trouble coming > > > > Dialect [f1 f2] ; --Still worksPhew. > > > > Recycle; > > Dialect [f1 f2] ; * Crash * -- Looks like the GC was a bit enthusiastic.
[REBOL] Andrew, you beast! - GC too tidy? Re:(2)
Just a thought most of the "philosophical" questions / discussions here about i.e. object lifecycle, scope, bindings, etc. would be simply, formally, and workably solved if Rebol had a true lexical scoping model. As it is, it's sort of the worst of both worlds: it's semi-fluid scope with explicit manipulation coupled with a sort of hybrid object / object lifecycle model that is never really formally elaborated. Without knowing the internal nitty gritty of the implementation, it's hard to say if this is endemic to Rebol or not, but looking at i.e. the potential solutions to similar problems in early Lisps vs. Scheme, I'd say there's a whole lot of good reasons for solving the problem now. jb [EMAIL PROTECTED] wrote: > Nicely described Galt :) > > > I suppose it means you > > can bind a block to another block or word > > and it will share the context of that other > > block. I wonder what would happen if you > > unset O at this point. Could you still > > run Dialect and have it bind and reduce another block > > to what O was bound to? > > Tried it, yup it will and it won't work. > > It will for a bit until the garbage collector takes away O. > > Try > > Create O as in the example. > > Dialect [f1 f2] ; --Ok > Unset 'O ; -- oh oh , could be trouble coming > > Dialect [f1 f2] ; --Still worksPhew. > > Recycle; > Dialect [f1 f2] ; * Crash * -- Looks like the GC was a bit enthusiastic.
[REBOL] Andrew, you beast! - GC too tidy? Re:(2)
:-) It would be really, really nice if Rebol's Garbage Collector worked properly. :-( Andrew Martin ICQ: 26227169 http://members.xoom.com/AndrewMartin/ -><-
[REBOL] Andrew, you beast! - GC too tidy? Re:
Nicely described Galt :) > I suppose it means you > can bind a block to another block or word > and it will share the context of that other > block. I wonder what would happen if you > unset O at this point. Could you still > run Dialect and have it bind and reduce another block > to what O was bound to? Tried it, yup it will and it won't work. It will for a bit until the garbage collector takes away O. Try Create O as in the example. Dialect [f1 f2] ; --Ok Unset 'O ; -- oh oh , could be trouble coming Dialect [f1 f2] ; --Still worksPhew. Recycle; Dialect [f1 f2] ; * Crash * -- Looks like the GC was a bit enthusiastic.
