AltME groups: search

for example, if I want to do a real time debugger which shows me 
the current content of the block which is being stepped through by 
a loop... 

I can't since I can't get access to the block which is being used 
by that function...

Yes Maximn, to do runtime debugging, we must be allowed to construct 
observable functions

we could be able to do this by switching to a "debug" version of 
the various func creating mezz

Now you have to circumvent it, at the cost of having longer code. 
I suppose, that the not simplified code is more like:


f: func [] [error? try [do-something return 1] return 2], which can 
be transformed to:

f: func [] [return either error? try [do-something] [1] [2]]

_I_ won't. People in general might well be able to do so.

The header changes in A108 will be ignored by A107, and the old settings 
will be ignored by A108, so if you want to have transitional code 
you can use both. The only change that I know is not automatically 
adjusted for is the isolate: true header, so if you need that and 
want it to also be compatible with A108 then also include options: 
[isolate]. And you don't need to use type: 'extension anymore, type: 
'module will do (in either version). Don't use the word 'hidden in 
your modules though, at least not at the top level - hidden will 
be a new keyword in module code, like export.

Yes, but you would have to do half of the compression anyway.

others do both and don't get the time to release  them  ;-)

Just a little tidbit I thought might be good for others still resisting 
the dark side of the force (R3 :-)


I'm at a point where I'm 50:50 in my time spend on R2 and R3 overall. 
which is a nice observation.

ATM, I much prefer R3 for many reasons.

-binding control and dynamic code building is soooo much better.
-embeded modules
-extensions which can (at last) almost do anything with REBOL.

-being able to fix/understand some limitations myself by "looking 
under the hood".

-it really is much better designed, scalable, fast, consistent and 
more.

why is R3 the dark-side?
-it constantly tempts you, 

-promises power (which it ultimately delivers, after kicking you 
in the nuts a few times), 

-allows much easier access to evil dlls (dark lawless libraries) 
than R2, 

-can be a lot more harsh finding your errors, but then removes guilt 
by disarming them 
-some unexpected issues still make it highly temperamental. 
-it will actually KILL your app with mush less discrimination 

-DOS shell makes it a trial by pain experience (and no, making its 
bg color white doesn't changes this ;-)

You can already build a better shell with the hostkit :) Until someone 
actually gets annoyed enough to do this, it's probably easiest to 
just install a "proper" shell, maybe along with rlwrap.

Pekr, we can write an R2-style console app with the hostkit. It's 
just that someone needs to actually do it :)

Damn, do I really have to fire up a Windows VM just to test if this 
is really possible right now :) ?

Sunanda, you wrote, that INF support was good, not mentioning why. 
Can you explain, why do you want to have it?

I really like how you've evolved the system and its doing all of 
what I wanted slim to do minus one or two little things, which I 
can easily graft over modules as they are .

If you want the reloading, use DO. DO works on scripts and modules 
both, and does them every time. It even tries to import the module 
after it is created. This is everything that you were requesting 
out of reloads. What it won't do is override a loaded module in the 
module list that is the same version or newer, but you can import 
those directly using IMPORT options.

What /no-lib does is converts a module to a private module. It does 
a full import directly into the user context instead of importing 
through lib. It doesn't even go into the system modules list as a 
reusable prebuilt module, which named private modules otherwise do.

...approaches extend from INF always throws an error to INF is a 
first class value. Somwhere in the middle is INF acting like UNSET!...

 - I do not think this describes the situation. I see it differently, 
 thinking, that there are only two consistent alternatives (the current 
 state is inconsistent, as everybody agrees with):


1) inifinities are not REBOL values (this state existed before FP 
pairs were introduced). I am pretty sure, that the description "INF 
always throws an error" is misleading, exactly because such a value 
does not even exist in REBOL


2) infinities exist in REBOL. In this case, they have to be "first 
class values", but, of course, they are not handleable by all functions, 
since e.g. +INF + -INF is not defined

supporting infinity opens up a can of worms IMHO.  if one really 
needs to do heavy math stuff, its probably better to use C and professional 
math libraries via an extension.

I almost agree with Maxim here. I think there should be a clear definition 
of REBOL 3 math *can* and *cannot* do. Leave the complex numbers, 
symbolic math and infinity to modules and extensions.

Actually, infinities, are not that much "scientific stuff" as it 
may look at the first sight. Anything you can do with infinities 
is not hard to do withouth them as well.

BrianH: I just looked into Delayed extension note is CC - cool guru 
stuff :-) btw - do I understand it correctly, that unnamed modules 
will be named in module list, according to the filename? But what 
if there is unnamed module, which is not loaded from file?

Actually what is stopping me from using REBOL3 is the lack of GUI 
and SQLite support but I have them in REBOL2 and I'll continue using 
it.

In REBOL3 I am only a spectator. I do not complain on the time it 
gets to be complete. I do not need the very last feature. I am passionate 
about the work you are doing on it. It is very hard.  It is nice 
to see you, genius, at work.

No, you don't want to do that.

I need a reliable way to QUIT with a return value from a script. 
But I do not know how this script is called.

Do I recall correctly that there was a reason tuple! values couldn't 
be extended to 16 slots? I don't know that it's a great idea to map 
IPv6 addresses to them, or the feasibility of adding an ipv6! type. 
A utype! may be good enough, but I don't know how those are going 
to work either.

If we go all out for IPv6 integration then we can do a utype or even 
a built-in type with syntax (utypes won't have literal syntax). But 
we don't need to do that to get IPv6 support; we can get that now 
using the existing datatypes and some functions to work on the data, 
in theory.

before utypes, we could finish e.g. vectors, sound is non-existant 
too ... tasking, new codec model - still lots of things to do :-)

Do I recall correctly that there was a reason tuple! values couldn't 
be extended to 16 slots?
 - yes

Is the safe R3 way to execute a script to use:
   do load %script-name
rather than R2's way:
   do %script-name
?


The reason I ask is the different behaviours I see here (I'd expect 
them both to print a 1)....
    n: 1 try [do %test-script.r ] print n
    n: 1 try [do load %test-script.r ] print n

....where test-script.r is these two lines:
    rebol []
    0 / 0

And that doesn't even get into the syntax issues: IPv6 syntax is 
really different, not the same as dotted. A different type would 
allow different syntax. But that syntax is really specific, only 
used for that one thing, and not necessarily a very common thing 
at that (do you tend to type out IPv6 addresses, or the domain names 
that refer to them?). It's not like tuples, that get used outside 
of the networking realm. It really might not be bad to just use strings 
for the IPv6 syntax, and binaries for the decoded values. We don't 
have to wait for syntax changes to get started. And once we get something 
running, the syntax changes would be easier to justify :)

This one is a poll question everyone should not have trouble to answer. 
In R2, the USE function initialized the local values to #[unset!] 
for better user protection. In R3 (implementation quirk) the local 
USE variables are initialized to #[none!]. Which alternative do you 
prefer?

I, personally, do not mind much, but, depending on the result of 
this poll, I intend to adjust my policy when judging other cases, 
e.g. new functions, that are not yet implemented.

Good argument, Henrik.

Ladislav, you wrote "the USE function initialized the local values 
to #[unset!] for better user protection."

Better protection than what? Or what is the protection? (Or do you 
just mean USE creating locals is the protection?)

Am I to understand, that some of the USE3/USE2 variants would do 
that?

Am I to understand, that some of the USE3/USE2 variants would do 
that?

Brian: "And if we are really concerned with initializing the values" 
- actually, I am not. I am more like one of those wanting to have 
it the same way in functions as well as in other locals. (like Henrik, 
Oldes, Anton, Andreas). That is currently the same in USE, which 
I do not object against. This way, only object (and module) fields 
are currently initialized to #[unset!], although in the newly proposed 
LET we can choose. BTW, it looks to me, that it is good, that LET 
can accept any-word!, i.e. be more flexible than USE.

(if I do not need any local variables, then I do not need to call 
the function creating them)

Empty vars or values blocks, like all of the other assignment-related 
characteristics of LET, serves the same purpose that they do in SET. 
Remember, a lot of the time LET will be used on data, not just inline 
words and values. Sometimes you want to screen for #[unset!], because 
being screened for is the whole point to that datatype, so setting 
it should be an option like it is with SET. Other times the words 
will be collected from the body, such as with COLLECT-WORDS/set. 
It is not necessarily an error if there are no words - it depends 
on the programmer's intention.

My note to the "rehashed #[unset!] argument": I like the "The whole 
point of #[unset!] is to trigger errors" formulation. Nevertheless, 
it is broken in a big way by USE and function contexts. Only any-object 
contexts adhere to this convention now, so it is an error to write.:

context [
    print a
    a: 1
]

, while a corresponding

use [a] [
    print a
    a: 1
]

would be an error in R2, but not in R3 anymore, while

do has [a] [
    print a
    a: 1
]

was not an error even in R2.


Therefore,  "The whole point of #[unset!] is to trigger errors" is 
true, but, as demonstrated, the #[unset!] value is sneakingly losing 
its point to the extent, that it is becoming negligible. BTW, this 
is one more "arms race", which a protection measure is losing when 
confronted with the freedom of a programmer to write code he likes 
to write. The previous victim of this race in the datatype space 
seems to be the #[none!] value (at least to me).


I do not object, since due to the changes the #[unset!] value is 
becoming more of an annoyance, than a useful bug protection. And, 
there are other benefits, like increased compatibility between USE 
and functions, exactly as the discussion revealed, as well as the 
fact, that the protection was never as useful as it was planned to 
be.

But, being at it, there is one annoyance I perceive:


1) the variables bound to a function context don't cease to exist 
even when the function is not running
2) code like:
    f: func [/a]['a]
    block: [a]
    bind block f

do not work, while I can do such a bind on my own without needing 
any permission:
    change block f
So, this is clearly just an annoyance, and not a useful feature.

And yes, you will want to do some math on it

So we don't need to do an OID type, but having support for OID would 
be helpful. Good catch :)

I guess the sort of operations you want to do are to compare oids, 
add leafs etc

Anybody can pretend whatever he likes to pretend, but I do not understand, 
why a blind faith is required from me.

What I wanted to demonstrate was, that:

block: [a]
g: closure [a] ['a]
f: func [a] ['a]
; this works
bind block g
; this does not work
bind block f
; but it can be replaced by this, doing what was requested:
change block f


, i.e. there is no reason why the operation should not work, except 
for the fact that somebody does not want me to do it (ineffectively, 
since I demonstrated, that it can be done anyway

you can't rebind because definitional binding depends on the order 
of binding operations

 - there are at least two things I do not understand in this sentence:

* "you can't rebind" - I am not trying to "rebind" above

* "because definitional binding depends on the order of binding operations" 
- sure it does, does that mean, that the BIND function should not 
work at all?

As Brian says, case sensitive map is easy to do with binary keys.

Here's my implementation of such, for anyone who needs it today). 
Improvement suggestions are welcome!
   http://www.rebol.org/view-script.r?script=r3-rehash.r

It goes the other way too: If you try to write REBOL-like code in 
most other languages then you will run into a wall. For most you 
will need to reimplement most of the natives before you can start, 
if it is possible to do REBOL-like code at all (often not with parsers). 
And when you do manage to get that code running it is often slower 
than REBOL code because of the optimization its natives have gone 
through.

PARSE rules are comparable to Perl 6 rules, both in speed and functionality. 
There are tricks you can do in either that you can't do in the other, 
or in some cases not easily. R2's PARSE outdid Perl 5's regexes, 
but R3 had to drastically update PARSE to catch up with Perl 6's 
rules.

There are tricks that you can do with dynamic rules that are provably 
impossible for static rules to do (patterns that static rules can't 
recognize). PARSE is a superset of the PEG model, while Perl 6 rules 
are a superset of recursive descent (LL), and there are patterns 
that LL can't handle that PEG can.

There are a lot of tricks that you can do in REBOL's DO dialect as 
well that can't be replicated in a compiled language without using 
self-modifying code. And vice-versa as well. Tradeoffs. But once 
you choose interpretation then you can optimize the language semantics 
to make that really efficient. That is why half of what a compiler 
does is done by LOAD, and optimized REBOL code looks a lot like what 
the other half of a compiler does. That is why REBOL DO is more comparable 
to one of Scheme's macro systems than it is to Scheme itself.

R3's DO dialect can be slower than compiled code for certain code 
patterns, but faster for others, depending on the compiler and language 
you are comparing it to (many dynamic languages were slower for a 
lot of code until recently). But you can make things a lot faster 
if you stop thinking of REBOL as being a language, and start thinking 
of it as being a library of native functions and datatypes, with 
a variety of high-level scripting languges built in to script that 
library, and some built-in functions written in those scripting languages. 
Plus you can add your own libraries and scripting languages if you 
like. Looking at things that way is the first step to becoming good 
at hand-optimizing REBOL.

That's true, "drastic" is a bit of an overstatement. Almost(?) everything 
you can do in R3's PARSE you could do in R2 with dynamic parse tricks, 
DO dialect tricks or a preprocessor. But for the average PARSE user 
who can't understand the advanced workarounds the new capabilities 
are just that: new. If you look at idiomatic R3 rules compared to 
their R2 equivalents then the changes at least *look* drastic. Certainly 
different enough that for most people PARSE is quite a bit more powerful.

And it was an objective, from way back when we did the first round 
of PARSE proposals. At the time I had been following the development 
of Perl 6, especially their rules enhancements. Some of the PARSE 
proposals were based on trying to catch up with or show up Perl 6, 
and others came from tricks that other parser generators like ANTLR 
could do (like IF). To be fair, it was an unstated objective, at 
least on the pages. Peta had different objectives of course, like 
better matching the PEG theoretical model, and those were also good.

When I look at the parse project, I see these changes as very useful:


1) the FAIL keyword - has been used as an idiom and proposed before 
the parse project started

2) the NOT keyword - has been used as an idiom and proposed before 
the parse project started
3) the AND keyword - a new and useful addition

4) the QUOTE keyword - used as an idiom and proposed before the parse 
project started

5) the REJECT keyword - a new and useful addition allowing to stop 
a parse cycle with a failure

6) the IF keyword - used as an idiom and proposed before the parse 
project started


As far as other improvements are concerned, I do not find them useful, 
and do not plan to use them, in fact. (YMMV)

We already resolved that problem earlier - maps rehash with a bigger 
limit when they run out of room now. All we need to do is provide 
Carl with an appropriate number of items to hash, where Ladislav 
would know what I mean by appropriate.

I wonder what is difficult to simulate on the JS prototyping? IMO 
it is possible to do it easily in REBOL.

Why do you bother to try to help Tutorial translate a non-working 
code example?

this is not worth discussing (I do not use JS at all, using only 
Java from time to time), but where did he use that in his code?

We can implement semantically equivalent code in REBOL, but that 
exact code can't be made to work.

 - I do not understand - that code works, what does "that exact code 
 can't be made to work" mean?

The equivalent to what RT requests would be to extend person *after* 
JaneDoe is created, and then have JaneDoe work.

 - why do you suspect him not being able to demonstrate the code he 
 wants to work?

GUI frameworks tend to be a good place to use class-based or delegation-based 
OOP, as we do in the R3 GUI.

I don't really see the point though. Explicit delegation is not hard 
to do, especially when you write accessor functions, like in the 
R3 GUI.

We don't have the option of using compilation or static analysis 
(except in dialects with more overhead). REBOL's speed depends on 
direct binding. We could (and can now) use path-based dynamic lookup, 
even if it's slower, and can refer to fields that weren't there when 
our functions were created through that notation. We can even do 
a version of messageNotUnderstood using IN tests and accessor methods. 
But remember that this:
    a
is faster than this:
    self/a
which is faster than this:
    either in self 'a [self/a] [something-else]


And "something is better than nothing" is not a factor, because REBOL 
is the way it is for really good reasons, and because the "nothing" 
is something we can do easily already.

DO of string! can be slow, but DO of block! is much faster. It was 
a tradeoff to increase the overall speed.

We do miss typical OOP facilities as being able to hook into init, 
pre-init, post-init, access phases ... E.g. Visual Objects I used 
in the past define:


You can prevent a runtime error from occurring when an
instance variable 
name is not found by defining methods called
NoIVarGet() and NoIVarPut(). 
These methods, if present, will
be automatically invoked whenever 
an instance variable cannot
be found. They are called with the instance 
variable name as a
parameter, in the form of a symbol and, in the 
case of
NoIVarPut(), with the value to be assigned as a second
parameter. 
This feature is useful in detecting and preventing a
runtime error 
and also for creating virtual variables
dynamically at runtime.

BrianH: if you don't have anything better to do, you could read one 
chapter from CA-VO language - chapter 25 - Classes, Objects, etc. 
I used it some 12 years ago, so I don't even properly remember it. 
But it allowed some nice tricks, as having access/asign methods, 
where you just used normal assignment operator, and if your child 
overrided the variable with virtual method, you still did not need 
to change the source code, you still used asignment.


What was also handy was various types of visibility - protect, hidden, 
export  .... in regards to class, inherited classes, and instantiated 
objects. I wonder if possible new object specs could work more like 
a modules, having exports too, etc. But maybe we don't need to complicated 
the stuff further ...


In case you would be interested - http://www.cavo.com/support/manuals/vo25pg.pdf

It's always amazing what people will do to avoid calling a function 
:)

And you can screen function calls for security (we do this a lot 
in the mezzanines). It is much more difficult to screen assignment 
statements with other side effects.

Most of the module-like stuff we used to do with objects can be done 
with modules instead. We should be conservative about what goes in 
an object spec.

Giuseppe, part of the reason that there are no set accessors (what 
I called "properties" above) in REBOL is that there are no classes 
either, so such accessors would need to be defined on a per-object 
basis. This makes them quite a lot less useful. The other part of 
your question is that we *do* have get accessors: We use the same 
syntax for variable getting as we do for function calls, so you can 
just assign a function to a word and it will act like a get accessor. 
You only need real get accessors in a language that puts parens around 
arguments or in some other way distinguishes function calls. However, 
let's for the moment assume that you mean get-word accessors, functions 
that will still be called even if you use the GET function, a get-word 
or get-path to access the value.


But one of the main reasons is to avoid hidden unexpected overhead 
and security issues. Assignment is fast in REBOL, because it does 
basically the same thing every time (with some variation in set-path 
assignment). If we had properties, that would add overhead to every 
single assignment statement whether to a property or not just because 
we would have to check for that every time. In languages with native 
properties their compiler makes this determination and generates 
the underlying function calls. With REBOL that overhead is at runtime 
because we don't have a compiler. We could compile our own dialects 
to make set-word accessors - Gregg's COLLECT, or R2/Forward's APPLY 
or MAP-EACH do this - but it is slower.


The security issue is that at the moment assignment and get-word 
access is safe. Set-path assignment and get-path access is at least 
safe with the built-in datatypes. Accessor assignment is not safe: 
it can have side effects or unexpected overhead. If we had accessors 
then you could not safely use words that you got from unknown locations. 
We wouldn't even be able to screen for functions, which a lot of 
the mezzanine code does now. Combined with get-word arguments and 
that means that there would be no way to avoid code injection exploits, 
and thus no way to make even a secure subset of REBOL. 


Now with path syntax the behavior is (apparently) type-specific, 
so with the appropriate datatypes we can do accessor functions; .NET 
object wrappers would benefit from this, for instance. But that requires 
utypes, because there is no point to making built-in types have that 
behavior. Then for security we could just disallow utypes from a 
function that might otherwise be exploitable.

I've got a reply from NTP server via SNTP packet (RFC 2030) almost 
all nulls in client packet (in Rebol 2 UDP port, because it is not 
clear how to do it in R3)

BTW Steeve there is UDP definitions in header files of Host kit, 
so I think UDP should be possible somehow, but TCP scheme is hard 
coded (ie not available to play with other variants)

I've been away kids.  And the itch is back.  If my goal is embedding 
REBOL scripting in OpenCOBOL, do I dig into a host kit yet?  Can 
I access REBOL data from the C interface?   Plop REBOL data onto 
the stack?  Even bother to think about REBOL as an application extension 
language?  Umm, 64bit GNU/Linux.

is there a way that I can do to pre-allocate a huge file? Pre-allocated 
file will have a continuous disk space, which makes seeking fast.

What antagonist language of the day do we want to counter-benchmark?

They are, but that's the question is different... we should be able 
to do such a conversions somehow. Don't know how at this moment.

Let's have:
	o: context [a: 1 b: 2]
I can do:
	values-of o ;== [1 2]

Can I update these values somehow to get o == make object! [a: 3 
b: 4]  just using block of values [3 4]?

It's used in mezzanines, for instance. I tend to just write code 
in micro-optimized form in the first place, since it is easy to do 
and saves you the trouble of doing it later. Even if you are macro-optimizing 
the code (refactoring and such) you tend to use the same micro-optimizations 
in the new code. For that matter, many of the changes and enhancements 
in R3 were done to make micro-optimized code cleaner to read and 
write than they are in R2. But I mostly write library and mezzannine 
code nowadays, so micro-optimization has greater impact than it would 
for user-level code.

I tend to just write code in micro-optimized form in the first place

And do you consider that premature optimization, or not?

Re "premature optimization" - I do not think I ever did have any 
feeling I used that. For example, I would never want to write O(n 
*n) code when O(n) is available, no matter how would anybody want 
to call my approach.

Do we know a reason why it is desirable to have decimal! NaNs?

The primary reason for supporting NaNs would be for easy of interaction 
with systems that do support NaN, eg Oracle.


Right now, any REBOL system that was trying to trade values with 
an Oracle system that supported NaN and +/-INF would need to code 
for special cases.


However, I do not know of anyone who has such a need -- so time for 
some to make the busines case!

Any particular language you do want to imitate?

Many languages are implemented using C. If you don't do anything 
particular regarding NaNs, you get outputs like from this C program:

#include <math.h>
#include <stdio.h>

int main()
{
	printf ("%lf\n", sqrt (1.0));
	printf ("%lf\n", sqrt (-1.0));
	printf ("%lf\n", sqrt (2.0));
}

Output:

1.000000
nan
1.414214


So it may actually take more effort to grab the NaN output and make 
e.g. an error output. Like REBOL does:

>> square-root -1
** Math Error: Positive number required
** Near: square-root -1

Re: "I am open to it" - maybe I misunderstood: do you mean, that 
you really want to obtain NaNs from expressions instead of errors 
being triggered?

I was hoping it would do more or less what you programmed: servicing 
system events but without waiting for all windows to close

The we should stick to principles. But I am not sure even Carl himself 
is strictly following the rules. In his doc he claims, that 'quit 
is as clear, as quit-system. Well, we have 'do, and we have 'do-browser, 
'do-service, where we are breaking on encapsulation rules, with excuses 
to not polutu 'do's name-space (not complicating it - because in 
other words, the proper way is to use refinements, as do-browser 
could be do/browser as well)


What is a bit tricky about question marks is, that the meaning is 
not clear enough,e.g. - modified? Does it stand for the logic value, 
returning the true or false, or does it stand for the return of modification 
date? How should user know?


That is just my opinion on this topic - sometimes things are not 
easy to sort-out. Rules are rules, and we should probably stick to 
them ... the other thing is, if we are not forgetting another rebol 
"rule" (or at least principle) - make things pop-out to your mind 
at first sight, if possible. So - what is more self-explanatory - 
faces?, or get-faces (or what was the suggestion alternative)?

Whether to prefer 'do-browser or do/browser - such a principle was 
not stated explicitly, so, we do not have any "guide" which one shall 
be preferred

Well, I think I know why we went with do-*, open-* - simply to not 
overload those functions with refinements, and hence slowing them 
down ...

Sorry, but it makes no sense to interpret this optional convention 
strictly. If we do, we also have to do the following renames:

Every variable name is a noun, in principle. Do we have to use question 
marks on all variables?

it is hard to use a logic argument when you refuse to discern nouns 
from other words, but, in that case, you are unable to stick to the 
function naming convention anyway, and I don't know what do you want 
to discuss

The difference is, that when sticking to the convention, it is easier 
to find out, that:


DO is a function, PRINT is a function, GET is a function, LENGTH? 
is a function

when "length" is followed by a serie

Why do we need to write "length of serie" , Is that not already implicit 
?

I just wonder, giving that idiom 
-> length serie
Why do we need to specify:
-> length of serie

Is that not already implicit, that the word "length" applies on the 
"serie"

if you are saying "I do not want to respect the REBOL function naming 
convention" then I don't want to change your mind in that. But, I 
think, that a reasonable naming convention is of advantage, and the 
one Carl wrote looks good enough to me.

I do want to respect the convention when possible, and, frankly, 
you cannot do anything about my will in that respect

I do not think, that the name of a function should describe everything, 
so, if I really want to get the maximal of the values in a series, 
I can be content to know that the MAXIMUM-OF function exists and 
be prepared to read the doc string what it actually does.

or, if you do not want to, I can do it

I don't have the time this week to do so, and am waiting on some 
more community understanding before I jump in. The "intrinsic property" 
thing likely won't survuve the cut, being replaced by the "implicit 
-of" thing.