Re: [Scheme-reports] WG1 Scheme as a language for CS1 Jeronimo Pellegrini (09 May 2011 03:12 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 John Cowan (09 May 2011 16:57 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Jeronimo Pellegrini (09 May 2011 18:06 UTC)
Re: WG1 Scheme as a language for CS1 Arthur A. Gleckler (09 May 2011 18:10 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Jeronimo Pellegrini (09 May 2011 18:34 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Andy Wingo (09 May 2011 21:56 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Ray Dillinger (11 May 2011 03:14 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Alaric Snell-Pym (10 May 2011 09:00 UTC)
Re: [Scheme-reports] WG1 Scheme as a language for CS1 Alaric Snell-Pym (10 May 2011 08:54 UTC)

Re: [Scheme-reports] WG1 Scheme as a language for CS1 Alaric Snell-Pym 10 May 2011 08:58 UTC

On 05/09/11 19:34, Jeronimo Pellegrini wrote:
> On Mon, May 09, 2011 at 11:09:34AM -0700, Arthur A. Gleckler wrote:
>>>
>>> If you'd like to see threads in WG1, it would be nice to provide us with
>>> some kind of rock-bottom-minimum API; SRFI 18 is huge, and it's far from
>>> clear to me that mutexes and condition variables are even the right
>>> abstraction (some kind of CSP would appeal to me much more, but that's
>>> just me).
>>>
>>
>> I also prefer CSP when writing programs, but it makes sense to include the
>> most fundamental mechanisms, e.g. at least mutexes and condition variables.
>>  As Jeronimo points out, they are the primitives out of which higher-level
>> abstractions like CSP can be implemented.
>
> It may be that WG1 has conflicting goals. A minimalistic language would
> have continuations but not excaptions; maybe a clock for seeding random
> generators, but not the generators themselves; condition variables and
> mutexes, but not mailboxes or other easier synchronization tools...

Minimalism is a pressure to shrink the feature set, but it must also be
paired with a point at which you stop. Otherwise, we wouldn't need
numbers. Church numerals for the win!

Now, I strongly supported exceptions for the following reason: Having a
single central exception mechanism, on top of which others can be built,
means that you can always guarantee to be able to trap exception exits
(while not trapping non-exceptional exits caused by people using
continuations in creative ways). This means that all well-written
exception handling libraries built on WG1 will be able to correctly
catch each other's exceptions, even if they can't then understand the
exception object they get. Which makes it safe to write top-level "grab
all exceptions random libraries may throw" handlers in your UI main loop
and the like.

> But a "small language for learning only how to do basic programming" may
> need an exception system, and not continuations; RANDOM; mailboxes
> for synchronization, and so on.
>
> This is because it's not always the case that complex things are built
> on top of simpler things. Quite often the opposite happens.

Indeed, balancing different needs and finding a common core that nobody
objects to too strongly, and that doesn't lack things people love, can
be challenging! It's a very subjective decision, to be honest...

> But in spite of that, I do like what the working group has done.

Thank you ;-)

>
> J.
>

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports