World: r4wp
[#Red] Red language group
| older newer | first last |
| 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
]
| |
| DocKimbel 11-Aug-2012 [912] | I haven't followed R3 contexts and binding evolutions, but as Red will use a slightly different model (more statical), I guess we'll come up with different solutions than with R2/R3. |
| Steeve 11-Aug-2012 [913] | Oh yeah, sorry to taint your thread Dock |
| BrianH 11-Aug-2012 [914] | WITH makes more sense for Red. DO IN is inherently more dynamic and runtime, while WITH can be more static. |
| DocKimbel 11-Aug-2012 [915] | Steeve: no problem ;) |
| older newer | first last |