Re: [Factor-talk] ndrop

2015-01-28 Thread John Benediktsson
Feel free to ask more questions on the mailing list, or through a Github
Issue if you'd like some help.

On Wed, Jan 28, 2015 at 7:48 AM, Alexander Iljin  wrote:

> Hello, Jon!
>
>   Thank you, you've explained a lot!
>
>   It's funny that I stumbled into this on my second day of
> experimentation. Turns out there's an important characteristic of the
> language, and thanks to you I'm now aware of it. Unfortunately, the
> documentation is too terse for me to understand at this time, but I'll keep
> trying.
>
>   You've been very helpful!
>
> ---=---
> Александр
>
>
> --
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


Re: [Factor-talk] ndrop

2015-01-28 Thread Alexander Iljin
Hello, Jon!

  Thank you, you've explained a lot!

  It's funny that I stumbled into this on my second day of experimentation. 
Turns out there's an important characteristic of the language, and thanks to 
you I'm now aware of it. Unfortunately, the documentation is too terse for me 
to understand at this time, but I'll keep trying.

  You've been very helpful!

---=---
Александр

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


Re: [Factor-talk] ndrop

2015-01-28 Thread Jon Harper
Hi Alexander,

The input quotations to “while” don't match their expected effects
> Input Expected Got
> [ dup 0 > ]   ( ..a -- ..b ? ) ( x -- x x )
> [ 1 - swap drop ] ( ..b -- ..a )   ( x x -- x )
>
>   Regarding the first line:
>
These two lines can not be interpreted separately, as you'll se below.

Input Expected Got
> [ dup 0 > ]   ( ..a -- ..b ? ) ( x -- x x )
>
>   I read it as "a boolean is expected at the stack top, but some other
> value was found".

The first line means "starting from a number of elements on the stack
(represented as "..a"), there should be "..b" elements and a boolean on the
stack. In your case, based on the "Got" column, it means ..a is 1 element,
and ..b and the boolean are 2 elements (so ..b is 1 element). It doesn't
say anything about the types of the elements.

>   How can that be if the last function is ">", and it does return a
> boolean.
>
The error is not about the types of the elements (using '?' does mean the
type should be a boolean, but it is just a convention). The two lines can't
be read separately: quoting from the docs (
http://docs.factorcode.org/content/article-effects-variables.html) : "the
number of inputs or outputs represented by a particular .. name must match
among all of the quotations". So the error is about the fact that the
second line forces "..b" to represent 2 elements, which contradicts the
first line where ..b must represent 1 element.


>   I read it as "you can't reduce the stack size inside the loop body".
>   Why not?
>
Words must have a known fixed stack effect. This is a design decision. The
number of inputs and outputs is fixed, must be declared and must match the
result inferred from the body of the word.

This is explained in
http://docs.factorcode.org/content/article-cookbook.html and its linked
articles (for example
http://docs.factorcode.org/content/article-effects.html).

However, there is some more advanced stuff to this:
- Some flexibilty is allowed for inline words (see
http://docs.factorcode.org/content/article-effects-variables.html) which
allows them to have a stack effect depending on their inputs. Still the
resulting stack effect must be fixed at each call site.
- Also, ndrop already exists in the library:
http://docs.factorcode.org/content/word-ndrop,generalizations.html
The key to make it work is to use macros (
http://docs.factorcode.org/content/article-macros.html). "1 ndrop" is
changed into  "[ drop ] [ call ] keep drop", "2 ndrop" is changed into "[
drop ] [ call ] keep [ call ] keep drop", etc.
You can see it by entering "[ drop ] 2 call-n" in the graphical listener
and pressing CTRL-m.
But this means the argument to ndrop must be a known at compile time so
that the macro expansion succeeds. For example:
: foo ( x x -- ) 1 1 + ndrop ; ! error, Cannot apply “call-n” to a run-time
computed value
: bar ( x x -- ) 2 ndrop ; ! OK

Hope that helps,
cheers,
Jon
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


[Factor-talk] ndrop

2015-01-28 Thread Alexander Iljin
Hi, all!

  I'm a newbie trying to understand Factor.

  Today I wrote a function called ndrop. The idea is that if you have nine 
pieces of junk on the stack you could write "9 ndrop" to get rid of them. 
Here's my attempted solution:

USING: kernel math ;
IN: ndrop

! Drop n items from the stack (plus the "n" itself).
: ndrop ( ..n -- ) [ dup 0 > ] [ 1 - swap drop ] while drop ;

  When I try to run it I get some error messages that I need your help 
understanding:

The word ndrop cannot be executed because it failed to compile

The input quotations to “while” don't match their expected effects
Input Expected Got
[ dup 0 > ]   ( ..a -- ..b ? ) ( x -- x x )
[ 1 - swap drop ] ( ..b -- ..a )   ( x x -- x )

  Regarding the first line:
Input Expected Got
[ dup 0 > ]   ( ..a -- ..b ? ) ( x -- x x )

  I read it as "a boolean is expected at the stack top, but some other value 
was found".
  How can that be if the last function is ">", and it does return a boolean.

  Regarding the second line:
Input Expected Got
[ 1 - swap drop ] ( ..b -- ..a )   ( x x -- x )

  I read it as "you can't reduce the stack size inside the loop body".
  Why not?

  Any general advice would be highly welcome as well.

---=---
 Александр

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk