Wojciech Kaczmarek | 1 Jul 2007 12:16
Picon

Choice points

Hello,

I'd like to experiment with non-deterministic choices (cf. CTM book, chapter 9). In Oz the choice statement is implemented using Space.choose function. How to mimic this behaviour using Alice with gecode library?

cheers,

Wojtek

_______________________________________________
alice-users mailing list
alice-users <at> ps.uni-sb.de
http://www.ps.uni-sb.de/mailman/listinfo/alice-users
Guido Tack | 2 Jul 2007 11:40
Picon

Re: Choice points

Hi!

Wojciech Kaczmarek:

> I'd like to experiment with non-deterministic choices (cf. CTM  
> book, chapter 9). In Oz the choice statement is implemented using  
> Space.choose function. How to mimic this behaviour using Alice with  
> gecode library?

Nondeterministic choice like in Mozart is not supported in Alice.

Cheers,
	Guido

--

-- 
Guido Tack
Programming Systems Lab, Saarland University, Germany
http://www.ps.uni-sb.de/~tack
Wojciech Kaczmarek | 2 Jul 2007 14:44
Picon

Re: Choice points

On 7/2/07, Guido Tack <tack <at> ps.uni-sb.de> wrote:

Hi!

Wojciech Kaczmarek:

> I'd like to experiment with non-deterministic choices (cf. CTM
> book, chapter 9). In Oz the choice statement is implemented using
> Space.choose function. How to mimic this behaviour using Alice with
> gecode library?

Nondeterministic choice like in Mozart is not supported in Alice.

What I have in mind is to mimic it by tinkering with computational space. Failing the space is possible. Branching is done at high-level in gecode lib. I was wondering if there is a low-level api for creating a child space and manually decide what constraints are to be added there. Just something like Space.choose in Oz.

So are you saying it's inherently impossible because of some Alice internal mechanisms or that just there's no api to do/simulate it?

cheers
 


_______________________________________________
alice-users mailing list
alice-users <at> ps.uni-sb.de
http://www.ps.uni-sb.de/mailman/listinfo/alice-users
Guido Tack | 2 Jul 2007 16:07
Picon

Re: Choice points

Wojciech Kaczmarek wrote:

> What I have in mind is to mimic it by tinkering with computational  
> space. Failing the space is possible. Branching is done at high- 
> level in gecode lib. I was wondering if there is a low-level api  
> for creating a child space and manually decide what constraints are  
> to be added there. Just something like Space.choose in Oz.

The advantage of Space.choose is that it is compatible with the  
Space.status method, i.e., it works out-of-the-box with existing  
search engines. Something like that cannot be done in Alice/Gecode,  
because it would require installing a branching in the Gecode space  
that is then called back from the status function.

What you can do, however, is to implement your own search engine.  
That would allow you to post arbitrary constraints, also based on the  
current state of the space. You can look at the source code of the  
Alice search engines, which is in lib/gecode/Search.aml, to get an  
idea for the implementation.

Cheers,
	Guido

--

-- 
Guido Tack
Programming Systems Lab, Saarland University, Germany
http://www.ps.uni-sb.de/~tack
Lucas Dixon | 3 Jul 2007 17:28
Picon
Picon
Favicon

Re: picking, signatures, LCF, and a wee bug...


Andreas Rossberg wrote:
> "Lucas Dixon" <ldixon <at> inf.ed.ac.uk>:
>> 
>> Given the modular design Alice, I suspect this should be easy, I
>> would guess that the top-level is just an incrementally compiled
>> module. So it should be possible to end the module and pickel it.
> 
> It's not that simple. The main problem is that Alice does not allow 
> pickling of resources. So you cannot just pickle the continuation of
> the interactive loop, since it will certainly contain resources like
> I/O streams etc. Even if you factorise away this problem, you cannot
> pickle the current dynamic environment of the toplevel loop, since it
> will likewise contain resources.

I was not imagining  pickling the interactive loop itself, which will
have a IO stream to stdin/stdout, but the result of it. I know that
alicec can compile arbitrary ML files (presumably assuming that no
streams are left open?). So I thought that similar behavior must be
possible with the a user interaction - just take the users input lines
as lines in a file that is being compiled. The result would be a
compiled alice component, which, I thought, was pickleble?

For instance, I could write a very slow and ugly version of the idea in
a scripting language that, for each line that is entered creates a new
file, which it then compiles with alicec, importing the previous files.
I expected that this could be done properly within Alice herself because
there are no external resources or context... or perhaps there is some
fundamental thing I am misunderstanding?

thanks,
lucas
Makarius | 3 Jul 2007 17:38

Re: picking, signatures, LCF, and a wee bug...

On Tue, 3 Jul 2007, Lucas Dixon wrote:

> Andreas Rossberg wrote:
> > "Lucas Dixon" <ldixon <at> inf.ed.ac.uk>:
> >> 
> >> Given the modular design Alice, I suspect this should be easy, I
> >> would guess that the top-level is just an incrementally compiled
> >> module. So it should be possible to end the module and pickel it.
> > 
> > It's not that simple. The main problem is that Alice does not allow 
> > pickling of resources. So you cannot just pickle the continuation of
> > the interactive loop, since it will certainly contain resources like
> > I/O streams etc. Even if you factorise away this problem, you cannot
> > pickle the current dynamic environment of the toplevel loop, since it
> > will likewise contain resources.
> 
> I was not imagining  pickling the interactive loop itself, which will
> have a IO stream to stdin/stdout, but the result of it.

My impression is that pickling (and resources) is not the main concern 
here.  The main problem is not so much persistance, but being able to 
``use'' ML sources at runtime, affecting the global compiler environment 
(and mutable values), but continuing execution as expected.

A few weeks ago, just before I left for vacation, there was a proposal to 
use the component manager of Alice to bring compiled code back into the 
current toplevel.  What happened to that attempt?

	Makarius
gabriele renzi | 4 Jul 2007 09:47
Picon
Favicon

Style comment on alice Socket usage

Hi everyone,

I'm trying again to learn Alice again and I was trying to write a dummy
echo server, the cod I came up with is this:

fun serve (socket, host, port) =
	let
		val lineOpt = Socket.inputLine socket
	in
		case lineOpt of
			  SOME(line) => print line
			| NONE	     => ()
			;
		
		Socket.close socket
	end

val port = SOME 8802;
val (socket, port) = Socket.server (port, serve);
	
which imposes serialization of the requests. Now, if I want to serve
concurrent requests it seem enough to add "spawn" to the serve
declaration.

Is this correct idiomatic code or am I doing something stupid ?

Thanks in advance :)

--

-- 
goto 10: http://www.goto10.it
blog it: http://riffraff.blogsome.com
blog en: http://www.riffraff.info
Andreas Rossberg | 4 Jul 2007 12:07
Picon

Re: picking, signatures, LCF, and a wee bug...

From: "Lucas Dixon" <ldixon <at> inf.ed.ac.uk>:
>
> I was not imagining  pickling the interactive loop itself, which will
> have a IO stream to stdin/stdout, but the result of it. I know that
> alicec can compile arbitrary ML files (presumably assuming that no
> streams are left open?). So I thought that similar behavior must be
> possible with the a user interaction - just take the users input lines
> as lines in a file that is being compiled. The result would be a
> compiled alice component, which, I thought, was pickleble?

Actually, you do need neither alicec nor pickling to do that, as the 
Compiler structure from the Alice library allows you to compile directly 
from a string to a first-class component value in memory. You can pass such 
values directly to the component manager for evaluation.

Given that, what you describe is pretty much the implementation of the Alice 
toplevel. So yes, your suggestion is workable. But admittedly, I do not 
fully understand what you are getting at. It seems that what you are 
considering boils down to 'using' files by compiling and evaluating them 
line by line (or rather, dec by dec). I already proposed something along 
these lines in an earlier post:

http://www.ps.uni-sb.de/pipermail/alice-users/2007/000785.html

I think it should be fairly easy to write a wrapper to the 'use' function 
that operates that way (i.e., splits the file and then uses each bit 
separately). That doesn't even require changing or redoing the toplevel 
implementation - just import the wrapper into the toplevel before use-ing 
anything.

Obviously, this would be simpler if there was some form of 'useString' 
function. Then you'd just do

fun splitSource (s : string) : string list = ...   (*) some string hackery

val useStringProper = useString
fun useString src = List.app useStringProper (splitSource src)
fun use file =
    let
       val f = TextIO.openIn file
       val src = TextIO.inputAll f
    in
       TextIO.closeIn f;
       useString src
    end

Short of that, you have to create temporary files. Here is a skeleton 
(untested):

val useProper = use
fun use file =
    let
       val f = TextIO.openIn file
       val src = TextIO.inputAll f
       do TextIO.closeIn f
       val srcs = splitSource src
       val files = List.tabulate (List.length srcs, fn _ => 
OS.FileSys.tmpName ())
       val final = OS.FileSys.tmpName ()
       val ffinal = TextIO.openOut final
    in
       ListPair.app (fn (src, file) =>
          let
             val f = TextIO.openOut file
          in
             TextIO.output (f, src);
             TextIO.closeOut f;
             TextIO.output (ffinal, "do OS.FileSys.remove \"" ^ file ^ 
"\"\n");
             useProper file    (*) queue it
          end) (srcs, files);
       TextIO.closeOut ffinal;
       useProper final      (*) remove temp files
    end

Admittedly, this is quite a hack with all the temporary files. But it should 
work. Maybe I'll add a useString function for the next release. :-)

Hope that helps,
- Andreas
Andreas Rossberg | 4 Jul 2007 12:22
Picon

Re: Style comment on alice Socket usage

From: "gabriele renzi" <rff_rffREMOVE <at> yahoo.it>:
> 
> fun serve (socket, host, port) =
> let
> val lineOpt = Socket.inputLine socket
> in
> case lineOpt of
>   SOME(line) => print line
> | NONE      => ()
> ;
> Socket.close socket
> end
> 
> val port = SOME 8802;
> val (socket, port) = Socket.server (port, serve);
> 
> which imposes serialization of the requests. Now, if I want to serve
> concurrent requests it seem enough to add "spawn" to the serve
> declaration.
> 
> Is this correct idiomatic code or am I doing something stupid ?

Looks fine to me. Do you experience problems running it?

Cheers,
- Andreas
Tom Ridge | 4 Jul 2007 13:41
Picon
Picon
Favicon

Socket SML basis library

Dear All,

Alice ML provides a simplified version of the Sockets interface defined in the SML basis. Is there a way to
access the (non-simplified) Sockets interface as defined in the SML basis?

Thanks

Tom

Gmane