Re: Slate for Tunes HLL? (was: Lambda (was: Refactoring inTunes))

"Brian T. Rice" wrote:
 
> The arrow system is absolutely not a language, it's something else.

I never objeted to this. Objecting to this statement requires at least
an agreement on the definition of the concept designated from the word
"language". Than a comparison between this concept and the concept of
"arrow system" that shows, without ambiguity, that the one could be
brought back to the other.

I have a little exposure to traditional methods to define various
aspects of a language: syntax (Chomsky's formalization), algebraic,
denotational and operational semantics, totally ignorant about pragmatic.
On the contrary, I have a still little understanding of arrow system.
So, for now, I accept this statement without objections (the paragraph
"4.1.3 Not A Language" of your "The Arrow System Philosophy" is too much
terse for me).

In any case, I have not confused your arrow system with Squeak, Self
or Lisp never.

> One way I've recently found to describe it is as a language-independent
> co-inductive type system. In that sense, I'm rejecting Squeak in favor of
> Slate, mostly because of language issues.

Do you want construct Slate for have a "co-inductive type system" in
which express the Arrow System, is it correct?
 
> I should also mention that one reason for using Squeak is that it has
> useful tools for generating parsers, and it is relatively simple to create
> a compiler from Squeak VM sources in the smalltalk language and the
> C-Translation library.

On the contrary, I'm objecting precisely to this method to implemet
Slate: the Squeak VM is written in C, if I'm not wrong, than you'll write
the Slate compiler in Smalltalk, than you'll metacompile this Smalltalk
code in C, is it right?
 
> I guess I should make it clear that I don't appreciate the HLL/LLL model at
> all. As I understand it, this involves using the LLL as an extension
> language as well as a close-to-the-hardware implementation hack that
> doesn't resort to unsafe assembly or c. This is totally not what using
> Squeak is about. The only thing I want is to implement Slate over a
> relatively abstract language, so that the source code exposes the semantics
> in simple terms.

This is the point: I'm absolutely not convinced about the necessity
of this multitude of layers of abstractions introduced by this
different languages/environments to the end of ".. implement Slate
over a relatively abstract language, so that the source code exposes
the semantics in simple terms". In other words, I don't understand
the diffused phobia to reach the machine level, in name of portability
or other reasons. The mention of Forth is not casual: it shows how
simple, but carefully selected, implementation techniques permit
an expressive power that varies from the machine level to a level of
abstraction sufficient for various applications. However, I'm not
proposing the Forth model (in particular, the traditional model)
*as is*.

> Otherwise, I will make no use of the implementation system.
> The same goes for the common lisp code currently being used.
> 
> At any rate, I can see that it's pointless to continue debating this. I
> will implement Slate in one way or another, and you will either accept it
> or reject it. That's all there is to it. The HLL/LLL issue is a non-issue.

I'm here to share, debate and learn ideas. Surely not to denigrate or
(worse) hinder the projects of anybody (and frankly I don't see how it
is possible to hinder a project through a mailing-list).

> >So ".. Slate is a testbed for some Arrow ideas ..", but I don't understand
> >what this means. Slate is only a preparatory work? Why this effort?
> >See later ...
> >> It's also nice to know someone's considering the semantic modelling
> >> capabilities of arrows to some extent. :)
> >
> >I want to emphasize: *some* extent. The Forth example is exactly this:
> >only an example! The underlying idea is: why not map *directly*
> >(1:1 or near 1:1) the arrow abstraction to machine level?
> >I have suggested the connection with Forth because is well-known
> >that is possible to map Forth directly to machine level, with less
> >possible layers of abstractions (this is the motivation for which
> >Moore has invented Forth). What are the difficulties of this operation?
> >
> >Because if you are not following this way evidently you think there are
> >some insurmountable difficulties. Why, on the contrary, do you think
> >that is necessary to interpose several layers of abstractions to
> >implement ".. some Arrow ideas .."? Arrows have certainly a powerful
> >semantic modelling capabilities but are even incredibly *simple*
> >(as I understand arrows).
> >Probably I miss something. Where am I wrong?
> 
> Yes, you're missing everything that I've written about arrows, which
> encompasses a much greater scope than "arrow logic". This entire
> development is not about layering abstractions, in the sense of
> implementation.

Here you completely ignore my question. Two cases: my proposal is 
completely foolish and thus is a waste of time to debate it (with
my understandig of arrow system this is not improbable at all. In this
case you can stop the reading here).

Or you read my proposal as "arrow system = language" probably because
my capacity to express ideas in english is quite scarce.
In this case I try to re-phrase the questions.

I make these assumptions (everyone of which you could reject,
of course):

1) the arrow system is a powerful modelling framework;
2) it's possible to model in the Arrow System (AS) a VM and/or
   a language (VM/L);
3) it's possible to model in the AS a VM/L especially suitable
   to describe the arrow system itself (or the key ideas);
4) it's possible to map this VM/L directly to the machine level;
5) it's possible to model the machine level (or a remarkable subset)
   in the arrow system at the end to facilitate (or even to prove
   the accuracy of) the mapping at the point 4;
6) it's possible to do this *practically*.

So, my questions are: do you have ever considered a development of
your system in this manner? In affirmative case, why do you have
rejected it?

> That arrow logic paper covers maybe 1% of my ideas for
> arrows, so don't identify my opinion with it's formalism. If you really
> want to ask questions about Arrow, quote the paper or something.

I never confused the arrow logic with your arrow system. It's only an
example and you can legitimate object the adherence to your system
but not assert that I confuse arrow logic with your system (in any case,
the eventual confusion is not intentional, I know that the paper on arrow
logic doesn't address your system specifically).

I have read your precedent paper and now I'm reading "The Arrow System
Philosophy". I hope to reach a better understanding of your proposal.

-- 
Massimo Dentico