Re: [Factor-talk] stack effect
Am Wed, 29 Jul 2015 08:44:20 +0100 schrieb Iain Gray iaing...@ednet.co.uk: Just guessing: Replace [ 0 amount 0 coins = or [ 0 ] with [ 0 amount 0 coins = or [ 0 ] signature.asc Description: PGP signature -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] stack effect
why do I get the following error? Stack effect declaration is wrong inferred ( x x x -- x x ) declared ( amount coins -- ways ) from this lexical variable :: cc ( amount coins -- ways ) 0 amount = [ 1 ] [ 0 amount 0 coins = or [ 0 ] [ amount coins 1 - cc amount coins denominations at* drop - coins cc + ] if ] if ; -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] stack effect
Georg solved your problem, but in the future you can easily use Factors introspection to see why it complains about stack effects. For example, the first quotation given to the inner if is [ 0 ] and you can infer its stack effect: IN: scratchpad [ 0 ] infer. ( -- x ) Then because the two quotations given to if must have the same stack effect, the second quotation must also have ( -- x ) which you can check like this: ! Needs to be declared because you are using locals IN: scratchpad SYMBOLS: amount coins cc denominations ; IN: scratchpad [ amount coins 1 - cc amount coins denominations at* drop - coins cc + ] infer. ( -- x x x x x ) Or you can manually count the stack delta. Local variables and numbers are +1, binary operations and drop -1 and at* is +/- 0: +1 +1+1 -1 +1 +1 +1+10 -1 -1 +1+1 -1 [ amount coins 1 - cc amount coins denominations at* drop - coins cc + ] 1 + 1 + 1 - 1 + 1 + 1 + 1 + 1 + 0 - 1 - 1 + 1 + 1 - 1 = +5 2015-07-29 9:44 GMT+02:00 Iain Gray iaing...@ednet.co.uk: why do I get the following error? Stack effect declaration is wrong inferred ( x x x -- x x ) declared ( amount coins -- ways ) from this lexical variable :: cc ( amount coins -- ways ) 0 amount = [ 1 ] [ 0 amount 0 coins = or [ 0 ] [ amount coins 1 - cc amount coins denominations at* drop - coins cc + ] if ] if ; -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- mvh/best regards Björn Lindqvist -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] stack effect
many thanks On 29 Jul 2015, at 12:04, Björn Lindqvist bjou...@gmail.com wrote: Georg solved your problem, but in the future you can easily use Factors introspection to see why it complains about stack effects. For example, the first quotation given to the inner if is [ 0 ] and you can infer its stack effect: IN: scratchpad [ 0 ] infer. ( -- x ) Then because the two quotations given to if must have the same stack effect, the second quotation must also have ( -- x ) which you can check like this: ! Needs to be declared because you are using locals IN: scratchpad SYMBOLS: amount coins cc denominations ; IN: scratchpad [ amount coins 1 - cc amount coins denominations at* drop - coins cc + ] infer. ( -- x x x x x ) Or you can manually count the stack delta. Local variables and numbers are +1, binary operations and drop -1 and at* is +/- 0: +1 +1+1 -1 +1 +1 +1+10 -1 -1 +1+1 -1 [ amount coins 1 - cc amount coins denominations at* drop - coins cc + ] 1 + 1 + 1 - 1 + 1 + 1 + 1 + 1 + 0 - 1 - 1 + 1 + 1 - 1 = +5 2015-07-29 9:44 GMT+02:00 Iain Gray iaing...@ednet.co.uk: why do I get the following error? Stack effect declaration is wrong inferred ( x x x -- x x ) declared ( amount coins -- ways ) from this lexical variable :: cc ( amount coins -- ways ) 0 amount = [ 1 ] [ 0 amount 0 coins = or [ 0 ] [ amount coins 1 - cc amount coins denominations at* drop - coins cc + ] if ] if ; -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- mvh/best regards Björn Lindqvist -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Stack effect declaration is wrong
Hello list. Sometimes I get an error that a stack effect declaration is wrong, and then can't figure out why. --- The word historical-prices-from-year cannot be executed because it failed to compile Stack effect declaration is wrong inferred ( x x x x -- x ) declared ( symbol year -- csv ) --- If I put BPT and 2009 on the stack, then run historical-prices-from-year, in the listener, I get the above error. If I put BPT and 2009 on the stack, then paste the code for historical-prices-from-year, in the listener, it works. What am I missing? Cheers, mrw dax.factor Description: Binary data -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Stack effect declaration is wrong
Er, nevermind, seems to work now somehow. On 08/24/2014 01:01 PM, mr wzrd wrote: Hello list. Sometimes I get an error that a stack effect declaration is wrong, and then can't figure out why. --- The word historical-prices-from-year cannot be executed because it failed to compile Stack effect declaration is wrong inferred ( x x x x -- x ) declared ( symbol year -- csv ) --- If I put BPT and 2009 on the stack, then run historical-prices-from-year, in the listener, I get the above error. If I put BPT and 2009 on the stack, then paste the code for historical-prices-from-year, in the listener, it works. What am I missing? Cheers, mrw -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] stack-effect syntax
They're count-binding, but not type-binding. Ignore for now the fact that you can declare nested effects. Take the basic case. What if I really want word sum-of-integers to be able to add only integers and not, say, floats?: Then I suggest you try some other language which has static typing. No, that would certainly be a mistake. Factor is more than adequate, but excessive dynamicity, as is so common is Smalltalk, for example, has its problems too. This issue is much of what I'm addressing in the establishment of a stricter, but still flexible type-discipline. Shaping -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] stack-effect syntax
I can't find any info in Browser on quot:. http://docs.factorcode.org/content/article-effects.html I was looking for a definition. quot: does not seem to behave like a word or literal. quot: occurs only once on the above page in an example of a row-polymorphic combinator, but is not defined. However, quot is mentioned briefly in the table of 13 names: Inputs and outputs are typically named after some pun on their data type, or a description of the value's purpose if the type is very general. The following are some examples of value names: Above is the sentence preceding the table of 13 names. The bold parts concern me. What am I to think? Are these names words or literals? They don't seem to be either. I can't find the few names I've looked up in the help browser, which fact makes me think they are not words. Are they standard names, part of a special syntax for stack-effects, and not my personal choice? If so, this convention looks like a break from the pattern that makes Factor simple and elegant. If these names must be used in stack-effects declarations, can someone please update the above language, accordingly. Shaping -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] stack-effect syntax
I was looking for a definition. quot: does not seem to behave like a word or literal. quot: occurs only once on the above page in an example of a row-polymorphic combinator, but is not defined. However, quot is mentioned briefly in the table of 13 names: There's no documentation for quot: because, just like other names in a stack effect without the colon, the name quot doesn't mean anything except as documentation for the human reader. Yes, that is the part that concerns me. Why did we design this convention? The : at the end indicates that it's followed by a nested stack effect declaration. From the linked Stack effects documentation: -- Parameters which are quotations can be declared by suffixing the parameter name with : and then writing a nested stack effect declaration. -- Yes, I saw that but don't like it. Is there way to use Factor productively without this convention? A word could be defined with the following stack effects and the behavior would be the same: -- : foo ( a quot -- ) : foo ( apples bananas -- ) : foo ( !...@# @#$ -- ) -- Likewise, with nested stack effect checking, the following are equivalent: -- : bar ( a quot: ( b -- ) -- ) : bar ( apples bananas: ( pears -- ) -- ) : bar ( !...@# @#$: ( #$% -- ) -- ) -- The point of these examples seems to be that the tokens appearing in the stack-effect syntax are truly arbitrary, but how then are the stack-effects count- and type-binding? Ignore for now the fact that you can declare nested effects. Take the basic case. What if I really want word sum-of-integers to be able to add only integers and not, say, floats?: : sum-of-integers ( integer integer -- integer ) + ; In the above definition, I want the references to integer to be real references to class integer, as a type of the instance expected in the corresponding stack position. I want to say what I mean, mean what I say, and be held accountable by the compiler for all it, but I don't see that happening in the examples, unless apples and bananas, for instance, are real classes, and not just surrogates. I don't see the utility of the scheme. I just want to define the number, position, and types of inputs and outputs for a word. Shaping -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] stack-effect syntax
On Thu, Nov 18, 2010 at 5:28 PM, Shaping shap...@charter.net wrote: I was looking for a definition. quot: does not seem to behave like a word or literal. quot: Yes, that is the part that concerns me. Why did we design this convention? The convention comes from Forth best practices, in which word definitions are followed by a short comment indicating the number of inputs and outputs the word expects. Factor just takes it one step further by enforcing the documentation. The important thing Factor needs to know for things to work is the number of inputs and outputs, so the stack effect syntax could well have been just a pair of numbers: : foo ( 2 -- 1 ) However, having named slot names that follow a set of conventions allows a lot of documentation about a word to fit in a small amount of space: : foo ( ? quot -- n ) Based on common Factor conventions, I can reasonably guess that foo takes a boolean value, quotation, and returns a number. Note that you can define a function that binds its inputs to local variables, in which case the names do have meaning as the names of the variable bindings: :: foo ( x y -- z ) y x - ; 2 3 foo . ! outputs 1 Yes, I saw that but don't like it. Is there way to use Factor productively without this convention? Nested stack declarations are never strictly necessary, though they improve error reporting a lot when you have a stack error in combinator-heavy code. They're more important in standard library code. The point of these examples seems to be that the tokens appearing in the stack-effect syntax are truly arbitrary, but how then are the stack-effects count- and type-binding? Ignore for now the fact that you can declare nested effects. Take the basic case. What if I really want word sum-of-integers to be able to add only integers and not, say, floats?: : sum-of-integers ( integer integer -- integer ) + ; Being count-binding is easy: the number of names or name: effect pairs to the left of the -- must match the number of inputs, and the number of names to the right must match the number of outputs. As for being type-binding, Factor is fundamentally a dynamically-typed language, and strict type enforcement has historically not been a primary goal of the language design. However, if you want type checking enforcement, there is a typed library that extends the stack effect syntax with the ability to provide type assertions for inputs and outputs: -- USING: typed ; TYPED: sum-of-integers ( x: integer y: integer -- z: integer ) + ; 1 2 sum-of-integers . ! outputs 3 1.0 2.0 sum-of-integers . ! raises an error -- Just like name: ( -- ) associates a static stack effect with name in standard Factor, within a TYPED: definition, name: class associates an enforced type with name. -Joe -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] stack-effect syntax
On Thu, Nov 18, 2010 at 05:58:48AM -0600, Shaping wrote: A word could be defined with the following stack effects and the behavior would be the same: : foo ( a quot -- ) : foo ( apples bananas -- ) : foo ( !...@# @#$ -- ) Yes. Likewise, with nested stack effect checking, the following are equivalent: : bar ( a quot: ( b -- ) -- ) : bar ( apples bananas: ( pears -- ) -- ) : bar ( !...@# @#$: ( #$% -- ) -- ) Yes. The point of these examples seems to be that the tokens appearing in the stack-effect syntax are truly arbitrary, but how then are the stack-effects count- and type-binding? They're count-binding, but not type-binding. Ignore for now the fact that you can declare nested effects. Take the basic case. What if I really want word sum-of-integers to be able to add only integers and not, say, floats?: Then I suggest you try some other language which has static typing. Miles -- Note that those are the bitwise OR (|) and AND () operators, not the more commonly used logical OR (||) and AND ( ) operators. Getting the two mixed up can lead to hours of interesting debugging. -- Maciej Ceglowski -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Stack effect checking changes, and performance improvement
Hi all, I changed how the stack checker works. Previously, if a word's stack effect could not be inferred, a compile error/warning would be generated and the word would be compiled with the non-optimizing compiler, as would all words that called it, directly or indirectly. (Inline words and macros were an exception to the latter rule; a combinator like 'each' doesn't infer but its callers do if the quotation is known). This has changed: - Inline words and macros no longer produce compiler warnings. This is because a warning here won't tell you anything you don't already know. As before, callers which pass literal or curried quotations infer and get optimized, etc. - If a word fails to compile with a compiler error, then calling the word throws an error. This means that unless a word is inlined, then either its stack effect declaration is correct, or calling it halts execution -- so the stack checker does not have to recursively check stack effects of words, it just trusts your declaration and lets the compiler sort it out. So stack effect inference is now a purely local operation, operating on a word and its inlined factors only. This has three important consequences: - It is now possible to write code that produces no compiler warnings and errors, and in fact this is now the normal mode of operation since code with warnings and errors won't run. If you don't understand the combinator inlining rules, you can always use call( and execute( everywhere too -- they are pretty efficient (of course not quite as efficient as inlining the combinator and quotation away entirely). When a compiler error popups up, you'll know for sure its something in your code, instead of being confronted with a list of 500 warnings after loading a library from basis/. - If you accidentally make a word not infer, its callers are not affected. So, for example, something as simple as this would break Factor, and/or make the UI really slow, because most words in the system would cease to infer and get unoptimized; almost everything calls 'length' via transitivity, and so all those callers would get deoptimized since length would cease to have a static stack effect: TUPLE: bad-sequence ; M: bad-sequence length 1 2 3 ; ! stack effect error; length is declared ( seq -- n ), our method leaves with 4 items Now, the above code just generates a compiler error for that one method, everything else works, and calling the method throws an error. FORGET: bad-sequence removes the method and the error goes away. Try it! - Bootstrap and loading source files is faster now. Together with the new UI error list tool, these changes should make programming in Factor more enjoyable. Faster loading time is a good plus too, and I have some more changes planned that should improve load time. Once the dust settles, I plan on doing a screencast to demo the recent UI tool changes, the new error list tool, and the stack checker. Enjoy, Slava -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Stack effect inference (COM words not using define-declared)
On Jun 11, 2008, at 4:34 PM, Slava Pestov wrote: The new 'beep' code causes a bootstrap failure on Unix platforms with X11. I found and fixed the problem; never mind. Slava - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
[Factor-talk] Stack effect inference
Hi all, For a while now Factor has required that the stack effect be declared on recursive words. Non-recursive words did not require a declaration, but it was considered good style to add one except for the most trivial words (such as those pushing constants on the stack). Well, the problem is that I recently realized any word can technically become recursive, _except_ those that push constants on the stack! So what we have now is unsound. Consider this scenario: You're working at a large enterprisey firm on a project with lots of developers ;-) Developer A writes the following code: GENERIC: a ( x -- y ) GENERIC: c ( x -- y ) Developer B writes the following code: : b ... a ... ; ! no stack effect declaration -- but it's not recursive! M: foo c ... b ... ; Developer C writes this: M: bar a ... c ... ; Wham, suddenly 'b' is recursive, because we have a cycle in the control flow graph: a - c - b - a, which didn't exist before! But developer C doesn't care about the word 'b', they may not know it exists even, but they just broke it. This scenario is not contrieved; it comes up in extra/ from time to time. Someone will add some code which defines a bunch of methods, then suddenly the compiler starts complaining about some totally random word being recursive and needing a stack effect, such as this word from calendar.format: : year write- ; Surely it doesn't look recursive, but there is some path through the call graph where write- calls write, which calls some low-level Unix I/O code, which somehow calls back into the calendar code... To make matters worse, it doesn't _always_ complain about a word needing a stack effect declaration. Sometimes things work out just fine and it gets along without hitting the code path where it needs the declaration to be there. So what we have here is that some guy makes an innocent-looking change to the code, and at some undetermined point in the future, a totally unrelated word may stop compiling. The technical term for languages with such features is toy language :-) Since my plan is to use Factor to take over the world and get disgustingly rich, this is not an acceptable state of affairs. There are two solutions: 1) Revive the old stack effect inference algorithm which did not require annotations at all. 2) Require stack effect declarations on all words except for the most trivial ones which only push literals on the stack I don't want to do #1 because the old algorithm was more complex, both in terms of code and run time. So that leaves us with #2. I don't mind having to annotate more words, what do you guys think? Slava - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Stack effect inference
I vote for #2, I probably need/want stack effect declarations even more than the compiler when I look at code. But, I vote for 2b) Require stack effect declarations on all words On Sat, Jun 7, 2008 at 12:00 PM, Slava Pestov [EMAIL PROTECTED] wrote: Hi all, For a while now Factor has required that the stack effect be declared on recursive words. Non-recursive words did not require a declaration, but it was considered good style to add one except for the most trivial words (such as those pushing constants on the stack). Well, the problem is that I recently realized any word can technically become recursive, _except_ those that push constants on the stack! So what we have now is unsound. Consider this scenario: You're working at a large enterprisey firm on a project with lots of developers ;-) Developer A writes the following code: GENERIC: a ( x -- y ) GENERIC: c ( x -- y ) Developer B writes the following code: : b ... a ... ; ! no stack effect declaration -- but it's not recursive! M: foo c ... b ... ; Developer C writes this: M: bar a ... c ... ; Wham, suddenly 'b' is recursive, because we have a cycle in the control flow graph: a - c - b - a, which didn't exist before! But developer C doesn't care about the word 'b', they may not know it exists even, but they just broke it. This scenario is not contrieved; it comes up in extra/ from time to time. Someone will add some code which defines a bunch of methods, then suddenly the compiler starts complaining about some totally random word being recursive and needing a stack effect, such as this word from calendar.format: : year write- ; Surely it doesn't look recursive, but there is some path through the call graph where write- calls write, which calls some low-level Unix I/O code, which somehow calls back into the calendar code... To make matters worse, it doesn't _always_ complain about a word needing a stack effect declaration. Sometimes things work out just fine and it gets along without hitting the code path where it needs the declaration to be there. So what we have here is that some guy makes an innocent-looking change to the code, and at some undetermined point in the future, a totally unrelated word may stop compiling. The technical term for languages with such features is toy language :-) Since my plan is to use Factor to take over the world and get disgustingly rich, this is not an acceptable state of affairs. There are two solutions: 1) Revive the old stack effect inference algorithm which did not require annotations at all. 2) Require stack effect declarations on all words except for the most trivial ones which only push literals on the stack I don't want to do #1 because the old algorithm was more complex, both in terms of code and run time. So that leaves us with #2. I don't mind having to annotate more words, what do you guys think? Slava - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Stack effect inference
Since my plan is to use Factor to take over the world and get disgustingly rich, this is not an acceptable state of affairs. There are two solutions: 1) Revive the old stack effect inference algorithm which did not require annotations at all. 2) Require stack effect declarations on all words except for the most trivial ones which only push literals on the stack I don't want to do #1 because the old algorithm was more complex, both in terms of code and run time. So that leaves us with #2. I don't mind having to annotate more words, what do you guys think? It might make sense to require all definitions to have a stack effect, and have a shorthand parsing word for defining constant words. The CONST: word could ensure that the definition consists of nothing but literals and other const words, automatically apply inline and any other optimizer annotations that make sense, and maybe even figure out the types of the literals and annotate the stack effect with them. For example: CONST: FOO_BAR_BAS foo bar bas ; could expand out to: : FOO_BAR_BAS ( -- |string |string |string ) foo bar bas ; inline const ! etc. -Joe - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Stack effect inference
Joe, Eventually I might do something like that; when I implement multi- methods, it might make sense for the parser to always expect ( after the word name. For now, I'm enforcing this in the compiler, not the parser. By the way, the COM code defines some words with 'define'. Can you update it to use 'define-declared' please? The new stack effect literal syntax (look at (() might help. Slava On Jun 9, 2008, at 1:29 PM, Joe Groff wrote: It might make sense to require all definitions to have a stack effect, and have a shorthand parsing word for defining constant words. The CONST: word could ensure that the definition consists of nothing but literals and other const words, automatically apply inline and any other optimizer annotations that make sense, and maybe even figure out the types of the literals and annotate the stack effect with them. For example: CONST: FOO_BAR_BAS foo bar bas ; could expand out to: : FOO_BAR_BAS ( -- |string |string |string ) foo bar bas ; inline const ! etc. -Joe - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
