RE: Bliss update
-------Phoenix-Boundary-07081998-
Hi Kat, you wrote on 8/2/02 5:11:41 PM:
>> An interesting possibility is to overload 'find' on the number
>> of parameters and have both:
>> find (item, seq)
>> and:
>> find (item, seq, start)
>>
>> Sound good=3F or bad=3F
>
>Sounds good, in a way. I think this may lead to a little confusion. I
>would use find(item,seq) and find_from(item,seq). I considered doing
>something like that in strtok-v2, but i decided to nest some
> parameters, and change the name of case-insensitive functions.
>
I like the overloaded function foe several reasons.
1) The overloading is actually more like an optional parameter
The 'real' function is find(i,s,start), but the start may be
omitted for compatibility with Euphoria.
2) It is easier for me to remember a single function name.
3) It is easier to implement (less code, smaller symbol table)
>> 1) Overload methods on # of parameters
>
>Hmmmm
>
The primary use is to allow multiple instance initializers
('new' methods).
>
> 5) Reseller license
>
>How about lower price for source=3F
>
I havn't really considered offering source code. If I were to offer
source code like Rob, the purchaser would have to purchase 2 sets
of code -- gets pretty expensive. I was thinking that if a user
wished to offer a commercial application using Bach, I could
provide a way for the user to 'piggy-back' on my licensing
arrangement.
> 7) Interfaces to IUP, SQLite, and TCP4u
>
>As much as i use tcp4u, i suggest you do NOT interface to it, for 5
>reasons:
>1) needs tcp4u.dll
>2) the tcp4u.ew is not fixed
>3) tcp4u is blocking
>4) there are more options in using the api calls, and tcp4u uses only a
> few of them.
>5) I'd like to see all the internet functions in winsock, and whatever dos
>uses (Trumpet=3F), and linux, made available in the core Eu, transparently
to
> the programmer, so a call in Euphoria on *nix or dos or win95 gives the
> same results.
Yes, but I probably will not offer a Dos version, and *nix is probably
far on the future. I know nothing about the world of TCP, so I'm open
to suggestions
> Ever look at Rebol=3F
Only very briefly. It may very well be that Internet things are
handled so well by languages like Rebol that there is little point
in putting too much support into Bach. I shall learn, eventually.
>>
>> 8) Buit-in extract(seq, index)
>>
>That's a string function, yes=3F Nested "string" function=3F I don't know
>if it is worth mentioning, but i was going to make *one* .ew for
>string functions, since i use them, and have to watch what i include
>for nearly every program. If you include string functions, may i
>suggest we discuss strtok also=3F, it's just as valid a lib. I suspect
>you will have more applications where several layers of processing
>are needed before you get to the point of using mid_str().
>
The issue is what sequence primitives should be included. Rob has
chosen a minimalist set, which I am inclined to enlarge. I would
envision that a library for string and sequence manipulation
still would be needed -- What primitives would most help in the
creation of that library=3F
>> 9) Build in PCRE
>>
>Who=3F What=3F
Perl Compatible Regular Expressions is a comprehensive and
powerful way to deal with the myriad ways we want to process
strings.
Some time ago I submitted a Euphoria library to interface with
the PCRE dll. I recently ran a benchmark comparing the speed
of PCRE versus a Euphoria string library (yours=3F). The result
was pretty even, though I would expect that PCRE would get
better as the test got larger. I hope that embedding
PCRE into Bach might produce a clear advantage.
Note that PCRE only deals with strings -- more complex
sequences still require find() etc.
Karl Bochert
-------Phoenix-Boundary-07081998---
|
Not Categorized, Please Help
|
|
