Re: Phoenix language

[Dr. H. Nikolaus Schaller]

Am 23.10.2014 um 11:16 schrieb Gregory Casamento <greg.casamento@gmail.com>:

> Nikolaus,
> 
> On Thu, Oct 23, 2014 at 3:39 AM, Dr. H. Nikolaus Schaller
> <hns@computer.org> wrote:
>> Hi,
>> 
>> Am 23.10.2014 um 00:22 schrieb Gregory Casamento <greg.casamento@gmail.com>:
>> 
>>> Dr. Schaller,
>>> 
>>> On Wed, Oct 22, 2014 at 6:06 PM, Dr. H. Nikolaus Schaller
>>> <hns@computer.org> wrote:
>>>> 
>>> [ snipped.. ]
>> 
>> [reinserted to have the real context]
>> 
>>>>> There was, in fact, some discussion on these lines.  There were
>>>>> postings to the list about swift when the language was first
>>>>> announced.   The decision at that time was to write one if Apple
>>>>> didn’t open theirs.
>> 
>>>> 
>>>> I remember some discussion but wasn’t aware that such a decision was taken.
>>> 
>>> That's because I'm doing it because I am interested in doing it.   I'm
>>> not sure that we needed a discussion or decision by committee on this.
>> 
>> You can of course always decide what you do privately (and I do the same).
>> IMHO it is a little different when a project is represented.
> 
> Yes, I agree that I should be able to do what I want.  I, however, was
> unaware that I was representing the GNUstep project in this case. I
> never said "we" as a project were working on it or that it was being
> done by the GNUstep project as I didn't feel as though I should do
> that as I don't see myself as having the power to speak for the
> actions of others.  It was, however,  made very clear that I am doing
> it because I feel it is the right thing to do.  While I wasn't
> explicit about it being part of GNUstep I made it clear that it is
> very important to GNUstep on more than a few occasions.
> 
> For the record, I still don't think that it's fair to say that I
> should have asked permission since I already did on the list months
> ago.  So, I'm, frankly confused, but this discussion, however, is
> unproductive.
> 
>>> Here was the announcement of our position, which I shared with the
>>> list:
>>> 
>>> http://heronsperch.blogspot.com/2014/06/gnusteps-position-on-swift.html
>> 
>> I apparently missed that. Wetware shows exponential decay of information.
>> Unless it is refreshed regularily… This is what we engineers tend to leave
>> to “marketing people”.
> 
> LOL, indeed.
> 
>>> 
>>>> It looks like a “I, GC” project rather than a “we, GNUstep”. So you should 
>>>> not
>>>> be astonished about some reactions here.
>>> 
>>> Seriously?  And here I was under the impression that when I say
>>> something is for this project, then it is.  What other reason would I
>>> have for doing it?   We have soooo much stuff in our repository, does
>>> it seem appropriate to put a compiler in there as well?  I mean if you
>>> guys think it's appropriate to put it there on top of everything else,
>>> I certainly can if that would make you feel more comfortable.  I know
>>> that it would facilitate people helping me with it as we wouldn't have
>>> to go through the issues of adding people to the repo at
>>> source.ind.ie.
>> 
>> That is indeed an argument to make it part of GNUstep. Almost nobody
>> knows these ind.ie activities - while GNUstep is known (I don’t know the
>> number of subscribers on this list but it must be many).
> 
> I will place a copy in the GNUstep repo, in that case.
> 
>>> 
>>> I am, honestly, astonished with how good intentions can be stretched
>>> and distorted by others to be something else.    What I don't
>>> understand, quite frankly, is that when I first joined this project
>> 
>> which project are you talking about? GNUstep or Phoenix?
> 
> The GNUstep project as we are on the GNUstep list. :)
> 
>>> we
>>> were all very much in the spirit of doing things that we enjoyed.
>>> Lately it seems like everyone has to go through committee and I have
>>> to tell you I'm getting very very tired of that approach.  Mainly
>>> because it hasn’t worked very well for us.
>> 
>> My POV on this is that it does not need a committee but developers who
>> tell the group (represented e.g. by the gnustep lists) what they plan to do
>> and why - (but only if they want help and support from the community).
>> 
>> And listen to comments and suggestions from peers. This is not a decision
>> committee (which is IMHO only needed if it is about distributing money).
> 
> Agreed with respect to the money part.
> 
>> But a lively community.
>> 
>> Riccardo, Fred and myself did have several such workshops (and sometimes
>> others joined as well). These were very fruitful moves forward.
> 
> I heard about the workshops.   Very cool.
> 
>> Call this team a “development committee” instead of “decision committee”
>> and it has worked very well for us (and fixed many bugs).
> 
> As far as I'm aware I was telling people what I planned to do and why.
> This is why I posted to the list.  The fact that no one objected led
> me to believe that no one had a problem with it.
> 
>> <ignore>
> <DELETED SINCE IGNORING IT WAS REQUESTED>
>> </ignore>
>> 
>>> [snipped]
>>>>> Swift, as I see it, is important for our future.  Also, I wasn't sure
>>>>> if it was a good idea to put it into GNUstep's repo.  I may still put
>>>>> a version of it there if needed.
>>>> 
>>>> This makes me even more puzzled. Are there two versions planned?
>>> 
>>> I can have the same code in two places.   This is not a new concept.
>>> 
>>>> Anyways it is a good initiative.
>>> 
>>> Thanks, at least one thing positive here.
>> 
>> Let me add some more questions to better understand the details of the
>> Phoenix project. So that I am enabled (and maybe others) to positively
>> contribute on the technical side:
>> 
>> * what is the target of the compiler output? I could imagine Obj-C,
>>   Assembler, C++, Java or JavaScript but don’t know.
> 
> Currently it's Objective-C, but I would like to move to LLVM IR.
> 
>> * could you take the AST code from the ObjCKit.framework of mySTEP?
> 
> Yes, I would.  Is it under GPL/LGPL?

Yes, everything of mySTEP is under LGPL (even if not stated explicitly in the
header files).

> 
>> * could you make it compatible to use the same pipeline, i.e. make Phoenix
>>  a frontend for a common AST framework/library and backends?
> 
> Certainly.
> 
>> * what is the rationale to write it in Obj-C if Swift tries to supersede it?
> 
> What other language would you suggest.  I selected Obj-C since it is
> the language I know the best.

Hm. I do not really know what the best solution in such a case would be.

Implementing it in Swift might be an alternative, but reduces the developer
base to people owning Xcode 6.1.

> 
>> * what is the problem with lex/bison (I didn’t understand David’s concerns)?
> 
> The bison/lex parser generator/lexicographical scanner don't generate
> code which is easily reusable and they don't report errors very well.
> This is one of the principal reasons why GCC moved away from using
> bison/lex and why LLVM has never utilized them.    They are certainly
> still useful, but they don't make things much easier in the long run,
> so I understand his objection to it.

Ok, I see.

> 
> The reason I chose it is for two main reasons: 1) I have used bison
> extensively in the past, so I know it very well..

The same for me with the objc-interpreter. So I understand your decision.

>  2) the grammar.y is
> from a project known as swift2js which is a transpiler that compiles
> swift to JS code.  It used a scraper to pull the grammar directly from
> Apple's documentation.  This has the advantage of always being up to
> date and easy to regenerate.
> 
> The alternative to using these technologies is to write a hand-written
> recursive descent parser, which I've also done before when I wrote the
> parser for Gorm.  

SWK jas a JavaScript parser for that purpose and if I remember correctly
mySTEP introduced one for NSExpression and NSPredicate.

> The disadvantage is obvious... it's harder and
> slower and can't be automatically regenerated when/if the language
> changes.

But mightbe more flexible in special cases, e.g. treating whitespace
and newlines as tokens in some sutuations while not in others.

E.g. JavaScript either wants a ; or a newline to end a statement (or both).

BR,
Nikolaus