Re: discriminant questions

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 30.09.11 14:38, Dmitry A. Kazakov wrote:
> On Fri, 30 Sep 2011 12:07:53 +0200, Georg Bauhaus wrote:
> 
>> Back on track: my question was whether or not a language should
>> enable programmers to implement or override what is built into the
>> language core.
> 
> It should not.

Aha!

>> Whether or not programmers should be able to correctly manipulate
>> language features.
> 
> They should not. 

So that's a no.

Then:

>> Should a language like Prolog be defined such that (...)
>> replace the backtracking implementation with one of their own?

> Yes, if Prolog designers wished it survive... but they didn't.

And that's a yes.

Can the contradiction be resolved?

The example about Prolog and its struggle for existence
would emphasize my point. The example would show one way
in which compiler making and language making are not
independent in some situations. The aspect being that economic
rationality would suggest programmer-defined language built-ins.
(If it sells, ...)


> I bet that practically no program uses the number -435167342. Is it not
> general purpose?

It is not, if no purpose can be specified, and I suppose that
few language standards talk about the number -435167342.
(Maybe the telephone directory of Eckernf�rde does :-)
Numeric types will more likely match general purpose.

Anyway, a language standard may define a set of operations,
such as Sqrt, and say that they are available in the core language.
Array concatenation is one such operation, Sqrt isn't.


>> I'll also prefer "task" to mean something that Ada programmers would
>> recognize.
> 
> As something, which is not a task?
> 
> I don't understand what you are trying to say. Task is fundamental to
> concurrent computing, they cannot be expressed in any other terms.


The notion of Ada tasks is a composite notion. A task has ...
A task operates this way [sequence of conceptual steps] ...
A task type is ...  Hence, seen as a notion, a task is not atomic.
Typical facilities of an Ada task can be built from other primitives
of concurrent programming, if one were to do this in another language.
Compiler writer must do this. For programmers, Ada has much of it in
the language, Java programmers will find little in the language,
but a fair bit in java.util.concurrent.*, i.e. a library.
And the necessary discipline.
Coming back to the selection of built-ins for a language,
communicating tasks are an important building block. The importance
is reflected in its special presence in Ada, the language.
It has special syntax. Ada tasks do not come from some library.

Since the Ada notion of task incorporates many facilities
that can be taken for granted, I call tasks heavy, in this
sense.

Since we have protected objects, sometimes qualified to be
light weight, there must have been another notion of "heavy"
associated with task. (I.e., in another sense.)

>> Plus: 4) compiler making business requirements,
> Irrelevant.
Practically, compiler making business is rather decisive.
Just look at who is active on behalf of the ARG; Google is paying
... for Python, Go ...,  MS is paying ... for language research
(including standardized languages like C++ or Javascript), the
WGs being  staffed by ...

>> 5) programmers, customers,
> Programmers /= customers
Yes.

> Anyway, you didn't answer which category is supposed to decide what is
> "heavy".

People from all of the categories try to move decisions in certain
directions. That's necessarily my point. To learn about why a feature
should go into a language, it takes an interdisciplinary approach,
not just because it might be desirable, but because this is what
happens as soon as a language starts to have a significant number
of users.  I should add 6), which is fashion, which sometimes
facilitates (and funds!) a language effort in the first place.

For example, Douglas Crockford has commented on the pressure that
Microsoft (and others?) are exercising on the development process of
Javascript. They want the language such that their other languages
would have a better backend (i.e. Javascript being the target language).


>> A general purpose programming language will IMHO either
>> be a panacea that includes, in its definition, every mechanism ever
>> invented,
> That would be just a poorly designed language.
OK

>> or tries to be minimal in some sense.
> 
> This applies to *any* language.

Being minimal applies to any language only if one trivializes
"minimal in some sense", which is a trap. The "some sense"
part is the interesting part.


>> Alternatively, the customer/programmer can just have
>> a Prolog shop make an implementation the meets their special requirements.
> 
> See above. It didn't work in 60s,

It works for some of the Ada business now, if I'm not mistaken.
A nice thing is that programmers can still write core Ada by the
book and talk to the compiler guys about what their run-time
should do.