Another stab at the HLL ...

[spc@gate.net]

On some network somewhere in cyberspace, premont@cs.toronto.edu transmitted:
>
> I'm not talking about doing occasional low level stuff from the HLL
> when the HLL isn't adequate. It should be possible to do that. I'm
> talking about low level programmers programming whole applications or
> whatever in their custum made language to play with the Tunes
> internals. I'm affraid nothing but the HLL will be able to allow low
> level programming since many aspects of the low level structure of
> Tunes will probably change dynamicaly as directed by the HLL (take
> data representations and calling conventions for exemples). This
> dynamism probably won't be there in the first implentations and thus
> it will be possible to write low level programs until dynamism is
> implemented. Then we will have to perform major rewrites of the low
> level stuff (in something more like the HLL) to make it configurable
> by the HLL.
>
  This is EXACTLY what bugs me about the supposed HLL.	That somehow, all
these messy details about concrete implimentation details will be
automagically taken care of, somewhere.  Somehow.

  How?

  I'm not looking for the final answer.  I'm just looking for AN answer that
reasonably answers the question.  At at a fairly low level.  As in bits being
moved about the computer.

  Okay, maybe an example is in order.  Using the Mythical HLL, I develop,
what?  An object?  A class?  Library?  Subroutines?  Something.  For the sake
of argument, I develop Something that impliments a way to simulate rolling
dice.

  The Argument is in the form of 'XdN', where:

	X - Positive integer greater than 0.  This is optional, and if not
	    specified, defaults to the value of 1.  This represents the number
	    of "dice" to roll.
	d - the literal character 'd'.  This is required.
	N - Positive integer where the following values are the only ones
	    allowed:  4,6,8,10,12,20,30 and 00[1].  This is required and there
	    is no default value.

[1]	if '00' is specified for N, X is not allowed to be specified and
	defaults to the value 1.

  The Something works by simulating a roll of an N sided die X times [2] and
returning the sum of all the rolls, plus the individual rolls.	For lack of a
better term, these results are returned in a List (not the LISP kind either.
More of an open ended array) where the first element is the total, and the
rest are the individual values.

[2]	If '00' is specified for N, the result is one roll of a hundred side
	dice.

  The notation was picked since it's a common notation that gamers use.  How
it's passed in is of no concern, right?  And how the results are passed out
are of no concern, right?  Okay.

  Now, Fare, you are implimenting a craps game.  So far, the only "Dice"
Something out there is my package.  Okay, a craps round, as far as my Dice
Something goes, is a single call with the Argument of:

			2d6

  And you get the results of two six sided dice being thrown.  Okay so far.

  Now the hitch.  Patrick out there writes a new "Dice" Something, allowing
one to specify different sized die in a single throw.  The Argument(s) for his
Dice Something are:

	 A Series of positive integers, larger than 0, each representing
	the number of sides for a die.	The result is a List which contains
	the individual results, with the total as the last element.

  Now, for the sake of argument, you, Fare, like Patrick's Something better
than mine.  But, the argument for your craps game would look like:

			6 6

  Now, this being Tunes, that doesn't matter, right?  You can just plonk in
Patrick's Dice Something and not have to change a thing, right?  Because the
messy details of calling conventions, return results and data representations
don't matter, right?

  THEN HOW THE BLOODY HELL DOES THIS WORK?  (Excuse my Engligh)

  -spc (And please, some CONCRETE examples.  Implimentation details.
	Something better than "Automagically".  Please.)