On Thu, Nov 18, 2010 at 5:28 PM, Shaping <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to