Re: [Factor-talk] New short-circuit combinators
> What do the 0, 1 and 2 signify?
Each of those combinators takes a sequence of quotations. The number indicates
the "arity" of the quotations. So for example:
10 { [ even? ] [ 10 = ] [ 20 < ] } 1&&
You'd use '1&&' there because the quotations consume 1 item.
Ed
-
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] New short-circuit combinators
What do the 0, 1 and 2 signify? On Tue, Jun 10, 2008 at 4:31 PM, Eduardo Cavazos <[EMAIL PROTECTED]> wrote: > Hello, > > The combinators.lib vocabulary now has these combinators: > >0|| >1|| >2|| > >0&& >1&& >2&& > > They replace all the short-circuit combinators that were previously in that > vocabulary. They work similarly, except that for the || variants, the first > non-f value is returned and for the && variants, the value of the last > expression is returned if it is non-f. > > I noticed a few vocabs that use the old combinators. || can be replaced by > 0||. && can be replaced by 0&&. > > I'll give everyone a chance to update their code to use the new words. If any > vocabs are orphaned, I'll take care of those. > > Ed > > - > 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
[Factor-talk] New short-circuit combinators
Hello, The combinators.lib vocabulary now has these combinators: 0|| 1|| 2|| 0&& 1&& 2&& They replace all the short-circuit combinators that were previously in that vocabulary. They work similarly, except that for the || variants, the first non-f value is returned and for the && variants, the value of the last expression is returned if it is non-f. I noticed a few vocabs that use the old combinators. || can be replaced by 0||. && can be replaced by 0&&. I'll give everyone a chance to update their code to use the new words. If any vocabs are orphaned, I'll take care of those. Ed - 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 (COM words not using define-declared)
> 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. Sure thing--the change is in git://repo.or.cz/factor/jcg.git . I've got a couple of other patches in there too: one adds integer>bit-array and bit-array>integer words to the bit-arrays vocab for blowing up an integer into bits and mashing it back together, and another adds a "beep" method to ui.backend to play the system alert sound. -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
[Factor-talk] 0 nnip
Slava, You pointed out that some of the n... shuffle words are no-ops when you pass 0 to them. This is convinient for generalizing macros of varying arity. However, while "0 nnip" is a no-nop, it throws an error if the stack is empty. Do you think "0 nnip" should work on an empty stack? I'm leaning towards that it should. Ed - 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
[Factor-talk] Non-recursive versions of the short-circuiting combinators
Hello,
Here are non-recursive versions of 0||, 1||, 0&&, and 1&&. They expand
into 'cond':
MACRO: 0|| ( quots -- quot )
[ '[ drop @ dup ] [ ] {2} ] map
{ [ drop t ] [ f ] }suffix
'[ f , cond ] ;
MACRO: 1|| ( quots -- quot )
[ '[ drop dup @ dup ] [ nip ] {2} ] map
{ [ drop drop t ] [ f ] } suffix
'[ f , cond ] ;
MACRO: 0&& ( quots -- quot )
[ '[ drop @ dup not ] [ drop f ] {2} ] map
{ [ t ] [ ] } suffix
'[ f , cond ] ;
MACRO: 1&& ( quots -- quot )
[ '[ drop dup @ dup not ] [ drop drop f ] {2} ] map
{ [ t ] [ nip ] } suffix
'[ f , cond ] ;
Ed
-
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] Short-circuiting combinators which return their value
Hello, In combinators.lib, we have &&, ||, and some arity variants. However, they only return 't' or 'f'. We're interested in versions which return non-f results. In the case of '||' it would return the first non-f result. In the case of '&&' it would return the last result if all the results were non-f. If you perform a manual expansion of expressions which you'd pass to && and ||, a pattern arises. I think this macro captures the 0 arity case: : 0||-rewrite ( quots -- quot ) dup empty? [ drop [ ] ] [ unclip swap 0||-rewrite '[ drop @ dup [ ] [ @ ] if ] ] if ; MACRO: 0|| ( quots -- quot ) 0||-rewrite f prefix ; This is 1 arity case: : 1||-rewrite ( quots -- quot ) dup empty? [ drop [ nip ] ] [ unclip swap 1||-rewrite '[ drop dup @ dup [ nip ] [ @ ] if ] ] if ; MACRO: 1|| ( quots -- quot ) 1||-rewrite f prefix ; And finally the 2 arity case: : 2||-rewrite ( quots -- quot ) dup empty? [ drop [ 2nip ] ] [ unclip swap 2||-rewrite '[ drop 2dup @ dup [ 2nip ] [ @ ] if ] ] if ; MACRO: 2|| ( quots -- quot ) 2||-rewrite f prefix ; Fry really helped here. I'm the syntax rebel/separatist around here. I'd been experimenting with a syntax I call "auto fry" whereby you don't have to single-quot a quotation in order to fry it. If a quotation contains fry directives, it's fried. I really like this but this in this application it didn't work. I was using auto-fry instead of the explicit fry above. The probem is, the quotation I intend to fry is actually in another quotation. The inner directives cause the outer quotation to fry; not the desired result... Ed - 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
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
[Factor-talk] replace-patterns in cpu.8080.emulator
Hi all,
Here is some code from cpu.8080.emulator:
SYMBOL: $1
SYMBOL: $2
SYMBOL: $3
SYMBOL: $4
: replace-patterns ( vector tree -- tree )
#! Copy the tree, replacing each occurence of
#! $1, $2, etc with the relevant item from the
#! given index.
dup quotation? over [ ] = not and [ ! vector tree
dup first swap rest ! vector car cdr
>r dupd replace-patterns ! vector v R: cdr
swap r> replace-patterns >r 1quotation r> append
] [ ! vector value
dup $1 = [ drop 0 over nth ] when
dup $2 = [ drop 1 over nth ] when
dup $3 = [ drop 2 over nth ] when
dup $4 = [ drop 3 over nth ] when
nip
] if ;
This code was written a while ago, before we had some of the
abstractions we do now.
Here is a new version:
SYMBOLS: $1 $2 $3 $4 ;
: replace-patterns ( vector tree -- tree )
[
{
{ $1 [ first ] }
{ $2 [ second ] }
{ $3 [ third ] }
{ $4 [ fourth ] }
[ nip ]
} case
] with deep-map ;
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
