headers
Niko Korhonen | 2 May 2006 09:00
Picon

Re: Fun with packing

Lex Spoon wrote:
> It seems to me that it is Boo in the bad position.  What kind of
> collections library does Boo have in its 70 kB DLL?  What kind of XML
> support?  What concurrency models are available?

Everything that's available in the .NET Framework and Python-style 
arrays, lists and hash tables. In a similar manner that Scala has 
everything that's available in Java standard library.

> Scala's bytes buy
> you a lot.  It would strike me as negative progress to start worrying
> more about bytes than about functionality and convenience.

In a regular case I'd agree strongly, however...

> That said, maybe you can be more specific about what kinds of
> applications you are picturing that Scala misses out on?

...I'm thinking of small applet-like tools and CLI/GUI utilities. In 
Java, if you assume that all clients have a compatible JRE installed, 
you can write a nifty and even pretty complex tool that fits into a 10 
kilobyte JAR, because only the application code must be distributed.

If you write ten nifty tools in Scala, you have to redistribute the 
Scala runtime library with each of them. Suddenly the 10 * 10 kB 
download becomes 10 * 10 + 1048 kB.

If you're writing a /large/ application in Scala, where the Scala 
runtime size is insignificant compared to the application distribution 
size, or the application is distributed offline, or the functionality of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Matthias Aust | 2 May 2006 11:38
Picon

Re: Continuations in Scala?

Florian,

Florian Hof schrieb:

> As you have guessed, I have used closures instead of real continuations, 
> but it's sufficient and is actually exactly what we need. The idea of my 
> framework is similar to your small example.

Thanks for sharing this. Being somewhat ill, I finally had the time to 
read your thesis. Quite interesting and well written (understandable 
even with mild flu ;) but also quite tricky.

Perhaps too tricky. I'm not sure.

You wrote that it would be very interesting to measure performance data 
which was out of scope for your work. You probably meant runtime 
performance data (speed, memory) but I think, even more interesting 
would be to measure "developer performance". Does this approach has 
measurable advantages over the "traditional" approach?

I've no good idea how to measure this, though.

For quite some time, I'm trying to come up with some interesting pet 
project or some class of problems where continuations might really save 
time and effort - compared to let's say a decent agile web framework 
like Rails. My fear is that the "sum of all problems" is more or less 
constant - but I'd love to be proven wrong.

While complex interactions are easier to express with continuation style 
- simple control flow is not. The question is, which kind of interaction
(Continue reading)

Permalink | Reply | 3 comments |
headers
Florian Hof | 2 May 2006 22:14
Picon
Picon
Favicon

Re: Continuations in Scala?

Le 2 mai 06, à 11:38, Stefan Matthias Aust a écrit :

> Florian,
>
> Florian Hof schrieb:
>
>> As you have guessed, I have used closures instead of real 
>> continuations, but it's sufficient and is actually exactly what we 
>> need. The idea of my framework is similar to your small example.
>
> Thanks for sharing this. Being somewhat ill, I finally had the time to 
> read your thesis. Quite interesting and well written (understandable 
> even with mild flu ;) but also quite tricky.
>
> Perhaps too tricky. I'm not sure.
>
> You wrote that it would be very interesting to measure performance 
> data which was out of scope for your work. You probably meant runtime 
> performance data (speed, memory) but I think, even more interesting 
> would be to measure "developer performance". Does this approach has 
> measurable advantages over the "traditional" approach?

I meant runtime performance data. It would be a constraint for an 
effective use.
I have not spoken about "developer performance", but I see it related 
to convenience (for web developers). The project is focused on 
developers.

Developer performance is difficult to measure. An easier measure, 
although not perfect, could be the length of sources. I expect sources
(Continue reading)

Permalink | Reply | 2 comments |
headers
Judson, Ross | 3 May 2006 03:49
Favicon

RE: Re: Fun with packing

Thanks for doing this; I have been unavailable for the past few
days...apologies for not answering sooner.

Pack200 appears to be very efficient at compressing .class files in
general; the -Ustrip pulls away the attributes that Pack200 doesn't do
much with (the gzipping helps somewhat, but isn't as good as not having
them there in the first place).

This is really about deciding if it's worthwhile to have a "deploy" mode
for Scala, versus a "compiled" mode.  I'd say the jury is still quite
out on that one.  There are a limited set of circumstances under which
we want the compression we're outlining below, and perhaps having a tool
that can get us there is good enough.  

It is useful to know how dense compiled Scala can become!

RJ

-----Original Message-----
From: news [mailto:news <at> sea.gmane.org] On Behalf Of Stefan Matthias Aust
Sent: Sunday, April 30, 2006 5:56 PM
To: scala <at> listes.epfl.ch
Subject: Re: Fun with packing

Martin Odersky schrieb:
> I think it would be good to see for scala-library the following data:
> 
> 1. size of original jar
> 2. size of original jar treated with pack200 3. size of jar with scala
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stefan Matthias Aust | 3 May 2006 14:24
Picon

Re: Continuations in Scala?

Florian Hof schrieb:

> I have not spoken about "developer performance", but I see it related to 
> convenience (for web developers). The project is focused on developers.

Yes, I know that you didn't take about "developer performance". I wanted 
to mention that I consider this the more important factor.  Faster 
machine are usually quite affordable.  And if there are no faster 
machine, just add more. Web applications typically scale very well.

However, you can't "scale" developers by just adding more :)

> Developer performance is difficult to measure.

Indeed.

> An easier measure, although not perfect, could be the length of sources.

Well yes.  Once you have code, the application is the easier to 
understand the less you have to read.  Unfortunately, for initial 
writing, this mostly measures "typing speed".

A better metric would be the time you need from the problem to your 
first solution, that is the time required to express you ideas with 
code.  This is incredibly hard to measure and very dependent on the 
individual developer.

Still, I think, the language and its paradigm can affect this time.

> For code length, I'm happy with my example of a (really basic) wiki
(Continue reading)

Permalink | Reply | 1 comment |
headers
Florian Hof | 3 May 2006 22:27
Picon
Picon
Favicon

Re: Continuations in Scala?

> Still, I think, the language and its paradigm can affect this time.

Of course, otherwise let's write web applications in Fortran.

>> For code length, I'm happy with my example of a (really basic) wiki 
>> dictionary which is less than 400 lines, including a lots of 
>> comments. See my sources for details (link given in my previous 
>> post).
>
> Well, used to "old school" web application, I find that application 
> very difficult to understand.  You basically dispatch commands in the 
> for-loop of start(), just as you'd do without continuations. There's 
> preprocess() which seems to deal with authentication but then, it also 
> lists the word - why isn't the main loop in start() dealing with that 
> command? All these nested ifs in logIn are also difficult to grasp. It 
> is not clear to me why you need to call preprocess() from inside the 
> logIn() function.  Don't get me wrong, you code isn't bad, it's just, 
> that I don't find it obvious.

Effectively, the idea is that there is one continuation for each HTML 
page (because there is only one execution state at the page's 
creation).  The drawback is that you have to handle all possible links, 
including "global" ones likes "home" and "login". The last idea (see 
below) would offer a better approach. But it moves away from the 
concept of continuation.

> Have you looked at Seaside?  It tries to mix continuation and a 
> traditional component based framework and is quite successful.

I have only looked what it is for, not how to develop with it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
burak.emir | 7 May 2006 14:45
Picon
Picon
Favicon

on script-shipping and "send/suspend/callback" using staged code instead of first-class continuations?

Hi there,

mzscheme's "send/suspend/callback" emerged on the wishlist for scala web app
development.

Let me try to summarize. Some languages tweak control-flow in a similar manner
to Scala's webcont

* Scheme is the language where all the continuation business started
* Seaside is the SmallTalk version of the continuation dance

But they use first-class continuations and don't live in the statically strongly
typed Scala world. The Scala webcont library/framework lives in this world, and
its main goal was to make *straight line programs* fit for web apps. It's in its
early stages but already has a proof of concept that it works.

Now here's Stefans code again to see what is missing (all very close to what is
on the agenda for Links)

(define (show-page id request)
(send/suspend/callback
     `(html
      (head (title "View " ,id))
       (body (h1 ,id)
             (p ,(wikify id))
             (p
              (a ((href ,(? (r) (edit-page id r)))) edit)
              (a ((href ,(? (r) (delete-page id r)))) delete)))))))

Points to remember:
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jamie Webb | 8 May 2006 00:30

Re: on script-shipping and "send/suspend/callback" using staged code instead of first-class continuations?

On Sun, May 07, 2006 at 02:45:41PM +0200, burak.emir <at> epfl.ch wrote:
> I can thus imagine some markup like this
> 
> <a href={ editPage(): Code[unit] }>edit this page</a>
> 
> (staged code means it is left symbolic) and refine the server actions to the
> following
> 
> 1a) the server invokes show-page and obtains the markup with the *staged* code.
> 1b) for each staged code bit it encounters, it constructs the appropriate
> continuation, stores it somewhere and fills in the href-string.

Why go to all that trouble? Given a function:

def store(f : Request => Node) : String = {
	// Save f for later and return a unique URL for it
}

We can write:

<a href={ store(r => editPage(id, r)) }>edit</a>

Job done.

Having said that, I don't think this design is a good idea, or rather
that the marginal programming elegance it affords comes at a high
price which is very rarely worth paying. It introduces a lot of
unnecessary server-side state which clobbers application scalability,
subjects the user to annoying timeouts, makes URLs non-memorable,
non-bookmarkable and unfriendly to Google, and causes redeployment
(Continue reading)

Permalink | Reply | 6 comments |
headers
Lex Spoon | 8 May 2006 18:20
Picon
Favicon

Re: on script-shipping and "send/suspend/callback" using staged code instead of first-class continuations?

Jamie Webb <j <at> jmawebb.cjb.net> writes:
> > 1b) for each staged code bit it encounters, it constructs the appropriate
> > continuation, stores it somewhere and fills in the href-string.
> 
> Why go to all that trouble? Given a function:
> 
> def store(f : Request => Node) : String = {
> 	// Save f for later and return a unique URL for it
> }
> 
> We can write:
> 
> <a href={ store(r => editPage(id, r)) }>edit</a>

Yes, this store() function for registering a callback sounds like a
simple place to start along the way to trying more exotic things.
Then you can use the facility however much seems appropriate for your
application.

Incidentally, I do not understand the emphasis on staged code.
Seaside does not use it in the examples I have read, and the `(...)
format of Scheme is actually desugared at compile time.  For example,
this:

    '(p ,(wikify id))

desugars into this:

    (list 'p (wikify id))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Burak Emir | 8 May 2006 19:26
Picon
Picon
Favicon

Re: on script-shipping and "send/suspend/callback" using staged code instead of first-class continuations?

Jamie Webb wrote:

>On Sun, May 07, 2006 at 02:45:41PM +0200, burak.emir <at> epfl.ch wrote:
>  
>
>>I can thus imagine some markup like this
>>
>><a href={ editPage(): Code[unit] }>edit this page</a>
>>
>>(staged code means it is left symbolic) and refine the server actions to the
>>following
>>
>>1a) the server invokes show-page and obtains the markup with the *staged* code.
>>1b) for each staged code bit it encounters, it constructs the appropriate
>>continuation, stores it somewhere and fills in the href-string.
>>    
>>
>
>Why go to all that trouble? Given a function:
>
>def store(f : Request => Node) : String = {
>	// Save f for later and return a unique URL for it
>}
>
>We can write:
>
><a href={ store(r => editPage(id, r)) }>edit</a>
>
>Job done.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane