Re: floating-point-bits

I would say that, at this time, Lisp is on the cusp of a minor software revolution. Lisp was the old school way of doing the right thing. But that is simply not true any more. Much as I dislike Rust, that strongly typed language direction seems to be the way of the coming future. Lisp does not quite support that goal (thankfully!).

But Lisp, today, is very much like Forth once was - a language in which you can do nearly anything you can imagine - even when it demands bending type rules. If Lisp had the ability to drop directly into Assembly language, it could become a clear winner in the scientific community, just like Forth once was during the 16-bit era. Lisp is almost there with LW’s FLI. 




> On Feb 17, 2025, at 09:56, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> Heh! Well I basically agree with your conclusions - but mostly for “programmers” who need to produce libraries or apps for broad consumption.
> 
> I have never been a “programmer”, but rather a scientist who knows how to program and needs immediate results - not for broad consumption but for my own immediate pressing needs. Hence why I first cut my teeth in Forth. 
> 
> And so the effect of the programmers dominating the field is to produce layer upon layer of complexity which impedes those in my camp. My first rude exposure came in the mid 80’s when Apple started doing everything in Pascal and produced a 7 volume manual set describing all the various subsystems. Getting to the usable “bottom” of that pile took enormous effort compared to the simplicity of before.
> 
> I won’t argue the point. The two camps both have legitimate needs. But I am always first concerned with my own.
> 
> - DM
> 
> 
>> On Feb 17, 2025, at 09:37, Tim Bradshaw (as tfb at cley dot com) <[email protected]> wrote:
>> 
>> I think building assumptions about endianness into a language would be a deeply stupid idea.
>> 
>> Any program which, for instance, might want to deal with streams of UTF-16 or UTF-32 data will need to decide whether to move bytes around on a per-stream basis.  Any program which deals with XDR or NetCDF (uses XDR) will almost certainly need to do this on most modern machines.  And people do this so much in C that compilers have support to make it as fast as it can be.  Reinventing those wheels in Lisp seems like, well, reinventing wheels.  I like not to do that.
>> 
>> On 17 Feb 2025, at 15:30, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>>> Byte Order….
>>> 
>>> That was an issue back in 1990. But today, all the processors in my lab speak little-endian (opposite of Standard Network Byte Order). So why do we have endian issues today?
>>> 
>>> Not trying to be facetious here… just a question of progress vs legacy issues.
>>> 
>>> - DM
>>> 
>>> 
>>>> On Feb 17, 2025, at 05:34, Tim Bradshaw <[email protected]> wrote:
>>>> 
>>>> On 15 Feb 2025, at 18:18, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>>>>> So it is confounding that Lisp, for all of its amazing capabilities, has never thought it necessary to represent Union types.
>>>> 
>>>> A general union type is essentially impossible in a language like Lisp: what should the GC do if it meets an object which is a union of, say, a cons and an integer?  What does such a type even mean?
>>>> 
>>>> A specific thing which was essentially an array whose elements could be addressed as some subset of number & character types would probably be possible and would merely expose a great many implementation details (endianness, how floats are represented, &c) which CL does not currently expose.
>>>> 
>>>> If I wanted to fill an array with floats from the network I'd do that in C, handing the guts of the array to a C function to fill and dealwith all the byte order questions.  That's what C is good at.
>>>> 
>>>> --tim
>>> 
>>> 
>>> _______________________________________________
>>> Lisp Hug - the mailing list for LispWorks users
>>> [email protected]
>>> http://www.lispworks.com/support/lisp-hug.html
>> 
>> _______________________________________________
>> Lisp Hug - the mailing list for LispWorks users
>> [email protected]
>> http://www.lispworks.com/support/lisp-hug.html
> 
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html