Intent

[btanksley@hifn.com]

From: Jason Marshall [mailto:jmarsh@serv.net]

>>Okay, the topic is a lot clearer to me.  You want metadata, and you 
>>want it
>>embedded in the language.  IMO, it would be best as an 
>>optional thing, but I
>>don't mind it being required.  You don't actually object to 
>>concatenative
>>languages; you simply want a language with metadata provided.  (You 
>>should have _said_ that, instead of just stating that concatenative 
>>languages were inferior.)

>I want explicit metadata as a standard, yes.  If it's not part of the 
>design
>process, and doesn't improve static checking of the code, then I don't 
>know how Useful it is.

It is useful, but I have to agree that we can and should do better.

>While it's true that a lot of metadata can be 
>assigned at the
>function/method level, I am still not entirely grasping how 
>you prevent 
>loss of information in the translation from brain-to-silicon 
>within the body
>and signature of the method in a terse form that relies on deductive 
>logic.

Hmm.  I'm not following what you're saying here.  The two parts of this
sentence don't seem to me to be entirely connected logically.  Oh, BTW, I'm
getting a _lot_ of ugly linewrapping in your posts.  Is it just my really,
really vile email client (MS Outlook) or are your line lengths set too long?
Sorry.

I sense that the second half of the sentence requires some thought on my
part, but I can't figure out what you're asking for.  When I simplify the
sentence it makes even less sense: "How [do you] prevent loss of information
in a terse form?"

Perhaps if I rephrase: "What terse notations do you use to prevent
information loss _within_ a function body?"

I'm still puzzled, because this is the question to the answer I've already
given.

>>Okay, try this on for size: a concatenative language with two types of
>>annotation.  The first, in the form ( x -- y ), appears at the 
>>beginning of
>>the word definition and is a type description (x and y may be any 
>>number of
>>type names, seperated by spaces).  The last item in x is the type of 
>>the top
>>of the stack (as with traditional Forth stack comments).  Types are 
>>handled
>>entirely statically, and are fully polymorphic (including return 
>>values).

>>The second annotation, in the form ( x ), appears anytime within the
>>definition of a word, and is a stack naming (x may be any number of 
>>one-word
>>names).  Names for stack elements may be traced at compile time, and 
>>must be consistent within a given definition.

>>example:
>> 3 2 ( adder addend ) swap ( addend adder ) + ( sum )
>>or
>> ( number[myType] number[myType] -- number[myType] ) 
>>    ( adder addend ) swap ( addend adder ) + ( sum )
>>or
>> 3 2 ( adder addend ) swap ( adder ) + ( sum )

>>The last one of these demonstrates that the stack names don't have to 
>>name everything on the stack.

>I'm mostly worried about names between code modules, where most of the
>trouble will crop up.  

I think that's best handled by a word defined for that purpose -- I won't
burden the compiler down with more syntax.

>But if you name the variables, the system can labor to sort out which 
>variable
>order makes most sense, based on data alignment issues, frequency of
>argument use, difficulty of reordering at the caller, etc.

Names are irrelevant for that (pure dataflow is more than sufficient), and
the cure is to reorder the execution of your code.  My friend's optimiser
has the beginning of the code needed for that reordering.

>Your function 
>implementation from four months ago will likely no longer maintain your
>optimal ordering as you determined when you first wrote it, and woe be 
>unto s/he who changes the order of his arguments after everyone else
>is already using his/her code.

Who cares?  A stack juggle is almost instantaneous.  It's a waste of time if
you're doing them constantly, but that's easy to detect, and almost as easy
to solve.

>I keep bumping into situations where static type checking seriously 
>erodes
>the advantages gained by reflective code.  Sometimes pushing error 
>discovery off until runtime comes back to bite you in the butt.

Huh?  You keep coming up with these cool, true statements which seem to have
nothing to do with the discussion.  The interesting thing here is that these
two statements are at cross-purposes; one is advocating static checking, and
the other is dismissing it.

In fact, the advantages of static checking need not cause any problems to
reflective code; static checking does not have to remove dynamic binding or
dynamic type information.  IMO.

>>>Not in the least.  People want flexibility in a language in case
>>>the environment isn't subtle enough for their tastes.  Then they turn
>>>around and complain because everyone comes up with a 'clever' synonym
>>>for the code they would have written, sometimes correctly, sometimes
>>>totally wrong, but either way, totally greek to their peers.  
>>>Formalism
>>>takes the edge off such concerns over abuse of power.  Here is your
>>>rope sir, but you have to justify any requests to tie it into a knot.

>>The odd thing is that I think I understand what you're saying (both 
>>times
>>you've said it), and I'm just about certain I agree entirely with it, 
>>but I
>>_still_ don't see what on earth it has to do with our discussion.  
>>What does
>>this have to do with named parameters versus implicit parameter 
>>passing?

>Because formal logical naming of parameters is a type of formalism.  

Of course.  So are many other things, some of which are mutually exclusive
of named parameters.

>>>Concerns over how big an 'unabridged' edition of the machine would be
>>>have some merit, but not as much as you're attributing to the issue.

>>Okay, here's the concern I'm expressing: contrary to your statement, I
>>believe that my optimiser, with or without metainformation, will 
>>produce compact, efficient code.  I base this opinion on systems 
>>similar to mine, such as Quartus Forth and 4THCOMP.

>How do these systems benchmark compared to C or C++ equivalent
>code?  I've been curious about how these other styles compare to
>the rest of the industry.

Hmm...  Let me try to find some papers on that...
********************************************

>>>Different environments will contain a different subset of the content
>>>handlers for the language.  My deployment environments won't care 
>>>about
>>>debug data.  My dev environment will.  My palm pilot doesn't care 
>>>about
>>>MPP or high precision math or vector math, or advanced speed-for-
>>>space
>>>tradeoffs.  My workstation doesn't care about space-for-speed 
>>>tradeoffs,
>>>but when I'm downloading a new multiplayer game off the net, I'd much
>>>appreciate if it was usable the first time I ran it.  No VM I know of
>>>is giving me that.

>>Check out Elate, formerly known as Tao OS, at
>>http://www.tao.co.uk/2/tao/index.html.  Very cool.  Very similar to 
>>what Sam and I are building, and does exactly what you say.

>And commercial, yes?

Yes.  Which is irrelevant to our discussion, since I was providing a
proof-of-concept.

>If I've learned anything, it's that you always 
>give the razor
>away for free, and then you talk about selling the blades.

If I've learned anything, it's that there's more than one way to skin a cat.
No one aphorism always works, and analogies are very risky ways to think.

>Every language
>someone has forced developers to buy has been marginalized.

I agree.  Elate isn't a language.  It's a system which includes loaders and
translators for Java bytecode.

>You want to make
>money off a language?  Fine.  You wrote the thing, don't you 
>think that qualifies
>you to make a killing on consulting contracts?  Books?  Just please 
>stop this silly
>nonsense of trying to sell the basic runtime.

I agree.  Look at the J and K languages for examples of this kind of
silliness.  It's a real pity that such clever languages can't be more
useful.

But anyhow, again, Elate isn't a language, and even if it was I'm pointing
you to it so you can see how my system might wind up looking in the future.

>Jason Marshall

-Billy