ooc-dev team mailing list archive

[Marc Calaway <walker_tejas_ranger@xxxxxxxx>]

Of course it'd be a chance to clean up code. But I don't see any reason why to allow it for everyday, pure ooc-code.
That's what I mean by "FFI". It should be restricted to a very small part of the language. Automatic translation in larger projects... I better prepare my pipe bombs.

"It's not a feature, it's a bug!"

--- Amos Wenger <amoswenger@xxxxxxxxx> schrieb am Sa, 7.8.2010:

Von: Amos Wenger <amoswenger@xxxxxxxxx>
Betreff: Re: [Ooc-dev] [ooc-dev] "Implicit As"
An: "Marc Calaway" <walker_tejas_ranger@xxxxxxxx>
CC: ooc-dev@xxxxxxxxxxxxxxxxxxx
Datum: Samstag, 7. August, 2010 17:12 Uhr

Hey there, good to finally have you on the mailing list there
So the 'translation' (e.g. replacing s by s data) doesn't seem too bad to me. In fact, that's how I had planned to implement it in the beginning.


And by FFI I'm not exactly sure what you mean. Do you want to create 'wrapper' for C functions, ie. if it takes a 'char*' there's a variant that can also take a String? That sounds a lot messier than the 'translation' alternative imho. And generates more code, too.


The main use of "implicit as" I currently see is precisely this char* vs String matter. But in the future it might be useful with other bindings.
If it is used irresponsibly by users it might lead to a mess. But what are the alternatives? Manually converting types / calling conversion functions, etc.? Don't think so.


With every feature we give to users, we give them a chance to mess up - but also an opportunity to write cleaner code. When well used, implicit as is very useful imho.
In the docs, we might add this piece of advice: "'implicit as' is designed as a facility for interfacing with foreign code. It's probably a wrong solution for many other problems."


ndd
On Sat, Aug 7, 2010 at 6:41 PM, Marc Calaway <walker_tejas_ranger@xxxxxxxx> wrote:


Hey there,



I'd like to suggest some possibilities to the so-called "implicit-as". Background is the migration to a String-class from plain `Char*`.

However, since C is our core backend language, interoperability is an important factor.

rofl0r wanted to have an automatic translation when one passes a String-class object to an external C function

expecting a Char*.

(The actual implementation of String is not important right now.)



In code (ooc):

   String: class {size: SizeT; data: Char*} // or whatever

   a := "hello, world" // Of type "String"

   puts: extern func(Char*)

   puts(a)



What's the matter? Well, String won't be a 'Cover' anymore, so one can't pass a String when a Char*'s expected.



The translation process itself would consist of a simple replacement:

   puts(a)

becomes

   puts(a data)



As you can see, the user would not have to do this manually.

Issue's now how to achieve this goal. First, there was the idea to do it as an operator.

   operator implicit as (s: String) -> Char* { s data }



Well, that doesn't make much sense. It's not an action where a operator takes place. In fact, you can't see it at all, it'd be invisible.

In my opinion, an operator is always some sort of literal as in "+, -, ++, ..."



Another alternative would be the introduction of a new keyword, e.g. "otherwise" (don't get me on the naming).

   String: class { size: SizeT; otherwise data : Char* } // more pseudo code, yes...



The problem right here is to figure out when to fall back to the "otherwise"-case.

"Just when an extern function expects a Char*" you might think. But that's a special case then. We'd introduce new syntax pollution for a very special case. That's wasted grammar, it needs to be more general.





There has to be a way to clearly say on which context a translation should take place.

   String: class { size: SizeT; data: Char*; context { String: this; Char*: data }}



(Yes, context is a very bad keyword, it's just used for this presentation.)

Harhar, now let's destroy this one.

First, it works around rock's type-system. Kay, we often do in rock itself, but never in user-code.

Q: Why this?

A: Simply because the `context` section is not translated to C. It's not checked during runtime but all handled

during the process of compilation. It's an annotation.



By itself, not a too bad idea, but it makes the language and larger sources a lot more difficult to understand.

"Yay, we're passing an object of type A to a function which expects a... oh wtf - it wants to have type Z"

You can imagine the rest, and some very clever people already wrote a lot about this case. They called that source of evil C++.



Automatic transformation into another type is a ***very***, ******very******* sharp sword. Too dangerous to be given

to the user.

"But didn't you say the "implicit-as" has to be general?" Yep, I did. And I'm coming to the conclusion that this not

completely right. FFI is the magic word. We don't need the transformation in pure ooc-code but just when interfacing

foreign code.

My suggestion is to introduce some sort of API which handles these cases - just for cases when interfacing with C.

It'd be done as a way of compiler annotation.



I don't give any source here because I have no idea what's the best way to do this. That's why I'm asking YOU, (yes I'm lookign right at you)

to put your opinion on the ML.



Does "implicit-as" makes sense at all?

Should it be used in everyday ooc?

Are annotation the right way to do this?

Do we need a special FFI to C?



BTW: This is not my work alone, I tried to summarize rofl0r's main idea and added suggestions on how to achieve it.



Cheers,



Yannic (showstopper)