[Prev][Next][Index][Thread]

Re: Dylan and OIL(SCP)

On Tue, 30 Nov 1999 14:45:03 -0500 (EST), ingjyehwang@my-deja.com wrote:

> Hi,
> 	Recently because of work, I learned i2 supply chain planner
> (SCP) product.
> In SCP, there is an interactive scripting language OIL (object
> interaction language).
> I like the syntax very much.  Maybe we can support similar syntax in
> Dylan.
> 
> 	I think that everyone know how slot reference works in Dylan.
>  (<=> is equivalent.) For getter,
> A.B <=> B(A).
> For setter,
> A.B := C   <=>  B(A) := C <=> B-setter(C, A).
> 
> For the getter, it is the same as Dylan. For the setter,
> A.set_B(C) <=> set_B(A,C).
> There is no A.B := C syntax in SCP.
> 
> In SCP, one of the reason which I like their syntax because it is easier
> to write deep class hierarchy.
> For example, in SCP
> (Expression A)
> supply_chains.find("My supply chain").plans.find("Actual
> plan").horizon.start
> is equivalent to
> (Expression B)
> start(
>    horizon(
>       find(
>          plans(
>             find(supply_chains,
>                  "My supply chain")
>          ), "Actual plan")
>       )
>     )

This is a slight unfair comparison since the A was written on one line and B was
written across several lines:

supply_chains.find("My supply chain").plans.find("Actual  plan").horizon.start

start(horizon(find(plans(find(supply_chains,"My supply chain")),"Actual plan")))

However, there is an argument for looking at extending the dot function call
syntax. Currently the dot syntax is a bit of a wart and doesn't allow for
multi-arg calls. However a more symmetric and perhaps more Dylany version of
multi-arg dot calls might be:

((supply_chains,"My supply chain").find.plans,"Actual plan").find.horizon.start

However, it is not often you see such big chains since you regularly need to
check the intermediate values for validity.

> In my opinion, Expression A is much easier to read and write than
> Expression B.
> In fact, it seems to me that, Expression A is not allowed in Dylan.
> QUESTION: More explicitly, can we define  A.B(C) is Dylan?
> I think: Since Dylan uses method dispatch, we need to define B(A,C)
> method.  We can't define B(C) as member function to class A.

Indeed.

> If we need to write valid Dylan syntax, it will be similar to Expression
> B.
> In fact, Expression A can be understood by listener if the following
> expressions
> are equivalent.
> A.B(C,...)  <=> B.(A, C, ...).
> 
> I don't know how difficult it is to modify the compiler to use this kind
> of syntax.

I don't think the function calling syntax is the main reason people would choose
not to use Dylan.

> There are several points that I think we can make Dylan more dynamic.

NB Dylan is in some sense Lisp with the dynamic bits taken out. If you want more
dynamism you might like to try Common Lisp or Scheme.

> 1.  Has load-file("file_name.dylan").
>     I really like these features.

Fun-Dev can load shared libraries via Win32's LoadLibrary function. I think we
might wrap that up as an abstract load-library() function. However, this is at
the level of compiled Dylan libraries not individual Dylan source files.

What do you want to do with load-file()?

> 2.  More dynamic to evaluate the Dylan codes.
>     For example,
>     define B = "foe";
>     define code = "A." &  B  & " := C;";
>     (Assume & is concatenating.)
>     evaluate(code) will yield
>     A.foe : =  C;
>     This kind of feature appears in Perl.

This is a feature of Lisp that Dylan dropped in order to help deliver compact
and efficient programs.

__Jason
Follow-Ups: References: