World: r3wp
[Core] Discuss core issues
older newer | first last |
Fork 2-Apr-2008 [10078x5] | Erm... I still can't quite figure out how to conveniently get my assert routine to access the system/script/header from the caller, without writing: |
assert system/script/header 1 != 0 | |
I'd like some shorthand FOO so I don't have to type system/script/header each time, so I'd settle for: | |
assert FOO 1 != 0 | |
But if FOO is a function that lives in debug-functions.r then I'd need some parameter trick to access the calling context, the way bind uses a known-word for example. Is that the case? | |
BrianH 2-Apr-2008 [10083] | That won't work, even if you specify system/script/header at the call site, unless your assert statement is run during the execution of the script in question. Once a function is loaded, its source is gone - system/script/header refers to the currently running script. The only way to get your assert system working is with a preprocessor. |
Fork 2-Apr-2008 [10084] | Ah, well, I was thinking of doing that anyway. |
BrianH 2-Apr-2008 [10085x2] | REBOL doesn't have declarations - it has expressions that build functions and assign them to variables at runtime. |
You might consider extending prebol.r from the SDK - it has all of the preprocessing infrastructure built in. All you would have to do is add a #assert directive that would be replaced at preprocessing time with the info you want to log. | |
Fork 2-Apr-2008 [10087x2] | An option I considered was a refinement to assert, called /loc (for location) and let you pass in an identifying string for that assert. Then, a tool which goes through all the asserts in the code and if it doesn't have a location, add the refinement and a parameter based on a GUID. It will also make a database of file/lines for each location. Thereafter programmers can move them around without much trouble. |
Does R3 have guid! ?? | |
BrianH 2-Apr-2008 [10089x3] | You can make your own using binaries or strings, but nothing built in. |
Yet - user-defined datatypes aren't done yet. | |
In your case, filename, line and position on the line would probably be sufficient. | |
btiffin 2-Apr-2008 [10092x2] | Brian (fork); :) Check out rebol.org - pager.r for an attempt I made at keeping track of source line numbers. Again, some REBOL scripts are built without newlines. Best to keep index? values. imho. It's what I use for the word cross referencer I'm working on (forth style locate and tour) |
As far as I can figure, the only things in REBOL that cares doodle about newline is; the semi-colon comment, that newlines are retained in multi-line braced strings (and kinda in blocks) and a newline breaks a quoted string. | |
Fork 2-Apr-2008 [10094x2] | You can just call me Fork, that's fine, no offense taken. :) |
Seems to keep things clearer... and I can feel all hacker elite to be one of the few on here with a handle. :) | |
btiffin 2-Apr-2008 [10096] | Only add fork that time as this is a three-way Brian chat. :) |
RobertS 2-Apr-2008 [10097] | --[[ a Lua multi-line comment --]] but adding a hyphen as in ---[[ lets the commented block run and the --]] can remain in place as both bookends are now just -- single-line comments; really quite clever. Rebol could use ;{ and ;} where ;;{ opens up the 'commented' lines to run (not a block comment at that point) but leaves the 'markers' in place until debugging or profiling or unit test or whatever is completed; |
Henrik 3-Apr-2008 [10098x2] | dumb question: >> a: make object! [b: 'c] >> mold a == "make object! [^/ b: 'c^/]" ; c is lit >> mold/all a == "#[object! [^/ b: c^/]]" ; c is not lit I guess the question is why c is not lit for MOLD. It means that when you probe an object , words in an object appear lit, when they are really not. (Are they?) |
sorry, it should be "why is c lit for MOLD" | |
Anton 3-Apr-2008 [10100x4] | make evaluates the object spec block. Therefore, the lit-word is transformed into a word. |
mold/all, on the other hand, does not evaluate the object spec block. | |
compare probe load mold a probe load mold/all a | |
They both load the same. | |
Henrik 3-Apr-2008 [10104] | in your first reply, did you mean "mold evaluates the object spec block"? |
Anton 3-Apr-2008 [10105x2] | no, I definitely meant make. |
Try this: make object! [a: 1 + 2 print "hello"] | |
Henrik 3-Apr-2008 [10107] | then I don't understand: "mold/all, on the other hand, does not evaluate the object spec block.". should that not produce a lit-word in the object? |
Anton 3-Apr-2008 [10108x2] | You can see both the expression 1 + 2 and print "hello" are evaluated. |
Sorry, I meant when you evaluate the result of mold and mold/all. | |
Henrik 3-Apr-2008 [10110] | What doesn't make sense to me is that MOLD presents the lit-word. I don't really care that they mold and load the same and what is evaluated after MOLD. It's MOLD itself that bothers me. :-) |
Anton 3-Apr-2008 [10111x6] | Ok, first of all, trust me that the way it is is just perfect. Now, I have to think how to explain it well.. |
A first explanation attempt :- MOLD's basic task is to provide the specification for the value being molded, so that, when DOne you get the original value. MOLD/ALL's basic task is to provide the specification for the value being molded, so that, when LOADed, you get the original value. | |
The difference is, do [ make object! [...] ] will evaluate whatever is in the spec block, whereas do [ #[object! [...] ] will not, no matter how many times you try it. | |
The first one relies on 'make being evaluated as the default native MAKE function that we all know and love, and the second one does not. A simple load is all that is required to build the object. | |
MOLD/ALL works straight from the the object itself, whereas MOLD/ALL goes "back further", returning code which *produces* the specification. | |
The best explanation should probably come from a sound definition of mold and mold/all.... | |
Henrik 3-Apr-2008 [10117] | you wrote MOLD/ALL in both cases in the line above. |
Ingo 3-Apr-2008 [10118] | I guess you meant "MOLD goes back further" |
Henrik 3-Apr-2008 [10119] | As I read here, I understand it. I also think that it would have been better for MOLD/ALL to be called SERIALIZE, because it is not an extension of MOLD, but perhaps a different mode. But I bet that Carl already has thought about this. |
Anton 3-Apr-2008 [10120x2] | Ingo, yes. |
As I remember, there was some debate about what to call mold/all when it was developed. We could probably just search some archives to find out... | |
Gregg 3-Apr-2008 [10122x2] | SERIALIZE implies to me that there would be a target to serialize to, which is SAVE. |
i.e. SAVE/ALL | |
Anton 3-Apr-2008 [10124x2] | disagree - check the expression "serialise to disk" |
serialise means "turn into a series" ie. a string. That's all. | |
[unknown: 5] 4-Apr-2008 [10126x2] | I have been thinking about this for sometime. I'm thinking we need an alternative set of mezzanines for those that need performance and want to build something off the /base product. Problem with existing mezzanines is that they need to maintain backwards compatibilitiy which means we may lack some of the performance we might gain from a current alternative. The goal of the new set of mezzanines is to be driven from the most recent distribution of the REBOL platform R2. Obviously, R3 should be accomplishing this task inherently. |
However, would anyone use them? Or would they just code as needed if they are going to use the /base product anyway? | |
older newer | first last |