[Tfug] Language choices

Tim Ottinger tottinge at gmail.com
Wed Nov 8 07:21:05 MST 2006


> But no. Transactions probably have to be another specific addition to the
> > grammar. Sigh. I know that if I wrote my programs they way they write
> their
> > grammars, my coworkers would make me refactor it.  And might pick on me.
> >
> >
>
> As far as why "synchronized" is part of Java grammar... if I remember
> correctly, it is to signal to the JVM that a method can only be
> executed in one thread at a time.


Right.  And that could have been done with a more general mechanism.
You have underlying mutexes already, and we did something rather like
the snippet above for years in C++.  Our term for it was  Resource
Aquisition
is Initializatoin (from Cope, I think: RAI).  It worked in C++ for reasons
it
would not work in Java -- every local object was destructed at the end of
the file.  That meant that creating an object before a chunk of code was
effectively the same as wrapping that code with the constructor and
destructor of the object.  It was a general mechanism, and it worked
well.   I'm not saying Java can/does work that way, but that Java needed
an equally useful (and hopefull more intentional) general mechanism.

Not that I know what language you are writing in, but I fail to see
> how your instantiation above helps at all in this case  without help
> of some kind of semaphore.


In the above case, the "synchronized" would not be a keyword but
an object or class. The Synchronized class would use semaphors,
the Transaction class would use transactions, the mmap would
use memory mapping, etc.  It would be in the library, not the
language.

Aren't you going to get in trouble if two
> threads instantiate synchronized at the same time?


Nope. Never did in C++ either.

Even with your
> much beloved closures?


Nope.

Assuming  your language is providing a
> semaphore for you, how do you then signify that threads can run
> concurrently?


Because threads would be objects also, and they would receive
closure parameters. You would tell them to run concurrently.
BTW: Python isn't ideal here. You end up either deriving from a
thread class or else passing a function pointer (named, real function)
to a thread instance. But it works very well, if the syntax is not all
that I'd like.

I also doubt that "transactions" have to be part of the grammar.


I would hope not. They should use the same wrapping mechanism
that synchronized should use, which of course does not exist.

Are we talking right past each other?  I see what you say, but I don't
know how to express the thing I'm talking about.

Whether you or I like closures or not is immaterial.  The point is that
they allow a much smaller and simpler grammar partly because having
closures  makes more general mechanism possible.  Having more
general mechanism makes the library more consistent and powerful
and makes the language  much more simple (in terms of fewer keywords,
operators, etc).

The reason smalltalk only has 5 keywords is that it supports closures.
closures add only these symbols: [, ], |  It's a very small price to pay
to keep the grammar that small and simple.  In ruby it adds {, }, | and
the alternatives do...end.


Once
> you can define atomic operations in a language, then I would figure
> you could pretty much come up with a transactional system.  I mean,
> people have been doing that for a very long time in languages with
> relatively few grammar rules.  But maybe, I am misunderstanding your
> point...


My point is that it should not be part of a language, and that  we've had to
do it in langages with far too much grammar because we didn't have
closures -- hence the "far reaching" bit about closures.

I think that I'm not going to make this point in english text.  I think you
will have to get into a language with closures to see it.



More information about the tfug mailing list