World: r4wp
[#Red] Red language group
| older newer | first last |
| 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 ;) |
| Kaj 11-Aug-2012 [916] | Object expansion is another one of those things. When you say objects can't be expanded, it sounds fair enough, but when you say contexts can't be expanded in a language meant to create languages, that's a serious limitation |
| DocKimbel 13-Aug-2012 [917] |
`system/words` virtual path support was added in today's commits,
to be able to get/set a global variable or call a function from within
namespaces with conflicting local names.
Example:
e: 123
a: context [
e: -1
print-line e
print-line system/words/e
system/words/e: 0
]
print-line e
will output:
-1
123
0
|
| Pekr 13-Aug-2012 [918] | is there aliasing possible? e.g. sys*: :system/words sys*/print |
| DocKimbel 13-Aug-2012 [919x3] | No, you can't do that. You can use macros for full paths if it's really required. Anyway, the use of system/words should be rare. |
It has been added just to make it possible to resolve conflicting cases. | |
I just need to upgrade Red/System specifications, improve the Red/System runtime with this new feature, and I'll be ready to merge this branch into master. I might also make a new global release (v0.2.6). | |
| Kaj 13-Aug-2012 [922] | That would be good. I'm now only updating the bindings for releases |
| Rebolek 14-Aug-2012 [923] | If some external library requires 64bit integer, but Red/System supports only 32 bit integers, how can I supply that number? Can I "cover" it with a struct? |
| DocKimbel 14-Aug-2012 [924] | If you need to pass a 64-bit integer as argument, currently you would need to split it in two integers and pass them instead. A struct is passed by reference, not by value (yet). |
| Kaj 14-Aug-2012 [925] | Couldn't you pack them in a float64!? |
| DocKimbel 14-Aug-2012 [926] | Yes, that should work too. |
| Rebolek 14-Aug-2012 [927] |
Nenad, can you give me an example, please? When the function requires
for example (pseudo-code):
pointer! [byte!] integer64! struct! ; data, index, metadata
how should I pass the integer64! value?
|
| DocKimbel 14-Aug-2012 [928x2] | Where do you get that integer64 value from? |
In your example, do you also need metadata to be passed by value? | |
| Rebolek 14-Aug-2012 [930] | Ok, no metadata, I was wrong. See http://www.mega-nerd.com/libsndfile/api.html#read sf_count_t is 64 bit integer. |
| DocKimbel 14-Aug-2012 [931] | If you need to make some 64-bit calculations as suggested by the description, it is more difficult to achieve, but not impossible. I think that Peter has coded some 64-bit addition and subtraction functions that operate on two 32-bit integers. |
| Kaj 14-Aug-2012 [932] | I'm testing the namespaces branch. I can't use CONTEXT as a local variable anymore. Is it necessary to reserve it that strongly? |
| PeterWood 14-Aug-2012 [933] | I found the issue with handling 64-bit integers in Red is the lack of support for unsigned integers. I only needed to 64-bit integers support on Windows so I used Lib calls in the end. |
| older newer | first last |