The expression problem

[JS]

How would one approach the expression problem with Shen?

[Mark Tarver]

which is?

Mark

[JS]

"The Expression Problem is a new name for an old problem. The goal is
to define a datatype by cases, where one can add new cases to the
datatype and new functions over the datatype, without recompiling
existing code, and while retaining static type safety (e.g., no
casts).[6]"

Here's an article about clojure's approach to it:
http://www.ibm.com/developerworks/java/library/j-clojure-protocols/


[6] http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt

> --
> You received this message because you are subscribed to the Google Groups "Qilang" group.
> To post to this group, send email to qil...@googlegroups.com.
> To unsubscribe from this group, send email to qilang+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/qilang?hl=en.
>

[shaun gilchrist]

"The Expression Problem is a new name for an old problem. The goal is
to define a datatype by cases, where one can add new cases to the
datatype and new functions over the datatype, without recompiling
existing code, and while retaining static type safety (e.g., no

casts)." - http://www.daimi.au.dk/~madst/tool/papers/expression.txt

[Raoul Duke]

>> http://www.ibm.com/developerworks/java/library/j-clojure-protocols/
> nice article!
> had a language that worked perfectly for it, then that language would
> be horribly deficient in other ways, for other things you want to
> solve, i dare guess.

going over what i wrote, i think it is not true if you can change the
paradigm up and away from straw-man functional and straw-man oo. which
is what the article seems to say clojure has done. nice.

the article sounds very compelling, but then clojure is not statically
typed, drat. :-(

[Raoul Duke]

> http://www.ibm.com/developerworks/java/library/j-clojure-protocols/

nice article!




(rambling: the expression problem is fun in that there isn't, as far
as i've heard and i'm not that educated about it of course, any
perfect solution -- everything kind of sucks in some way. and if you

had a language that worked perfectly for it, then that language would
be horribly deficient in other ways, for other things you want to
solve, i dare guess.

the crux of the nut is the old saw that functional lets you easily
(which means: not have to edit already-existing code) add new
functions, whereas oo lets you easily add new datatypes.

if you look at the "wonderful" scala solution that was around a while
back, i think it has all sorts of less-than-idealness about it.)

[Raoul Duke]

http://stackoverflow.com/a/4185102

heh.

[Mark Tarver]

OK; if this is the problem then really there is no problem - not in
Shen. You can use side-conditions to any type and extend that type
dynamically while running your code. Globals, property vectors,
files, etc. can be accessed through a side-condition.

(datatype employees

if (element? Employee (value *employees*))
____________________________________
Employee : employee;)

Mark

On 18 Oct, 16:40, shaun gilchrist <shaunxc...@gmail.com> wrote:
> "The Expression Problem is a new name for an old problem. The goal is
> to define a datatype by cases, where one can add new cases to the
> datatype and new functions over the datatype, without recompiling
> existing code, and while retaining static type safety (e.g., no

> casts)." -http://www.daimi.au.dk/~madst/tool/papers/expression.txt

[David Nolen]

On Thu, Oct 18, 2012 at 3:02 PM, Mark Tarver <dr.mt...@gmail.com> wrote:

OK; if this is the problem then really there is no problem - not in
Shen.  You can use side-conditions to any type and extend that type
dynamically while running your code.  Globals, property vectors,
files, etc. can be accessed through a side-condition.

(datatype employees

   if (element? Employee (value *employees*))
   ____________________________________
   Employee : employee;)

Mark

It is useful for any such extension to module local. Is that the case in Shen?

David 

[Mark Tarver]

Sorry David, could you expand that question?

Mark

On 18 Oct, 20:06, David Nolen <dnolen.li...@gmail.com> wrote:

[David Nolen]

On Thu, Oct 18, 2012 at 3:07 PM, Mark Tarver <dr.mt...@gmail.com> wrote:

Sorry David, could you expand that question?

Mark

If I extend a type to add some novel behavior - does everyone see it? That is are other modules affected by this change.

In some languages this is called "monkey-patching" and you run into trouble when you load modules that have changed types shared across modules in incompatible ways.

It's preferable to support ad-hoc extension without affecting other consumers of the same data type.

David 

[Mark Tarver]

The solution in that case would be to update the global only within
some package or to declare the type within a package. In that way
only if the package was explicitly referenced could the type be
changed.

Mark.

On Oct 18, 8:12 pm, David Nolen <dnolen.li...@gmail.com> wrote:

[JS]

On Thu, Oct 18, 2012 at 12:40 PM, Mark Tarver <dr.mt...@gmail.com> wrote:
> The solution in that case would be to update the global only within
> some package or to declare the type within a package. In that way
> only if the package was explicitly referenced could the type be
> changed.

When you say "update the global only within some package", how is that
supposed to work? I didn't know globals could be scoped. (value
*something*) is going to return the same thing no matter if it's
executed from within a package or anywhere else, isn't it?

[Mark Tarver]

Yes; I imply meant that placing the global within a package would
restrict the tendency for a global to be overwritten by another
package is all. But dynamically extending a type during execution is
no problem though it carries risks..

Mark

On 26 Oct, 12:32, JS <j...@mentics.com> wrote:

[jo...@mentics.com]

On Thu, Oct 18, 2012 at 11:23 AM, Raoul Duke <rao...@gmail.com> wrote:
>>> http://www.ibm.com/developerworks/java/library/j-clojure-protocols/

>
> the article sounds very compelling, but then clojure is not statically
> typed, drat. :-(

Interesting thing I learned recently: there appears to be significant
progress done adding typed racket to clojure. So... clojure now has an
optional static type system.