Functional Developer UNICODE support + source? 
Author Message
 Functional Developer UNICODE support + source?

Hi,
Just wondering if anyone knows whether the next version of FD
will have real UNICODE support?  (will there be a next version?)
IMO it's basically crippled for serious development work as it
is at the moment.

Also half the source seems to be missing so I can't create my own
CFFI win32 libraries automatically like they do, or look into the
various libraries for examples.  Does anyone know if all the source
is available, not just bits of it?

Thanks,
Mark Jordan.



Sat, 10 Jan 2004 10:47:55 GMT  
 Functional Developer UNICODE support + source?

Quote:

> Just wondering if anyone knows whether the next version of FD will
> have real UNICODE support?  (will there be a next version?)  IMO
> it's basically crippled for serious development work as it is at the
> moment.

That would be 'serious development that requires unicode' I guess. I
use it for non-unicode serious development without difficulty.

Quote:
> Also half the source seems to be missing so I can't create my own
> CFFI win32 libraries automatically like they do, or look into the
> various libraries for examples.  Does anyone know if all the source
> is available, not just bits of it?

I don't think they include the .h -> .dylan c-ffi generator. You could
perhaps look at pidgin from Gwydion Dylan which was written to perform
this purpose. Don't know what stage it is at though.

What particular libraries were you looking for the source for? There's
quite a bit in there but not everything as you note.

Chris.
--
http://www.double.co.nz/dylan



Sat, 10 Jan 2004 05:19:51 GMT  
 Functional Developer UNICODE support + source?
On Mon, 23 Jul 2001 15:00:05 -0400 (EDT), "Mark Jordan"

Quote:

> Hi,
> Just wondering if anyone knows whether the next version of FD
> will have real UNICODE support?  (will there be a next version?)
> IMO it's basically crippled for serious development work as it
> is at the moment.

> Also half the source seems to be missing so I can't create my own
> CFFI win32 libraries automatically like they do, or look into the
> various libraries for examples.  Does anyone know if all the source
> is available, not just bits of it?

The FFI builder that Fun'O use is a bit of a kludge. It is a glorified
pattern matcher (written by David Gray) which is cajoled by impenetrable
runes to perform its tasks. Rather than release, and support this kludge I
think the plan is to develop or encourage the development of a proper
parsing tool.

Many of the libraries are open source (even the editor), but key components
like the compiler and IDE are currently close source.

__Jason



Sat, 10 Jan 2004 16:42:15 GMT  
 Functional Developer UNICODE support + source?

Quote:
> On Mon, 23 Jul 2001 15:00:05 -0400 (EDT), "Mark Jordan"

> > Hi,
> > Just wondering if anyone knows whether the next version of FD
> > will have real UNICODE support?  (will there be a next version?)
> > IMO it's basically crippled for serious development work as it
> > is at the moment.

> > Also half the source seems to be missing so I can't create my own
> > CFFI win32 libraries automatically like they do, or look into the
> > various libraries for examples.  Does anyone know if all the source
> > is available, not just bits of it?

> The FFI builder that Fun'O use is a bit of a kludge. It is a glorified
> pattern matcher (written by David Gray) which is cajoled by impenetrable
> runes to perform its tasks. Rather than release, and support this kludge I
> think the plan is to develop or encourage the development of a proper
> parsing tool.

Hi Jason,
Aaaahhh, so it uses good old Gemma. I use it and don't find the
rules to be that difficult. I wrote a assembly language translator
for x86 to MSP430 micro using it for Borland C++.

I'd ask for the rules, but the complex job of writing Dylan CFFI's and
no unicode has put me off using Dylan at all. What I really need is
a CPPFFI to interface to existing C++ class libraries.  Any ideas on
how this might be done?

Quote:
> Many of the libraries are open source (even the editor), but key components
> like the compiler and IDE are currently close source.

I couldn't see the source anywhere for the math library. I don't care
what licence you have, I just wanted to look inside to see how
things work to get a better understanding of things when the docs
let me down.

Cheers,
Mark Jordan.



Sun, 11 Jan 2004 09:48:51 GMT  
 Functional Developer UNICODE support + source?
On Tue, 24 Jul 2001 18:48:51 -0700, "Mark Jordan"

Quote:

>I'd ask for the rules, but the complex job of writing Dylan CFFI's and
>no unicode has put me off using Dylan at all. What I really need is
>a CPPFFI to interface to existing C++ class libraries.  Any ideas on
>how this might be done?

We're definitely aware that the lack of unicode is a big hole that's
high priority to fix.  As is C++ support -- the recommended approach
is to use COM.  It's not ideal, but direct C++ interoperability is
really an impossible problem for any language that's not C.

Gail Zacharias
gz -at- functionalobjects.com



Sun, 11 Jan 2004 07:16:07 GMT  
 Functional Developer UNICODE support + source?

Quote:

> On Tue, 24 Jul 2001 18:48:51 -0700, "Mark Jordan"

> >I'd ask for the rules, but the complex job of writing Dylan CFFI's and
> >no unicode has put me off using Dylan at all. What I really need is
> >a CPPFFI to interface to existing C++ class libraries.  Any ideas on
> >how this might be done?

> We're definitely aware that the lack of unicode is a big hole that's
> high priority to fix.  As is C++ support -- the recommended approach
> is to use COM.  It's not ideal, but direct C++ interoperability is
> really an impossible problem for any language that's not C.

Some other approaches to Dylan-C++ integration are:

        create a C interface via extern C
        and use the C FFI

        CORBA

        COM

Then of course there are shared files, shared dbs, sockets, etc.

__Jason



Sun, 11 Jan 2004 17:02:38 GMT  
 Functional Developer UNICODE support + source?

Quote:

> I'd ask for the rules, but the complex job of writing Dylan CFFI's and
> no unicode has put me off using Dylan at all. What I really need is
> a CPPFFI to interface to existing C++ class libraries.  Any ideas on
> how this might be done?

C++ compiler manufacturers would need to agree on common name mangling,
vtable layout and exception handling conventions and they'd then all
need to implement them. This would allow C++ code compiled with
different versions of the same compiler, or C++ compilers from different
vendors, to call C++ code that isn't statically compiled into the same
compilation unit. It would then be relatively trivial to allow other
languages to join the party.
Gwydion Dylan was used on BeOS to call the BeOS C++ frameworks through C
wrappers. This really is the only non-COM, non-magic way of calling C++
code from *any* language.

Gwydion Dylan has Unicode support and a utility that parses C header
files and generates Dylan wrappers (well, its own C-FFI, but
Fun-Dev-style C-FFI support is coming). I've written Dylan C wrappers
for the Mac Toolbox in GD by hand. It's doable (but a header parser is
more fun :-) ).

- Rob.

--
"The idea behind Dylanto offer a range of dynamism appropriate to each
piece of an applicationfeels right, and after using Dylan you will
become frustrated with C++ and Java."
- Peter Norvig, Software Developer Magazine.



Sun, 11 Jan 2004 23:27:43 GMT  
 Functional Developer UNICODE support + source?

Quote:


> > I'd ask for the rules, but the complex job of writing Dylan CFFI's and
> > no unicode has put me off using Dylan at all. What I really need is
> > a CPPFFI to interface to existing C++ class libraries.  Any ideas on
> > how this might be done?

> C++ compiler manufacturers would need to agree on common name mangling,
> vtable layout and exception handling conventions and they'd then all
> need to implement them. This would allow C++ code compiled with
> different versions of the same compiler, or C++ compilers from different
> vendors, to call C++ code that isn't statically compiled into the same
> compilation unit. It would then be relatively trivial to allow other
> languages to join the party.
> Gwydion Dylan was used on BeOS to call the BeOS C++ frameworks through C
> wrappers. This really is the only non-COM, non-magic way of calling C++
> code from *any* language.

BTW In the absence of such a standard Microsoft's COM and IBM's SOM
(pre-CORBA ORB) were solutions to calling C++ libraries from other
languages and other C++ compilers. So COM and CORBA really are the industry
standard approaches. However if all you have is a C++ library at the moment
you need to wrap it up in some COM or CORBA machinery. Perhaps there are
C++ IDEs which will wizard that for you?

__Jason



Sun, 11 Jan 2004 23:38:59 GMT  
 Functional Developer UNICODE support + source?
On Wed, 25 Jul 2001 17:44:55 +0100, Keith Playford

Quote:

> I've never used it myself, but check out SWIG at http://www.*-*-*.com/

>   SWIG is an interface compiler that connects programs written in C,
>   C++, and Objective-C with scripting languages including Perl,
>   Python, and Tcl/Tk. It works by taking the declarations commonly
>   found in C/C++ header files and using them to generate the glue code
>   (wrappers) that scripting languages need to access the underlying
>   C/C++ code.

> Someone would need to write a Dylan FFI back-end for it, however.

> Things like this usually work around the lack of a common C++ ABI by
> generating C {*filter*}oline functions and interfacing to those instead
> (one implication being that you need a C++ compiler to compile the
> glue).

Hi Keith,

I'm sure I've posted almost exactly this same SWIG reference before to this
list...

__Jason



Mon, 12 Jan 2004 01:04:37 GMT  
 Functional Developer UNICODE support + source?

Quote:


> > I'd ask for the rules, but the complex job of writing Dylan CFFI's and
> > no unicode has put me off using Dylan at all. What I really need is
> > a CPPFFI to interface to existing C++ class libraries.  Any ideas on
> > how this might be done?

> C++ compiler manufacturers would need to agree on common name
> mangling, vtable layout and exception handling conventions and they'd
> then all need to implement them. This would allow C++ code compiled
> with different versions of the same compiler, or C++ compilers from
> different vendors, to call C++ code that isn't statically compiled
> into the same compilation unit. It would then be relatively trivial to
> allow other languages to join the party.

As I understand it, C++ (either by standard or methodology) actually
_encourages_ the divergence of mangling techniques per vendor, so as
to render such an idea virtually useless (or at least very hard and
C++ vendor specific).  I heard this second-hand, so I don't know if
it is common practice or actually mentioned in the C++ standard.  The
rationale is apparently that disparate mangling would reduce the
chance of a name clash between vendors (not that I've ever heard of
any two C++ vendors linking programs together :-).

So in the CL world we speak to C++ as directly as possible by their
only real direct interface: extern "C", or indirectly through COM,
Corba, etc.

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704



Mon, 12 Jan 2004 00:31:12 GMT  
 Functional Developer UNICODE support + source?
I've never used it myself, but check out SWIG at http://www.*-*-*.com/

  SWIG is an interface compiler that connects programs written in C,
  C++, and Objective-C with scripting languages including Perl,
  Python, and Tcl/Tk. It works by taking the declarations commonly
  found in C/C++ header files and using them to generate the glue code
  (wrappers) that scripting languages need to access the underlying
  C/C++ code.

Someone would need to write a Dylan FFI back-end for it, however.

Things like this usually work around the lack of a common C++ ABI by
generating C {*filter*}oline functions and interfacing to those instead
(one implication being that you need a C++ compiler to compile the
glue).

-- Keith



Mon, 12 Jan 2004 00:53:57 GMT  
 Functional Developer UNICODE support + source?

Quote:

> On Tue, 24 Jul 2001 18:48:51 -0700, "Mark Jordan"

> >I'd ask for the rules, but the complex job of writing Dylan CFFI's and
> >no unicode has put me off using Dylan at all. What I really need is
> >a CPPFFI to interface to existing C++ class libraries.  Any ideas on
> >how this might be done?

> We're definitely aware that the lack of unicode is a big hole that's
> high priority to fix.  As is C++ support -- the recommended approach
> is to use COM.  It's not ideal, but direct C++ interoperability is
> really an impossible problem for any language that's not C.

Gail,
Good to hear you're onto the UNICODE problem. I hadn't
thought of the COM approach, I'll mull over it some ;-)

It would be cool to be able to compile C header files into dylan
interface libraries automatically. It would be even cooler to compile
C++ header files into dylan interface libraries, but I guess the differences
are probably a bit much. IBM's SOM might have been useful
since it supported inheritance, unlike COM.

Cheers,
Mark.



Mon, 12 Jan 2004 11:37:29 GMT  
 Functional Developer UNICODE support + source?

Quote:
> I'm sure I've posted almost exactly this same SWIG reference before to this
> list...

As did Bryn Keller earlier today in the multimethods thread I see.
I sure hope someone takes the hint soon. ;)

-- Keith



Mon, 12 Jan 2004 04:08:03 GMT  
 Functional Developer UNICODE support + source?

Quote:

> Someone would need to write a Dylan FFI back-end for it, however.

 Alternatively some effort could be devoted to finish pidgin.

Quote:
> Things like this usually work around the lack of a common C++ ABI by
> generating C {*filter*}oline functions and interfacing to those instead
> (one implication being that you need a C++ compiler to compile the
> glue).


at least on HP-UX & Linux systems:

    http://www.*-*-*.com/

 Given that this ABI is implemented by GCC 3.0 (maybe with some warts[*]),
I would expect some of it to extend beyond ia64. I do not know whether
non-Unix platform or other Unix vendors will follow it on Itanium.

 Last time I looked, the exception handling mechanism had provisions
for cross-language barriers exceptions and language-specific handling.
I think even resumptive exceptions were possible (I had asked a colleague
who worked on it), but likely limited by cross-language calls.

 Regards - Eric

[*] Funny thing, I was thinking about this very issue, and this is the
   first mail I look at:

http://www.*-*-*.com/ :mss:1319:200107:mfjpjfmcohlpfccgmggc
-----
However, this will *not* work on IA64 in the long-term because
it will use function-descriptors, not function-pointers, in the
vtable.  (GCC doesn't do this, yet.)
-----



Mon, 12 Jan 2004 13:44:28 GMT  
 Functional Developer UNICODE support + source?

Quote:


> > C++ compiler manufacturers would need to agree on common name
> > mangling, vtable layout and exception handling conventions and they'd
> > then all need to implement them. This would allow C++ code compiled
> > with different versions of the same compiler, or C++ compilers from
> > different vendors, to call C++ code that isn't statically compiled
> > into the same compilation unit. It would then be relatively trivial to
> > allow other languages to join the party.

> As I understand it, C++ (either by standard or methodology) actually
> _encourages_ the divergence of mangling techniques per vendor, so as
> to render such an idea virtually useless (or at least very hard and
> C++ vendor specific).  I heard this second-hand, so I don't know if
> it is common practice or actually mentioned in the C++ standard.  The
> rationale is apparently that disparate mangling would reduce the
> chance of a name clash between vendors (not that I've ever heard of
> any two C++ vendors linking programs together :-).

 And have you ever heard of two CL / Dylan / Scheme / ... vendors
linking programs together ? :-(

 The lack of a common C++ name-mangling scheme is indeed
a blessing until a common ABI emerges. And the absence of an early
ABI can also be seen as a blessing, since it allowed some alternative
implementation techniques to be developped over the years before the
standardisation effort started.

 Example:
 "zero-cost" exception handling schemes are only now becoming the norm,
and those would have been hindered by earlier ABI standards.
(Now whether they are a blessing or a curse is another debate :-). )

Quote:
> So in the CL world we speak to C++ as directly as possible by their
> only real direct interface: extern "C", or indirectly through COM,
> Corba, etc.

 The "no-ABI" era may be slowly coming to an end. Cf.
http://www.codesourcery.com/cxx-abi/ and another message from me
in the same thread.

 Good to have you posting in this newsgroup. I appreciate your postings
in comp.arch. I only wish it meant Franz were interested in Dylan...

 Regards - Eric



Mon, 12 Jan 2004 13:49:51 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Q: Unicode support for text edit control? (D5)

2. APL2 support for Unicode

3. UNICODE support

4. CW 2.0 and unicode support

5. CW2 and unicode support ?

6. Dylan to support Unicode?

7. Dylan to support Unicode?

8. ruby unicode./encoding support

9. scheme implementations that support unicode

10. ANN: Native Unicode support in Pocket Scheme

11. Unicode supported by Object Ada 7.0 ?

12. Unicode support

 

 
Powered by phpBB® Forum Software