• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

DocKimbel
5-Aug-2012
[862x2]
For example: 
    a: context [c: 123 d: b/e]
    b: context [e: 456  f: a/c]

cannot be compiled currently.
I could live without that feature for Red compiler, but it will help 
it be cleaner and easier to debug. Currently, I'm using prefixes 
to mark contexts for variables and function calls in Red compiler 
output code, I hope to be able to remove them and use contexts instead 
once I merge this new branch.
Kaj
5-Aug-2012
[864x2]
I was hoping the demands for Red would push more REBOL features into 
Red/System :-)
We'll get two great languages for the price of one, and one is already 
here
PeterWood
5-Aug-2012
[866]
That's fantastic.
Kaj
5-Aug-2012
[867x4]
Will it be possible to put #import's in a context?
Will there be something like USE or BIND to compile code referencing 
a particular context?
use gtk [view [label "dialect"]]
use [gtk zmq] [
	view label "dialect"
	send "message"
]
DocKimbel
6-Aug-2012
[871x2]
Yes, it will be possible to declare imported functions in contexts.
For your USE propoposition, that would be nice indeed. I'll look 
into it once contexts will be fully implemented.
Kaj
6-Aug-2012
[873]
Cool, thanks
DocKimbel
8-Aug-2012
[874]
Kaj: since latest commits in `namespaces` branch, you can now do:

ctx: context [
    #import [
        LIBM-file cdecl [
            sin: "sin" [
	    x           [float!]
	    return: [float!]
	]
        ]
    ]
]

print ctx/sin 1.0

;-)
Endo
8-Aug-2012
[875]
Cool!
Kaj
8-Aug-2012
[876]
Great!
Rebolek
9-Aug-2012
[877]
Is it/would it be possible to pass context as an argument to a function?
DocKimbel
9-Aug-2012
[878]
No, contexts in Red are not values, they don't exist at run-time.
Rebolek
9-Aug-2012
[879]
ok, thanks
DocKimbel
9-Aug-2012
[880]
sorry, I meant Red/System, in Red, contexts (wherever functions, 
objects or modules) are first class values.
Endo
9-Aug-2012
[881x2]
So, how scripting support wiil work?
oops, sorry I meant your previous comment: "they don't exist at run-time."
DocKimbel
11-Aug-2012
[883]
<from !Cheyenne group>


I'll have a look emitting the executable in the working directory 
this afternoon.
Kaj
11-Aug-2012
[884]
In Syllable, I repackage Red and Cheyenne in a package with a Unix-like 
structure, such as a separate subdirectory for the executable, but 
it gets cluttered because they find all their other files related 
to that executable. Actually, that's the way we want it to work for 
Syllable Desktop GUI applications, but for a console program that 
needs to be in the system path, you need the Unix structure with 
separate search paths for separate subdirectories
DocKimbel
11-Aug-2012
[885]
FEAT: added new WITH keyword for locally specifying implicit namespaces.

Usage: with <ns> [<body>]

    <ns>    : one or several block-enclosed namespace(s)

    <body> : code to execute within one or several implicit namespace

Example: 

    a: context [b: 123]
    with a [print b]
Kaj
11-Aug-2012
[886x2]
Nice, WITH would have been my other choice :-)
I suppose the first context has the highest priority?
BrianH
11-Aug-2012
[888x2]
I would expect that the nearest nested WITH would have priority.
So WITH would be like DO IN a [...] in R3.
DocKimbel
11-Aug-2012
[890]
first context has the highest priority

: the nearest nested WITH has the higher priority (implemented but 
not tested yet).


Also, when specifying a block of namespaces, the first one in the 
list has priority other the next one, and so on.
Kaj
11-Aug-2012
[891]
The latter is what I meant
BrianH
11-Aug-2012
[892]
Nice. I remember that being proposed for R3, but we went with DO 
IN instead. IN block block is still proposed though.
Kaj
11-Aug-2012
[893]
I was disappointed when that was rejected. I have a VM where I need 
to bind to dynamic stacks of contexts
BrianH
11-Aug-2012
[894]
DO IN was supposed to be the same as WITH, with only one extra space. 
However, IN block block wasn't implemented; IIRC it wasn't rejected, 
it was deferred, same thing at the moment I suppose.
Kaj
11-Aug-2012
[895]
I vaguely remember the blog at the time was about RESOLVE, not sure 
how that ties into IN
BrianH
11-Aug-2012
[896]
Deferred until it can be put in Red :)
Kaj
11-Aug-2012
[897]
Hear hear :-)
Steeve
11-Aug-2012
[898]
the IN block! block! is a must have at least. It's a pain in the 
ass to have to rebind the same block several times.
Kaj, I also worked on VMs and it was a shame.
Kaj
11-Aug-2012
[899]
Exactly
BrianH
11-Aug-2012
[900x2]
IN block word is used in the R3 GUI. It does the same context walk 
that Doc says WITH does, but only to retrieve a word.
The bug with RESOLVE is unrelated. Not sure if that is what you're 
talking about though.
Steeve
11-Aug-2012
[902x3]
What we need is to be able to rebind a block of code into several 
context in one time
*at one
I used several BIND in sequences. Not neat
Kaj
11-Aug-2012
[905]
Yes, I wondered how a language for constructing languages could make 
this omission
Steeve
11-Aug-2012
[906x2]
I show you some code. Follow the rebounds :-)
is: func [
		[catch]
		{Current face inherits from a block!}
		spec [block!]
		/local locals old when init
	][
		either all [
			find spec set-word!	; locals founds
			not empty? exclude  ; new ones (not found in the current face)

    first locals: construct copy spec ; copy: because [construct] modifies 
    the block (R2 bug ?)
				first face
		][

   ; Would be simpler, faster and safer using R3 (objects can be expanded)
			; rebuild face with new locals 

   ; (make face spec : can't be used here because of the special bounding 
   rules)

   when: face/when					; prevent copy/deep of when and init blocks
			init: face/init
			face/when: face/init: none
			set locals none

   resolve* locals face			; initialize locals with current face (if 
   intersect)

   face: make old: face locals		; rebuild current face with new locals
			face/when: when
			face/init: init
			do-safe bind bind spec face self; run style constructor 

   bind bind init face self		; rebound current face constructor (which 
   is currently running)

   error? set old :bound-err		; prevent old object from being used anymore
			old: none
		][
			; no new locals

   do-safe bind bind spec face self		; just run style's constructor 
		]
		if error throw-exit
	]
Kaj
11-Aug-2012
[908x2]
Brian, there was a blog about having RESOLVE, I think, walking a 
list of contexts, but Carl eventually decided that it wasn't needed 
"due to R3's new binding capablities"
Maybe it was about BIND directly
BrianH
11-Aug-2012
[910x2]
Probably. I'm having trouble imagining a use for RESOLVE doing that.
Maybe it could be used for some kind of multiple-prototyping of objects. 
Something like this:

>> resolve/extend context [] reduce [context [a: 1] context [a: 2 
b: 3]]
== make object! [
    a: 1
    b: 3
]